Microservices vs. Monolith – Paradigmenwechsel in der Software-Entwicklung

In einer sich ständig wandelnden Geschäftswelt müssen sich auch Anwendungen und Programme schnell an die Anforderungen der Nutzer anpassen können. Und genau darin liegt die Stärke von Microservices. Denn Microservices unterstützen lose miteinander verbundene Architekturen und die unabhängige Skalierung der einzelnen Komponenten. Darin unterscheiden sie sich von der traditionellen monolithischen Softwareentwicklung.

Microservice vs. Monolith: der Unterschied metaphorisch verdeutlicht

Nähern wir uns der Angelegenheit mit einem Bild. Ebenso wie beim Hausbau gibt es eine Vielzahl von Möglichkeiten, wie IT-Systeme entworfen und gebaut sind. Daran lässt sich der Unterschied zwischen einem Microservice im Vergleich zu einem Monolithen sehr anschaulich verdeutlichen.

Der monolithische Ansatz

Man stelle sich zur Vereinfachung ein Ein-Familien-Haus vor: Je nach Bedarf kann der Architekt ein klassisches Haus in rechteckiger Form bauen Die Architektur ist starr, alles hat seinen festen, vorab definierten Platz. Fenster, Türen, Wände, Keller und Etagen… – ein monolithisches System, ein starres Gebilde. Will der Bewohner hier nach Jahren etwas ändern, dann steht er vor einer Vielzahl von Problemen: Kann ich zum Beispiel wirklich diese oder jene Wand einreißen oder im Dachgeschoss neue Wände und somit Räume für diverse Zwecke errichten – oder gefährde ich dann die Statik? In der Software-Entwicklung entspräche dieses Konzept dem Monolithen (s.u.)

Der Microservice-Ansatz

Ein Hausbesitzer kann sich aber auch von Anfang an für eine flexible, modulare Bauweise entscheiden. Eben in der Voraussicht, dass seine Bedürfnisse sich in Zukunft ändern werden. Im ersten Schritt überlegt der Bauherr sich, das Haus aus einzelnen Containern zu bauen. Schon während seiner Anfangsüberlegungen, fällt ihm ein, nicht auf quaderförmige Container zu setzen – sondern auf Container in einem hexagonalen Format, ähnlich der Waben eines Bienenstocks. Warum wird gleich klar. So kann er z. B. ein Haus aus hexagonalen Containern bauen, indem der Bauherr nicht nur weitere daneben und obendrauf stapelt. Vielmehr kann er später z.B. in der dritten Etage einfach auch einen Container wieder rausziehen, ohne dass die vierte oder fünfte Etage in Mitleidenschaft gezogen wird. Dieser Ansatz entspräche einer Microservices-Architektur.

Diese sehr simple Darstellung lässt sich auch auf IT- und Software-Systeme übertragen. Das klassische Haus entspräche in etwa der monolithischen Architektur, das Containerhaus der Microservice-Architektur. Beide besitzen Vor- und Nachteile.

Monolithen und Microservices: Unterschiede

Eine traditionelle monolithische Architektur ist als ein großes System gebaut und basiert meistens auf einem Code. Sie wird meistens im Ganzen bereitgestellt – das heißt, dass bei Änderungen von Details die ganze Architektur bearbeitet und geschlossen zur Verfügung gestellt werden muss. Bei Microservices hingegen sind Apps als eine Suite kleiner Services gebaut, die alle eine eigene Code-Basis haben. Diese Services sind rund um bestimmte Funktionalitäten gebaut und können unabhängig voneinander bereitgestellt werden. Das heißt, für Detailänderungen muss stets nur der entsprechende Microservice geändert werden und es muss nicht die gesamte App neu aufgelegt werden.

Das hat entscheidende Vorteile, was sich zum Beispiel in der Geschwindigkeit der Bereitstellung und Entwicklung im Rahmen von Continuous Delivery bemerkbar macht. In der Realität erhöhen Microservices aber auch die Komplexität, so dass sie schwerer zu managen sind. Und auch Themen wie die IT Governance und Compliance sind häufig ungeklärt.

Konventionell denkende Unternehmen und IT-Abteilungen tendieren daher dazu, zunächst mit einer traditionellen Monolith-Architektur zu beginnen, vor allem, wenn es sich um ein nur sehr kleines Team handelt und die Zeitvorgaben sehr eng sind. Dabei ist das nicht immer die richtige Entscheidung. Die richtige Wahl hängt ganz von der Projektart ab. Um das besser zu verstehen, ist zunächst eine klare Definition beider Optionen, sowie eine Auflistung ihrer Vor- und Nachteile notwendig.

