Der ultimative Guide

Microservices-Architekturen

Alles, was Sie über den neuen Architekturstil und die unabhängig einsetzbaren Services wissen müssen.

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.

Kostenloses Poster

Erfolg in der Cloud messbar machen

Downloaden Sie dieses Poster und finden Sie heraus, ob Sie bereits über eine gute Cloud-Strategie verfügen und wie der Erfolg der Cloud-Umgebung gemessen werden kann.

Kostenloses Poster herunterladen
Poster: Erfolg in der Cloud messbar machen

 

Was sind die wesentlichen Vorteile einer Microservices-Architektur?

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:

  1. Zugang: Da Microservices separat deployed werden und über APIs kommunizieren, werden Codes und Applikationen zugänglicher für Mitarbeiter, die nicht Teil der Entwickler-Teams sind. Dank des modularen Ansatzes können Unternehmen ihre verschiedenen Services, einschließlich ihrer spezifischen Funktionen, verstehen, ohne sich Gedanken um andere Softwareteile machen zu müssen.
  2. Fehlermanagement: Wenn eine Microservices-Architektur richtig implementiert wird, macht es das den Entwickler-Teams einfacher, Bugs oder andere Fehler zu erkennen. Immer wenn ein Fehler auftritt, wissen die Entwickler ganz genau, wo sie schauen müssen, wodurch wertvolle Zeit eingespart und Aufwand im Allgemeinen reduziert wird. Zudem bedeutet die Fehlerbehebung an einem einzelnen, unabhängigen Service gleichzeitig, dass keine anderen Codes repariert oder die gesamte Applikation als solche deployed werden muss.
  3. Wartung: Dieser Vorteil geht Hand in Hand mit den ersten beiden genannten Punkten. Microservices-Architekturen gestalten die Wartung und die Verwaltung der Services einfacher. Tatsächlich kann jeder einzelne Service von einem anderen Team verwaltet werden, da diese Services für einen einzigartigen Prozess mit eigener Datenbank stehen. Zudem können einzelne Updates durchgeführt werden, ohne dass dafür das gesamte Softwaresystem zum Stillstand gebracht wird.
  4. Anpassungsfähigkeit: Microservices sind nur lose miteinander gekoppelt und kommunizieren über standardisierte Schnittstellen (APIs). Aber da sie einzeln entwickelt werden, brauchen sie nicht auf derselben Programmiersprache oder Technologie zu basieren. So kann jeder Service individuell, den auszuführenden Funktionen entsprechend, gestaltet werden.
  5. Evolutionär: Geschäftsanforderungen sind konstanten Änderungen unterworfen, weswegen Services angepasst und neue Features hinzugefügt werden müssen. In traditionellen Architekturen, in der Software als ein großes Ganzes gesehen wird, bedeutet dies einen ernsthaften Eingriff in die gesamte Unternehmenssoftware und die mögliche Beschädigung bereits vorhandener Features. Durch den modularen Ansatz der Microservice-Architektur wird diesen Problemen vorgebeugt.
  6. Skalierbarkeit: Einer der wichtigsten Vorteile von Microservices ist ihre Fähigkeit, horizontal zu skalieren: Jeder eingesetzte Service kann dupliziert werden, um Engpässe aufgrund einer langsamen Ausführung zu vermeiden. Eine weitere Möglichkeit der Leistungssteigerung wäre das Deployment von Services auf einer leistungsfähigeren Hardware oder auf mehreren Maschinen, die Daten parallel verarbeiten.
  7. Tests und Überwachung: Einzelne Software-Komponenten lassen sich viel einfacher testen als komplexe Applikationen. Wenn jeder Microservice angemessen getestet wird, dann ist meist die Software als solche robuster und zuverlässiger. Und da man eben auch nur bestimmte Teile einer Applikation isoliert betrachten kann, führt dies zu einem besserem Sicherheitsmanagement.
  8. Bereitstellung: In den letzten Jahren haben sich Automatisierungstechniken drastisch verbessert, wodurch auch die Entwicklung der Cloud und AWS vorangetrieben wurde. Dank Automatisierungstechniken für Infrastrukturen und des Prinzips der kontinuierlichen Bereitstellung konnte die operative Komplexität der Erstellung, Implementierung und des Testens von Microservices signifikant reduziert werden.
  9. Integration: Eine Software sollte so viele Features und Services wie nötig integrieren. Auch wenn dies auf den ersten Blick logisch erscheinen mag, kann die Integration einer neuen Softwarekomponente in eine bereits bestehende Applikation in der traditionellen Software-Entwicklung eine Herausforderung darstellen. Durch den Einsatz kontinuierlicher Integrationstools haben Microservices diesen Prozess grundlegend revolutioniert.
  10. Wiederverwendbarkeit: Ein allzu häufig vernachlässigter Vorteil von Microservices ist die Tatsache, dass die unabhängigen Komponenten, die die Software ausmachen, für andere Projekte in der Zukunft genutzt werden können. Indem erfolgreiche Prozesse wiederverwendet und nur leicht an die neuen Anforderungen angepasst werden, brauchen Entwickler nicht für jedes Projekt das Rad neu zu erfinden und sparen wertvolle Ressourcen ein.

 

