Blog Series | Agile Integration | #3
With a Distributed Integration Platform & Integration Frameworks to more Agility
Author: Oliver Faust
Integrations are classically implemented through centralized, monolithic Enterprise Service Bus (ESB), which can often become a bottleneck (see Rethink your integration strategy)). Today, more agility is needed. Agile integration solutions offer a remedy (see Forms of agile integration - an outline). These used cloud paradigms to have integrations built and operated decentrally by DevOps teams. In this article, we will look at how such a decentralized integration can be implemented with cloud-native microservices.
For distributed development to work optimally in an enterprise environment, it needs a provided integration platform. In this blog, we analyze the implementation using a Distributed Integration Platform (DIP). This DIP provides the foundation and working tools so that integrations can be implemented quickly. Such a platform must provide technical as well as organizational services:
A provided container platform serves as the technical foundation of the platform.
Based on this platform, DevOps teams can develop their integrations independently for the provided container platform (e.g. OpenShift/Kubernetes). The integrations themselves are then developed based on a specific integration framework. There are a variety of such frameworks which are suitable for this purpose. In this blog, we will look at a combination of Quarkus as well as Apache Camel as an example:
Comparing a traditional ESB setup with a microservice-based approach reveals several changes. Figure 1 shows an example of what such a difference might look like. On the one hand, the integration logic is moved to where the integration is needed: in or to the actual applications. On the other hand, the integration responsibility is also shifted. This is no longer centralized with an integration team, but shifts to the applications with integration needs. These organizational changes are also discussed in the blog post 5 Learnings for Agile Integration .
Vergleicht man ein traditionelles ESB Setup mit einem Microservice-basierten Ansatz, so zeigen sich einige Veränderungen. Abbildung 1 zeigt exemplarisch, wie ein solcher Unterschied aussehen kann. Einerseits wird die Integrationslogik dorthin verschoben, wo die Integration nötig ist: in respektive zu den eigentlichen Anwendungen. Andererseits verschiebt sich auch die Integrationsverantwortung. Diese ist nicht mehr zentral bei einem Integrations-Team, sondern verlagert sich zu den Anwendungen mit Integrationsbedarf. Diese organisatorischen Änderungen werden auch im Blogbeitrag 5 Learnings for Agile Integration diskutiert.
This distributed and cloud-native architectural approach also allows integrations as a microservice ...
But what is also true for integration microservices (as well as for microservices in general): the appropriate "cut" is often not so easy to make. The Domain-Driven Design (DDD) approach can help here, in which the modeling is carried out from a functional point of view and thus supports the division of the system into suitable units.
Integration as a microservice is already a reality and thus the integration layer can also benefit from the above-mentioned advantages of a cloud-native microservice architecture. Of course, as with so many architectural decisions, trade-offs must be made. In this case, a trade-off must be made between flexibility and complexity. The application landscape becomes more heterogeneous and resources are needed to build up expertise. Nevertheless, a liberalization of the integration layer takes place, which can contribute to the agility of a company.
#3 | Integration as a Microservice (coming soon)
#4 | Controlled Risks: Agile integration requires automated testing (comming soon)
#5 | Agile Integration made easy with Red Hat (comming soon)