Monolith: Was ist darunter zu verstehen?

Eine monolithische Anwendung ist als eine einzelne und zusammenhängende Einheit gebaut. Meistens besteht sie aus drei Teilen: einer Datenbank, einem User-Interface und einer serverseitigen Applikation. Diese handhabt Anfragen, führt domainspezifische Logik aus, ruft Daten von der Datenbank ab und sorgt für das entsprechende Update und pflegt die HTML Ansichten ein, die an den Browser geschickt werden.

In einer Monolith-Logik sind die Frontend Logik auf Seiten des Users, die Prozesse Hintergrund, die Server-Logik etc. alle in der gleichen massiven Code-Basis hinterlegt. Wenn Entwickler Veränderungen und Updates vornehmen, müssen sie den gesamten Stack komplett neu bauen und bereitstellen. Das heißt aber nicht, dass ein Monolith eine veraltete Architektur ist, die wir in der Vergangenheit lassen sollten. Für bestimmte Anwendungszwecke ist ein Monolith ideal, zum Beispiel bei einer kleinen Anwendung, bei der es viel zu aufwändig wäre, diese in einzelne Microservices aufzusplittern.

Monolith-Vorteile im Detail:

• Der größte Vorteil einer monolithischen Architektur ist, dass es bei den meisten Apps viele Überschneidungen gibt – etwa bei Protokollierung oder Sicherheitsfunktionen und diese sich in monolithischen Architekturen einfacher handhaben lassen. Wenn alles über die gleiche App läuft, dann ist es einfach Komponenten anzuschließen.
• Geringere betriebliche Gemeinkosten: Da es sich nur um eine große Applikation handelt, müssen auch nur für eine Applikation Logs, Monitoring und Tests eingerichtet werden. So ist die App auch ganz grundsätzlich einfacher bereitzustellen.
• Performance: Auch hier können sich Vorteile bieten, da keine Kommunikation zwischen einzelnen Services stattfindet.

Monolith-Nachteile im Detail:

• Feste Verkopplung: Monolithische Architekturen neigen dazu sich enger zu verzahnen und zu verstricken, wenn sich die Applikation weiterentwickelt, was es schwierig macht, einzelne Services für einen Zweck zu isolieren, wie etwa für eine unabhängige Skalierung oder Code-Wartung.
• Höhere Komplexität: Monolithische Architekturen sind sehr viel schwieriger zu verstehen, denn es gibt immer Abhängigkeiten und Auswirkungen, die sich nicht eindeutig erkennen lassen, wenn man sich einen bestimmten Server oder Controller anschaut.
• Wächst eine monolithische Anwendung, so wächst auch die damit verbundene Code-Basis, die die Entwicklungsumgebung jedes Mal überlastet, wenn die Applikation lädt. Das reduziert die Produktivität der Entwickler.
• Da die Applikation zum Beispiel auf EAR/JAR/WAR läuft, wird es schwierig, die Technologie nachträglich zu ändern. Die Code-Basis eines Monolithen zu ändern ist kompliziert, da sich immer nur schwer absehen lässt, wie sich das auf die Funktionalität der gesamten monolithischen Anwendung auswirkt.
• Versagt eine einzelne Funktion des Monolithen oder eine einzelne Komponente, dann versagt die gesamte Anwendung. Wenn zum Beispiel eine Anwendung Funktionen wie Bezahlung, Login und History beinhaltet und nur eine der Funktionen beginnt, mehr Rechenleistung zu beanspruchen, dann behindert das die Leistung der gesamten Anwendung.
• Wer monolithische Applikationen skalieren will, der kann dies nur tun, indem er die gleichen EAR/JAR/WAR Pakete auf zusätzlichen Servern verteilt. Das bezeichnet man als horizontale Skalierung. Jede Kopie der Applikation auf zusätzlichen Servern nutzt die gleiche Zahl der darunterliegenden Ressourcen, was es zu einem ineffizienten Design macht.
• Monolithische Architekturen beeinflussen die Entwicklung ebenso wie die Bereitstellung von Applikationen. Wenn sich Applikationen vergrößern, dann ist es umso wichtiger, Applikationen in kleinere Komponenten aufzubrechen. Da alles so eng zusammenhängt, können Entwickler bei monolithischen Architekturen nicht unabhängig voneinander arbeiten oder nur ihre eigenen Module bereitstellen. Vielmehr sind sie abhängig von anderen und das verlangsamt die Entwicklungszeit.
• Ob neue Funktionen, Oberflächen oder Schnittstellen: Software muss schnell und einfach Neuerungen bereitstellen, ohne dabei die bestehenden Anwendungen negativ zu beeinflussen. Dies ist auch für Softwarehersteller keine einfache Aufgabe, denn häufig ist bestehende Software noch als Monolith entwickelt: Und je größer der Monolith wird, desto risikoreicher ist es, neue Funktionen schnell bereitzustellen.

