Agile Integration mit Red Hat leicht gemacht

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.

Was definiert eine agile Integrationsplattform?

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.

Wie setzt Red Hat eine agile Integrationsplattform um?

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:

• AMQ Broker für Messaging
• AMQ Streams für Events
• Apicurito für API Design
• 3scale für API Management
• Apicurio als Schema Registry

Ü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.

Wie funktioniert dies in der Praxis?

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.

Gibt es ein Beispiel?

Als fiktives Beispiel verwenden wir eine klassische Microservice Applikation mit:

• Business Applikation
• Backends für Core Systeme
• Klassischen Queues für Entkopplung einer Datenbank

Verteilte DevOps Teams könnten nun eine solche Applikation mit der Red Hat Integrationsplattform wie folgt umsetzen und sie mit anderen Systemen integrieren:

• Mit Apicurito werden die API Definitionen für die Backend Services erstellt
• Aus den API Definitionen werden direkt in Apicurito Fuse Projekte für die Backends generiert
• Zusätzlich werden die API Definitionen in die Apicurio Schema Registry publiziert, wo bereits die Definitionen für die asynchronen Messages abgelegt sind
• Mit diesem Contract First Ansatz entwickeln die verteilten Teams unabhängig die unterschiedlichen Komponenten der Applikation und integrieren sie mittels CICD Pipelines
• Durch automatisierte Tests in allen Stufen wird die Qualiät und Kompatibilität sichergestellt
• Die einzelnen Komponenten werden als Container auf der OpenShift Plattform deployed und in unabhängigen Releases weiterentwickelt
• Die 3scale Gateways und AMQ Broker werden vom DevOps Team im Self-Service selbst deployed, konfiguriert und betrieben
• Zugriffe auf Backends, Datenbanken und Queues werden in den Fuse Komponenten mittels Camel Technologie Adapter, welche es für die meisten Systeme und Protokolle gibt, integriert

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:

• Mit Debezium wird eine Kafka Connect Komponente für die Datenbank generiert
• Wie die bisherigen Komponenten wird auch diese Komponente als eigener Container ohne Abhängigkeit zu einem Kafka-Connect-Cluster via CICD Pipeline deployed und individuell weiterentwickelt
• Das Schema für die Events werden in der Schema Registry für potenzielle Clients publiziert
• Für die zentrale AMQ Streams Plattform werden mittels Selfservice Topics und User angelegt

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.

Lohnt sich eine Investition langfristig?

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.

Was sind zusammengefasst die Vorteile?

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.