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.