Mit diesen Nachteilen im Hinterkopf soll nun ein Blick auf die Microservices geworfen werden. Dabei gilt es Fragen zu beantworten, warum gerade Microservices im Vergleich zum Monolithen ein Plus an Flexibilität bieten und welche Faktoren die Vorsetzung für einen erfolgsversprechenden Einsatz von Microservices bieten –  nicht verschwiegen  werden  auch die Nachteile der Microservices. 

Definition von Microservices

Microservices stellen ein Architekturkonzept dar, das die Art und Weise der Anwendungsentwicklung revolutioniert. Umfangreiche Anwendungssoftware, die konzeptuell über Microservices realisiert wird, besteht aus kleineren, voneinander unabhängigen Programmen. Jedes dieser Programme kümmert sich genau um eine Aufgabe – getreu der Unix-Philosophie: „Do one thing well.“ Diese Programme kommunizieren als Microservices über wohl definierte APIs (Schnittstellen) miteinander, was neue Spielräume für Entwicklungsteams eröffnet, da Schnittstellen im Idealfall gegenüber den verwendeten Programmiersprachen agnostisch sind.

Microservices sind nicht unbedingt klein oder „micro“. Sie sind zwar in der Regel kleiner als klassische Monolithen, aber die Komplexität oder die Codebasis können durchaus sehr umfangreich sein. Die Microservice-Architektur ist ein Ansatz, um eine Applikation bereitzustellen, die aus einem Satz kleinerer Services besteht, die alle über ihre eigenen Prozesse verfügen und über Schnittstellen (API) kommunizieren. Diese Services sind rund um Fähigkeiten gebaut, die ein Unternehmen bereitstellen muss, und werden durch automatische Deployment-Mechanismen unabhängig voneinander bereitgestellt. Das Management dieser Services ist dabei zentralisiert und auf ein Minimum reduziert.

Gleichzeitig erzwingt das Microservices-Paradigma eine Unabhängigkeit der einzelnen Microservices voneinander. Ein einzelner Microservice funktioniert unabhängig von allen anderen Services und Diensten. Tritt ein Ausfall auf, bringt dieser nicht alle anderen Services zum Stillstand. Ein Software-System, das konzeptionell aus vielen dieser Microservices besteht, lässt sich mit Recht eine Microservices-Architektur nennen.

Microservices-Vorteile im Detail:

Sollten Flexibilität und Geschwindigkeit gegenwärtig in der Geschäftswelt von Bedeutung sein, kommt einer Microservice-Architektur eine besondere Rolle zu.  Zwar sollte der initiale Aufwand, eine Microservice-Architektur zu planen, zu entwickeln und schließlich auszurollen, nicht unterschätzt werden. Jener ist mit Sicherheit höher als im Vergleich zu einer monolithischen Applikation. Aber: Steht die Architektur erst einmal, lassen sich viele Microservice-Vorteile ausspielen. Dann stellt es ein Unternehmen eben nicht mehr vor Probleme, z.B. neue Geschäftsideen “einfach mal“ auszuprobieren.

So wäre es dann ohne  Weiteres möglich, Geschäftsideen oder Ziele über sogenannte „minimum viable products“ (MVPs) beschleunigt einem ersten Realitätstest zuzuführen. Darin liegt einer der Microservice-Vorteile. Gleiches gilt für darauffolgende, schnelle Iterationen von Fehlerkorrekturen, Anpassungen und Verbesserungen des ersten MVPs als Microservice – ideal für serviceorientierte Architekturen. Aber dies ist eben nur einer der Microservice-Vorteile. Schauen wir uns an, was Microservices noch an Vorteilen bieten und warum dies so ist.

