Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Self-Service DevOps mit Galapagos

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.

Hermes Germany GmbH

December 03, 2020
Tweet

More Decks by Hermes Germany GmbH

Other Decks in Technology

Transcript

  1. 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
  2. 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.
  3. 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.“
  4. … 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.“
  5. 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
  6. 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!
  7. 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
  8. 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!
  9. 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
  10. 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
  11. 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
  12. 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?