Vortrag II Mitschrift - Archi-Lab/fae-team-3 GitHub Wiki

Rewe digital Pionier der MS in D Reise durch die Geschichte

Seit 4 Jahren bei REWE digital REWE digital gegründet mitte 2014

großer Konzert, klassischer Konzern >90 Jahre

2014 REWE Digital, digitaler Hub innerhalb der REWE Gr. Erforschung neuer Geschäftsfelder, Lieferung von Ware 2014 übernahme eines Monolithen von externer Agentur (2 Teams)

2 Teams je 12 Leute -> Schwierige Weiterentwicklung

Überlegung wie skalieren (vor allem organisatorisch), wie die Arbeit so verteilen das die Teams sich nicht gegenseitig behindern

Squad concept (Spotify), überführen des Monolithen in MS, Ablauf klare Trennung zwischen Entwicklung und Operativ

Containerisierung gewünscht: Docker, bewusste Entscheidung, Container als solches verstehen

Erstes Produkt auf MS Platf. REWE App gewachsen auf etwa 20 Teams

identifizieren von Hauptdomänen aufgrund von Wachstum, eCom, fllfillment, big data platform; 30 Teams

MS funktioniere, müssen aber organisiert werden

REWE Marketplace; 50 Teams

Entwicklung von Services 1 2014 -> 270 2018 Entwicklung Teams 2 -> 48

5000 - 7000 Docker Container

Domain 1 -> N Subdomain 1 -> N Bounded Ctx Logisch (eCom,...) 1 1 ^ ^ 1 1 Platform N Service Technisch 1 1 ^ ^ 1 1 Tribe 1 -> N Squad 1 -> N Team Organisatorisch (Mitarbeiter)

Der Monolith wird nicht skaliert -> Dezentralisierung, Vertical Boundaries Die Entscheidung soll an dem Ort passieren wo sie auch stattfinden muss Die Entwickler sollen im Team entscheiden: Das ist mein Anwendungsfall, den kann ich am besten so lösen

Die Teams entscheiden möglichst viele Dinge eigenständig, zentrale Entscheidungen gehen schief

!Vertikale Grenzen, anstatt Schichtenarchitektur Teams bleiben durch vertikale Schnitte unabhängig. Conway's Law -> direkter Zusammenhang zwischen Organisationsstruktur und Softwarearchitektur Wenn nur GUI-Entwickler und nur Datenbankteam, dann entsteht automatisch eine Schichtenarchitektur

Wenn Architektur erreicht werden soll muss die Organisationsstruktur so aufgebaut werden, dass diese der Zielarchitektur entspricht. Teams werden so aufgestellt das Struktur abgebildet wird, auch wenn diese noch nicht erreicht ist

Teams bestehen aus Spezialisten für unterschiedliche Aufgaben Ein Team beinhaltet alle Funktionen vom Erstellen, Testen, Relasen, zu Betreiben

Nicht immer alle Funktionen erforderlich, aber erforderliche Funktionen

T-Shape Developer Breites aber oberflächliches Wissen über alle Bereiche, aber dafür Experte auf einem speziellen Gebiet

T nebeneinander, alle Funktionen im Team abbilden

Wie werden Teamgrenzen gefunden

Früher: große IT-Projekte, Stakeholder hat Requirement, Requirements Eng. übersetzt in Technisches -> Softwareingenieure, bauen etwas, nach längerer Entwicklungszeit Ergebnis. Stille Post verändert Informationen, bei der Implementierung kommt nicht das an, was ursprünglich gedacht war

Domänenexperten mit Entwicklern uvm. an einen Tisch Gemeinsam diskutieren was wird warum gebraucht. Sprache der Domäne wird von den Entwicklern gelernt Domänenexperten können lernen warum etwas wie gelöst wird -> Weniger Missverständnisse

2 Blöcke Strategisches Design Building Blocks - Aggregates, Repositorys usw.

Was ist eine Domäne? Bereich von Interesse oder Aktivität einer Organisation

