Integration as a Microservice

Autor: Oliver Faust

Integrationen werden klassischerweise durch zentralisierte, monolithische Enterprise Service Bus (ESB) umgesetzt, die oft zum Flaschenhals werden können (siehe Rethink your integration strategy). Heute ist mehr Agilität nötig. Abhilfe bieten hier agile Integrationslösungen (siehe Formen der agilen Integration - eine Auslegeordnung). Diese nutzten Cloud Paradigmen, um Integrationen dezentral von DevOps Teams bauen und betreiben zu lassen. In diesem Beitrag beleuchten wir, wie so eine dezentrale Integration mit Cloud-native Microservices umgesetzt werden kann.

Distributed Integration Platform als technisches Fundament

Damit eine dezentrale Entwicklung in einem Unternehmensumfeld optimal funktioniert, braucht es eine bereitgestellte Integrationsplattform. In diesem Blog analysieren wir die Umsetzung mittels einer Distributed Integration Platform (DIP). Diese DIP stellt die Grundlagen und Arbeitsmittel bereit, damit Integrationen schnell umgesetzt werden können. Eine solche Plattform muss technische wie auch organisatorische Dienste erbringen:

• Microservice-Templates für das schnelle Bootstrapping
• Infrastruktur für Integration Patterns (Event Streaming, Messaging, API-Mgmt, etc.)
• Libraries für projektübergreifende Problemstellungen
• Einheitliches Tracing, Monitoring & Logging
• Governance-Kontrollen
• Bereitstellung von Guidelines, Best-Practices sowie Coaching- und Support-Angeboten

Als technische Grundlage der Plattform dient eine bereitgestellte Containerplattform.

Vorteile von Microservices und Integrationsframeworks nutzen

Basierend auf dieser Plattform können DevOps Teams ihre Integrationen selbstständig für die bereitgestellte Containerplattform (z.B. OpenShift/Kubernetes) entwickeln. Die Integrationen selbst werden dann auf Basis eines speziellen Integrationsframeworks entwickelt. Es gibt eine Vielzahl solcher Frameworks, welche sich für diesen Zweck eignen. In diesem Blog schauen wir uns als Beispiel eine Kombination aus Quarkus sowie Apache Camel an:

• Quarkus ist ein Kubernetes-natives Java Framework, welches speziell für Container optimiert ist. Es verspricht einen kleineren Memory Footprint was zu tieferen Laufzeitkosten sowie schnelleren Startup-Zeiten führt. Zudem ist es möglich, mit Hilfe der GraalVM die Applikation auch native zu kompilieren und somit den Memory Footprint und die Startup-Zeit noch einmal massiv zu verkleinern, da keine JVM mehr benötigt wird.
• Apache Camel ist ein weit verbreitetes Integrations-Framework, welches über 300 Konnektoren für alle möglichen Integrationsszenarien verfügt. Camel eignet sich sehr gut für den Einsatz in Microservices. Ausserdem ist es möglich, in wenigen Zeilen Java Code auch komplexe Integrationsmuster in einer einheitlichen und deklarativen Schreibweise abzubilden. Damit werden Integrationen “as Code” geschrieben und mit gängigen DevOps Methoden ausgerollt, was bei iPaaS Lösungen mit ihren Low-/No-Code Ansätzen kaum möglich ist. Entsprechend bevorzugen viele Entwickler Integrationsframeworks anstelle von grafischen Lösungen. Trotzdem können Integrationsframeworks zu komplexen Codes führen, was wiederum einiges an Expertise benötigt.

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 Integrationsteam, sondern verlagert sich zu den Anwendungen mit Integrationsbedarf. Diese organisatorischen Änderungen werden auch im Blogbeitrag 5 Learnings zur agilen Integration diskutiert.

Dieser verteilte und Cloud-native Architekturansatz erlaubt es zudem Integrationen as a Microservice ...

• einzeln zu skalieren & deployen

• portierbar zu machen (Multi und Hybrid-Cloud Fähigkeit)
• automatisiert zu testen (CICD)
• schneller und mit bestehendem Know-how (z.B. Java oder agilen Methoden) zu entwickeln

Was aber auch bei Integrations-Microservices (wie auch generell bei Microservices) gilt: Der passende "Schnitt" ist oftmals nicht so einfach zu ziehen. Hier kann der Domain-Driven Design (DDD) Ansatz weiterhelfen, bei welchem die Modellierung aus einer fachlichen Sicht vorgenommen wird und so bei der Aufteilung des Systems in passende Einheiten unterstützt.

Fazit

Integration as a Microservice ist bereits Realität und damit kann auch die Integrationsschicht von den oben genannten Vorteilen einer Cloud-nativen Microservice-Architektur profitieren. Natürlich müssen auch hier, wie bei so vielen Architekturentscheidungen, Trade-offs eingegangen werden. Im vorliegenden Fall muss zwischen Flexibilität und Komplexität abgewogen werden. Die Applikationslandschaft wird heterogener und es bedarf Ressourcen für den Know-how Aufbau. Dennoch findet eine Liberalisierung der Integrationsschicht statt, was zur Agilität eines Unternehmens beitragen kann.

Blogserie:

#1 | Formen der agilen Integration - eine Auslegeordnung

#2 | 5 Learnings zur agilen Integration

#3 | Integration as a Microservice

#4 | Controlled risks: Agile integration requires automated testing

#5 | Agile Integration Made Easy with Red Hat