Self-Service DevOps mit Galapagos

Schon vor anderthalb Jahren hat Hermes sich dafür entschieden, Apache Kafka unternehmensweit einzusetzen – nicht nur als „Sammel- und Verteilmaschine“ für Unmengen technischer Daten, sondern auch als Werkzeug zur fachlichen Entkoppelung der einzelnen Entwicklungsteams und zur Einführung einer unternehmensweiten ereignisgetriebenen Architektur.

Aufbauend auf dem JUG-Vortrag von damals (https://speakerdeck.com/hermes/kafka-ist-nicht-nur-ein-autor) stellen wir unseren Weg dorthin aus Sicht des Architekturteams vor. Basierend auf der Erkenntnis, dass eine zielgerichtete Nutzung von Kafka gewisse Regeln erfordert, haben wir eine eigene Softwarelösung geschaffen, um die Teams weitestgehend von den „Niederungen“ des Regelwerks zu befreien, aber dennoch den strukturierten, entkoppelten Austausch von Geschäftsereignissen zwischen den Anwendungen zu ermöglichen. Dabei haben wir vermieden, einen „neuen ESB, nur mit Kafka“ zu bauen oder neue Flaschenhälse zu schaffen, und nutzen stattdessen die Vorteile, die Apache Kafka mit sich bringt, bestmöglich aus.

Transcript

1. Apache Kafka: DevOps Self-Service mit Galapagos Hamburg, 3. Dezember 2020 Florian Albrecht, Solution Architect
2. Agenda Ausgangslage und Lösungsansatz Live Demo Fragen & Diskussion
3. 3 Die digitale Transformation ist da! • Eigenverantwortliche DevOps- und Kompetenzteams • Änderungen müssen schnell durchgeführt werden können • Für Koordination über mehrere Teams fehlt meist die Zeit • Die Zeit der Monolithen und zentralen Releases ist vorbei
4. Hermes Architekturprinzipien 4 Jede Applikation unterstützt nur eine Business Capability. Das Architekturteam definiert einen Rahmen für Kerntechnologien. Technologieentscheidungen für einzelne Applikationen können von dem jeweiligen Team selber getroffen und verantwortet werden. Eigenentwicklung findet auf einer PaaS Umgebung statt. Relevante Geschäftsereignisse werden über eine zentrale Austauschplattform kommuniziert. Geschäftsobjekte werden führend von einer Applikation verwaltet. Applikationen stellen ihre Funktionalität in einer stabilen, dokumentierten API bereit. Applikationen sind unabhängig, sicher, skalierbar, überwachbar, resilient und schnell transformierbar. Jede Applikation kann jederzeit automatisiert und transparent für andere Applikationen geändert werden.
5. Ereignisgesteuerte Architektur als Lösungsansatz… 5 „Zum Potential von Event-Driven Architecture für komplexe Unternehmensnetzwerke“, Thomas Buckel, Universität Würzburg, 2012 „Der Einsatz einer EDA erhöht den integrierten Informationsfluss, ist gut skalierbar und verhilft zur intelligenteren und logischeren Arbeitsweise der gesamten unternehmerischen Architektur. Alle diese Faktoren reduzieren die bestehende Komplexität.“
6. … aber leider bisher nicht einsatzreif 6 „Zum Potential von Event-Driven Architecture für komplexe Unternehmensnetzwerke“, Thomas Buckel, Universität Würzburg, 2012 „EDA weist allerdings Schwächen hinsichtlich der Standardisierung auf. […] In Verbindung mit der fehlenden Standardisierung und der uneinheitlichen Event-Modellierung mangelt es zum heutigen Zeitpunkt an einer etablierten Entwicklungsmethodik. Zukünftig gilt es daher, Best-Practice-Beispiele sowie Standards für die jeweilige Implementierung zu entwickeln bzw. bestehende Ansätze zu erweitern.“
7. 7 Ereignisgesteuerte Architektur (Beispiel) Last Mile Handling Sendung zugestellt Billing Transport Management Sendung in LC eingegangen Planning & Disposition ParcelShare Track & Trace (Web) Topics Produzenten Konsumenten
8. 8 Wie finde ich Ereignisse, die relevant für mich sind? Woher kenne ich das Datenformat? Wie bekomme ich Änderungen mit? Wer benötigt / nutzt meine Ereignisse / Topics? Wie sichere ich sensible Daten? Wann und wie kann ich Topics wieder löschen? Neue Fragestellungen!
9. 9 Die Lösung: Regeln! Namensschemas für Topics, Groups und Event Types Nutzung von Kafka ACLs CloudEvents JSON Format nutzen Consumer-Kompatibilität achten Dokumentieren im Architekturtool (LeanIX) Sauberes „Staging“ durchführen Client-SSL-Zertifikate Ein Owner pro Topic Einteilung in API- und interne Topics Deprecation- und Löschregeln und -fristen
10. Galapagos als Self-Service Tool 10 • Application Topic Owner können für ihre Anwendung(en) Topics anlegen und abonnieren • „Katalog“ der API-Topics • JSON-Schema-Registry • Kompatibilitätsprüfung („Schema Evolution“) • Ausstellen von Client-Zertifikaten • Vergabe von Rechten (ACLs) • Staging von Änderungen • Sicherstellen von Namenskonventionen • Entwicklerunterstützung (Kafka-Client- Konfiguration, Topic-Einstellungen…) • Freigabe-Workflow für „geschützte“ Topics • Nicht für den eigentlichen Kafka-Betrieb notwendig!
11. Galapagos im Kafka-Kontext 11 DEV Cluster INT Cluster Schnittstellen Topics ACLs Metadaten
12. Topic-“Taxonomie“ 12 Intern API Events Commands Data • (Fast) keine Einschränkungen oder Vorgaben • Nur innerhalb einer Anwendung, auch zwischen den Modulen einer Anwendung nutzbar • Normalerweise hauptsächlich technische Treiber • Dürfen auch dynamisch erzeugt und gelöscht werden • Der wichtigste Topic- Typ für Kommunikation zwischen Anwendungen • Enthält alle Events (genau) eines Business Event Typs • Immer fachlich! • Fachlicher oder technischer Treiber • Beispiel: „Sende folgende E-Mail“ • Sollte nur selten genutzt werden (invertiert „Event“- Logik) • Hauptsächlich für (fachliche) Stammdaten gedacht • Eigentlich ein Event- Topic für das Event „Stammdatum XY wurde geändert“ • Nicht benutzen, um Geschäftsobjekte zu transportieren! • Müssen über Galapagos erzeugt und gelöscht werden
13. 13 LIVE DEMO
14. 14 Galapagos Key Technical Facts • Spring Boot Backend • Angular Frontend • Microservices (Micronaut) für LeanIX-Integration (optional) • Betrieb auf Kubernetes Cluster • Authentifizierung mit Keycloak • Keine eigene Datenbank: Metadaten werden in Kafka Topics gespeichert Bild: CC-BY-SA 2.0, Autor: Alan Chia
15. 15 • Seit Ende 2019 produktiv bei Hermes im Einsatz • Positives Feedback von allen Teams, starker „Ansturm“ auf Kafka • Kontinuierliche Weiterentwicklung • Validierung durch die „Realität“ • Open Source geplant für Ende 2020 https://github.com/HermesGermany/galapagos • Entwicklerteam verstärkt
16. 16 Fragen & Diskussion • Wie klappt bei Euch die teamübergreifende Koordination mit Kafka? • Wie stellt Ihr Kompatibilität sicher? • Gibt es ein querschnittliches „Kafka- Team“? • Haltet Ihr die Verknüpfung zu Geschäftsereignissen für sinnvoll? • Nutzt Ihr Dinge wie GitOps für Kafka? Wie läuft es damit? • Bilden sich neue Flaschenhälse oder Wissensinseln?
17. Platzhalter Präsentationstitel Kontakt Florian Albrecht florian.albrecht@hermesworld.com Lust, mitzumachen? https://www.hermesworld.com