Jeder wie er will, aber so nicht

Transcript

1. Jeder wie er will, aber so nicht Streaming Architektur skalieren Kristian Kottke Dr. Jan Christian Dammann 10.04.24 1 Foto von Zac Ong auf Unsplash
2. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 2 Kristian Software Architect Whoami §Reactive Systems §Data Engineering §Stream Processing Hintergrund: §Online Shop – 4 Teams, 12 Devs §Domain Services – Self Contained System (SCS) §Domänenübergreifende Kommunikation über Kafka §Vendor-neutrales Setup – Kein Confluent 😉
3. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 3 Jan Senior Software Architect Seit 1999 in der IT 2010 2023 § API-Management § Plattform Engineering § Architektur-Reviews § Java und Python § Async. API Management Plattform für einen Logistiker § Confluent Enterprise mit Erweiterungen § > 120 angebundene Applikationen
4. § ... ihr entscheiden müsst, ob ihr eine Event Streaming-Plattform benötigt und wie die zu gestalten wäre. § ... euch unsere Learnings aus über drei Jahren Praxis von zwei Event Streaming Plattformen interessieren. § Was verstehen wir unter einer Event Streaming Plattform? § Ressourcen der Plattform sind Sequenzen von Einträgen (Streams of Records) § Einträge haben keinen spezifischen Empfänger § Einträge sind persistent und können mehrfach gelesen werden Hier seid ihr auf jeden Fall richtig, wenn ... Ziele und Rahmen dieses Vortrags 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 4
5. Bitte scannt diesen Code:
6. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 6 § Der große Logistiker Trucker Corp. entschließt sich dazu sein Transportmanagementsystem neu zu implementieren § Dazu wird ein „Grüne Wiese“-Projekt gestartet § Die beteiligten Teams glauben an eine schnellere Entwicklung durch eine Entkopplung der Teams § Die Lösung soll deshalb als verteiltes System mit mehreren Teams implementiert werden § Die Teams entscheiden sich für asynchrone Integration als Paradigma ... in den frühen 2020ern irgendwo in Hamburg Es war einmal ... Foto von Glenn Hansen auf Unsplash
7. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 7 asynchron == unabhängig == Probleme gelöst?
8. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 8
9. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 9 § Bertrand Meyer führt in 1992 “Design by Contract“ erstmals ein § Anbieter und Konsumenten stimmen gegenseitig Zusicherungen und Erwartungen ab § Asynchronität => zeitliche Entkopplung => Producer-Driven => mehrere Versionen existent Pacta sunt servanda Änderbarkeit von Schnittstellen Vertrag Validierung Prüft die Einhaltung Version beschreibt Durch Vertragsparteien
10. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 11 § Ein Vertrag ermöglicht die Feststellung von Korrektheit eines Records § Vertragskonformität kann technisch überprüft und erzwungen werden § Die Versionierung erlaubt spätere Änderungen am Vertrag/Schema Entkoppelte Inbetriebnahme von Änderungen Änderbarkeit von Asynchronen Schnittstellen Vertrag Validierung Prüft die Einhaltung Versionierung beschreibt Kompatibilität Ermöglicht nicht- brechende Änderungen Durch Vertragsparteien Durch Plattform
11. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 12 § Schemata sind die rudimentärste Stufe eines Vertrages § Schemata definieren die (hierarchische) Struktur, Benennung und Wertbereiche einzelner Einträge § Unterschiedliche Integrationstiefe der Schema-Formate in Frameworks / Plattform-Lösungen § Unser Learning: Avro hat sich vor allem aufgrund der Validierung und Kompatibilität bewährt Bestandteile einer (asynchronen) Schnittstelle Schema Schema- Definition(en ) Struktur und Wertebereiche einzelner Einträge § XML Schema Definition (XSD) § Hm…XML…Yeah §JSON Schema § Menschenlesbar § Grammatik- und regelbasiert § Open & Closed Content Modell Schema Standards / Lösungen: Plattform- Komponente: § Avro § Binäres Format § Kompaktes Encoding § Protobuf § Populär durch gRPC § Vergleichbar mit Avro
12. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 13 § Die Schema Registry verwaltet und verteilt Schemata § Es gibt mehrere ausgereifte Lösungen für Registries am Markt § Schema Registries bieten (noch) keine Navigation durch Schema- Beschreibungen § Unser Learning: Integration über Confluent oder Karapace funktioniert sehr gut und zuverlässig Bestandteile einer (asynchronen) Schnittstelle Schema Registry Schema- Definition(en ) Struktur und Wertebereiche einzelner Einträge §Confluent Schema Registry §De-Facto Standard §Etablierte Lösung §Karapace §Kafka REST API §Schema Registry §Drop-In Replacement §Apicurio §API Registry §Modell-Typen und Kompatibilität Schema Registry Standards / Lösungen: Plattform- Komponente:
13. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 14 § Einhaltung der Verträge muss durchgesetzt werden § Dies kann Publisher-Seite geschehen § Libraries für die client-seitige Validierung – Confluent – Apicurio § Der Consumer kann lediglich eine Vertragsverletzung feststellen § Confluent unterstützt plattform- seitige Validierung mit DLQ- Behandlung oder Zurückweisung Validierung Events Publisher Consumer 🧐 🧐 🧐 😢
14. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 15 § Kompatibilität einer konkreten Schema-Version – Message Pact (Consumer-Driven Contract, CDC) § Kompatibilität über verschiedene Schema-Versionen – Avro & Protobuf – Kompatibilitätslevel: Backward, Forward, Full, Transitive – Automatisches Ausgleichen von nicht-brechenden Unterschieden – Z. T. sind auch automatische Migrationen und Quality Gates möglich Geschenkt durch Avro + Schema Registry: § Kontrolle und Einhaltung der Schema-Konformität § Durch Kompatibilitätslevel lassen sich Avro-Schemata stabil weiterentwickeln § In „kleineren“ Umfeldern reichen deshalb Schemata zur Erleichterung der Zusammenarbeit Kompatibilität Kompatibilität Upgrade-Reihenfolge Backward Consumers Forward Producers Full Egal
15. Platform Type 1: Inter-Vertical Integration Platform § Der Kafka Cluster dient als Middleware zur Integration von verschiedenen Systemen. § 2 bis 6 Teams, die an einer Lösung arbeiten § Weiche Anforderungen an Ressourcen-Isolation § Hohe Änderungsrate bei Schemata § Enge Integration mit CI/CD Infrastruktur der Teams Broker Schema Registry Monitoring & Alerting Inter-Vertical Integration Platform 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 17
16. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 18 § Das neue Transportmanagementsystem (TMS) der Trucker Corp. ist erfolgreich in Produktion gegangen § Zahlreiche Applikationen benötigen Ereignisse und Daten aus dem TMS § Das TMS muss Daten Zwecks Rechnungsstellung an die ERP- Lösung geben § Der Bestand muss an die Plattform angebunden werden ... ein Jahr später ... Es war einmal ... Foto von Glenn Hansen auf Unsplash
17. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 19 Was genau meint „Brownfield“? Mögliche Wachstumsfaktoren § Skalierung über Ressourcen: Topics, Record Count, Avg. Record Size, Retention Time § Skalierung über Applikationen: Consumer und Publisher § Skalierung über Datenarten § Skalierung über Teams Ø Kann eine „Inter-Vertical Integration Platform“ dieses Wachstum angemessen abbilden?
18. Diskutiert 2 Minuten mit euren NachbarInnen Was fehlt der Plattform für die Brownfield-Integration? 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 20
19. Bitte scannt diesen Code:
20. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 22 Ergänzungen der Inter-Vertical Integration Platform Broker Schema Registry Monitoring & Alerting Extended Inter-Vertical Integration Platform Service Account Management Connectoren Trans- formation Async API Catalog Platform Guidelines
21. Ergänzungen der Inter-Vertical Integration Platform Für Skalierung über Teams Platform Guidelines: ü Zusammenarbeit zwischen Menschen braucht Regeln ü Die Regeln müssen von allen Beteiligten akzeptiert werden ü Mögliche Motivationen für Regeln: Höhere Qualität, höhere Security, mehr Transparenz ü Unsere Motivation: Zusammenarbeit auf Augenhöhe (Fairness) Broker Schema Registry Monitoring & Alerting Extended Inter-Vertical Integration Platform 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 23 Service Account Management Connectoren Trans- formation Platform Guidelines Async API Catalog
22. 24 Inhalte der Platform Guidelines Schema Definition Namenskonventionen Verwendung natürlicher Sprache API Specification Message- / Event- Envelope Schema Compatibility § Anforderungen an den Aufbau die Beschreibung und das Verhalten der API § Zusammenarbeitsmodell mit Verantwortlichkeiten von Anbietern und Konsumenten Muster zur Fehlerbehandlung API-Versionierung API-Lebenszyklus 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren
23. 25 Beispiel für ein API-Reifegradmodell Maturity Level Erfüllung der Guidelines Beispiele für Guideline-Anforderungen 0 None Namenskonvention für Topics 1 Grundlegend Redumentäre Beschriebung einer API und eines Schemas 2 Größtenteils Definition eines Kompatibilitätslevels 3 Vollständig Vollständige Beschriebung einer API und eines Schemas § Reife einer API: Je mehr Anforderungen aus den Guidelines erfüllt werden, desto reifer § Die Reife sollte mit Geschäftskritikalität oder Sichtbarkeit steigen 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren
24. 26 Beispiel für Sichtbarkeit-Levels für APIs anhand #Consumer Private (0 – 1 Consumer) Protected (2 – 7 Consumer) Public > 7 Consumer Inner-vertical: APIs, die vom selben oder sehr wenigen Teams auf kurzem Dienstweg als Teil einer Lösung entwickelt werden Inter-vertical: APIs, die von mehreren Teams auf Basis individueller Vereinbarungen genutzt werden Cross-Vertical: APIs, die unternehmensweit genutzt werden Global: APIs, die auch außerhalb des Unternehmens von Partnern und Kunden genutzt werden Published Mind. 1 externer Consumer
25. 27 Reife und Sichbarkeit ergänzen sich Sichtbarkeits-Level Maturity Level Private Protected Public Published Schema 0 ✅ ❌ ❌ ❌ Kannst du haben 1 ✅ ✅ ❌ ❌ Must irgendeines haben (Avro empfohlen 😉) 2 ✅ ✅ ✅ ❌ Must Avro haben 3 ✅ ✅ ✅ ✅
26. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 28 Ergänzungen der Inter-Vertical Integration Platform Broker Schema Registry Monitoring & Alerting Extended Inter-Vertical Integration Platform Service Account Management Connectoren Trans- formation Async API Catalog Platform Guidelines
27. Ergänzungen der Inter-Vertical Integration Platform Für Skalierung über Applikationen Service Account Management: ü Technische User für Apps ü Technische User besitzen Ressourcen ü Technische User gehören Teams ü Passwort-Rotation ü Self-Service für Teams 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 29 Bei uns: AWS Directory Service + gitops mit Argo CD Broker Schema Registry Monitoring & Alerting Extended Inter-Vertical Integration Platform Service Account Management Connectoren Trans- formation Async API Catalog Platform Guidelines
28. Ergänzungen der Inter-Vertical Integration Platform Für Skalierung über Applikationen Connectoren: ü Records 1:1 in Nachbarsystem schreiben oder von dort lesen ü Erweiterbar über API / SMTs (Simple Message Transformators) ü Limitierung: 1 : null oder 1 : n geht nicht 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 30 Bei uns: Kafka Connect Broker Schema Registry Monitoring & Alerting Extended Inter-Vertical Integration Platform Service Account Management Connectoren Trans- formation Async API Catalog Platform Guidelines
29. Ergänzungen der Inter-Vertical Integration Platform Für Skalierung über Applikationen Transformation: ü Applikationen bringen eigene Nachrichten-Formate mit (nicht änderbar), z.B. Standardprodukte oder SaaS-Lösungen ü Übersetzungen zwischen verschiedenen Bounded-Contexts im DDD 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 31 Bei uns: In Evaluierung (Apache Nifi, Camel, etc.) Broker Schema Registry Monitoring & Alerting Extended Inter-Vertical Integration Platform Service Account Management Connectoren Trans- formation Async API Catalog Platform Guidelines
30. Ergänzungen der Inter-Vertical Integration Platform Für Skalierung über Applikationen Async API Catalog: ü Inventar aller asynchronen Schnittstellen inkl. Dokumentation und Beispiele ü Feature: Request for Subscription 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 32 Bei uns: Event Catalog Broker Schema Registry Monitoring & Alerting Extended Inter-Vertical Integration Platform Service Account Management Connectoren Trans- formation Async API Catalog Platform Guidelines
31. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 33 Header Definition: § Header erlauben Filter und Routing auf Topics § Header ermöglichen Tracing von Records über verschiedene Applikationen Bestandteile einer (asynchronen) Schnittstelle Erweiterung des Vertrags Schema- Definition(en ) Header- Definition(en ) API-Definition Semantik, Aufbau und Nutzung der API Struktur und Wertebereiche einzelner Einträge Metadaten einzelner Einträge § Avro § Kompatibilität § Validierung auf der Plattform § Confluent Schema Registry § De-Facto Standard § Etablierte Lösung § Karapace § Kafka REST API § Schema Registry § Drop-In Replacement § Apicurio § API Registry § Modell-Typen und Kompatibilität Schema Registry Async API Catalog Standards / Lösungen: Event / Message Tracking § Async API § Beschreibung der Schnittstelle § Nennung von Umgebungen § Event Catalog § Static Site Generator § Liest AsyncAPI-Files § Confluent Stream Governance § Indexiert Confluent Ressourcen § Bietet Suche und Doku Plattform- Komponente: Custom Software § Cloud Events § Standard für Header API-Definition: § Mehrere Topics können zu einer asynchronen Schnittstelle gehören (Request-Response) § Die API-Definition bildet diese explizite Klammer
32. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 34 Aufbau und Ablauf Event Catalog 1. Developer erstellt Pull-Rerquest mit AsyncAPI- und Avro-Schema-Dateien 2. Reviewer prüft die API-Definition und akzeptiert sie 3. Die API-Definition wird gespeichert unter <serviceaccount>\<api- name>\<api-version> 4. Der Push triggert die Pipeline 5. Die Pipeline erzeugt das HTML mit dem Event Catalog und deployed dieses auf einen HTTP-Server 6. Die anderen Kunden der Plattform erhalten eine Benachrichtigung über die Änderung via Teams / Zoom / Slack / ... § Das Plattform Team stellt ein öffentliches git-Repo zur Ablage der API-Definitionen bereit § Developer reichen Ihre API-Definition per Pull-Request ein und erhalten ein Review vom Platform Team § Akzeptierte API-Definitionen werden in den Katalog aufgenommen
33. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 35 Beispiel aus dem Event Catalog
34. 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren 36 § Neue Services der Plattform der Trucker Corp. sind über zusätzliche Komponenten skaliert worden § Für jede Komponente gab es eine umfassende Problem- und Lösungsanalyse § Generische Fragestellung: Make or Buy mit Antwort als ADR § Die Trucker Corp. ist mit diesem Vorgehen angemessen gefahren und wird dieses Vorgehen beibehalten § Heads Up: Der Markt entwickelt sich weiter. Die Trucker Corp. evaluiert deshalb kontinuierlich, ob ein Austausch von Komponenten sinnvoll wäre 3 Jahre und nach 6 Komponenten-Entscheidungen später Die Reise geht weiter ... Foto von Glenn Hansen auf Unsplash
35. 37 § Technische Schnittstellen lassen sich bereits mit dem richtigen Tooling stabilisieren § Je mehr beteiligte Akteure, desto hilfreicher sind Regeln und Konventionen und vor allem Kommunikation § Regeln und Konventionen brauchen Legitimität und Akzeptanz § Wir haben unsere Regeln und Konventionen mit gegenseitiger Fairness und Augenhöhe in der Zusammenarbeit motiviert § Plattform-Lösungen wie Confluent Enterprise oder Stream Native bieten out-of-the-box geringe bis gar keine Unterstützung für diese Skalierung § Diese Lücken können durch „konfektionierte“ Open Source-Lösungen und Eigenentwicklung geschlossen werden 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren Unsere Learnings
36. Jeder wie er will, aber so nicht | Streaming Architektur skalieren Foto von Camylla Battani auf Unsplash Vielen Dank für Eure Aufmerksamkeit Fragen?
37. Bitte scannt diesen Code:
38. 40 Wie ihr uns erreichen könnt Kristian Kottke Software Architect +49 170 3748447 kristian.kottke@iteratec.com @_kkottke xing.to/kkottke speakerdeck.com/kkottke Dr. Jan Christian Dammann Senior Software Architect +49 151 25 33 16 45 jan-christian.dammann@iteratec.com https://www.linkedin.com/in/janchristiandammann/ 10.04.24 Jeder wie er will, aber so nicht | Streaming Architektur skalieren