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.

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.

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 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 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.

Microservices-Vorteile im Detail:

• 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.
• 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.
• 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.

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.
• 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.

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.

Kurz zusammengefasst: Es ist nicht das Ende monolithischer Architekturen, vielmehr sollten Microservices entsprechend des Kontexts zum Einsatz kommen. Unternehmen sollten immer den eigenen Nutzen an erste Stelle stellen und sich dann für die entsprechende Architektur entscheiden.