Microservices, Monolith & Serverless: Die Unterschiede im Überblick

In den letzten Jahren gab es in der Softwareentwicklung eine starke Tendenz weg von klassischen monolithischen Architekturen hin zu verteilten Microservices oder gar komplett dezentrale Serverless Systeme. Was genau dahintersteckt und warum nicht immer als Gold ist, was glänzt, erfahrt ihr in diesem Beitrag. Eines ist sicher, eine universelle Antwort auf alle Herausforderungen gibt es schlicht und ergreifend nicht. Der Artikel vergleicht die drei Architektur Varianten anhand des Beispiels eines kleinen Customer-Relationship-Managements (kurz CRM) Tools. 

Die Google Trends sprechen von der Aktualität eine erwartbare, aber doch sehr deutliche Sprache. Zum Verständnis der Diagramme ist folgendes anzumerken. 

Die Werte geben das Suchinteresse relativ zum höchsten Punkt im Diagramm für die ausgewählte Region im festgelegten Zeitraum an. Der Wert 100 steht für die höchste Beliebtheit dieses Suchbegriffs. Der Wert 50 bedeutet, dass der Begriff halb so beliebt ist und der Wert 0 bedeutet, dass für diesen Begriff nicht genügend Daten vorlagen – Google Trends.

Abbildung 1: Monolithische Architektur bei den weltweiten Google Trends

Während sich das Interesse bei den Suchtrends für monolithische Softwarearchitekturen kaum merkbar verändert oder gar nach oben geht, sieht es bei den beiden anderen Vergleichsarchitekturen völlig anders aus.

Abbildung 2: Microservices bei den weltweiten Google Trends

Microservices hatten im Februar 2022 den historischen Höchststand und der Serverless Ansatz ist Ende 2022 relevanter den jemals zuvor.

Abbildung 3: Serverless bei den weltweiten Google Trends

1. Was ist eine monolithische Architektur?

Eine monolithische Architektur beschreibt kurzum eine Anwendung, die in sich geschlossen ist und praktisch alles selbst erledigt und verwaltet. Sie kann auch als schwarze Box (engl. Blackbox) bezeichnet werden. Monolithische Anwendungen tendieren aus ihrer Definition heraus zu seiner sehr großen Codebasis, die oftmals zu schwierig wartbarem Code mutieren. Hier ist es besonders wichtig dabei zu achten, eine saubere Trennung zwischen den einzelnen Funktionen und Bereichen sicherzustellen. Andererseits ist der Zugriff auf andere Teilbereiche der Anwendung relativ einfach, da keine fremden Services aufgerufen werden müssen.

Abbildung 4: Aufbau einer klassischen monolithischen Architektur

Angewandt auf unserer CRM-System bedeutet ein Monolith, dass sämtliche Funktionen wie Benutzer-, Kunden-, Angebots-, Rechnungsverwaltung et cetera in einer einzelnen Anwendung gehandhabt werden. Soll eine Rechnung zu einem Angebot verbunden werden, kann diese Anwendung direkt im Monolith durchgeführt werden, ohne einen zusätzlichen Aufruf außerhalb der Anwendung. Das hat auf den ersten Blick den charmanten Vorteil, sich mit keinen anderen Service oder Dienst beschäftigen zu müssen – da alles im Monolith vorhanden ist.

Abbildung 5: Beispielhafte Bestandteile der Business Logik bei einem Monolith

Ebenso haben alle Teilbereiche immer Zugriff auf die komplette Datenbank über die Datenzugriffsschicht. Das ist dahingehend bedeutend, da hier nicht klar abgegrenzt werden kann, dass ein Teilbereich nur seine notwendigen Daten sehen und bearbeiten kann. Damit kann unter Umständen eine unbeabsichtigte Datenbearbeitung technisch nicht komplett ausgeschlossen werden. Bei den beiden anderen Architekturen kann der Datenzugriff pro Service feingranular gesteuert und eingegrenzt werden. 
Aus unserer Erfahrung eignen sich monolithische Systeme besonders gut für einen schnellen Prototyp wie auch für kleinere Anwendungen und Teams. 

Vorteile von einer monolithischen Architektur:

• Evolution der Anwendung ist einfach
• Zu Beginn der Entwicklung sind die Kosten niedrig.
• Die ursprüngliche Entwicklung ist einfach.
• Debugging ist einfach möglich
• Testen der Gesamtanwendung ist einfach möglich.
• Die gesamte Anwendung wird auf einmal ausgerollt.

Nachteile von einer monolithischen Architektur:

• Enge Kopplung zwischen den einzelnen Teilbereichen der Anwendung.
• Es ist keine gezielte Skalierung möglich.
• Bei schwacher Performance steigen die Infrastrukturkosten stark an.
• Upgrades auf neue Technologien werden schwer bis teilweise unmöglich.
• Andere Technologien einzusetzen ist unmöglich.
• Bei kleinen Änderungen muss die ganze Anwendung neu ausgerollt werden.

2. Was ist eine Microservice Architektur?

Eine Microservice Architektur besteht im Gegensatz zum monolithischen Ansatz aus vielen kleineren Services. Im Grunde gibt es keine festen Einschränkungen, wie kleinteilig die Services sein können. In unserem Beispiel wäre es ein denkbarer Weg, pro Teilbereich des CRM-Systems einen einzelnen Service zu erstellen. Das bedeutet, dass es einen Service pro Benutzer-, Kunden-, Angebots-, Rechnungsverwaltung et cetera geben kann. Die einzelnen Services sind jetzt lose gekoppelt und können mit HTTP-Request miteinander kommunizieren. Ebenso wird bei einer Microservice Architektur eine getrennte Datenhaltung angestrebt. Es soll pro Service eine eigene, getrennte Datenbank verwendet werden. Werden Daten von einem Service benötigt, wird nicht direkt auf deren Datenbank zugegriffen, sondern die Daten über den Service per HTTP-Anfrage ausgeliefert.

