Blind Bird Special: Register until July 3 and save €300!

Blog

iSAQB Software Architecture Gathering 2025​

Dr Annegret Junker
Dr. Annegret Junker
Passionate Lead Architect
Published On
September 1, 2021

Integration Architectures in a Microservice World: An Article by Dr. Annegret Junker

Integration architectures are the key to modern applications in hybrid cloud environments or even in mixed hybrid cloud and classic environments. Moreover, such architectures change constantly because of technology transformations and the requirement to adapt to market changes quite fast. It requires from the architectural side, to implement highly flexible and adaptable components. Those can react on changes without jeopardizing the entire system.
Integration Architectures
Integration architectures are the glue to the components and modules which are creating an entire enterprise application. Integration architecture changes with cross-platform requirements and other development paradigms.[1] Imagine an insurance company build up by operational system, sales, claims system, but even human resources, accounting, purchasing etc. as well. Such a company with all those fine meshes needs to rely on its integration architecture, so that introducing new software or even substitutions of already existing software don’t jeopardize the entire system. The samples in this paper concentrate on the areas sales, operations and claims to keep understandability of the complex subject.

Integration architectures take over responsibility for data flows and interfaces, so that data flows along the single components and modules are visible along the whole application environment. Different architectural styles have been developed over the time, some of them are explained in the next paragraphs.

Peer to Peer Integrations
Peer to peer integration is the simplest way of integration architectures (see Figure 1). It is simple to setup, but in the follow, it leads to growing complexity and bad maintainability. Each point in the application environment is connected to each other point. Those application points are usually quite large, because each additional point would mean a growth of connections and insofar complexity increasing.

Figure 1 Peer to peer integration of domains

Figure 1 Peer to peer integration of domains

Enterprise Service Bus
Enterprise Service Bus components were developed as integration architecture. It promised to connect all applications of an enterprise by one bus. This central promise wasn’t kept. An Enterprise Service Bus requires a common domain model throughout the entire enterprise. Such a model is too large, too inflexible, and too powerful. It cannot be enforced and maintained in the entire enterprise. Even in smaller enterprises, such model cannot be enforced, because sales will have a different point of view to a customer as accounting in every case.

Figure 2 Enterprise Service Bus as integration architecture of domains

Figure 2 Enterprise Service Bus as integration architecture of domains

Microservices
If you define domain objects per domain and a service for each of them, then you get microservices. They can be defined separately and be implemented separately. Those objects are defined per domain specifically and not throughout the entire enterprise. E.g., the customer object is defined for the sales domain specifically and the contract object for operations. But it is necessary to exchange data between those domains. Insofar we need even more a suitable integration architecture.

Figure 3 Integration architecture and Microservices

Figure 3 Integration architecture and Microservices

Figure 3 shows a typical microservice architecture and corresponding integration components.

The single domains are represented by multiple microservices. Those microservices represent different domain object e.g., in the sales domain Prospect and Offer. Different integration components such as service mesh and event bus allow to exchange data, even though different services own different interpretation of domain objects e.g., prospect in sales area and customer in operations domain. How such an integration could work will be explained in the next chapter.

Integration Scenarios for Microservices
API Management
API Management describes the creation and publishing process of Application Programming Interfaces (API). It enforces usage policies, controls access, collects and analyzes usage statistics, nurtures subscriber community, and creates performance reports.[2] An API Management tool is built up by a gateway, publishing tools, a developer portal, and report and analyzing tools. Additionally, tools for billing tools available, which allows monetarizing of the API usage.

API Management scenarios allow single microservices to publish REST APIs for the corresponding domain object e.g., a prospect in the sales area. Those domain objects are available to other microservices. Comparable to a façade, the implementation details are hidden behind the API.

Service Mesh A service mesh is a dedicated infrastructure layer, to support service to service communications between microservices. To do so the sidecar pattern is used as a service proxy.[3] The sidecar takes over the responsibility to make the service accessible and to access other services. A central component monitors, logs, and inspection of the network communication.
Eventing
Eventing means here the producing and consuming of events. Those events contain immutable objects, which are used for data exchange. Events can be “true” events. Which means something has happened and the result is contained in the event — e.g., a changed contract. But it might be a command as well e.g., the creation of a contract.

Hybrid Environments
The presented integration scenarios – peer-to-peer integrations, integrations with Enterprise Service Busses or service meshes with microservices – exist in typical enterprise environments in parallel today. So, what can one do, when new applications are introduced, or old applications are substituted? How can one guarantee that the enterprise environment doesn’t become more complex and insofar not controllable anymore? The presented integration scenarios for microservices can be used in hybrid environments as well. There appear north-south and west-east communication. North-south communication is a communication from frontend applications to classical backend applications. Whereas west-east communication is the communication between typical enterprise applications.

Figure 4 Hybrid integration architecture with different communications

Figure 4 Hybrid integration architecture with different communications

To support hybrid architectures, events are used for east-west communication. API calls are defined for north-south communication. In both cases, the communication needs to be supported by well-defined interfaces. But in the different domains, interface models can be defined independent from each other. If a communication between domains is necessary — e.g., when an offer becomes a contract — an enterprise alignment is necessary. But such an alignment is the exception and not the rule. For legacy applications, adapters are implemented. Those adapters support the target architecture already (see Figure 4, marked green). To do so, API adapter as well as event adapter are necessary. So, the legacy applications can be substituted step by step without jeopardizing those applications which are following the target architecture already. Using such an approach, modern architectures can be reached even by migration architectures.

Summary
Integration architectures allow different services out of different domains to exchange data.

Integration architectures are provided by REST APIs in north-south communications and by events in west-east communications.

For REST APIs, provider as well as consumer of such APIs are supported by API management tools.

Events allow flexible and highly decoupled architectures, which complements the communication via APIs.

In hybrid migration architectures, modern integration architectures can be supported by introducing adapters for legacy applications, which support the target architecture and hide the legacy application behind a façade.

[1] N.N. Integration Architecture, https://www.techopedia.com/definition/30625/integration-architecture, retrieved 26.08.2021

[2] Wikipedia: API Management, 4.11.2020, https://en.wikipedia.org/wiki/API_management, abgerufen 30.08.2021

[3] Junker, A.: Lösungsmuster für Cross-Cutting-Concerns, 30. Juni 2020,  https://www.informatik-aktuell.de/entwicklung/methoden/loesungsmuster-fuer-cross-cutting-concerns-in-microservices.html#c32075, retrieved 31.8.2021

Session by Annegret Junker:

Event driven architecture @Allianz Advisory

Return to Blog Home Page
Stay up-to-date with the SAG newsletter
Stay up-to-date with the SAG newsletter
SAG-Logo-2024-rgb-500x170-transparent

The Software Architecture Gathering is presented by iSAQB in cooperation with heise.

Linkedin
Become A Sponsor

Sponsoring a conference is a terrific way to support and connect with our global community of software architects.

Learn More
Useful Links