Ein großes Missverständnis bei der Verwendung von Microservices, ist die Annahme, es wären einfach nur sehr kleine Services. Diese Herangehensweise führt zwar schnell zu beträchtlichen Erfolgen, sie fördert aber mittel- und langfristig Fehler in ihrer Betrachtung, Verwendung und Entwicklung.
Wikipedia liefert zum Thema Mikroservices die folgende Definition:
“Microservices sind ein Architekturmuster der Informationstechnik, bei dem komplexe Anwendungssoftware aus unabhängigen Prozessen komponiert wird, die untereinander mit sprachunabhängigen Programmierschnittstellen kommunizieren. Die Dienste sind weitgehend entkoppelt und erledigen eine kleine Aufgabe. So ermöglichen sie einen modularen Aufbau von Anwendungssoftware.”
Wikipedia
In diesem Beitrag soll deshalb der Blick auf zwei Aspekte der Mikroservice Architektur gelenkt werden, einem sehr kleinen und einem sehr großen.
Eine Architektur spiegelt sich nicht nur in einigen Bibliotheken wieder, sondern auch in der Art und Weise, wie die Organisation diese Architektur umsetzt und verwendet.
Weil Microservices sehr klein und spezialisiert sind, sollen sie nur von einem Team entwickelt werden, dass die vollständige Hoheit über diesen Service und seine Domäne besitzt. Andere Teams kümmern sich um andere Microservices. So autark wie die Microservice sollten also auch ihre Teams sein. Da es nur schwache Kopplung zwischen den Microservices gibt, sind nur wenige Absprachen zwischen den Teams zu treffen.
Ein häufiger Fehler ist die Entwicklung aller Services in nur einem Team. Allein schon Conways Law erklärt das Scheitern dieses Ansatzes. Die Entwickler verschmieren die Services, erzeugen ungewollte Abhängigkeiten und Komplexität.
Microservices können sehr schnell implementiert und deployt werden. Klassische und damit lange Entwicklungszyklen behindern die Entwicklung, weil viel neue Features auf Halde liegen und kein schnelles Feedback erzeugen. Daher muss sich eine Organisation, die Microservices einsetzen möchte, einem kontinuierlichen Prozess öffnen. Die schnelle Entwicklung bietet die Möglichkeit, ganze Microservices in kurzer Zeit völlig neu zu implementieren. Die Zeit des “Wir können nichts ändern, weil wir schon so viel investiert haben” geht damit auch langsam ihrem Ende entgegen.
Eine Architektur die aus vielen autarken Microservices besteht, benötigt keine zentrale Steuerung, Entwicklung oder Planung. Vielmehr muss die Organisation in die Lage versetzt werden, den Teams die Möglichkeit zur direkten Absprache zu geben. Big Room Planning, Lean Coffee und Scrum of Scrum sind hier bewährte Techniken.
Soviel zu dem, was Mikroservices im Großen, für die Organisation und ihre Teams bedeuten.
Schaut man als Softwareentwickler auf einen Microservice als einzelnes Element dieser Architektur, dann fällt eine Ähnlichkeit mit einem ganz anderem Konzept auf. Microservices sollen sich mit einem speziellen, abgegrenzten Thema beschäftigen (Single-Responsibility-Prinzip), sie sollen in ihren Schnittstellen stabil bleiben, aber dennoch erweiterbar sein (Open-Closed-Prinzip), ein neuer Service, der einen alten ersetzt, sollte nicht mit unerwarteten Verhalten überraschen (Liskovsches Substitutionsprinzip), Services die zu viele Verantwortungen haben, sollten in mehrere Services aufgeteilt werden (Interface-Segregation-Prinzip) und zusätzlich sollten generelle Services nicht von spezialisierten Services abhängen (Dependency-Inversion-Prinzip). All diese Anforderungen entsprechen den SOLID Prinzipien der Objekt Orientierten Software Entwicklung.
Auch sonst ähneln Microservices den Objekt Konzept sehr. Microservices kommunizieren genauso wie Objekte über Nachrichtenaustausch und besitzen einen internen Zustand. Nachrichten sind bei ihnen beispielsweise Aufrufe ihrer REST Schnittstellen oder Benachrichtigungen über einen Event Mechanismus. Daher ist es nicht verwunderlich, dass es für Microservices einen Design-Pattern Katalog gibt, der frappierende Ähnlichkeiten mit dem der Objekte hat. Auf der einen Seite existieren Anti-Corruption Layer, Gateway, Gateway-Aggregation, Strangler und auf der anderen Seite ihre Entsprechungen wie etwa Gatekeeper, Facade, Decorator, Mediator, Proxy, Chain Of Responsibility und Branch By Abstraction.
Dies bedeutet zwar noch nicht, dass jeder OOP Kenner ein Spezialist für Microservices ist, aber Lösungen zu Problemen in der eigenen Microservice Architektur können einfacher gefunden werden.