Microservices-Architekturen vs. monolithische Architekturen vs. SOA Was sind Microservices und wo liegen ihre Vorteile?

Anbieter zum Thema

SolarWinds EMEA Headquarters

SolarWinds Software Germany GmbH

Windhoff Group

Für viele ist die im Rahmen der XML-Revolution eingeführte serviceorientierte Architektur (SOA) der Vorläufer heutiger Microservice Architekturen. Fakt ist: die digitale Welt ist heute von Microservices durchzogen – und wäre ohne Microservices so nicht möglich. Ein Überblick.

Nicht nur Unternehmensanwendungen haben sich im Laufe der Zeit verändert, um den verschiedensten Geschäftsanforderungen und Computersystemen gerecht zu werden. Auch die Mechanismen für die Kommunikation zwischen verschiedenen Ebenen von Computersystemen mussten sich weiterentwickeln.

So etwa konnte man schon früh die XML-Revolution und die Einführung der serviceorientierten Architektur (SOA) miterleben, vor allem in IT-Großunternehmen. Protokolle wie das Distributed Computing Object Model (DCOM) und die Common Object Broker Request Architecture (COBRA) führten zum Konzept der SOA, die von vielen als Vorläufer der modernen Microservices-Architektur betrachtet wird.

Microservices sind in Unternehmen ganz unterschiedlicher Art und Größe verbreitet, was bei SOA oder Simple Object Access Protocol (SOAP) so nie der Fall war. SOA entwickelte sich anschließend zu einem asynchronen Messaging-Modell, das Publisher und Subscriber nutzte, um Daten über Warteschlangensysteme auszutauschen und die Skalierung von Systemen zu ermöglichen.

Microservices-Architekturen bauen auf diesem Modell auf, mit einem zentralen Unterschied: RESTful-APIs erledigen fast die gesamte Kommunikation. RESTful-APIs versuchen, die Komplexität der Kommunikation zwischen Computern zu reduzieren.

Wenn es ein Standardprotokoll für die Kommunikation gibt, können Entwickler zudem Schnittstellen einfacher entwickeln und diese zu zentralen Bausteinen für die Softwarebereitstellungen machen. Microservices-Architekturen werden immer beliebter und auch Infrastruktur- und Entwicklungs-Frameworks wurden ausgebaut, um das Modell zu unterstützen.

Auf der Infrastrukturseite bietet Kubernetes – eine cloudnative Container-Orchestrierungsplattform – Kerndienste wie softwaredefinierte Netzwerkdienste, vor allem für den Lastenausgleich und Desired State Management. Public-Cloud-Angebote von Amazon, Google und Microsoft haben weitere Möglichkeiten für die Microservices-Entwicklung geschaffen, indem Unternehmen jeder Größe mit ihnen kosteneffektive Designmuster nutzen können, etwa serverlose Funktionen und softwaredefiniertes Routing. Jeder Microservice kann unabhängig entwickelt und aufgebaut werden, sodass Unternehmen DevOps nutzen können, um CI/CD (Continuous Integration/Continuous Delivery) zu ermöglichen.

Beispiele für Microservices

Microservices zerlegen Anwendungen in ihre Kernfunktionen, die jeweils als Service bezeichnet werden. Jeder Service wird unabhängig entwickelt und bereitgestellt, damit beim Ausfall eines Services keine mit ihm verbundenen Services ebenfalls ausfallen.

Ein konkretes Beispiel: Wenn man beim Online-Shopping nach einem Produkt sucht, ist die Suchfunktion ein eigener Service. Wenn man Artikel in den Warenkorb legt, ist es ein weiterer Service. Falls es ein Empfehlungsmodul gibt, ist auch das ein weiterer Service für den Kunden, der mit einer Diagrammdatenbank für den Datenspeicher ausgeführt wird. Der Aufbau von Microservices ermöglicht Anwendungen zudem eine höhere Skalierbarkeit.

Microservices-Architekturen vs. monolithische Architekturen vs. SOA

Wie bereits erwähnt, sind Microservices nichts grundlegend Neues. Unternehmen sind aus verschiedenen Gründen – darunter Leistung, Kosten und Flexibilität – von monolithischen Anwendungen auf ein auf Webservices basiertes Modell umgestiegen. Jeder Service in einer SOA war genau wie bei Microservices rund um einen bestimmten Geschäftsprozess organisiert.

SOA unterschied sich darin von Microservices, dass Gruppen von Anwendungen über einen Enterprise-Service-Bus kommunizierten, der auf einem bestimmten Kommunikationsprotokoll basierte. Die Verbreitung von SOA hat zwar zugenommen, wird aber durch ihre Komplexität gebremst.

Meine Erfahrung bei der Arbeit mit SOA-Systemen hat gezeigt, dass die Entwicklung von Anwendungen durch diese Komplexität erschwert und das Debugging fast unmöglich gemacht wird. SOA hat dennoch eine bleibende Wirkung hinterlassen und dafür gesorgt, dass Anwendungen eigenständiger und Anwendungsentwicklungsteams kleiner werden und sich stärker auf bestimmte Geschäftsfunktionen konzentrieren.