• Eine kleinere Codebasis bedeutet eine geringere Komplexität innerhalb der einzelnen Microservice.
• Skalierbarkeit: Einer der größten Vorteile von Microservices ist die Skalierbarkeit. Es lassen sich einzelne Services mehrfach skalieren. Große Unternehmen wie Amazon, Netflix oder eBay nutzen bereits die Vorteile von Microservices. Dazu gehören eine bessere Fehlerisolation, die Vermeidung von Lock-in-Effekten, einfache Verständlichkeit und die einfache Skalierung durch Bereitstellung in Containern.
• Bessere Organisation: Microservice-Architekturen sind typischerweise besser organisiert, da jeder Microservice eine spezifische Aufgabe hat und sich nicht weiter mit den anderen Komponenten beschäftigt.
• Entkoppelung: Entkoppelte Services sind einfacher wieder zu zerlegen und neu zu konfigurieren, um dem Zweck verschiedener Apps zu dienen (z.B. dem Authorisierungs- sowie Streaming-Dienst). Sie erlauben auch eine schnellere, unabhängige Auslieferung einzelner Teile innerhalb eines größeren, integrierten Systems. Jeder dieser Microservices ist in sich abgeschlossen und hat nur die eine ihm zugedachte Aufgabe. Es ist somit sehr einfach, weitere Microservices hinzuzufügen, ohne die Stabilität der ganzen Software zu gefährden. Auch die Weiterentwicklung von Services ist so viel leichter möglich, da die Komplexität deutlich reduziert ist. Eine Software, die auf einem solchen Paradigma basiert, kann eine hohe Stabilität und gleichzeitig eine schnelle Weiterentwicklung ermöglichen.
• Leistung: Unter den richtigen Umständen können Microservices Leistungsvorteile liefern, abhängig davon, wie sie organisiert sind, vor allem, weil stark beanspruchte Dienste isoliert und unabhängig vom Rest der App skaliert werden können. Während in einem Monolithen jede Funktion nur einmal verfügbar ist und nur mit dem ganzen Monolithen skaliert, können Microservices beliebig oft verfügbar sein. Als Beispiel sei hier ein Suchservice genannt: Wenn Sie feststellen, dass die Anwender der Software sehr viel suchen, dann kann genau dieser Service mehrfach verfügbar sein, um weiterhin eine gute Performance der Suche zu gewährleisten. Es ist aber hierbei nicht nötig auch die anderen Services mehrfach zu starten, sondern nur den, den sie mehrfach brauchen. Diese Fähigkeit macht die Software nicht nur extrem leistungsfähig, sondern führt auch dazu, dass sie wirtschaftlich sehr effizient ist.
• Weniger Fehler: Microservices ermöglichen parallele Entwicklungen, da es schwer zu überschreitende Grenzen zwischen verschiedenen Teilen des Systems gibt. Das macht es schwieriger, das Falsche zu tun, nämlich Teile miteinander zu verbinden, die nicht verbunden gehören, oder Dinge, die verbunden gehören, zu eng zu verbinden. Dies sorgt für eine hohe Ausfallsicherheit.

Microservices-Nachteile im Detail:

• Der größte Nachteil von Microservices liegt in der Konvergenz verschiedener Services: Wer eine Miroservice-Architektur erstellt, wird feststellen, dass sich viele Ansätze überschneiden. Eine Lösung ist es, Schnittstellen komplett durch eine separate Schicht laufen zu lassen, die genau für die Prozesse zuständig ist. Sogar in monolithischen Architekturen läuft Traffic häufig durch eine äußere Service-Schicht für genau diese Überschneidungen, allerdings lassen sich die Kosten dieser Arbeit bei monolithischen Architekturen sehr viel länger herauszögern, also bis das Projekt sehr viel weiter vorangeschritten und gereift ist.
• Höhere operative Gemeinkosten: Microservices werden häufig auf ihren eigenen virtuellen Maschinen oder in Containern bereitgestellt, was oft für einen Kostenzuwachs sorgt. Diese Aufgaben werden häufig automatisiert. Jeder Microservice stellt ein unabhängiges System dar; das gilt auch für den Deployment-Prozess; Ressourcen müssen vorgehalten werden. Hoher Aufwand bei der Migration von Alt-Systemen in die neue Microservice-Architektur.
• Anpruchsvolles Monitoring der Microservices: Wer eine klassische App in Microservices aufbricht oder ein ganz neues Microservice-System baut, hat sehr viel mehr Services zu überwachen. Die Services sind auf verschiedenen Maschinen und/oder in unterschiedlichen Containern aktiv; nutzen verschiedene Technologien und/oder Sprachen und verfügen gegebenenfalls über ihre eigene Versionskontrolle. Unschwer zu erkennen: Hier besteht das dringende Bedürfnis nach zentralisierter Überwachung und Protokollierung.
• Aufwendige Fehlersuche: Angenommen ein Microservices-Verbund besteht aus mehreren hundert Microservices, die miteinander interagieren. Hier nun die Ursache eines Fehlers herauszufinden, die sich ja potentiell gleich über gleich mehrere Services verteilt, ist nicht einfach. Das macht es notwendig ein zentralisiertes Werkzeug zu haben, das diese Probleme von der Wurzel her erkennt.