Wie kann eine Microservices-Architektur implementiert werden?

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.

 

Beispiele für Microservices-Architekturen

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:

  • Spotify: Die Musikstreaming-Plattform zählt monatlich über 75 Millionen Nutzer. Mit mehr als 90 Teams, 600 Entwicklern und 5 Entwicklungsbüros weltweit musste Spotify Abhängigkeiten reduzieren, um eine Synchronisierung zu vermeiden. Durch kleinere Microservices und autonome Teams werden Systemausfälle klein gehalten und beeinträchtigen die User Experience nicht.
  • Zalando: Das europäische E-Commerce-Unternehmen ist ein weiteres Beispiel für einen erfolgreichen Umstieg auf eine Microservices-Architektur. Als Zalando sich für einen modularen Ansatz entschied, führte das Unternehmen auch STUPS ein, ein Plattform-as-a-Service-Toolset von AWS, das von verschiedenen autonomen Teams verwendet werden kann. Das Toolset ermöglicht Abteilungen schnelle Iterationen und die Erreichung ihrer Reportingziele.

 

Was unterscheidet Microservices-Architekturen von serviceorientierten Architekturen (SOA?)

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.

 

Was unterscheidet Microservices-Architekturen von monolithischen Architekturen?

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.

 

Was unterscheidet Microservices-Architekturen von APIs?

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.

 

Microservices und Kubernetes Governance

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.

 

Fazit

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.

Gratis Poster

20 Fragen, die Sie mit
einem Microservice-Katalog beantworten können

Jetzt kostenlos herunterladen

DE-Cloud-Microservice-Catalog-Poster_Landing_Page_Preview
check

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.

check

Erfahren Sie in unserem Poster mehr zum Microservice-Katalog.

FAQ: Microservices-Architekturen

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?

  • Spotify: Die Musikstreaming-Plattform zählt monatlich über 75 Millionen Nutzer. Mit mehr als 90 Teams, 600 Entwicklern und 5 Entwicklungsbüros weltweit musste Spotify Abhängigkeiten reduzieren, um eine Synchronisierung zu vermeiden. Durch kleinere Microservices und autonome Teams werden Systemausfälle klein gehalten und beeinträchtigen die User Experience nicht.
  • Zalando: Das europäische E-Commerce-Unternehmen ist ein weiteres Beispiel für einen erfolgreichen Umstieg auf eine Microservices-Architektur. Als Zalando sich für einen modularen Ansatz entschied, führte das Unternehmen auch STUPS ein, ein Plattform-as-a-Service-Toolset von AWS, das von verschiedenen autonomen Teams verwendet werden kann. Das Toolset ermöglicht Abteilungen schnelle Iterationen und die Erreichung ihrer Reportingziele.
  • Gruner + Jahr: In den letzten Jahren hat das deutsche Verlagshaus Gruner + Jahr seine Applikationen dezentralisiert, indem das Unternehmen verstärkt auf die Cloud setzte, darunter AWS, GCP und Microsoft Azure. Mithilfe von LeanIX Value Stream Management konnte das Unternehmen eine Brücke zwischen der EA-Landschaft und einer großen Anzahl an Cloud-Services schlagen.

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.

Bewältigen Sie die Komplexität Ihrer Microservices

Demo vereinbaren