- Jeder Microservice kann seinen eigenen Technologiestack definieren. Die Aktualisierung eines Technologiestacks betrifft nicht mehr ein gesamtes System, und eine technologische Weiterentwicklung kann evolutionär (Schritt für Schritt oder Microservice für Microservice) fortschreiten. Technologiestacks von Microservices können sich unabhängig voneinander einwickeln.
Diese Option ist kein Freibrief, sondern tatsächlich muss sich jeder Microservice an gegebene strategische Rahmenbedingungen, z.B. die Architektur, halten. Insbesondere müssen Microservices die Vereinbarungen der Kommunikation untereinander einhalten.
Auch wenn von dieser Möglichkeit zu Anfang nicht Gebrauch gemacht werden sollte, wird sich im Laufe der Zeit bewähren, dass jeder Microservices den für sich geeigneten Zeitpunkt wählen kann, um auf neue Versionen der eingesetzten Betriebssysteme/Bibliotheken zu migrieren. Allein diese Möglichkeit hilft, die derzeit viel diskutierten technischen Schulden zu beherrschen. - Die Autonomie des Entwicklungsteams erhöht sich. Die Entwicklungsarbeit orientiert sich an Microservices. Teams haben die Möglichkeit, eigene technologische Lösungen zu wählen (im Rahmen der Architektur-Strategien, s.o.). Die Abhängigkeit von anderen Projekten ist reduziert. Durch die Fokussierung des Microservices auf das Domänenmodell ist der Kontext, in dem zu entwickeln ist, klar abgegrenzt.
Diese Überschaubarkeit erleichtert die Chance, sich verantwortlich für diesen Microservice zu fühlen. Denn was ich überblicken kann, dafür kann ich mich inhaltlich auch verantwortlich fühlen. Um diese Verantwortung in einem Team wahrnehmen zu können, sind jede Form von Hürden in der Kommunikation innerhalb des Teams hinderlich. Microservices sind deploybare und damit sichtbare und vorzeigbare Artefakte des Entwicklungsprozesses. Sie unterstützen damit agile Konzepte wie „potentially shippable product increment“. Ebenso sind Techniken wie evolutionäre Architektur und Continuous Delivery Teil des agilen Vorgehens. Microservices sind – wie in [InfoWorld] formuliert – die passende Architektur zur agilen Vorgehensweise. Agile Methoden harmonieren ausgezeichnet mit Microservices–Architektur.
Verantwortlichkeit eines Teams für den Microservice ist ein zentraler Begriff. Je einfacher und störungsfreier die Kommunikation (und damit auch die Entscheidungsfindung) innerhalb eines Teams ist, desto besser kann diese Verantwortlichkeit gelebt werden und desto mehr kommen die Vorteile von Microservices zum Tragen. Die Chancen von Microservices sollten nicht durch schwerfällige Kommunikation behindert werden.
Organisationsstrukturen bedingen nach dem Gesetz von Conway die Struktur von Softwaresystemen. Der Grund hierfür sind Kommunikationsflüsse, welche durch Organisationstrukturen stark beeinflusst werden. Die Verantwortung für einen Microservice sollte daher einem Team mit kurzen Kommunikationswegen obliegen [Newman Kap.10].
Kommunikation wird auch erschwert, wenn das Team geographisch verteilt ist. Je näher zusammen, desto besser [Newman Kap.10].
Die Verantwortung sollte sich vor allem nicht über mehrere Teams oder Abteilungen verteilen.
Im besten Fall sind alle für die Entwicklung und Betrieb eines Microservices entscheidenden Rollen im Team vertreten. Dieses Team spiegelt sich auch so in der Organisationstruktur wieder.