Grundsätzlich ist ein Blick auf die Vor- und Nachteile beider Ansätze sinnvoll. Als Entscheidungsgrundlage für Unternehmen sind sie allein aber nicht ausreichend. Vielmehr sollten sich Unternehmen einige essentielle Fragen stellen, um sicher zu gehen, dass sie den richtigen Ansatz für ihr Unternehmen wählen.

Beispiele für Microservices – Arbeitsteilung konkret veranschaulicht

Nehmen wir die Website eines Paket- und Briefdienstes. Auf dieser Website stehen zahlreiche Microservice-Beispiele zur Verfügung:

• Sendungsverfolgung,
• Portoberechnung,
• Online-Frankierung,
• Wunschort zum Sendungsempfang etc.

Und all dies natürlich auch als Services für Privat- und Geschäftskunden. Und nur weil zum Beispiel die Sendungsverfolgung ausfällt, heißt das eben nicht, dass alle anderen Microservices in Mitleidenschaft gezogen werden und nicht mehr verfügbar sind. Diese Dienste stellen gute Beispiele für eine Microservice-Architektur dar. Viele der Dienste lassen sich z.B. über eine Rest-API ansprechen; natürlich lassen sich Microservices dann eben auch über eine App für iOS und Android benutzen. Dies sind allesamt Indizien, die auf eine Microservices-Architektur hinweisen könnten.

Monolithische Architekturen – traditionell aber nicht überholt

Um überhaupt Microservice-Architekturen zu verstehen, lohnt sich zunächst nochmals ein Blick auf klassische Architekturen. Deren Struktur kann man sich als eine einzige große Anwendung vorstellen, einen Block, in dem der gesamte notwendige Code gesammelt ist. Schlechterdings sind die bereitgestellten Funktionen zwar modularisiert, dabei weder voneinander unabhängig noch als unabhängig vom gesamten Block zu sehen. Den Monolithen gibt es nur en bloc. Fertiggeschrieben wird die Software und als Einheit kompiliert und „deployed“, das heißt auf Anwender PCs oder auf Servern verteilt. Jener wurde vor Jahren als monolithische Anwendung realisiert (300 bis 500 MB groß, Compile-Zeit bis zu 10 Std.). Nicht leicht zu warten und nicht ohne weiteres ließen sich neue Funktionen hinzufügen, vom Deployment ganz zu schweigen.

Microservices oder Monolith: Den richtigen Ansatz wählen

1. Bewegt sich das Unternehmen auf bekanntem Gebiet?

Wer sich in einem Bereich bereits gut auskennt und den entsprechenden Nutzen kennt, kann direkt mit Microservices experimentieren. Wer sich aber auf komplett unbekanntem Terrain bewegt und keinerlei Vorerfahrungen auf dem zu bearbeitenden Gebiet hat, ist bei monolithischen Architekturen häufig besser aufgehoben.

2. Ist das Team gut vorbereitet?

Hat das Team bereits Erfahrungen mit Microservices? Und sind Microservices der richtige Ansatz, wenn das Team sich weiter vergrößert? Die Dimensionen zu evaluieren ist essentiell für den Erfolg eines Projekts. Wenn ein Team bereits gut vorbereitet ist, dann ist es sinnvoll direkt mit den Microservices zu beginnen, damit sie sich an den Rhythmus der Entwicklung in einer Microservice-Umgebung gewöhnen – und das gleich von Anfang an.

3. Wie ist die Infrastruktur?

Damit Microservices für ein Projekt funktionieren, bedarf es einer Cloud-basierten Infrastruktur. Mit modernen Cloud Services wie Google Cloud und Amazon AWS ist die Bereitstellung sehr viel einfacher geworden, da nicht gleich die ganze Serverbasis eingekauft und verfügbar gemacht werden muss.

4. risiko evaluieren

Microservices sind häufig ambitioniert und stellen daher auch ein Geschäftsrisiko dar, wenn Teams Microservices einsetzen, ohne im Umgang damit geübt zu sein oder der Einsatz nicht sinnvoll ist.

5. Kontext ist entscheidend

Der eigene Kontext und das eigene Szenario sind ausschlaggebend dafür, ob eine monolithische Architektur oder Microservices zu wählen sind. Unternehmen sollten sich dessen bewusst sein, bevor sie sich entscheiden, welche Architektur ihrer Situation angemessen ist.

