Head-to-head: Monolith vs. Microservices
Available Now • On-Demand
Watch Now
Diese Website ist zum Teil ins Deutsche übersetzt. Einige Inhalte sind weiterhin auf Englisch.
Was ist ein Microservice?
Microservices sind eine Softwarearchitektur, bei der die Funktionalität der Applikation in kleinere Fragmente aufgeteilt ist, um sie robuster und skalierbarer zu machen. Diese Fragmente nennen wir „Services“. Jeder Service beschränkt sich auf eine einzelne Funktion der Applikation und ist von den anderen isoliert. Dadurch ist jeder Service unabhängig von den anderen. So können Entwicklerteams an jeweils verschiedenen Services arbeiten und eine komplexe Orchestrierung untereinander vermeiden.
Die verschiedenen Services kommunizieren schließlich über APIs oder Webdienste miteinander.
Microservices-Architektur
Um besser zu verstehen, was Microservices sind und warum sie so populär geworden sind, hilft ein Blick auf ihren Ursprung. Hier ein kurzer Überblick über ihre Geschichte.
Ursprünge von Microservices: Das Versprechen von Services
Wie ein Phönix wurden Microservices aus der Asche ihrer früheren Inkarnation, den Services, geboren. Vor zwei Jahrzehnten haben Architekten Services konzipiert, deren Versprechen heute durch Microservices erfüllt wird. Die serviceorientierte Architektur (aka SOA) versprach der IT-Welt eine Art Wundermittel gegen schwierig zu handhabende monolithische Applikationen.
Derzeit waren Unternehmen von Backlogs und internem Hickhack geplagt, während Startups skalierbare Produkte entwickelten, die große Marktanteile verschlangen. Nun konnten Unternehmen ihre Monolithen aufbrechen, indem sie Mini-Monolithen erstellen, die die Funktionen des Kerngeschäfts enthielten.
Ein Mini-Monolith oder besser noch ein „Minilith“ wurde geschaffen, um agile Praktiken zu fördern, einem horizontalen Team die vollständige Produktverantwortung zu übertragen und allen, die ihn brauchten, einen einfachen Zugriff auf den Service zu geben. Das war beeindruckend. Doch was geschah dann?
Der Rückschlag
Bei Services handelte sich um einen Tech-Trend, der wie fast alle Trends dem Muster einer Modeerscheinung folgte. Modeerscheinungen verschwinden, weil diejenigen, die sie initiiert haben, sie schon jahrelang praktiziert haben. Andere, die sich von ihrem Erfolg anstecken lassen, haben es jedoch schwer, die gleichen Resultate zu erzielen. Einige talentierte Entwickler haben ihre Services gründlich ausgearbeitet, während der Rest der IT-Branche neidisch zu verstehen versuchte, wie sie das Ganze so einfach aussehen lassen konnten.
Martin Fowler, einer der Begründer von Agile, erklärte einmal, dass die meisten Unternehmen nicht zu echten SOAs migrieren, sondern lediglich die Komplexität verlagern, hauptsächlich in den Enterprise Service Bus. Der Enterprise Service Bus (ESB) ist eine Middleware, die für die Kommunikation zwischen Services und ihren Consumern entwickelt wurde. Unternehmen nutzen ESBs, um die Schwierigkeiten bei der Entkopplung eines Geschäftsprozesses von seiner monolithischen Muttergesellschaft zu mildern.
Das Ergebnis ist eine Blackbox-Lösung, die zwar technisch „funktioniert“, sich aber nur schwer ändern, testen und verwalten lässt. Martin Fowler beschloss deshalb, die Abkürzung ESB als Erroneous Spaghetti Boxes zu verstehen.
Die Einführung von Microservices
Haben Sie bei einer Präsentation schon einmal festgestellt, dass Ihre Zuhörer eine eindeutig falsch interpretierte Version Ihres Vortrags wiedergegeben haben? Erinnern Sie sich im Zweifelsfall an Situationen, in denen es auffällig viel Kopfnicken gab. Genau so fühlten sich Entwickler, als die Unternehmenswelt das Thema serviceorientierte Architekturen in Beschlag nahm.
In dieser Situation möchte man Missverständnisse gerne korrigieren. Entwickler haben dies getan, indem sie ihre ursprüngliche Idee zu Microservices umformuliert haben. Microservices bieten im Kern die gleichen Vorteile, die ursprünglich von Services versprochen wurden. Generell folgen sie den folgenden Konventionen:
- Netzwerk-Zugänglichkeit: Keine Anzeichen mehr von benutzerdefiniertem Spaghetti-Box-Code. Microservices beschränken sich strikt auf plattformunabhängige Netzwerkprotokolle wie HTTP, TCP/UDP etc. Diese Praxis hat sich wiederum auf die SOA-Welt ausgewirkt.
- Unabhängig bereitgestellt: Echte Entkopplung ist eine Säule der Microservice-Architektur. Teams müssen in der Lage sein, Updates für ihre Microservices unabhängig von anderen Komponenten – insbesondere ihren Consumern – bereitzustellen.
- Austauschbar: Aufgrund der ersten beiden Konventionen kann ein Microservice einen anderen ersetzen, indem einfach der Servicevertrag des Originals eingehalten wird. In diesem Fall ist der Vertrag eine API-Spezifikation.
- Enger Anwendungsbereich: Ein Microservice beschränkt sich auf einen bestimmten Geschäftswert oder eine bestimmte Funktion. Den Umfang der einzelnen Microservices zu definieren, ist eine Herausforderung, aber Abrechnungen, Fotospeicherung oder standortbezogene Dienste sind typische Fälle.
- Heterogen: Microservices verwenden die Bibliotheken und Technologien, die am besten zu ihrem Anwendungsfall passen, und nicht die, die ihnen durch eine monolithische Architektur aufgezwungen werden.
- Vollständig automatisiert: Microservices sind ein hervorragender Anwendungsfall für DevOps – die Philosophie, die die Lücke zwischen Softwareentwicklung (den Entwicklern) und IT-Betrieb (denjenigen, die die Software ausführen und dafür sorgen, dass sie bei Änderungen weiter funktioniert) schließt. Die Kombination von DevOps und Microservices schafft automatisierte Bereitstellungs-, Test- und Überwachungsprozesse, die die Servicezuverlässigkeit verbessern und reibungslose Entwicklungszyklen fördern.
Vorteile von Microservices
Mehrere Tech-Giganten wie Netflix, Amazon und Uber haben Microservices aufgrund ihrer vielen Vorteile längst eingeführt. Dazu zählen:
- Reduzierte Zeit bis zum POC: Entwickler können Microservices mit den Tools erstellen, die am besten für den intendierten Geschäftswert geeignet sind. In Kombination mit der vollständigen Datenisolierung haben Sie eine Formel für hyperschnelles Prototyping.
- Verantwortlichkeit liegt bei einem Team: Durch die Aufteilung des Geschäftswerts in eine Sammlung von Microservices kann ein kleines horizontales Team die vollständige Verantwortung für einen Microservice übernehmen. Dies bestärkt und motiviert die entsprechenden Mitarbeiter, ein herausragendes Produkt zu liefern. Bei großen Monolithen dagegen werden Entwickler von einer Aufgabe zur nächsten getrieben und haben nur selten das Gefühl, dass ihre Beiträge individuell bedeutsam sind.
- Skalierbar: Da ein Microservice unabhängig von anderen Applikationselementen erstellt und veröffentlicht wird, kann er je nach Bedarf des Unternehmens skaliert werden. Auch Downscaling ist möglich.
- Wiederverwendbar: Einmal erstellt, ist der Microservice für jeden Consumer verfügbar. Und da er je nach Bedarf skaliert, kann ein Microservice auch die zusätzliche Arbeitslast bewältigen.
- Fehlertolerant: Durch die Isolierung sowohl der Daten- als auch der Applikationsserver von anderen Komponenten können Microservices ausfallen, ohne das gesamte Produkt stillzulegen. Dass es sich bei einem Microservice um ein kleineres Produkt handelt, das unabhängig freigegeben, verwaltet und skaliert wird, erleichtert die Einführung von Fehlertoleranz. Die Erstellung eines fehlertoleranteren Systems wird einfacher, wenn man Fehlertoleranz in die kleineren Teile einführt, aus denen sich das System zusammensetzt. So ist es auch viel leichter, Erfahrungsgradienten zu schaffen, wenn ein oder mehrere Dienste ausfallen, aber nicht das gesamte System unterbrochen wird.
- Risikominderung: Microservices bieten per Definition einen geschäftlichen Nutzen. Zugleich mindern sie Risiken, indem sie von anderen Komponenten unabhängig bleiben. Auf diese Weise ist die Ausrichtung ihrer Entwicklung an den Interessen des Unternehmens bereits in ihrem Design verankert.
Nachteile von Microservices
Leider ist – wie bei jedem Trend – auch bei Microservices nicht alles rosig. Hier ist der Haken.
- Netzwerkabhängigkeit: Microservices kommunizieren ausschließlich über Standard-Netzwerkprotokolle. Das bedeutet, dass ein Netzwerkausfall oder eine Unterbrechung jeglicher Art (oft außerhalb der Kontrolle eines Unternehmens) den Geschäftsbetrieb beeinträchtigt. Dabei gilt: Je mehr Microservices bereitgestellt werden, desto größer ist auch das Risiko eines Netzwerkausfalls, der einen dieser Services gefährdet. Zudem bedeutet ein Netzwerk auch, dass Latenzzeiten in das System eingeführt werden, die berücksichtigt werden müssen. Kein Endnutzer wartet gerne sekundenlang, um seinen Kontostand abzurufen, nur weil die Netzwerkkommunikation langsamer geworden ist.
- Overhead: Mit Microservices zerlegen Sie ein großes Produkt in eine Konstellation kleinerer Produkte. Daraus ergibt sich ein Mehraufwand bei der Verwaltung dieser Konstellation. Dies ist einer der Gründe, warum viele Unternehmen nicht bereit sind, vollständig auf Microservices umzusteigen. Darüber hinaus benötigt jeder Microservice seine eigenen DevOps-Prozesse. Mit der wachsenden Anzahl von Microservices in einem Unternehmen steigt auch der Wartungs- und Überwachungsaufwand für die Instandhaltung.
- Abhängigkeitshölle: Stellen Sie sich Hunderte Applikationskomponenten vor, die auf einem Microservice mit einem etablierten Vertrag (API-Spezifikation) basieren. Und nun stellen Sie sich vor, das Microservice-Team möchte seine Spezifikation umgestalten oder auch nur leicht modifizieren. Das Unternehmen muss diese Anpassung nicht nur über unzählige Teams hinweg koordinieren, sondern auch ununterbrochen verfolgen, wer auf wen angewiesen ist.
- Strenge Verträge: Zudem müssen Entwickler darauf achten, eine Microservice-API-Spezifikation zu definieren, die robust genug ist, um noch lange nach der ersten Veröffentlichung einen Geschäftswert zu bieten. Diese Art von Voraussicht ist selten, und in manchen Unternehmen sogar unmöglich. Auch dies verringert die Attraktivität von Microservices.
- Zu einfach zu starten: Hierbei handelt es sich um eine Stärke, die leicht zur Schwäche werden kann. Die Möglichkeit, Microservices so einfach bereitzustellen und einzubinden, kann zum Übereifer verleiten. Wenn ein Unternehmen sich komplett auf Microservices umstellt, bevor es die damit einhergehenden Nachteile vollständig verstanden hat, kann dies zu einer fehlgeschlagenen oder unzureichenden Umgestaltung der Architektur führen.
Ist eine Microservices-Architektur das Richtige für Ihr nächstes Softwareprojekt?
Nach unserem Überblick über die Vor- und Nachteile von Microservices sollten Sie diese Frage nun gut beantworten können. Bevor Sie nach Microservices-Tutorials suchen, sollten Sie sich zunächst überlegen, warum Sie eine Microservice-Architektur entwickeln möchten. Wenn Ihre Antwort lautet „Weil alle großen Unternehmen das tun“, sollten Sie Ihre Entscheidung noch einmal überdenken.
In diesem Artikel haben wir einige Vorteile von Microservices vorgestellt, die deutlich machen, warum eine entsprechende Architektur nützlich sein kann. Mehrere Teams können voneinander unabhängige Continuous-Integration- und Continuous-Delivery-Pipelines (CI/CD) betreiben und dabei unterschiedliche Skills, Anbieter und Technologien einsetzen.
Entscheidend ist jedoch zu erkennen, wann genau sich dies lohnt. Die meisten Unternehmen verfügen nicht wie Netflix über ein großes Entwicklerteam mit einigen der besten Entwickler der Welt, die sich alle einer einzigen Applikation widmen. Im durchschnittlichen Unternehmen sind hochqualifizierte Entwickler rar. Zudem sind Teams in der Regel kleiner und kümmern sich um ein ganzes Portfolio von Business-Applikationen statt um ein einzelnes Produkt. Falsch eingesetzt können Microservices zu unlösbaren Situationen führen.
Gute Entscheidungen bezüglich Ihrer Architektur erfordern unbedingt ein Verständnis der Vor- und Nachteile jedes Ansatzes.
Um mehr über die verschiedenen Ansätze und die Wahl der richtigen Architektur für Ihre Entwicklungsprojekte zu erfahren, empfehlen wir die folgenden Ressourcen:
