Christian Sanabria
Principal Architect, Director
Blogserie | Agile Integration | #5
Autor: Christian Sanabria
In unserer Blog-Serie zu Agile Integration haben wir Ihnen mögliche Formen der agilen Integration vorgestellt, Sie haben fünf Learnings kennengelernt und das Zusammenspiel mit Microservices gesehen sowie Empfehlung zum optimalen Testen erhalten.
In diesem Blog-Beitrag wird nun anhand eines fiktiven Beispiels gezeigt, wie mit dem Red Hat Integration Bundle eine agile Integrationsplattform effizient aufgebaut und effektiv betrieben werden kann.
Durch die Anwendung der in den bisher erschienenen Blogs beschriebenen Best Practices können so innert kürzester Zeit Integrationen entwickelt werden. Diese bringen alle benötigten Daten performant von und zu den Business Anwendungen und verbessern so das Benutzererlebnis.
In früheren Zeiten bestand eine Integrationsplattform meistens aus einer zentralen Infrastrukturkomponente, auf welcher alle Integrationen liefen, egal welche Patterns oder Konzepte verwendet wurden. Dazu gab es oft spezialisierte Entwicklungswerkzeuge mit einzigartigen Prozessen, welche von einem dedizierten Integrationsteam verwendet werden mussten.
In der modernen, agilen Welt wird die zentrale Infrastrukturkomponente anhand ihrer Funktionalitäten in unterschiedliche, als Container betreibbare Komponenten verteilt. Zudem kommen anstatt spezialisierter Entwicklungswerkzeuge Frameworks zum Einsatz, welche sich mit den populärsten Programmiersprachen integrieren lassen. Dadurch können Entwickler ihre gewohnten Werkzeuge und Prozesse ohne grossen Aufwand weiterverwenden.
Um DevOps-Prozesse unterstützen zu können, werden alle Komponenten über APIs, CLIs oder andere Schnittstellen automatisierbar sein.
Das Red Hat Integration Bundle besteht aus mehreren Integrationsframeworks und spezialisierten Infrastrukturkomponenten. Kurz gesagt eine klassische Distributed Integration Platform (DIP).
Die Integrationsframeworks Fuse für Enterprise Integration und Debezium für Data Integration basieren auf Java. Somit bieten sie eine einfache Integration in Runtimes wie Spring Boot oder Kafka Connect. Durch die Unterstützung von Java und die breite Palette an Plug-ins für IDEs und Build-Werkzeuge können etablierte DevOps-Prozesse problemlos weitergelebt werden.
Folgende Infrastrukturkomponenten setzen auf die OpenShift Container Plattform und lassen sich über Operators innert Minuten einfach verteilt installieren und konfigurieren:
Über APIs und CLIs lassen sich Selfservice-Funktionalitäten umsetzen und stehen den Entwicklern dann zur Verfügung. Dadurch unterstützt das Integration Bundle DevOps-Prozesse sowie Hybrid- und Multi-Cloud-Modelle.
PS: Mit Fuse Online gibt es noch eine weitere Infrastrukturkomponente, welche für Citizen Integrators gedacht ist. Prinzipiell ist das eine iPaaS mit einem Browser-basiertem Frontend für sehr einfache Integrationen. In diesem Blog wird jedoch nicht weiter darauf eingegangen.
Früher kannte man den Satz ‘Wir integrieren die Applikation X mit dem System Y’. Neu sagt man: ‘Die Applikation X integriert das System Y’. Das soll den Unterschied zwischen klassischen und modernen Integrationsformen aufzeigen.
Heute gehört die Integration direkt zur Applikationsumsetzung und sollte nicht mehr als eigenständige Entwicklungsdisziplin angesehen werden. Das heisst die Integrations-Microservices werden von Entwicklungsteams genauso umgesetzt wie Business-Microservices.
Als Voraussetzung für diese Art agiler Integration benötigt es eine entsprechende Organisation, welche sowohl von der Führung, aber vor allem von den Teams getragen wird. Nur wenn die Organisation entsprechend aufgestellt ist, d.h. Entwicklerteams befähigt werden (z.B. durch Ausbildung, Consulting oder Blueprints), kann Integration erfolgreich direkt in den Entwicklerteams passieren.
Als fiktives Beispiel verwenden wir eine klassische Microservice Applikation mit:
Verteilte DevOps Teams könnten nun eine solche Applikation mit der Red Hat Integrationsplattform wie folgt umsetzen und sie mit anderen Systemen integrieren:
Nun erweitern wir das fiktive Beispiel um die Fähigkeit zur Datenintegration. Das heisst, Events auf der Datenbank werden in ein Event Streaming System geschrieben, worauf weitere Applikationen reagieren können.
Ein (anderes) DevOps Team könnte die existierende Applikation wie folgt erweitern:
Das ganze Beispiel lässt sich ausschliesslich mit Camel- bzw. Debezium-DSL Code umsetzen.
Für Spezialfälle lassen sich dank vielen Einstiegspunkten mit vernünftigem Aufwand eigene Erweiterungen erstellen. Komplexere Integrationen folgen ebenfalls demselben Muster, da sich Technologie und Prozesse einfach skalieren lassen.
Alle Bestandteile basieren auf bekannten Open-Source-Projekten. Fuse auf Apache Camel, AMQ Broker auf Apache Artemis, AMQ Streams auf Apache Kafka / Strimzi usw.
Die Frage, warum man sich eine Subscription von Red Hat erwerben sollte, wenn man sich die komplette Integrationsplattform umsonst selber zusammenstellen kann, ist also durchaus berechtigt.
Dabei ist die Frage der direkten Kosten nur die eine Seite. Auf der anderen Seite stehen die indirekten Kosten, wenn man auf eine Subscription verzichten würde.
Am offensichtlichsten ist der fehlende Support durch Red Hat, welcher insbesondere bei produktiven Problemen zeitnah erfolgen sollte (z.B. über Analysen oder Hot Fixes). Durch die reine Open Source Community ist dieser nicht gewährleistet. Aufwände bei selbstständiger Fehlersuche und anschliessender Behebung dieser können schnell ansteigen, zudem können potenziell lange Ausfallzeiten auftreten.
Eine zweite Quelle für indirekte Kosten ist das Zusammenspiel der einzelnen Komponenten, vorwiegend bei den Integrationsframeworks. Wie jede Software haben auch diese Frameworks Abhängigkeiten zu weiteren Bibliotheken. Dabei ist das Versionsmanagement zentral, wobei bei einer Subscription über ausführliche Tests durch Red Hat sichergestellt ist, dass alle verwendeten Bibliotheken problemlos zusammenarbeiten. Hier können eigene Aufwände für das Versionsmanagement ebenfalls schnell anwachsen und sind zudem wiederkehrend bei neuen Releases.
In diesem Blog haben wir aufgezeigt, wie einfach eine agile Integrationsplattform mit dem Red Hat Integration Bundle gebaut werden kann.
Durch die Unterstützung von Standardtechnologien, Microservice Architekturen und DevOps-Prozessen werden Teams befähigt, einfach verteilte Integrationen eigenständig zu entwickeln und zu betreiben, ohne von einem zentralen Integrationsteam abhängig zu sein.
Mit dem konsequenten Einsatz von Cloud-native Technologien ist die Plattform bereit für den Einsatz in Private-, Public-, Hybrid- und Multi-Cloud Szenarien.
Dadurch unterstützt diese moderne Integrationsplattform die Entwicklung von Businesslösungen, indem Daten flexibel dort zur Verfügung gestellt werden, wo sie benötigt werden. Diese Daten sind zudem in der gewünschten Form vorhanden. Dies erhöht die Zufriedenheit von Entwicklern und Anwendern, sprich diese der Kunden.
#1 | Formen der agilen Integration - eine Auslegeordnung
#2 | 5 Learnings zur agilen Integration
#3 | Integration as a Microservice
#4 | Kontrollierte Risiken: Agile Integration erfordert automatisierte Tests
#5 | Agile Integration mit Red Hat leicht gemacht
Ich freue mich auf Ihre Kontaktaufnahme