Eine monolithische Architektur ist sinnvoll, wenn…

• das Team sich noch in einer Gründungsphase befindet, es nur aus sehr wenigen Mitgliedern besteht und noch gar nicht in der Lage ist, die Komplexität einer Microservice-Architektur zu managen.
• das Unternehmen ein neues, nicht bewiesenes Produkt baut, oder einen Wirksamkeitsnachweis (Proof of Concept) braucht: Handelt es sich um eine neue Idee, ist es wahrscheinlich, dass diese sich im Laufe der Zeit immer weiter entwickelt. Ein Monolith ist daher ideal, um eine schnelle Produktabfolge zu ermöglichen. Das gleiche gilt für ein Proof of Concept, bei dem es darum geht möglichst schnell, möglichst viel zu lernen, selbst wenn man das Projekt am Ende verwirft.
• es keinerlei Vorerfahrung mit Microservices gibt: Wenn das Team keine Erfahrung mit Microservices hat, sollte es bei einem Monolith bleiben, es sei denn das Unternehmen riskiert ein „Learning by Doing“.

Für den Einsatz von Microservices spricht, wenn…

• das Unternehmen eine schnellere und unabhängige Service-Bereitstellung braucht: Microservices ermöglichen eine schnelle und unabhängige Bereitstellung individueller Teile innerhalb eines größeren, integrierten Systems.
• ein Teil der Plattform effizient sein muss: Genau dieser Teil sollte in einer äußerst effizienten Programmiersprache gebaut sein. Für andere Bestandteile können unterschiedliche Programmiersprachen verwendet werden.
• das Team wachsen soll: Wer mit Microservices beginnt, gewöhnt das Team von Anfang an daran, in separaten kleinen Services zu arbeiten. Wenn das Team wächst, muss nicht exponentiell eine größere Komplexität eingeführt werden, da die Teams ohnehin durch Service-Grenzen voneinander separiert arbeiten.

Microservices in Tiefe

Microservice – vielgestaltige Unabhängigkeit

Zentrale Merkmale, Eigenschaften und schließlich Vorteile der Microservices wie auch einer Microservices-Architektur bestehen in deren Unabhängigkeit und zwar in verschiedener Hinsicht.

Technologische Wahlfreiheit 1: Microservices REST-Api

In welcher Programmiersprache ein Client geschrieben wird, der mit dem Microservice interagiert, steht zur freien Wahl. Da Anfragen oft über eine REST-API(REpresentational State Transfer) entgegengenommen werden, kann clientseitig jede Programmiersprache benutzt werden, die REST beherrscht. REST basiert auf den HTTP-Verben GET, PUT, POST/PATCH wie auch DELETE und ist sehr altes Netzwerkprotokoll. So hat man für die Clients, was die Programmiersprache angeht, die Wahl. Denn ob ein Client für einen Microservice Python basiert ist oder in einer beliebig anderen Sprache, spielt keine Rolle, solange der Client REST beherrscht und die REST-API ansprechen kann.  Die Entscheidung über die Frage, in welcher Programmiersprache ein Client für einen Microservice geschrieben wird, hängt dann von anderen Gesichtspunkten ab.

Mit welchen Protokollen lassen sich Microservices clientseitig noch ansprechen?

REST stellt sicherlich nicht die einzige API/Protokoll dar, mit dem Microservices vom Client aus angesprochen werden können. Einige der nun folgenden Beispiele sind an REST angelehnt, erweitern diese und eignen sich für Microservices:

• Open Data Protocol (oDATA): Ein aus dem Hause Microsoft stammendes, ebenfalls HTTP-basiertes Protokoll
• WebSockets: Für Kommunikation in real-time, durch persistente Verbindung zwischen Client und Service, ohne HTTP-Overhead und Verzicht auf “long-polling”
• GraphQL: Anfrage- und API-Beschreibungssprache, eingeführt von Facebook
• RESTful API Modeling Language (RAML): Beschreibungssprache von APIs und deren Verwendung
• OpenAPI Specification: Standard zur Beschreibung REST-konformer APIs; vorangetrieben durch die OpenAPI Initiative

Technologische Wahlfreiheit 2: Unabhängigkeit der gewählten Programmiersprache

Selbst bei der Implementierung von Microservices besteht ein Plus an Freiheit. Prinzipiell kann jeder Microservice in einer anderen Programmiersprache implementiert sein. Die Entscheidung darüber muss im jeweiligen Team getroffen werden, dass den Microservice implementieren und betreuen wird. Sicherlich sind dazu wichtige Vorüberlegungen notwendig. Wichtig zu wissen: Nur auf diesem Wege ermöglicht und erhält man die Unabhängigkeit und Flexibilität der Microservices und schafft die Voraussetzungen für ein beschleunigtes Deployment von Microservices (siehe dazu auch Docker).

