Grundsatz Nr. 2 der Microservices-Architektur: Autonomie vor Koordination

Dieser Beitrag ist Teil einer sechsteiligen Serie über Microservices-Prinzipien. Die anderen Teile sind: Business Capability, Kleiner begrenzter Kontext, Asynchrone Kommunikation, Beste Technologie und Ein Team.   Microservices sind ein heißes Thema. Deshalb sagen viele Leute eine Menge Dinge. Um Unternehmen dabei zu helfen, das Beste aus diesem neuen Architekturstil zu machen, hat Xebia eine Reihe von Prinzipien definiert, die unserer Meinung nach bei der Implementierung einer Microservice-Architektur angewendet werden sollten. In diesem Blog wird erklärt, warum wir die Autonomie von Diensten der Koordination zwischen Diensten vorziehen.

Unser Xebia-Kollege Serge Beaumont hat Anfang des Jahres in einem Tweet "Autonomy over Coordination" gepostet und damit für mich einen der entscheidenden Aspekte für die Schaffung eines agilen, skalierbaren und robusten IT-Systems oder einer Organisationsstruktur zusammengefasst. Autonomie vor Koordination steht in engem Zusammenhang mit den Geschäftsfähigkeiten, die im vorherigen Beitrag dieser Serie beschrieben wurden. Jede Fähigkeit sollte in einem Microservice implementiert werden. Sobald Sie Ihre Business Capabilities korrekt definiert haben, sind die Abhängigkeiten zwischen diesen Capabilities minimal. Daher ist nur eine minimale Koordination zwischen den Fähigkeiten erforderlich, was zu einer optimalen Autonomie führt. Eine größere Autonomie für einen Microservice gibt ihm die Freiheit, sich zu entwickeln, ohne andere Services zu beeinträchtigen: Es kann die optimale Technologie verwendet werden, er kann skalieren, ohne dass andere skaliert werden müssen usw. Für das Team, das für den Dienst verantwortlich ist, sind die Vorteile ähnlich: Die Autonomie ermöglicht es ihnen, optimale Entscheidungen zu treffen, damit ihr Team bestmöglich funktioniert. Die Nachteile von weniger Autonomie und mehr Koordination sind offensichtlich und wir alle haben sie schon erlebt. Zum Beispiel führt eine Änderung zu einem Schneeball von abhängigen Änderungen, die im selben Moment bereitgestellt werden müssen, Änderungen an einem Modul erfordern die Zustimmung anderer Teams, eine rechenintensive Funktion kann nicht skaliert werden, ohne dass das gesamte System skaliert wird, ... die Liste ist endlos. Zusammenfassend lässt sich also sagen, dass Sie darauf achten sollten, Ihre Geschäftsfunktionen (Microservices) so zu definieren, dass die Autonomie maximiert wird, denn das bringt Ihnen sowohl organisatorische als auch technische Vorteile.   [bearbeitet: 3 aug 2015 - Präambel hinzugefügt und Zeile"In den nächsten Tagen werden wir jedes dieser Prinzipien in einer Reihe von Blogbeiträgen ausführlicher behandeln." entfernt]