Microservices

Vorweg sei gesagt: Ja, das Thema ist ziemlich ausgelutscht, Hype und irgendwie in aller Munde. Grund genug sich auch endlich einmal damit auseinanderzusetzen ..

Nun ist die Frage: Wo fängt man eigentlich an? Ich persönlich bin auf das Thema das erste Mal auf der JavaLand aufmerksam geworden, dort allerdings eher passiv. Zu dem Zeitpunkt wusste ich noch nicht sonderlich konkret etwas damit anfangen. Man hat also erstmal ein paar Begriffe aus diesem Kontext gesammelt, geschaut und mit der Zeit und steigender Beliebtheit des Themas, verdichtete sich auch die Vorstellung davon, was das ganze eigentlich ist.

Für mich persönlich ist es in erster Linie ein Architekturstil, welcher sich ein einer möglichst hohen Flexibilität, Modularität und Wiederverwendbarkeit ausdrückt.

Die genannten Aspekte beziehen sich hierbei nicht nur primär auf die Software selbst, sondern ebenso auf ihren gesamten Lebenszyklus und den Entwicklungsprozess an sich.

Dies ist meiner Meinung nach auch einer der Hauptgründe, weshalb es nicht ohne weiteres möglich ist, diesen Architekturstil großflächig und kurzfristig in bestehenden Strukturen zu etablieren.
Für größere Projekte die neu beginnen, kann eine solche Architektur (insofern sie notwendig erscheint) einkalkuliert werden. Das bedeutet aber nicht, dass es nicht vielleicht einen Mittelweg geben kann..

Eine Idee wäre es, zum Beispiel, Modularisierung bereits im Monolithen zu treiben und zu fokussieren sodass die Trennung und Modularisierung nicht nur auf der Ebene der Schichten (Persistenz / BL / UI) geschieht, welche lose gekoppelt miteinander interagieren, sondern auch Fachlich bereits getrennt wird. Eventuell eine vertikale Fassade, die eine Menge von Fachobjekten die eine bestimmt Funktionalität oder einen Service realisieren, kapselt. 

Jedenfalls würde die beschriebene Variante einer späteren Trennung in einzelne Services in die Hände spielen, die Fassaden werden auf REST Schnittstellen umgelegt, die Logik in eine gekapselte Deployment Unit herausgezogen und die Persistenz auf ein eigenes Schema oder eine eigene DB verlegt.

Allerdings liegt auch hierbei der Teufel im Detail. So unproblematisch das ganze klingen mag, werden hier und dort sicherlich Fallstricke auftauchen.. 

Ein Grund dafür, weshalb sich nicht nur der Fokus auf die Software, sondern auch der Entwicklungsprozess anpassen muss, um diese Konzepte zu unterstützen. Deployment-Zyklen von 1/2 Jahr oder länger, lassen wenig Raum für "Experimente". Teams mit enormer Fluktuation machen es schwierig, die Software zu warten und weiterzuentwickeln. Aufwändige und manuelle Prozesse (Test sowie Deployment) machen es schwierig, Anpassungen zu verteilen und zeitnah zur Verfügung zu stellen.

Technische Werkzeuge und Prozesse funktionieren nur gemeinsam mit den Menschen die sie nutzen. Deshalb ist ein Team, dass hinter dem Gedanken steht und Verantwortung übernehmen möchte, in diesem Zusammenhang genauso wichtig, wie die architektonischen Prinzipien, die Werkzeuge und die Prozesse.

Bereits ohne jetzt zu sehr in die Tiefe zu gehen ( es gibt haufenweise Artikel dazu ) stellt sich heraus, dass es sich hier um eine Umstellung im großen Kontext handelt, anstatt um Feintuning. Die Darseinsberechtigung von Monolithen oder stark verteilten Systemen zu diskutieren würde an dieser Stelle ebenfalls den Rahmen sprengen.

Ich für meinen Teil werde das Thema weiterhin im Auge behalten und hoffentlich auch etwas Praxiserfahrung diesbezüglich einsammeln können. Insbesondere die Netflix-Implementierungen im Zusammenhang mit Spring Boot haben es mir angetan und müssen zu mindestens exemplarisch mal ausprobiert werden. Eventuell werde ich dann auch mal meinen Knoten im Hirn bezüglich Docker los.