Die Erfahrung lehrt, dass an Geschäftsvorgängen​ orientierte Schnittstellen stabiler sind als an technischen Konzepten ausgerichtete. Wenn wir in unserem System Geschäftsbereiche nachbilden, versuchen wir damit nicht nur stabilere Schnittstellen zu erzielen, sondern auch zu gewährleisten, dass sich das System leichter an veränderte Geschäftsvorgänge anpassen lässt. Verwenden Sie begrenzte Kontexte, um die Schnittstellen zu verschiedenen Geschäftsbereichen festzulegen.

Microservices bringen nicht zuletzt aufgrund der großen Anzahl veränderlicher Systembestandteile einige Komplexität mit sich. Das Bestreben, die Automatisierung​ zu kultivieren, ist dazu geeignet, dem zu begegnen, und es kann durchaus sinnvoll sein, von vornherein Anstrengungen zu unternehmen, Microservices zu unterstützen. Automatisiertes Testen ist von entscheidender Bedeutung, denn das Funktionieren der Services zu gewährleisten ist komplizierter als bei monolithischen Systemen. Ein Kommandozeilenaufruf für das einheitliche Deployment ist dabei sehr nützlich und ermöglicht es, im Rahmen des Continuous Delivery nach dem Einchecken schnell Rückmeldung zur Qualität des Produktivsystems zu erhalten.

Ziehen Sie in Betracht, Umgebungsdefinitionen zu verwenden, um die Unterschiede zwischen verschiedenen Umgebungen zu dokumentieren, ohne dabei die einheitliche Deployment-Methode aufzugeben. Mittels maßgeschneiderter Images können Sie das Deployment beschleunigen, und die Einrichtung vollständig automatisierter unveränderlicher Server erleichtert es, die Funktionsweise Ihres Systems zu verstehen.

Um einen Service unabhängig von anderen Services fortentwickeln zu können, ist es erforderlich, Implementierungsdetails​ zu verbergen. Hier ist die Verwendung begrenzter Kontexte hilfreich, weil wir uns darauf konzentrieren können, welche Modelle gemeinsam genutzt und welche verborgen werden sollen. Außerdem sollten Services ihre Datenbank verbergen, um eine bei herkömmlichen serviceorientierten Architekturen so häufig auftretende Kopplung zu vermeiden, und stattdessen Datenpumpen oder Ereignis-Datenpumpen verwenden, um die zur Berichterstellung erforderlichen Daten verschiedener Services zusammenzuführen.

Verwenden Sie nach Möglichkeit technologieunabhängige APIs, um bei der Auswahl der einzusetzenden Technologie keinen Einschränkungen zu unterliegen. Ziehen Sie in Betracht, REST zu verwenden, das die Trennung interner und externer Implementierungsdetails formalisiert. Diese Konzepte können aber auch bei der Nutzung von RPC (Aufruf entfernter Prozeduren) Anwendung finden.

Zur Maximierung der durch Microservices ermöglichten Autonomie ist es erforderlich, laufend nach Möglichkeiten zu suchen, Entscheidungen und Zuständigkeiten an diejenigen Teams zu delegieren, die für den Service selbst verantwortlich sind. Dazu gehört auch, für möglichst viele Dinge Selbstbedienungsverfahren einzurichten, damit die Entwickler ihre Software nach Bedarf deployen können, was die Entwicklung und das Testen sehr erleichtert. Außerdem entfällt so die Notwendigkeit, dass verschiedene Teams diese Aufgabe erledigen müssen.

Teams sind für ihre Services verantwortlich – das ist hier ganz entscheidend. Im Idealfall ist das Entwicklerteam nicht nur für die vorgenommenen Modifikationen verantwortlich, sondern entscheidet auch selbst, wann diese veröffentlicht werden. Interner Open-Source-Code ermöglicht, dass die Entwickler Änderungen an Services vornehmen können, für die andere Teams verantwortlich sind, bedenken Sie aber, dass mit der Implementierung viel Arbeit verbunden sein kann. Stimmen Sie die Teams auf Ihre Organisationstruktur ab, damit Conways Gesetz in Ihrem Sinne arbeitet und die Teams zu Experten auf dem Gebiet der Geschäftsprozesse werden, für die sie Services entwickeln. Wenn eine bereichsübergreifende Führung erforderlich ist, können Sie ein Modell der gemeinschaftlichen Governance in Betracht ziehen, bei dem sich Mitglieder verschiedener Teams die Verantwortung für die Weiterentwicklung des technischen Leitbildes des Systems teilen.

