© Liashko/Shutterstock.com
Entwickler Magazin
Wie Microservices unsere Organisation und Kultur veränderten

Microservices bei der E-POST

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, […] auf Entwürfe festgelegt sind, 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.

Oliver Wehrens, Lars Gentsch


Diesen Effekt haben wir bei der E-POST auch bemerkt; aber auch etwas, was wir „Reverse Conway's 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, beziehungsweise 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 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äu...

Entwickler Magazin
Wie Microservices unsere Organisation und Kultur veränderten

Microservices bei der E-POST

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, […] auf Entwürfe festgelegt sind, 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.

Oliver Wehrens, Lars Gentsch


Diesen Effekt haben wir bei der E-POST auch bemerkt; aber auch etwas, was wir „Reverse Conway's 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, beziehungsweise 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 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äu...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang