Microservice oder Microservice-Architektur ist in aller Munde, gerade im Zusammenhang mit der Cloud. Aber was ist es?
Es gibt keinen formalen Standard oder eine allgemein anerkannte Definition, was ein Microservice oder eine Microservice-Architektur ist. Der Ursprung des Begriffs dürfte irgendwo zwischen 2005 und 2010 liegen und mehrere Urheber haben. Bei genauer Betrachtung liegen die Kernüberlegungen sehr viel weiter zurück, sie wurden einfach nicht so benennt. Die bekannt UNIX-Philosophie: "Write programs that do one thing and do it well" beschreibt im Grunde bereits die Ideen von Microservices. Dieses Zitat wird meist Malcolm Douglas McIlroy zugeschrieben. Er steuerte u.a. verschiedene Programme zum UNIX-System bei und gilt als ein Pionier des komponentenbasierten Softwaredesigns. Ein Microservice ist ein kleiner, unabhängiger Dienst, der eine spezifische Funktion innerhalb einer grösseren Anwendung übernimmt. Jeder Service kann dabei unabhängig von anderen Services deployed werden.
"... der eine spezifische Funktion innerhalb einer grösseren Anwendung übernimmt."
Was ist diese "grössere" Anwendung?
"Jeder Service kann dabei unabhängig von anderen Services deployed werden."
Warum ist das die vielleicht wichtigste Eigenschaft?
Zäumen wir das Pferd für einmal von Hinten auf:
Unabhängiges Deployment. Verschiedene Aspekte eines Microservice enden letztlich in der Fähigkeit, dass dieser eine Service für sich alleine deployed werden kann. Sie können sich vorstellen, dass der Nutzen gering ist, wenn Sie zwar mit verschiedenen Teams an unterschiedlichen Services arbeiten können, dieser aber dann letztlich nur gemeinsam deployed werden können. Alle Features und ggf. Korrekturen etc. müssen inhaltlich und zeitlich abgestimmt sein, damit diese am Tag X wieder zusammen funktionieren. Die Fähigkeit, ein Service unabhängig deployen zu können, bedingt verschiedene Voraussetzungen. Funktional muss der Services über nach aussen stabile Schnittstellen funktionieren, welche auch nach einem Release - ggf. versioniert - nach wie vor robust zur Verfügung stehen. Intern muss der Service über eine eigene Persistenz verfügen. Das heisst bspw. bei einer relationalen Datenbank, dass der Service Herr über die Tabellen ist, dass entsprechend keine anderer Service darauf zugreift, so dass der eine Service selbständig Änderungen an der Datendefinition vornehmen kann. Nur Herr über die Tabellen, oder auch über die gesamte Datenbank oder gar den gesamten Datenbank-Service? Wir kommen später darauf zurück. Bezüglich des Deployments schliesslich muss der eine Service über eine eigenständige Laufzeit verfügen. Das bedeutet, dass der Service bspw. auf Node V20 (LTS) läuft, während andere Services noch auf V18 (LTS) angewiesen sind.
Kann man einen Service wirklich unabhängig deployen, so ist er genügend gekapselt, um neue Funktionen rasch und sicher zur Verfügung stellen zu können. Das Gegenteil einer monolithischen Architektur.
Damit zurück zur "grösseren Anwendung".
Um hier etwas mehr Klarheit zu erlangen muss kurz ein weiterer Begriff, SOA, eingeführt werden.
Service Orienterte Architektur, SOA
Der Begriff Service Orienterte Architektur wurde 1996 erstmals von Gartner verwendet. Eine standardisierte Definition gibt es aber auch bei SOA nicht. SOA kapselt IT-Komponenten in Dienste, die dann orchestriert werden, um übergeordnete Geschäftsleistungen zu erbringen. Das Ziel ist es, die Komplexität der IT-Landschaft zu reduzieren und die Wiederverwendbarkeit von Softwarekomponenten zu erhöhen.
Es gibt Vertreter, welche die Unterscheidung zwischen Microservice- und Service orientierter Architektur in Makro- und Mikro-Sicht unterscheiden: SOA für die Unternehmensebene, Microservice für eine einzelne Applikation.
Diese Betrachtung greift meines Erachtens etwas zu kurz.
Ist eine SOA nicht ein Widerspruch zu Microservice?
SOA hat ein Ziel darin, Redundanzen zu reduzieren, während Microservice den Anspruch hat, Services unabhängig zu deployen. Nehmen wir das Beispiel Datenbank. In einer SOA ist eine Datenbank und insb. das Datenbank-Management-System, ein zentraler Service. Dies reduziert die Wartungsaufwände und macht die IT-Landschaft weniger komplex. Einen Microservice können Sie aber nicht so unabhängig wie definiert deployen, wenn die Datenbank, resp. das Datenbank-Management-System eine zentrale Komponenten ist. Was geschieht, wenn Ihre SOA-Datenbank PostgreSQL V15 ist, Ihr Microservice aber Funktionen von PostgreSQL V16 benötigt?
Macht die Cloud SOA überflüssig?
Cloud-Architekten kennen die drei Schichten:
- IaaS: Infrastructur as a Service
- PaaS: Platform as a Service
- SaaS: Software as a Service
Es ist zu Beginn relativ einfach, auf der Cloud eine Anwendung in einer reinen Microservice-Architektur zu deployen. Jeder Service läuft in einem eigenen Container in der gewünschten Laufzeit. Jeder Service hat eine eigene Datenbank als managed Service etc.
Fakt ist: Heutige Hyperscaler wie Google mit der Google Cloud GCP machen es wesentlich einfacher, Anwendungen als Microservice zu deployen.
Fakt ist aber auch, dass dies aus Sicht einer Gesamtarchitektur und unter Berücksichtigung von Ressourcen wie Geld und Mitarbeiter, in der reinen Form nicht in jedem Fall sinnvoll ist.
Die Verwendung von verschiedenen Cloud-Layern (insb. PaaS und SaaS) in einer Microservice-Architektur erschweren es, diese sinnvoll "rein" zu halten und drängen gewisse Kompromisse auf.
GCP bietet viele managed Services an und es lohnt sich in der Regel nicht, das Rad neu zu erfinden, wenn die benötigte Funktion als managed Service bezogen werden kann. Dabei ist die Unterscheidung gerade zwischen PaaS und SaaS nicht immer logisch scharf zu ziehen, die Grenzen von PaaS zu SaaS verwässern da zunehmend. Aber gerade bei diesen managed Services ist es vielfach so, dass diese spezialisiertes Wissen erfordern, teilweise Sockelkosten haben (nicht alles rein "pay as you go") und im Betrieb eine zentrale Überwachung benötigen. Schauen wir uns das am Beispiel von Apache Airflow an. Apache Airflow gibt es bei Google als managed Service: Cloud Composer.
Spezialisiertes Know-how:
In Airflow entwickelt man seine Workflows in Python. Der Rest eines Microservice wird vielleicht in Java oder Scala geschrieben. Im Unternehmen gibt es daher entsprechend ein dediziertes "Composer-Team", welches für verschiedene Services die notwendigen Composer-Workflows implementiert.
Geld:
Cloud Composer hat Sockelkosten. Hinweis: Die Preismodelle für Cloud Composer 1, 2 und 3 sind unterschiedlich. Das heisst, es fallen Kosten an, auch wenn gerade kein Workflow läuft. Es lohnt sich daher kaum, für jeden Microservice eine eigenen Composer-Instanz bereit zu stellen, vor allem, wenn diese bspw. nur unregelmässig einzelne Workflows benötigt.
Zentrale Überwachung:
Airflow bietet gute Überwachungsmöglichkeiten. Der Vorteil schwindet aber, wenn es mehrere Instanzen gibt. Es ist umständlich, wenn Sie als AM-Mitarbeiter bei einem Incident zuerst schauen müssen, welche Instanz Sie benötigen und daher zuerst jeweils 2-3 Mal die falsche öffnen.
Alles in allem Spricht einiges dafür, Cloud Composer zentral, mindestens für eine Gruppe von Services zentral, zu betreiben. Dasselbe gilt bspw. auch für Dienste wie Dataflow. Selbst für ein Datenbank-Management-System gibt es Vorteile für ein Sharing. Denn auch wenn eine Datenbank als managed Service wie Cloud SQL bezogen wird, braucht es Wartung. Sie müssen die Backups regelmässig überprüfen und BCM-Tests durchführen. Sie müssen bestehende Applikationen Regressionstesten, wenn Versionsupgrades anstehen. All diese Aufwände erhöhen sich massiv, wenn Sie pro Microservice eine eigene Instanz von Cloud SQL haben. Also vielleicht besser ein Datenbank Management-System oder gar eine Datenbank pro Anwendung und nicht pro Service und die Microservice-Kapselung auf Stufe Datenbank-Schema oder gar Tabelle machen? Und damit erneut zurück zur Frage: Welche grössere Anwendung?
Was also ist in einer Microservice-Architektur eine Anwendung, oder gar eine grössere Anwendung?
Sie kommen nicht darum herum, in Ihrer IT-Architektur verschiedene Systemgrenzen zu definieren. Und obwohl Microservice in der Cloud das bevorzugte Architektur-Pattern ist, werden Sie nicht um Kompromisse herum kommen.
Sie müssen definieren, welche Services eine Anwendung ausmachen. Welche gemeinsamen Ressourcen sich die Services einer Anwendung teilen und welche Ressourcen sich die Anwendung mit anderen Anwendungen teilt.
Denn das nächste Beispiel zeigt, dass es durchaus Beispiele von managed Services gibt, die nur für eine Gruppe von Anwendungen oder je nach Grösse des Unternehmens gar nur auf Unternehmensstufe sinnvoll sind: API Management Plattformen wie Apigee.
In der heutigen Zeit von API-First spielen API eine zentrale Rolle und früher oder später kommt man nicht um eine API Management Plattform herum. Diese entfaltet aber gerade dann ihre Stärke, wenn sie mehrere oder gar alle Anwendungen/Services orchestrieren kann. Eine API Management Plattform pro Service ergibt keinen Sinn. Und damit haben Sie aber eine zentrale Abhängigkeit und wenn nicht schon vorher, ab jetzt haben Sie Ihren ersten Kompromiss in der Microservice-Architektur. Wenn auch die Abhängigkeiten klein sind, eine (geringe) Abhängigkeit haben Sie nun vom API Management. Sogar fachlich, wenn Sie bspw. die REST Schema-Validierung des Microservice an den API-Gateway auslagern.
Ein weiteres, vielleicht noch offensichtlicheres, Beispiel ist das Identity and Access Management (IAM). Niemand kommt auf die Idee, dieses pro Service zu deployen. Dies ist eine zentrale Komponente und ein Service kann nicht unabhängig davon deployed werden.
Ich habe bereits erwähnt, dass "SOA für die Unternehmensebene, Microservice für eine einzelne Applikation" als Differenzierung zu kurz greift. Vielmehr haben wir gesehen, dass die beiden Pattern in der Cloud sinnvollerweise ineinander greifen.
Ich empfehle Ihnen, Ihre Cloud-Architektur mit beiden Brillen zu betrachten und für Ihre Bedürfnisse sinnvolle Systemgrenzen zu ziehen.
Wenn Sie den Begriff SOA nicht mögen, können Sie auch unterschiedliche Typen von Microservices definieren. Anstelle von Anwendung können Sie auch von einer Gruppe von Microservices sprechen. Nehmen Sie Begriffe die Ihnen passend erscheinen. Aber erstellen Sie ein differenziertes Zielbild von Komponenten, welche unterschiedliche Aufgaben und unterschiedliche Abhängigkeiten haben. So unabhängig wie möglich, so zentral wie sinnvoll.
Ein solches Architektur-Schema können Sie Blended Microservice Architectur (BMA) nennen.
Microservices sinnvoll in eine unternehmerische Gesamtarchitektur eingebettet, unter Nutzung einer Public Cloud. Damit ist klar, dass die IT-Architektur in der klassische Anwendungsentwicklung im Cloud-Zeitalter in vielen Fällen nicht unabhängig einer Gesamtarchitektur auf Unternehmensebene der Cloud-Plattform definiert werden kann. Software in Form von (Micro-) Services ist eng mit der Infrastruktur verbunden und entfaltet nur als Einheit orchestriert ihr volles Potential.
Keine Kommentare:
Kommentar veröffentlichen