EA Management
Value Stream Management
SaaS Management Platform
LeanIX Continuous Transformation Platform®
Cloud Native SaaS-Plattform, die die höchsten Sicherheits- und Datenschutzstandards erfüllt
Alles, was Sie über den neuen Architekturstil und die unabhängig einsetzbaren Services wissen müssen.
In den letzten Jahren erregten sogenannte Microservices, auch bekannt als Microservices-Architekturen, großes Aufsehen. Und dies ist auch nicht weiter verwunderlich: Software-Applikationen werden nicht nur immer komplexer, sondern auch schwerfälliger, wodurch die Verwaltung, Aktualisierung und Wartung dieser Applikationen für viele Unternehmen zu einer großen Herausforderung wird. Microservices-Architekturen sind eine relativ neue Herangehensweise an die Entwicklung von Software, mit der komplexe Applikationen in einzelne, unabhängige Bausteine oder Services aufgeteilt werden. Diese modularen Services können individuell deployed und verwaltet werden, wodurch große Applikationen robuster gegenüber Veränderungen werden.
Das Konzept der Microservices-Architekturen kam zum ersten Mal im Jahr 2005 auf, als Peter Rodgers, Begründer des Resource Oriented Computings (ROC), erstmals den Begriff „Micro-Web-Services“ prägte. In dem Versuch, eine flexiblere und stärker serviceorientierte Softwarearchitektur zu gestalten, beschrieb er erfolgreich die Prinzipien einer gut konzipierten Microservices-Plattform. Zwei Jahre später führte Softwarearchitekt Juval Löwy die Idee einer granularen Nutzung von Services aus und diente so als Inspiration für mehrere von Experten durchgeführten Fallstudien mit vielversprechenden Ergebnissen. Heute werden Microservices-Architekturen nicht nur als nützlich, sondern als Zukunft der effizienten Software-Entwicklung und -Wartung angesehen.
Microservices-Architekturen beschreiben einen bestimmten Stil, nach dem Software-Applikationen entwickelt werden. Im Gegensatz zu traditionellen Architekturstilen, die darauf abzielen, Software als eine einzelne Einheit aufzubauen, verfolgen Microservices-Architekturen einen modularen Ansatz. Hier werden Applikationen als Suites entwickelt, die aus einer Vielzahl von Microservices bestehen, die unabhängig voneinander deployed und verwaltet werden können. Aber was genau sind Microservices eigentlich? Auch wenn es keine eindeutige Definition für Microservices gibt, sind dennoch einige bestimmte Merkmale vorhanden, die diesen revolutionären Software-Entwicklungsansatz charakterisieren.
Einer der Hauptmerkmale von Microservices ist die Art und Weise, wie dieser Architekturstil komplexe Applikationen in unterschiedlichen Komponenten unterteilt. Die Software wird also in ihre Komponenten aufgeschlüsselt, die aus unabhängig voneinander austauschbaren und erweiterbaren Services bestehen. Diese Services können als Prozesse definiert werden, die häufig über ein Netzwerk unter Verwendung von technologieunabhängigen Protokollen kommunizieren. Zudem werden Microservices entsprechend den Business Capabilities entwickelt. Und da Microservices sowohl dezentralisiert als auch klein sind, können sie sich flexibel an verschiedenste Programmiersprachen, Hardware- und Softwareumgebungen anpassen.
Die Idee lose gekoppelter Services, die leicht in der Wartung sind und gleichzeitig einfach getestet werden können, klingt besonders für Unternehmen faszinierend, deren IT-Herausforderungen in zu komplexen Applikationen begründet liegen. Doch bevor das bestehende System komplett überarbeitet wird, müssen Unternehmen zunächst verstehen, wie Microservices überhaupt funktionieren. Um eine modulare Architektur aufzubauen, müssen Unternehmen zuerst ihre Business Capabilities ermitteln sowie die Services definieren, die unabhängig voneinander laufen. Ein Microservices-Architekturdiagramm ist für die Abbildung von Abhängigkeiten notwendig, die ansonsten die Flexibilität ein jedes Services beeinträchtigen würden. Es muss zwingend sichergestellt werden, dass sich ein Fehler in einem einzelnen Bereich nicht auf das gesamte System auswirkt.
Auch wenn Microservices darauf ausgelegt sind, unabhängig zu funktionieren, sind sie in manchen Fällen dennoch voneinander abhängig und müssen miteinander kommunizieren. Diese Kommunikation findet über APIs (Application Programming Interfaces); synchrone oder asynchrone Protokolle wie HTTP/REST oder AMQP statt. Im besten Fall hat jeder Microservice seine eigene Datenbank, damit Verantwortung dezentralisiert und Updates individuell durchgeführt werden können. Wenn man den „Database as a Service“-Ansatz verfolgt, wird ein Saga (saga pattern), d.h. eine Transaktion eingerichtet, die sich über mehrere Services erstreckt, sodass die Datenkonsistenz gewährleistet ist.
Es ist jedoch nicht ungewöhnlich, dass jeder Microservice im Laufe der Zeit mehr Service-Abhängigkeiten entwickelt. Das ist ein ganz normaler Verlauf, sobald Services wachsen und sich auf eine steigende Anzahl an Schnittstellen, Standorten und Protokollen auswirken. API-Gateways nehmen alle API-Anfragen auf und leiten diese zu dem Microservice weiter, der für die Bearbeitung der Anfrage am besten geeignet ist. Zudem rufen API-Gateways Backend-Services auf und aggregieren die Ergebnisse zur Ermittlung des besten Pfads. Sie sind also für die Verarbeitung aller Anfragen, die Organisation sämtlichen Inputs und die Gestaltung einer einfachen User Experience verantwortlich.
Microservices können Unternehmen eine Reihe von Vorteilen bieten. Schließlich sind große Applikationen beliebt und erfordern eine Softwarearchitektur, die die Bedürfnisse der Geschäftstätigkeiten, der Entwickler und der Endbenutzer erfüllt. Die 10 wichtigsten Vorteile von Microservices-Architekturen lauten:
Der Umstieg von einer traditionellen Softwarearchitektur auf einen neuen Architekturstil kann auf den ersten Blick wie eine Herkulesaufgabe erscheinen. Aber da Microservices schon von vielen anderen Unternehmen getestet und eingesetzt wurden (später einige Beispiele hierzu), haben sich in den letzten zehn Jahren einige Best Practices herauskristallisiert. Bevor man jedoch eine Microservices-Architektur implementiert, sollte man bedenken, dass jeder Microservice in einer unterschiedlichen Programmiersprache entwickelt und auf verschiedenen Technologien basieren kann. Daher sind die Technologien, die für die Umsetzung einzelner Services verantwortlich sind, weniger wichtig als die softwareübergreifenden Technologien, die Integration und Kommunikation ermöglichen.
Einander verstehen: Wenn sich Unternehmen für die Einführung einer Microservices-Architektur entscheiden, sollte jedes Team, das an diesem Umstieg mitwirkt, gründlich vorbereitet sein. Schließlich geht es bei diesem Architekturstil nicht nur darum, eine große Applikation in ihre einzelnen Bestandteile zu zerlegen – es erfordert eine Veränderung in der Unternehmenskultur und -mentalität. Jedes Team muss wirklich unabhängig sein, wobei gleichzeitig Kommunikationsstandards, eine gemeinsame API-Dokumentation und Logging-Formate wesentlich für eine erfolgreiche Microservices-Architektur sind.
Zielarchitektur definieren: Microservices-Architekturen sind so konzipiert, dass sie die Softwarelandschaft von Unternehmen weniger komplex gestalten. Wenn sie aber nicht richtig aufgebaut oder verwaltet werden, können Microservices Architekturen sogar mehr Komplexität schaffen oder sogar zu Chaos führen. Bevor mit Microservices gearbeitet wird, sollte zunächst die Zielarchitektur definiert werden. Die Beseitigung widersprüchlicher Abhängigkeiten und die Sicherstellung der Datenkonsistenz über alle Microservices hinweg ist von entscheidender Bedeutung. Ein Netzwerk-Upgrade könnte notwendig sein, um Traffic zwischen Services zu vermeiden.
Services konstant überwachen: Eine große Applikation in eine Vielzahl kleiner Applikationen zu unterteilen, führt natürlich auch dazu, dass jede einzelne dieser kleinen Applikationen eine große Anzahl von Protokollen generiert, die wiederum analysiert werden müssen. Deswegen sollte ein klarer Plan für die reguläre Überwachung einzelner Microservices durch Reaktionszeit- oder Service-Fehlermeldungen erstellt werden. Dashboards, Protokolle sowie Monitoring- und Cloud Intelligence-Tools erleichtern diese Aufgaben und schaffen die notwendige Transparenz.
Im Jahr 2009 führte Tech-Gigant Netflix zum ersten Mal eine Microservices-Architektur ein und löste sich damit von seiner traditionellen monolithischen Architektur. Dies war in der Tat einer der entscheidenden Schritte, das dem Unternehmen den Weg für das phänomenale Wachstum der Plattform ebnete: Microservices senkten die Risiken für Serverausfälle und ermöglichten es den Entwicklern, kleine Code-Komponenten zu reparieren, ohne dabei die Benutzeroberfläche zu beeinträchtigen. Daher ist es nicht weiter verwunderlich, dass andere Unternehmen dem Beispiel von Netflix folgten:
Auch wenn Microservices-Architekturen und serviceorientierte Architekturen einiges Gemein haben, gibt es doch ein paar grundlegende Unterschiede im Architekturmuster sowie in der architektonischen Herangehensweise. Sowohl Microservices als auch SOA nutzen Services als Architekturelemente, die über Protokolle in einem Netzwerk miteinander kommunizieren. Während jedoch die Datenspeicherung in einer SOA von allen Services geteilt wird, hat jeder Service in einer Microservices-Architektur seine eigene Datenbank. Zudem sind Microservices wesentlich kleiner und können unabhängig voneinander deployed werden. In einer SOA könnte der Enterprise Service Bus (ESP), der die Punkt-zu-Punkt-Verbindungen zwischen Services herstellt, möglicherweise einen umfassenden Systemausfall verursachen. Des Weiteren sollte an dieser Stelle angemerkt werden, dass serviceorientierte Architekturen auch monolithisch gestaltet werden können.
Monolithische Architekturen können als Gegenstück zu Microservices-Architekturen betrachtet werden und stellen die traditionelle Software-Entwicklung dar, in der Applikationen als eine einzige Einheit denn als lose gekoppelte Einheiten gestaltet werden. Eine monolithische Software besteht aus einer einzigen Datenbank, einem User-Interface und einer serverseitigen Applikation und kann somit auch nur als Ganzes ausgeführt werden. Das bedeutet natürlich auch, dass bei Ausfällen das gesamte System beeinträchtigt wird und Entwickler-Teams stets eine neue Version der serverseitigen Applikation deployen müssen, sobald irgendwelche Änderungen vorgenommen werden. Microservices lösen dieses Problem mit kleinen, funktional eigenständigen Applikationen, die unabhängig verwaltet und aktualisiert werden können.
Wenn über Microservices gesprochen wird, dauert es nicht lange, bis auch APIs genannt werden. Aber was genau sind APIs und worin unterscheiden sie sich von Microservices? API steht für Application Programming Interface (Programmierschnittstelle) und kann als Vertrag von Aktionen gesehen werden, die von einem bestimmten Service angefordert werden dürfen. Microservices-Architekturen jedoch beschreiben eine Software-Entwicklungstechnik, während ein Microservice als solcher als kleine, in sich geschlossene Applikation definiert werden kann. APIs machen einen wichtigen Teil ein jeder Microservices-Architektur aus. Sie ermöglichen verschiedenen Services mittels standardisierter Protokolle miteinander zu kommunizieren sowie direkte Interaktionen im Service selbst.
Während Governance in monolithischen Systemen zentralisiert stattfindet, ist Microservices-Governance völlig dezentralisiert und braucht daher geeignete Governance-Mechanismen. Daher nutzen viele Unternehmen das Open-Source-Container-Orchestrierungssystem Kubernetes, um ihre Microservices-Architektur zu hosten. Ursprünglich von Google entwickelt, bietet Kubernetes eine flexible Plattform sowie CI-Tools für effiziente Microservices-Governance. Aber wie genau sieht dies in der Praxis aus? Kubernetes ermöglicht es den Benutzern, ihre Applikationen zu containerisieren, sodass sie sie in eine Cluster-Umgebung integrieren können. Ein Container enthält alles, was für die Ausführung der Services notwendig ist. So können Microservices noch einfacher konfiguriert, skaliert und deployed werden.
Es gibt viele Gründe, warum immer mehr Unternehmen auf Microservices-Architekturen umsteigen. Einer dieser Gründe steht im direkten Zusammenhang mit der Entkopplung von Services, indem immer stärker auf die Cloud gesetzt wird. Zudem gestaltet sich die Wartung einer ständig wachsenden monolithischen Software als schwierig. Die Instandhaltung von Monolithen birgt einige Risiken, die das Geschäftswachstum sowie den Erfolg der Unternehmen erheblich beeinträchtigen können. Dennoch sollte nicht vergessen werden, dass der Übergang zu einer Microservices-Architektur gut durchdacht sein muss. Denn eine erfolgreiche Microservices-Architektur liegt nicht in jedem einzelnen Service selbst begründet, sondern in den übergreifenden Technologien und Tools, die für Governance, Integration und Kommunikation eingesetzt werden.
Durch die Dokumentation von Microservices können DevOps-Teams ihre Microservices-Landschaft detailliert visualisieren und erhalten akkurate Informationen zu Ownership, Abhängigkeiten und dem Geschäftskontext.
Erfahren Sie in unserem Poster mehr zum Microservice-Katalog.
Was ist mit Microservices gemeint und wie kommunizieren sie miteinander?
Microservices-Architektur ist eine nachrichtenbasierte Kommunikation. Die Kommunikation ist also nicht direkt, sondern findet mittels eines Messaging-Systems statt, an das die Nachrichten geschickt werden, die später von den Microservices verarbeitet werden sollen.
Was sind Beispiele für Microservices?
Was ist der Unterschied zwischen APIs und Microservices?
API steht für Application Programming Interface (Programmierschnittstelle) und kann als Vertrag von Aktionen gesehen werden, die von einem bestimmten Service angefordert werden dürfen.
Microservices-Architekturen jedoch beschreiben eine Software-Entwicklungstechnik, während ein Microservice als solcher als kleine, in sich geschlossene Applikation definiert werden kann.