Source – jaxenter.com
Enterprises are increasingly turning to a microservice architecture for new applications to achieve greater agility and scalability, and the software industry is supporting them with development frameworks and tools for creating microservices. Yet, these don’t operate in a vacuum and often require an effective approach to integration.
The challenge is that building integration logic from scratch at the microservices layer is essentially reinventing the wheel while adding a traditional integration layer defeats some key objectives of a fully distributed microservice model. What’s needed instead are new solutions designed specifically to handle integration microservices.
Working with various enterprises, we’ve seen the common challenges they face when integrating microservices. First, let’s understand why traditional integration approaches fall short and then explore the need for a new approach centered around integration microservices.
A typical organization has backend systems and a centralized services bus layer, usually via an enterprise service bus (ESB), which channels all integration logic and is governed by a centralized team. Because it enables a standard way to publish any integration logic and a single place to update changes to the backend systems, the enterprise can minimize complexity and optimize performance. This works well for service-oriented architectures, but a traditional ESB has a comparatively large footprint and takes too long to start up to support the leaner, distributed nature of microservices.
Recognizing that ESBs are not a fit for microservices, some developers are either building integration into the microservices or relying on APIs to integrate them. Yet, these approaches fail to provide some important reusable constructs offered by ESBs, such as pre-built connectors, integration templates and patterns, mediation, and transformation logic. To be clear, APIs are central to a microservice architecture, but they are not a workaround for integration requirements.
Integration Microservices refines your approach to integration
A better alternative is an integration microservice approach where conventional microservices and integration microservices interact with each other. This enables developers to utilize integration microservices for mediation, transformations and other integration functions for services or to compose multiple services into a single service.
Essentially, an integration microservice helps to leverage the essentials of microservices and add these to the integration layer. These integration microservices can be considered as a mini-services layer for composite services linking or chaining multiple fine-grained backend systems, as well as transforming and/or connecting to cloud systems, as shown in Figure 1.
Figure 1: A reference model for integration microservices
Moreover, an integration microservice approach gives development teams greater flexibility and end-to-end responsibility of their code. This means the same (small) team can be tasked with the creation of core services and composite services, database handling, integration logic, cloud connectivity, protocol transformation, user experience (UX) development, etc.
The architecture described here is best supported by a programming language that enables developers to build lean, microservice-style integrations while still using existing integration concepts—such as connectors, service chaining, and routing—when writing a new service.
As a programming language versus a highly specialized configuration language, it provides the added benefit of being intuitive for developers while naturally being compatible with development tools.
Ideally, to cater to today’s demand for citizen and ad-hoc integrators, it should also provide a visually intuitive interface, possibly replacing traditional data flow-driven approaches with a more visual tool that ensures parity between the visual model and the programming model. A much more understandable approach, such as sequence diagrams, would be applicable here.
For instance, a microservice that exposes customer information might need to connect to Salesforce, meaning the developer must build a connector or call a set of APIs. In another scenario, there might be a difference between the incoming message XML format and what the backend system expects. For such integration scenarios, it may be possible to build reusable integration logic into each service. However, only through a separate integration microservice layer can developers ensure scalability—not only in terms of time, effort and cost, but also in terms of re-work and maintaining the dependencies of libraries.
As leaner, agile, DevOps-based, distributed, and microservice-style development becomes the preferred go-to technology model, developers have struggled to find the right approach to integration. An integration microservice approach promises to provide the missing link with its ability to tackle integration challenges in a highly scalable manner while providing the agility to meet evolving requirements.