Wie kommunizieren eigentlich Microservices untereinander?

Nachdem der Client Daten via REST an einen Microservice übermittelt hat, stellt sich die Frage, was passiert nun damit? Innerhalb einer Microservice-Architektur liegt es ziemlich nahe, dass die Daten untereinander ebenfalls über an REST angelehnte APIs kommuniziert werden.

ne Kommunikation der verschiedenen Microservices untereinander – kurz: auf ASYNC abzustellen – sollte dabei stets das Ziel sein. Ohne an dieser Stelle in Details zu gehen, bedeutet asynchrone Kommunikation an dieser Stelle, dass z.B. Microservice A seinen Call an Microservice B absetzt – ohne auf das Resultat dieser Anfrage zu warten. . A “weiß” nun, dass seine Anfrage angekommen ist und sich darum gekümmert wird – mit der Folge, dass bei A Ressourcen freibleiben und weitere Vorteile entstehen, wie z.B. eine geringere Latenz innerhalb der Microservices-Architektur.  Als Protokolle kommen dann zum Beispiel die folgenden zum Einsatz:

• RESTful (s.o.)
• OData (s.o.)
• Google Remote Procedure Calls (gRPC)
• Remote Procedure Calls (RPC)
• Thrift

Der Einsatz von Message Queues, gewissermaßen ein eigener Nachrichtendienst, z.B.  mit RabbitMQ oder Kafka, treibt diesen ASYNC-Gedanken auf die Spitze. Bei RabbitMQ wird z.B. mit speziellen Nachrichten-Protokoll. Auch dazu bestehen verschiedene Ansätze. Das Wichtigste dazu vorab:  Eine asynchrolen (AMQP, MQTT, STOMP) gearbeitet. Hier werden Korrelations-IDs verwendet, um zu verfolgen, welche Antwortnachricht sich auf welche Anfrage bezieht.

Unabhängiges Deployment der Microservices

Im Idealfall besteht aufgrund vorheriger Überlegungen und Entscheidungen nun die Option, einen Microservice unabhängig von allen anderen Diensten der Microservice-Architektur auszurollen. Damit sind die zentrale Stärken und Eigenschaften eines Microservice beschrieben. Eben weil sich ein Microservice nur um eine Aufgabe kümmert, besitzt er idealerweise eine vergleichsweise kleine Code-Basis, ist im Vergleich schnell ausgerollt, gestartet – und dieser Dienst beeinflusst zudem keinen anderen Dienst der Microservices-Architektur. Alle anderen Microservices bleiben während des Deployments verfügbar, müssen nicht neu deployt werden. Um im oben erwähnten Beispiel zu bleiben, kann der Kunde weiterhin seine Sendungen frankieren, obwohl der Microservice zur Sendungsverfolgung gerade neu ausgerollt wird.

Dieser Ansatz eignet sich also perfekt für eine serviceorientierte Architektur. Wichtig zu wissen: Diese Aufteilung der Microservices spiegelt sich auch in den Verantwortlichkeiten der Teams wider. So können DevOps-Teams gebildet werden, die jeweils auf einen ganz bestimmten Microservice spezialisiert sind – das „Do one thing well“ gilt dann eben auch für die Teams (siehe: DevOps)

Im Vergleich zu einem monolithisch konzipierten System werden die Vorteile einer Microservice-Architektur offensichtlich: Ist der Monolith einmal in Betrieb, müssen bei Änderungen entsprechende Wartungszeiten eingeplant werden. Denn aufgrund der Struktur ist stets das ganze System betroffen und muss gegebenenfalls mehrfach neu gestartet werden, um zu testen, ob die Änderungen im Code auch den gewünschten Effekt haben. Dies entfällt durch eine Microservice-Architektur. Gerade diese Neustarts illustrieren ein weiteres Problem monolithischer Strukturen: Je häufiger die Veränderungen und je größer die Code-Menge, desto langsamer der Entwicklungsprozess – und häufige Veränderungen sind sehr erwünscht, wenn es um den Einsatz von bspw. MVPs via Microservices geht.

Microservices: Skalierbarkeit fein und granular