Abbildung 6: Aufbau einer Microservice Architektur

Eine getrennte Datenhaltung ermöglicht ein individuelle, optimierte Datenhaltung pro Service. Manche Daten machen in einer relationalen Datenbank mehr Sinn, andere sind besser in einer NoSQL Datenbank aufgehoben.

Vorteile von einer Microservice Architektur:

• Microservices lassen sich einfacher testen.
• Jedes Microservice kann in der passenden Programmiersprache entwickelt werden.
• Jedes Microservices kann mit der passenden Technologie entwickelt werden.
• Ändert sich ein Microservice, muss nur das betroffene Service neu ausgerollt werden und nicht die ganze Anwendung.
• Microservices können einfacher in Container und über eine Orchestrierung gesteuert werden.

Nachteile von einer Microservice Architektur:

• Die Komplexität steigt mit der Anzahl der verwendeten Microservices an.
• Debugging über mehrere Microservices hinweg kann sehr komplex werden.
• Für kleine Anwendung sind Microservices unserer Erfahrung nach nicht geeignet.
• Kleine Teams verbringen einen Großteil der Arbeitszeit mit der Administration/Wartung der Microservices Umgebung, anstatt mit neuen Features für die Applikation.

3. Was ist eine Serverless Architektur?

Eine Serverless Architektur ist eine Umgebung, die nicht vom Auftragnehmer oder Auftraggeber verwaltet wird. Üblicherweise sind solche Architekturen vor allem in Cloud Umgebungen wie Microsoft Azure, Amazon AWS oder der Google Cloud anzufinden. Die Hersteller übernehmen dabei die Wartung, Skalierung und Pflege der Server und der Infrastruktur. Die meiste Business Logik wird dabei in sogenannten Functions abgehandelt. Diese haben den Vorteil, schnell einsatzbereit und entwickelt werden zu können, aber im Gegenzug sind sie in vielen Fällen funktionell eingeschränkt und sind in der Ausführungszeit limitiert. Eine Serverless Architektur wird auch gerne als Functions as a Service (FaaS) Architektur bezeichnet.

Abbildung 7: Beispielhafter Aufbau einer Serverless Anwendung

In einer Serverless Umgebung ist man sehr stark an die Angebote der jeweiligen Cloud Anbieter gebunden und gibt sich damit in eine starke Abhängigkeit. Werden verwendete Dienste abgekündigt, oder kommen mit neuen Updates Breaking Changes, muss die Anwendung immer wieder aktualisiert und auf dem neuesten Stand gebracht werden. Auf der anderen Seite muss allerdings keine Zeit in die Bereitstellung und Wartung von Hardware investiert werden, da diese unsichtbar im Hintergrund läuft.

Vorteile von einer Serverless Architektur:

• Functions sind sehr günstig und werden in den meisten Fällen pro Ausführungszeit berechnet.
• Serverless Umgebungen sind sehr schnell aufgebaut und einsatzbereit.
• Die Skalierung kann auf einzelne Functions heruntergebrochen und individuell angepasst werden.
• Die Wartung von Hardware und Functions Umgebung liegt vollständig beim Cloud Anbieter.

Nachteile von einer Serverless Architektur:

• Die Sicherheit und der Schutz der Anwendung liegt zu einem großen Teil beim Cloud Anbieter.
• Ein Wechsel zu einen anderen Cloud Anbieter wird schwierig, da viele auf eigene Lösungen und Produkte setzen.
• Integration und end-to-end Tests sind sehr schwierig durchzuführen.
• Functions haben für gewöhnlich eine eingeschränkte Ausführungszeit. Ausnahmen dabei sind durable Functions, die eine längere Laufzeit haben.

4. Microservices und Serverless im Zusammenspiel

Microservice Lösungen können mit Serverless Komponenten vermischt und gemeinsam verwendet werden. Ein häufiger Anwendungsfall dabei ist der Versand von E-Mail-Nachrichten. Dabei schreibt das Microservice in eine Queue, dass eine E-Mail versandt werden soll. Am anderen Ende wird die Function benachrichtigt, dass es eine neue Nachricht in der Queue gibt und startet mit der Abarbeitung. Nach dem erfolgreichen Versand der E-Mail wird der bestehende Eintrag in der Queue gelöscht.

Abbildung 8: Anwendungsfall Microservice mit Queue und Function für einen E-Mail Versand.

An diesem Beispiel sieht man sehr deutlich, dass sich die beiden Architekturen nicht gegeneinander ausschließen. Functions bieten einen eleganten Weg, um bestehende Architekturen zu erweitern und Business Logik auszulagern.

5. Die wichtigsten Unterschiede im Überblick

Grundsätzlich kann mit jeder Architektur jede Herausforderung und Problemstellung gelöst werden. Interessant wird es, wenn Punkte wie Effizienz, Kosten, Wartbarkeit, Zukunftssicherheit usw. in die Entscheidungsfindung Einfluss finden.

6. Fazit

Wie in allen Projekten hängt die Wahl der richtigen Architektur von den Anforderungen und speziellen Herausforderungen des Kunden ab. Die Expert*innen der ACP unterstützen Sie dabei, die perfekte Architektur für ihre Bedürfnisse zu finden und umzusetzen. Durch unsere langjährige Erfahrung in der Umsetzung von Softwareprojekten sind Sie bei uns genau an der richtigen Stelle. Nehmen Sie Kontakt mit uns auf, wenn Sie mehr darüber erfahren möchten.

Hier Kontakt aufnehmen