Oliver Wehrens E-Post Development GmbH

„Durch ihre fachliche Zuordnung beginnen Teams, das bestehende System fachlich als auch technisch zu bereinigen. Wir nennen das den „Konsolidierungseffekt.“

Lars Gentsch Deutschen Post E-Post Development GmbH

„Unsere Beobachtungen und Organisationsänderungen zeigen sehr gut, wie sich Conways Gesetz bestätigen und aktiv nutzen lässt, um einen Monolithen in Microservices zu zerteilen, die enthaltende Fachlichkeit zu konsolidieren und das Verantwortungsgefühl der Teams zu stärken.“

Microservices sind in aller Munde, und auf Konferenzen versprechen Migrationsszenarien und technische Details gut besuchte Vorträge. Eine Folie, die fast immer auftaucht, ist eine Feststellung von Melvin Conway aus dem Jahr 1968, die besagt, dass „Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.“ (Conways Law). Das heißt konkret, dass sich die Organisation der Firma und der Teams direkt auf den Code und die Architektur auswirkt.

Diesen Effekt haben wir bei der E-POST auch bemerkt; aber auch etwas, was wir „Reverse Conways Law“ nennen. Microservices haben Auswirkungen auf unsere Organisation und sogar auf unsere Kultur.

Unsere Plattform entstand 2010 als ein (verteilter) Monolith. Das Team und die Funktionalität wuchs schnell, und je größer die Teams und je mehr Teams es wurden, desto komplizierter wurden Abstimmungen und Koordination von Aufgaben bzw. komplexere Tests wurden nötig, um alle Seiteneffekte abzutesten. Ab 2012 wurden Zeit und Energie investiert, diesen Monolithen aufzuteilen.

Die ersten Schritte

Jedes Team nahm sich über die folgenden ein bis zwei Jahre einige seiner Komponenten an, schnitt sie in kleinere Teile und entwickelte neue Funktionalität gleich in eigenen (kleineren) Services. Wir teilten Teams auf, um eine Fokussierung der Teams auf bestimmte Teilbereiche zu erreichen. Die Größe der Teams richteten wir dabei an der Architektur aus. Leider resultierte das in manchen Fällen in Teams mit sehr wenigen Mitgliedern (drei bis vier), und Urlaub oder Krankheit führte zu einer stark sinkenden Velocity. Wenn eine größere Fachlichkeit aufgeteilt wurde, führte das zwar zu wartbarerem Code, aber nicht dazu, dass die Abhängigkeiten zwischen den Teams und Komponenten aufgelöst wurden. Darüber hinaus waren es nun mehr Services, Build Chains und Deployments, die jetzt gewartet werden mussten – das Infrastruktur-Handling war komplexer geworden. Alle Arbeiten, die Kommunikation mit anderen Teams benötigten oder bei denen auf Deployments gewartet werden musste, dauerten sogar länger als vorher. In dieser Phase haben wir architektonische Richtlinien vorgegeben, die eingehalten werden müssen, um keine Inkompatibilitäten zu erzeugen. Dies war unter anderem die Rückwärtskompatibilität von Schnittstellen und die Vorwärtskompatibilität von Clients. Jeder konnte sich darauf verlassen, dass eine einmal geschriebene Anbindung an einen Service auch weiterhin funktionieren würde.

Wir hatten uns in Teams organisiert, die kleinere Services erstellen und betreiben, aber teilweise noch sehr stark voneinander abhängig waren. Je weiter die Teams räumlich voneinander entfernt saßen, desto geringer wurde die Kommunikation, und die Abstimmung wurde deutlich schlechter. Unser Ziel war es nun, die Abhängigkeiten zu verringern.

Wir wollten jedem Team alles an die Hand geben, um ein Feature komplett in Eigenregie zu entwickeln und zu betreiben. Dazu teilten wir unsere Komponenten in fachliche Säulen (Vertikale, Bounded Contexts) auf und identifizierten, welche Funktionalitäten des Gesamtsystems zusammengehören. Herausgekommen ist ein System, das sich in Hauptprodukte, Querschnittsfunktionen (z. B. Billing, Drucken) und nicht funktionale Anforderungen (z. B. Authentifikation) aufteilt.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Entwickler Magazin Spezial Vol. 9: Microservices - "Microservices"

Alle Infos zum Heft
275521Wie Microservices die E-POST veränderten
X
- Gib Deinen Standort ein -
- or -