Microservices ist nicht nur ein neues Schlagwort in Software-Design-Diskussionen, das darauf wartet in der nahen Zukunft wieder zu verschwinden. Microservices werden sich durchsetzen. Die Idee ist nicht neu, es gab sie seit vielen Jahren getarnt als Service orientierte Architektur oder unter anderer urheberrechtlich geschützter Nomenklatur. Also, was ist passiert und wie kann man den jüngsten Erfolg von Microservices erklären?


In unserem Unternehmen geht es vor allen Dingen (maßgeblich) um die Kosten der Software-Entwicklung, deren Bereitstellung und Wartung. Andere gewinnen durch die Verteilung auf verschiedene Entwicklungsteams Überschaubarkeit und dadurch bessere Beherrschbarkeit. Was auch immer die Motivation sein mag, das Ergebnis eines Wechsels zur Microservice Architektur ist eine Vereinfachung der manchmal beängstigenden Aufgabe ein Software Team zu führen und langfristigen Service bieten zu können.

Microservices sind kleine, überschaubare Software Einheiten, leicht zu implementieren, zu erweitern oder sogar zu ersetzen.

Diese Implementierung ist so einfach wie das Starten eines neuen Prozesses. Der neue Prozess logt sich in einen Service Dienstleistungsprozess ein, der Ressourcen (Kommunikationsanschlüsse, Datenbankverbindungen und mehr) verteilt. Ein anderer Microservice arbeitet als Watchdog-Funktion und überwacht den neuen Prozess. Ein weiterer Microservice stellt eine Logging-Funktion zur Verfügung und das neue Verfahren hat das System schneller verbessert als es brauchte um die letzten 3 Zeilen zu lesen. Der Prozess kann für Testzwecke gestoppt und wieder gestartet werden ohne negative Auswirkungen auf den Rest des Systems, das einfach weiter läuft.

Nach der Testphase schaltet der neue Microservice seine Schnittstellen (AIPs) für die anderen Services frei. Alle Microservices und all ihre Schnittstellen benutzen diesselbe Syntax, sodass es sehr einfach ist ältere Services zu modifizieren um die neuen Schnittstellen nutzen zu können. So übernimmt quasi der neue Microservice "Verantwortung" innerhalb des Systems und andere Microservices werden "abhängig" von dieser Funktionalität.

Was passiert falls der neue Prozess unter Druck zusammenbricht?

Bauen wir ein Kartenhaus und warten darauf bis eine Karte kippt? Das sollte nicht passieren. Gut konzipierte Systeme werden ohne Unterbrechung weiterlaufen, indem sie ältere Versionen des Microservices benutzen oder die neue Schnittstelle komplett meiden.

Software Umgestaltung oder Ersatz notwendig?

Nicht das Problem, das es früher einmal war. Sie werfen nur ein kleines Stück Code in den Müll, in unserem Fall wahrscheinlich so wenig wie eine Seite Code. Das macht die Dinge wirklich einfacher. Es befreit uns von der Last der Systemverbesserungen und beschleunigt den Software-Management-Zyklus.