Dasselbe Prinzip ist auch auf Architekturen anwendbar. Verzichten Sie lieber auf Ansätze wie Enterprise Service Bus oder Systeme zur Orchestrierung, die oft zu einer Zentralisierung der Geschäftslogik und trivialen Services führen. Geben Sie statt einer Orchestrierung lieber einer Choreografie und nicht zu schlauer Middleware mit der Programmlogik in den Endpunkten den Vorzug, um zusammengehörende Programmlogik und Daten innerhalb eines Services zu belassen und dadurch zur Geschlossenheit beizutragen.

Wir sollten stets darum bemüht sein, dass das Deployment unserer Services voneinander unabhängig durchgeführt werden kann und dies auch praktizieren. Selbst wenn zu Ausfällen führende Modifikationen anstehen, kann man versuchen, mehrere Versionen eines Endpunktes gleichzeitig zu betreiben, um den Consumern Zeit für den Wechsel zu der neuen Version zu geben. Diese Vorgehensweise gestattet die schnellstmögliche Veröffentlichung neuer Features und erhöht gleichzeitig die Eigenständigkeit des für den Service verantwortlichen Teams, das sich nicht mehr bei jedem Deployment um die Orchestrierung kümmern muss. Wenn Sie RPC-Verfahren einsetzen, sollten Sie die Erzeugung eng gekoppelter Client/Server-Platzhalter vermeiden, wie sie bei Java RMI Verwendung finden.

Durch ein Ein-Service-pro-Host-Modell lassen sich Nebenwirkungen vermeiden, die durch das Deployment eines Services bei anderen Services verursacht werden können. Ziehen Sie ein Blue/Green-Deployment und eine Canary-Veröffentlichung in Betracht, um Deployment und Veröffentlichung voneinander abzugrenzen und die mit der Veröffentlichung verbundenen Risiken zu reduzieren. Verwenden Sie Consumer-Driven Contracts (CDCs), um Modifikationen aufzuspüren, die zu Ausfällen führen würden, damit sie gar nicht erst stattfinden können.

Halten Sie sich stets vor Augen, dass es nicht die Ausnahme, sondern die Regel sein sollte, Änderungen an einzelnen Services des Produktivsystems vornehmen und veröffentlichen zu können, ohne gleichzeitig irgendwelche anderen Services deployen zu müssen. Die Consumer sollten entscheiden, wann sie Aktualisierungen durchführen – und Sie müssen diesem Anliegen nachkommen.

Eine Microservice-Architektur kann belastbarer als ein monolithisches System sein, allerdings nur dann, wenn mögliche Ausfälle von Teilen des Systems eingeplant werden. Wenn wir der Tatsache, dass nachgeschaltete Services ausfallen können und werden, nicht Rechnung tragen, kann es zu katastrophalen Kettenreaktionen kommen, die in der Konsequenz zu einem sehr viel anfälligeren System führen.

Wenn Sie Funktionen über das Netzwerk aufrufen, dürfen Sie entfernte Aufrufe keinesfalls als lokale Aufrufe betrachten, weil dadurch verschiedene Fehlerzustände verborgen bleiben. Sie sollten sich daher vergewissern, dass die eingesetzten Client-Bibliotheken die Abstrahierung entfernter Aufrufe nicht übertreiben.

Folgen wir den Maximen der Antifragilität und gehen davon aus, dass jederzeit und überall mit einem Ausfall zu rechnen ist, sind wir auf dem rechten Weg. Vergewissern Sie sich, dass Ihre Timeouts korrekt eingestellt sind. Finden Sie heraus, ob der Einsatz von Bulkheads und Circuit Breakers sinnvoll wäre, um die negativen Folgen des Ausfalls einer Komponente zu begrenzen. Machen Sie sich klar, welche Auswirkungen es für Consumer hat, wenn nur ein Teil des Systems ein Fehlverhalten zeigt. Die Folgen zu kennen, wenn aufgrund einer Netzwerkstörung Teile des Systems nicht miteinander kommunizieren können, und beurteilen zu können, ob es in einer bestimmten Situation besser ist, die Verfügbarkeit oder die Konsistenz aufzugeben, sind genau das Richtige.

Das Verhalten eines einzelnen Services oder den Betriebszustand einer einzelnen Maschine zu überwachen, reicht nicht aus, um zu beurteilen, ob das Gesamtsystem funktionsfähig ist. Wir benötigen stattdessen eine umfassendere Übersicht über das Geschehen. Verwenden Sie semantisches Monitoring, um die korrekte Arbeitsweise des Systems zu überprüfen, indem Sie Pseudo-Ereignisse auslösen, um das Verhalten echter Anwender zu simulieren. Fassen Sie Protokolle und Statistiken zusammen, damit Sie auftretenden Störungen auf den Grund gehen können. Und wenn es darum geht, hartnäckige Probleme nachzuvollziehen oder einfach nur die Funktionsweise des Produktivsystems zu beobachten, können Sie Korrelations-IDs verwenden, um Aufrufketten innerhalb des Systems nachzuverfolgen.