Grundsatz Nr. 6 der Microservices-Architektur: Ein Team ist für den gesamten Lebenszyklus eines Microservices verantwortlich

Dieser Beitrag ist der letzte Teil einer sechsteiligen Serie über Microservices-Prinzipien. Die anderen Teile sind: Geschäftsfähigkeit, Autonomie, Kleiner begrenzter Kontext, Asynchrone Kommunikation und Beste Technologie.

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 ein Microservice in der Verantwortung genau eines Teams liegen sollte (ein Team kann aber auch für mehrere Services verantwortlich sein).

Die Verantwortung für den gesamten Lebenszyklus eines Dienstes bedeutet, dass ein einziges Team einen Dienst bereitstellen und verwalten sowie neue Versionen erstellen und veraltete Versionen außer Betrieb nehmen kann. Das bedeutet, dass die Benutzer des Dienstes eine einzige Anlaufstelle für alle Fragen zur Nutzung des Dienstes haben. Diese Eigenschaft macht es einfacher, Änderungen an einem Dienst zu verfolgen. Die Entwickler können sich auf einen bestimmten Bereich des Unternehmens konzentrieren, den sie unterstützen, so dass sie zu Spezialisten in diesem Bereich werden. Das wiederum führt zu besserer Qualität. Die Notwendigkeit, auch Fehler und Probleme in Produktionssystemen zu beheben, ist ein starker Motivator, um sicherzustellen, dass der Code korrekt funktioniert und Probleme leicht zu finden sind. Die Tatsache, dass verschiedene Teams an verschiedenen Diensten arbeiten, stellt eine Herausforderung dar, die zu einer robusteren Softwarelandschaft führen kann. Wenn TeamA eine Änderung im Dienst von TeamB benötigt, um seine Aufgabe zu erfüllen, muss eine Form der Planung stattfinden. Beide Teams müssen sich auf Zeitverschiebungen und unvorhergesehene Ereignisse einstellen, die dazu führen, dass sich das Lieferdatum einer Funktion ändert. Es gibt viele triftige Gründe, warum sich eine Änderung verspäten kann (z.B. Produktionsprobleme oder Krankheit reduzieren vorübergehend die Kapazität eines Teams oder Änderungen mit hoher Priorität haben Vorrang). TeamA kann sich also niemals darauf verlassen, dass TeamB vor der Frist fertig wird. TeamA wird lernen, seine Wochenenden und Abende zu schützen, indem es seine Architektur ändert. Wenn Sie in einer Microservice-Umgebung keine Annahmen über den Zeitplan eines anderen Teams machen, führt dies zu robusterer Software.

[bearbeitet: 3 aug 2015 - Präambel hinzugefügt und Zeile"Der heutige Blog ist der letzte in einer Serie über unsere Microservices-Prinzipien." entfernt]