Microservices sind eine Variante der serviceorientierten Architektur (SOA), bei der eine Core-Applikation in eine Sammlung von lose gekoppelten Servicemodulen aufgeteilt wird. In den letzten Jahren wurde diese aufgrund ihrer Skalierbarkeit und Agilität sehr hoch gehandelt. Aber wird der Anspruch auch erfüllt?
Im Folgenden schauen wir uns die Gemeinsamkeiten und Unterschiede zwischen SOA und Microservices an und beleuchten, wann Unternehmen sie nutzen sollten – und wann nicht.
Eine serviceorientierte Architektur (SOA) ist ein Ansatz zur Erstellung von Software-Applikationen. Dabei stehen die Wiederverwendbarkeit und die Erfüllung nichtfunktionaler Anforderungen (wie Sicherheit, Skalierbarkeit und Leistung) im Vordergrund.
Obwohl es keine formale Definition dafür gibt, wie ein Microservices-basierter Architekturstil aussehen muss, sind die Merkmale ähnlich. Die Architektur besteht aus mehreren, unabhängigen Komponenten, die lose gekoppelt sind und wenig Ressourcen verbrauchen.
Während sich Teams bei einer SOA auf Systembereiche wie UI und Datenbank konzentrieren, werden sie bei Microservices um spezifische Geschäftsergebnisse herum organisiert, die Systemfunktionen wie ein Produkt oder eine Dienstleistung verbinden.
Eine serviceorientierte Architektur und eine Microservice-Architektur unterscheiden sich im Wesentlichen in drei Aspekten:
Eine SOA besteht aus einem Portfolio von Applikationen und Diensten, die auf Enterprise-Ebene betrieben werden. Eine erfolgreiche Programmierung erfordert von den Entwicklern ein umfassendes Verständnis der Applikation und aller ihrer Abhängigkeiten.
Bei Microservices handelt es sich dagegen um eine Applikationsarchitektur. Eine einzelne Applikation wird in mehrere unabhängige Dienste unterteilt, die jeweils eine bestimmte Funktion erfüllen. Jede Funktion konzentriert sich auf eine bestimmte Aufgabe. Dies reduziert den Umfang des Verständnisses, das Entwickler für jedes Modul benötigen. Andererseits erschwert es aber auch die Wiederverwendung von Code zwischen verschiedenen Funktionen.
Zusammengefasst: Während sich Microservices auf die interne Architektur der Applikation richten, befasst sich SOA mit der Architektur auf Enterprise-Ebene.
SOA ist „grobkörnig“, d. h. sie konzentriert sich auf umfangreiche, geschäftsspezifische Funktionalitäten. Dies hat zur Folge, dass jede Funktionalität eine lange Liste von Abhängigkeiten aufweist.
Microservices sind dagegen viel „feinkörniger“ und schaffen ein Netz von Funktionalitäten mit jeweils einem einzigen Fokus, der als Bounded Context bezeichnet wird. Jeder Bounded Context ist nur lose gekoppelt und unabhängig, und weitaus stärker fokussiert als die Domänenfunktionen einer SOA.
Dadurch sind Microservices auch weitaus skalierbarer als SOAs, da sie sich granular erstellen lassen.
SOA erfordert eine Software für die Kommunikation. In der Vergangenheit haben Unternehmen Webservice-Zugriffsprotokolle wie SOAP verwendet, um die einzelnen Funktionen zu veröffentlichen und dann mit ihnen zu arbeiten. Die Verbindung aller Applikationen eines Unternehmens wirkt sich jedoch negativ auf die Skalierbarkeit des Systems aus und kann eine zeitaufwändige Wartung erfordern.
Aus diesem Grund verwendet SOA ein Middleware-Tool namens Enterprise Service Bus (ESB), das die Kommunikation übernimmt und die Anzahl der Punkt-zu-Punkt-Verbindungen zwischen den Funktionalitäten reduziert. Allerdings erzeugen ESBs auch einen Single Point of Failure: Sollte der ESB ausfallen, wären alle SOA-Dienste unzugänglich.
Bei einer Microservices-Architektur arbeitet und skaliert jeder einzelne Dienst unabhängig und hat somit seine eigene Fehlerquelle. Dadurch sind Microservices weitaus widerstandsfähiger und agiler und ermöglichen die unabhängige Programmierung jeder einzelnen Funktionalität.
Microservices-Architekturen sind hoch skalierbare Applikationen, die Millionen Nutzer erreichen sollen, wie Netflix, Twitter und Amazon. Es handelt sich um cloudnative Architekturen, die auf ein hohes Maß an Agilität und Autonomie ausgerichtet sind. Ihre Granularität und Unabhängigkeit sorgen für eine kontinuierliche Service-Bereitstellung.
Aber was spricht dann überhaupt noch gegen den Einsatz von Microservices?
Wenn Sie ein System in entsprechend feinkörnige Teile zerlegen, entsteht ein System, das unglaublich komplex ist. Und Komplexität hat Konsequenzen.
Eine Folge dieser Komplexität ist, dass die ACID-Regeln (Atomicity, Consistency, Isolation, Durability) einer Datenbank nicht mehr zu jeder Zeit in gleicher Weise auf das Netz der Microservices-Funktionalitäten anwendbar sind. Die Regeln zielen darauf ab, die Integrität der Daten gegen Fehler, Ausfälle und Pannen in einem System zu gewährleisten. So schreibt etwa die Atomizität vor, dass eine Transaktion in einem System entweder vollständig oder gar nicht ausgeführt wird.
In einem Microservice-Netz ist dies jedoch nicht so einfach. Hier ist diese Atomarität vielmehr ein Eventualfall. Letztendlich wird das gesamte System kohärent sein, doch dies ist nicht bei jeder einzelnen Transaktion der Fall.
Dies macht Microservices zu einer Architektur, deren Aufbau, Wartung und Betrieb wesentlich anspruchsvoller ist.
Dieser Komplexität müssen sich Unternehmen und Enterprise-Architekten bewusst sein, bevor sie in eine Microservices-Architektur investieren. Es ist nicht ungewöhnlich, dass Unternehmen Microservices einführen und dann feststellen, dass die weitreichenden Störungen den potenziellen Nutzen weitaus überwiegen.
Jedes Unternehmen muss darüber nachdenken, welches Problem es genau lösen will. Noch wichtiger ist die Frage, ob es eine einfachere Lösung gibt, bei der die bestehende Infrastruktur nicht vollständig granuliert und verteilt wird.
Haben Sie ein Unternehmen wie Amazon oder PayPal? Benötigen Sie ein hoch skalierbares, leistungsstarkes Cloud-basiertes System, das Millionen von Transaktionen pro Minute abwickeln kann? Dann kann es an der Zeit sein, in den sauren Apfel zu beißen und in die Komplexität von Microservices einzusteigen.
Zu berücksichtigen sind dabei auch der erhebliche Zuwachs an Entwicklertalenten und die Komplexität Ihrer Prozesse.
Microservices sind kein Allheilmittel. Sie haben ihre Vor- und Nachteile. Eine schlechte Implementierung kann schwierige Situationen nach sich ziehen, die nicht zur gewünschten Lösung beitragen.
Wennn Sie die mit Microservices verbundenen Belastungen nicht tragen wollen, können Microservice-Architekturen in OutSystems oder die OutSystems Domain-driven-Architektur eine Alternative darstellen.