Die Rolle von Containern in Microservices

Containerinfrastrukturen wie in Kubernetes haben Microservices deutlich praktikabler gemacht. Man denke zum Beispiel an die Zeiten zurück, in denen man für jeden Service einen physischen Server in einem Rechenzentrum benötigte. Als Anwendungen immer komplexer wurden, war dieses Modell in keinster Weise skalierbar und wurde durch Virtualisierung ersetzt. Diese ermöglicht softwaredefinierte Infrastrukturen, doch die daraus resultierenden virtuellen Maschinen (VMs) benötigen immer noch viele Ressourcen: Jede Rechenumgebung muss eine vollständige Kopie des Gastbetriebssystems umfassen. Daher benötigt jede virtuelle Maschine ziemlich viel Speicherplatz und sie zu verschieben nimmt Zeit und Netzwerkressourcen in Anspruch.

Genau aus diesen Gründen sind die meisten Entwickler auf die von Netflix populär gemachten Container umgestiegen. Die moderne Containernutzung begann mit Docker und wechselte dann zu Kubernetes. Docker ist eine Container-Laufzeitumgebung, mit der Workloads einen Kernel mit dem Hostbetriebssystem teilen können, sodass sich nur der Anwendungscode und alle Bibliotheksabhängigkeiten in einem Container befinden müssen. Diese Container werden wie Open-Source-Module in öffentlichen oder privaten Repositorys veröffentlicht.

Einer der interessanten Vorteile von Docker besteht darin, dass einzelne Entwickler den gesamten Anwendungsstack auf ihren Laptops haben und auf ihren eigenen Geräten Anwendungen entwickeln, in cloudbasierte Testumgebungen übertragen und schließlich in die Produktion geben können. Da der Softwarestack an all diesen Orten identisch ist, sollte nie das früher in der Produktion allgegenwärtige „Auf meinem Rechner hat es noch funktioniert!“-Problem auftauchen. Durch die einfache Bereitstellung in öffentlichen Clouds wie Azure und AWS können kleine Teams sich außerdem darauf konzentrieren, Codes zu schreiben, statt Hardware zu verwalten.

Die Hauptvorteile von Microservices-Architekturen

Microservices bieten Unternehmen zahlreiche Vorteile. Auch wenn die Anwendungsarchitektur sich hauptsächlich auf technische Ergebnisse konzentriert, ermöglicht der Softwareentwicklungsprozess mehr gleichzeitige Entwicklungen. Durch die lose Kopplung einzelner Microservices sind außerdem verschiedene Entwicklungszyklen für jeden Service möglich, sodass Upgrades und neue Funktionen schneller bereitgestellt werden können.

Neben den Vorteilen für die Entwicklung ist die Infrastruktur, die Microservices zugrunde liegt, außerdem fehlertoleranter als ältere Systeme. Wenn man in älteren Hardware-Architekturen die High Availability von Systemen sicherstellen wollte, musste man sich um Clustering, Lastenausgleich und in manchen Fällen auch die Integration mit dem Back-End-Speicher kümmern. Diese Art der Architektur verursachte eine hohe Komplexität sowohl der Anwendungen als auch der Infrastruktur. In modernen cloudnativen Systemen wie Kubernetes ist High Availability bereits in die Plattform integriert. Wenn ein Container (oder Kubernetes-Pod) abstürzt, wird er auf einem anderen Knoten neu bereitgestellt, damit die Anwendung online bleibt.

So profitiert DevOps von Microservices

DevOps und Microservices haben sich gemeinsam entwickelt, angetrieben durch die Verbrauchernachfrage nach verschiedenen Internetdiensten, die sich wandelnden Benutzeranforderungen und die sich ständig weiterentwickelnde Sicherheitsbedrohungslandschaft.

Die Verbindung zwischen den Vorteilen von DevOps und Microservices beginnt mit den Entwicklungsmethoden, die Unternehmen nutzen. Typischerweise gibt es für jeden Service ein eigenes DevOps-Team, das sich mit einem begrenzten Bereich beschäftigt und sich so stärker auf das Fixen und Verbessern ihrer Services und auf das Anwendungsstackmanagement einstellen kann. Durch die Automatisierungsfunktionen von Kubernetes und anderen Containerplattformen können alle Services automatisiert getestet, gepackt und bereitgestellt werden.

Diese automatisierten Tests ermöglichen kürzere Feedbackschleifen und reduzieren den Zeitaufwand für die Behebung von Fehlern in der Codebasis. Neue Versionen bereitzustellen ist ganz einfach: Es reicht, die neue Build in die Containerregistrierung zu verschieben und die Produktions-Pod-Definition so zu aktualisieren, dass sie auf das Containerimage verweist. Je stärker DevOps sich weiterentwickelt, desto mehr sollten auch Performance-Monitoring-Tools mit diesen Entwicklungen mitwachsen.

Über den Autor

Joey D'Antoni ist Principal Consultant bei Denny Cherry and Associates Consulting und publiziert regelmäßig Fachbeiträge bei SolarWinds.

(ID:48799925)