"Microservices sind keine Patentlösung" – Ein Interview mit Michael Nygard

Inhaltsverzeichnis

Michael Nygard hat im Laufe seiner beruflichen Karriere von über 15 Jahren viele umfangreiche Softwaresysteme entworfen und bereitgestellt. Sein Buch "Release It!" fasst wesentliche Erkenntnisse seiner Tätigkeit zusammen. Er ist ausgewiesener Experte auf dem Gebiet der Microservices. Uwe Friedrichsen, CTO des IT-Beratungshauses codecentric, hatte die Gelegenheit, für heise Developer ihm einige Fragen zum Architekturstil zu stellen.

heise Developer: Microservices sind kein Hype mehr, sondern in vielen Unternehmen Realität. Noch mehr Unternehmen fangen gerade an, sie einzuführen. Andere, beispielsweise Segment, haben sie aufgrund spezieller Anforderungen wieder abgeschafft. Wie stehst du zu Microservices? Sind sie wirklich das lang ersehnte Allheilmittel, wie einige behaupten? Oder die Büchse der Pandora, wie andere warnen?

Michael Nygard: Es gibt keine Patentlösung. Microservices sind eine technische Antwort auf eine innerbetriebliche Herausforderung: Wie kann ich mein Entwicklungsteam skalieren, ohne den Fluss der Entwicklungsarbeit zu beeinträchtigen?

Meiner Ansicht nach resultieren Microservices oft aus Fehlern in unseren Betriebssystemen, Sprachen und Frameworks. Fehlereingrenzung und unabhängige Deployments sind grundsätzlich das Ziel. Erstens möchten wir, dass jedes Team nach eigenem Zeitplan deployen kann, ohne Ausfälle in anderen Teams zu verursachen. Zweitens wollen wir verhindern, dass der schlechte Code eines Service anderen Services schadet – was heute im Übrigen nur teilweise mit Microservices erreicht wird. Drittens geht es uns darum, die Namespaces der Betriebssystemebene, also IP-Adressen, TCP-Ports, Dateinamen, Verzeichnisinhalte etc., voneinander zu isolieren. Und zu guter Letzt wollen wir architektonische Grenzen zwischen den Services erzwingen. Braucht es dazu wirklich Tausende von Containern mit eigenem Betriebssystem-Image?

heise Developer: Es klang in deiner letzten Antwort an, aber um es noch auf den Punkt zu bringen: Wann ist es aus deiner Sicht ratsam, Microservices zu verwenden?

Nygard: Immer, wenn mehrere Teams in der Lage sein sollen, unabhängig voneinander zu deployen.

heise Developer: Man könnte deine Antwort auf die nächste Frage erahnen. Ich stelle sie aber trotzdem: Unter welchen Umständen sollte man lieber auf Microservices verzichten?

Nygard: Wenn man in einem kleinen Team eng zusammenarbeitet, etwa im selben Raum, sollte man die operative Komplexität von Microservices lieber vermeiden.

heise Developer: Mit Blick auf deine Kunden: Was sind die größten Herausforderungen bei der Einführung von Microservices? Womit haben Unternehmen am meisten zu kämpfen?

Nygard: Es gibt zwei große Hürden: Zum einen sind bei der Einführung von Microservices die APIs zwischen den Services oft nicht hinreichend durchdacht. Das Ergebnis ist ein verteilter "Big Ball of Mud", bei dem jeder Service einen beliebigen anderen aufrufen kann. Das wiederum führt zu übergeordneter Starrheit, da niemand die Möglichkeit hat, seine APIs zu ändern.

Zum anderen gehen viele, die Microservices einführen, davon aus, dass sie nur einmal einen Entwurf machen müssen, ein paar Microservices erstellen, und das war's. Fakt ist, dass der Architekturstil eine ständige Umgestaltung und Weiterentwicklung erfordert. Man muss beispielsweise bereit sein, einen Service zu löschen, den man gerade erst letzten Monat entwickelt hat. Das kann unangenehm sein, weil man es gewohnt ist, Code als langlebiges Asset zu betrachten.

heise Developer: Was empfiehlst du in Anbetracht dieser Herausforderungen? Was sind die wichtigsten Aspekte, die Einzelpersonen und Unternehmen beachten sollten, wenn sie sich für Microservices entscheiden?

Nygard: Erstens muss ein Bewusstsein dafür vorhanden sein, worauf es beim Entwickeln verteilter Systeme ankommt. Entwickler sollten einfach in der Lage sein, Lamport-Diagramme zu zeichnen und zwischen idempotenten Nachrichten und Exactly-once-Lieferinfrastruktur unterscheiden können. Das ist bereits ein wichtiger Teil des Systemdesigns und wird auch immer wichtiger – bis hin zum Frontend. Zeitgemäße Frontends sind Anwendungen in verteilten Systemen, mit all der Ungewissheit und Asynchronität, die damit einhergeht.

Zweitens wird in Entwicklerkreisen aus meiner Sicht viel über die Chancen und Risiken von Microservices diskutiert, aber die Wenigsten sind erfahren darin, Services zu entwerfen und ihre APIs kontinuierlich weiterzuentwickeln. Man findet zum Beispiel Hunderte von Tutorials darüber, wie man Kubernetes einrichtet oder mit Docker seinen Code für die Produktion bereitstellt. Darüber, wie man einen guten Service entwickelt oder wie man aus solchen Services ein ganzes System aufbauen kann, gibt es weniger. Entwickler dürfen nicht in die Falle tappen, ihre Microservices so zu gestalten, dass sie sich wie verteilte Objekte oder Entity Services verhalten. Das war ein wesentlicher Beweggrund für meinen Workshop "Monolith to Microservices". Im Rahmen des Kurses bauen Entwickler reale Services, und wir sprechen ausführlich darüber, wie man brauchbare, entwicklungsfähige APIs erstellen kann.