Verschiedene Arten von Domänen Core domain - Geschäftswert, Unterschied zur Konkurrenz, Custom Solutions

Supportive domain - Unterstützt Geschäftsprozesse, aber kein eigener Wert, kann trotzdem zur Unterscheidung von der Konkurrenz beitragen

Generic domain - Kein eigener Geschäftswert, Prozesse werden an Standardprozesse angepasst, evtl. möglich Standardlösung einsetzen

Innerhalb Domäne: Bounded Ctx Stellt eine Funktionalität bereit, klare Grenze, Kommunikation mit anderen aber mit klarer Grenze gleiches Ding kann in verschiedenen Bounded Ctx unterschiedliche Bedeutungen haben !Eventuell unterschiedliche Aspekte des gleichen Dings interessant Auch Sprachbruch, Worte können unterschiedliches Bedeuten

Bounded Ctx stellen Abgrenzung dar, über die Ctx werden die Systemgrenzen und damit auch die Organisationsgrenzen dargestellt

Ctx Map kann Abhängigkeiten und Kommunikation zwischen den verschiedenen Systemen darstellen Unterscheidung: Upstream (kann für sich selbst erfolgreich sein), Downstream (hängt vom Upstream ab)

Entscheidungen in kleineren Gruppen Orientierung an Customer journey

!Schneiden vertikal an der Customer Journey aber nicht immer möglich, Artikeldaten sind überall erforderlich (können nicht Vertikal geschnitten werden) Artikeldaten daher eher Horizontal gleiches auch für Backoffice Mobile, ebenfalls problematisch, da eine App auf aktuellen Smartphone OS monolithisch ist

Platform, Betrieb der Server usw. muss für alle gemacht werden, kann nicht einer Subdomain zugeschlagen werden

Ziel: Hilfestellungen aber keine Vorgaben, damit sich das System so entwickelt wie es geplant ist Feedback wichtig, damit sich die Planung ändern kann

Leitplanken (keine Interpretation, Fest, abstrakt genug um einhaltbar zu sein): Designziele Vertikale Grenzen Dezentralisierung

Architekturprinzipen: 9 basic laws Autonomy, Automation and communicatoin

Guides wie authentisierung wie restapis wie asynchrone kommunikation practical manual for common tasks, rfc 2119 Must, Should, Could

keine Anarchie sondern geordnet, Software soll unabhängig Deployt werden können !Fehler isolieren, Services sollen sich nicht durch Fehler in anderen Services beeinflusst werden Services sollen soweit wie möglich ohne Abhängigkeit funktionieren

Kapselung von Implementationsdetails, kein gemeinsamer State zw. Services

!Kapselung von Datenhaltung, keine gem. DB, jeder Service hat seinen eigenen Data Storage

Architektur sagt WIE möchte ich etwas haben Produktmngmnt sagt WAS möchte ich haben

Produktmngmt muss Scope von Features reduzieren, da unterschiedliche Teams, z. B.: Farbe aller Btns auf einmal ändern nicht möglich

Falls es Abhängigkeiten gibt die sich nicht auflösen lassen: Service veröffentlicht Produktdaten Produktdetailseite soll neu gestaltet werden Neue Produktdaten Produktdetailseiten werden NEU oder ALT angezeigt je nachdem welche Daten der Produktdatenservice liefert

Weiterentwickelnde Implementierung Mit einfacher Implementierung anfangen, Informationen an andere Teams weitergeben, neue Erkenntnisse an andere Teams weitergeben Mehrere Implementierungen in verschiedenen Teams die immer besser geworden sind Wird relativ spät erst in Bibliotheken gegossen Es wird in Kauf genommen das Arbeit mehrfach gemacht wird

Autonomie erlaubt den Techstack zu öffnen, jeder setzt die Technologie ein die sich für die Aufgabe am besten eignet

Frage zu den Teams: Organisationen möchten die Teams neu zusammensetzen können - als Argument gegen die Technologiefreiheit dem kann begegnet werden - immer wechsel von Entwickler durch Teams