Mit der beschriebenen Segmentierung lassen sich neben dem unabhängigen Deployment jedoch noch andere Vorteile der Microservice-Architektur erzielen. Einmal bspw. via Docker (s.u.) ausgerollt, stellt es die Teams vor keine größeren Herausforderungen, sich um die Skalierbarkeit der einzelnen Dienste zu kümmern. Gesetzt den Fall, dass ein Microservice in Übermaßen die CPU-Zeit in Anspruch nimmt oder zu viel Speicher alloziert, lässt sich dies recht zügig über einen Load-Balancer und über einen zusätzlichen Microservice ausgleichen. Bei einem Monolithen muss das System manuell immer in seiner Gesamtheit skaliert werden.

Alles eingepackt: Microservices mit Docker

Einmal in schmale Docker-Container verpackt, steht dem raschen Deployment einzelner Microservicnehmenskultur.es nichts mehr im Weg. Durch die Verbreitung und die Begeisterung für Microservice-Architekturen hat sich im Laufe der letzten Jahre eine Toolchain für den Prozess der Softwareauslieferung entwickelt.

Verschiedene Technologien stehen den Teams der einzelnen Microservices dafür zur Verfügung. Deren Ziel: Den Deployment-Prozess weitgehend zu automatisieren und damit zu vereinfachen. Zeit sparen, Fehler vermeiden ist die Devise.

Docker und Kubernetes

Bei der Komplexität von Services, die eine Microservices-Architektur aufweisen können, benötigt das DevOps-Team natürlich die passenden Werkzeuge zur Administration. Kubernetes (K8s) ist eines davon. Man stelle sich nur die Ausgangssituation vor: Die Basis der Architektur besteht aus vielen Docker-Containern und zahlreichreichen Hosts, also einzelnen physischen oder virtuellen Rechnern. Durch Kubernetes lassen sich nun die Docker-Container gruppieren, in Pods zusammenfassen und z.B. auf einem Node (Vhost oder physischer Rechner) ausrollen. Kubernetes Vorteile liegen hier im vergleichsweise einfachen und schnellen Deployment der Microservices. Gleichzeitig bietet K8s eine komfortable Lösung, um eine Microservice-Architektur mit z.B. hunderten Microservices zu managen: Lastspitzen auszugleichen, zu skalieren und zu monitoren. Dashboards (WebUI) und diverse Kommandozeilenprogramme stellen dabei die Werkzeuge der Wahl dar, um die Services dann On-Premises, Hybrid oder in der Public Cloud zu managen – perfekt für DevOps-Dirigenten zur Orchestrierung der Microservices. (Kubernetes ist Open-Source (Apache License 2.0))

Jede neue Iteration eines Microservice kann dann mit den Fehlerbehebungen und neuen Erweiterungen zügig, mit geringem Risiko und wenig manuellem Aufwand in die Staging- oder Produktivumgebung eingepflegt werden. Selbst für diesen Bereich der Software-Entwicklung bedient man sich neuer Methoden und Team-Strukturen und Verantwortlichkeiten, gewissermaßen auch einer neuen Unternehmenskultur.

Continuous Delivery, Devops und Microservices

Damit aus einem hehren Ziel auch Realität entsteht, hat es sich als Best-Practice erwiesen, auf DevOps-Teams und die Methode Continuous Delivery zu setzen. In Kombination mit Microservices stellt dieses Trio ein Kind seiner Zeit dar- Stichworte „Volatile Märkte/neue Herausforderungen für Unternehmen/schnelle Bereitstellung stabiler Dienste“. Warum lassen die eben angerissenen Anforderungen und Ziele gerade durch dieses Trio der Microservices,  DevOps  und  Continuous  Delivery  erreichen?

Das Kunstwort DevOps besteht aus der Zusammensetzung der Kurzformen von „Dev“ für Development und „Op“ für Operations – hier: für den IT-Betrieb. Softwareentwicklung und Systemadministration und das Deployment von Microservices werden nunmehr zusammengedacht. Eine enge Zusammenarbeit von Entwicklung und Betrieb zum Zweck der schnellen Bereitstellung reibungslos funktionierender Microservices ist das Ziel. DevOps-Teams haben ihre Expertise sowohl in der Software-Entwicklung UND in punkto IT-Systeme und System-Infrastruktur. In DevOps vereint sich also das Beste zweier Welten. Zusammengebracht mit der Methode Continuous Delivery bedient sich DevOps dabei einer Werkzeug-Kette, bestimmter Techniken und Prozesse, die das Software-Deployment automatisiert und optimiert – hinsichtlich Software-Qualität, Flexibilität und Geschwindigkeit.

Releasing software is too often an art; it should be an engineering discipline.

David Farley