Einführung
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.
Was genau ist eine Microservices-Architektur?
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.
Wie funktionieren Microservices?
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.
Mehr erfahren
/EN/White-Paper/SBOM-thumbnail-White-Paper.png?width=260&height=171&name=SBOM-thumbnail-White-Paper.png)
/EN/Reports/Gartner-Reprint-SBOM-Thumbnail.jpg?width=260&height=171&name=Gartner-Reprint-SBOM-Thumbnail.jpg)
/EN/Poster/Thumbnail-SBOM-Poster.png?width=260&height=171&name=Thumbnail-SBOM-Poster.png)
/DE/Reports/DE-LX-DevOp-Exp-Survey-Resource-Page-Thumbnail.png?width=260&height=171&name=DE-LX-DevOp-Exp-Survey-Resource-Page-Thumbnail.png)