Warum? Skalierbar (Horizontal, nicht größere VMs, sonder mehr VMs) - hier hilft Automatisierung Empfehlung: Jedes Deployment, immer mindestens zwei Instanzen, von Anfang an darauf achten das mehr als 1 Instanz verwendet wird

!Alles soll automatisiert werden, außer Softwareentwicklung Tests Deployment Ops

Systeme müssen beobachtet werden, Tests müssen immer wieder überprüft werden, im Notfall mit dem Monitoring auf der Produktumgebung

(Technik) Follow REST Principles (REST maturity level 2) kein Einsatz von HATEOAS (REST maturity level 3)

Frage: Warum? Persönliche Meinung: Informationen werden selten genutzt, Frontend braucht Informationen, APIs selber haben internen Zweck, Implementierungsaufwand zu hoch Versprechen Businesslogik aus dem Client in die API, kann nicht vollständig erlaubt werden. Client ist nach wie vor Eng mit der Anwendung verbunden Einzige Anwendung: API lvl. 3; klassischer Webbrowser

Standardisieren der Servicekommunikation: REST und JSON, kein SOAP und XML o. ä.

Kommunikation wann immer möglich Asynchron, es geht erstaunlich viel!

Probleme in REST-only Architekturen Was machen bei Ausfall eines MS Timeouts (kurz, 200ms) Fallbacks Circuit Breakers (Service wird in Ruhe gelasse, bei überlast) Eventing Soviel Daten wie möglich lokal Vorhalten (Informationen aus einem Service) Daten dürfen und sollen dupliziert werden Datenkonsistenz ist ein Problem, aber bei MS akzeptiert, man muss mit den Problemen leben können und es gibt Methoden damit umzugehen Verzögerte Konsistenz!

Customer Data Service kennt Kunden, Daten werden auf Queue publish
Services holen sich die Daten ab

Services speichern nur die Dinge in Datenbank die für sie wichtig sind

Jeder Service bietet drei APIs REST UI Kafka topic (Eventlog)

Asynchrone Kommunikation über Kafka REST hauptsächlich für Synchron und externe Clients

Kafka wird bei Ihnen nicht persistiert

Events sind wie APIs zu betrachten

Writing APIs is hard Apis werden oft zu speziell geschrieben neue Clients brauchen häufig API Änderungen Abwärtskompatibilität

Anti-Corruption Layer ist in den einzelnen Services, ein Publisher publisht alles, jeder Client kann hören wie er es braucht

Zugriff auf die Systemlandschaft Ausschließlich über Gateways Terminal, UI Gateway, Mobile Gateway Routing, Requests Authentifizieren, Request kombinieren

Wie bekomme ich eine Webseite? Problem hunderte MS, wie werden diese zu einer Webseite

Webseite (GUI) als Monolith? MS Ansatz ins Frontend

Verschiedene Bereiche der Seite müssen irgendwie miteinander kommunizieren Middleware erledigt Zusammenbau und Suche nach den zuständigen MS product detail service liefert alles was er weiß und baut diese direkt in die HTML-Seite ein zusätzlich baut er ein welche Dinge noch fehlen Middleware sieht das und kümmert sich darum das die Sachen eingebaut werden Vorgang ist rekursiv Seite wird zusammengesetzt und dem Kunden ausgeliefert

Dadurch möglich: MS im Frontend

https://git.io/vA2MY

Fragen:

• Mehrere Instanzen eines MS teilen sich eine Datenbasis

• Featuretoggles werden genutzt falls MS Optionen bieten bei denen noch andere MS fehlen

U Build it U run it - auch Verantwortung für (sicheren) Betrieb Softwareengineering mehr als nur Tickets abarbeiten, mehr Dinge als nur programmieren, auch Betrieb, Analytics usw.

++++++

Brownfield vs Greenfield

Es geht monolitische legacy Systeme auf MS umzustellen

Anregungen: Eventkommunikation vs. Synchron Vordenken in Richtung UI