Close

Microservices und Microservices-Architektur

Erfahre mehr über die Vor- und Nachteile von Microservices und wie sie sich von Monolithen unterscheiden.

Was sind Microservices?

"Microservices" ist ein moderner Begriff zur Beschreibung der traditionellen Trennung von Zuständigkeiten innerhalb eines verteilten, vernetzten Projekts. Microservices ist eine Idee, die der alten fundamentalen Unix-Philosophie "kleiner, scharfer Werkzeuge" folgt. Beide Konzepte bauen auf einem anderen grundlegenden Informatikmuster der "Komposition" auf, was bedeutet, dass komplexe Systeme die Summe der zusammensetzbaren Einheiten auf niedrigerer Ebene sind.

Artikel zu Microservices

[FORTSETZUNG]

Die Komposition erfolgt über alle Schichten eines Softwareprojekts. Auf der niedrigsten Ebene, der Unit-Ebene, interagieren einzelne unabhängige Codefunktionen über eine gemeinsame Schnittstelle miteinander, um Codesammlungen oder -bibliotheken zu erstellen. Auf der Shell-Ebene des Betriebssystems können Shell-Befehle erstellt werden, um eine Pipeline mit übergeordneten Funktionen zu erstellen. Microservices sind eine Kompositionsebene, die zwischen Webservices stattfindet. Ein Microservice ist ein Webservice, der für ein Teilstück der Domain-Logik verantwortlich ist. Microservices interagieren über einfache Netzwerkprotokolle wie REST miteinander, um Aktionen durchzuführen, sie wissen jedoch nicht, wie andere Services intern funktionieren. Dieses harmonische Zusammenspiel von Microservices ist eine Microservice-Architektur.

Die Microservices-Architektur oder (MSA) hat viel Aufmerksamkeit erhalten, da Softwareteams nach neuen Wegen suchen, um ihre Release-Workflows zu verbessern. Amazon, Netflix und Ebay gehören zu den Unternehmen, die diese Art der Softwareerstellung offen nutzen, und sie haben zur Community beigetragen, indem sie ihre eigenen Erfahrungen veröffentlicht und Tools entwickelt haben, die anderen bei der Einführung helfen können.

Das Leitmotiv von Mikroservices ist die Entwicklung von Anwendungen durch Aufsplitten von Businesskomponenten in Services, die unabhängig bereitgestellt und betrieben werden.

Ein Diagramm, das zeigt, wie ein großer Würfel in viele kleinere Würfel zerlegt werden kann.

Entwickler können sich dann in kleineren Teams organisieren, die auf verschiedene Services spezialisiert sind, mit unterschiedlichen Stacks und entkoppelten Bereitstellungen. Diese Trennung von Zuständigkeiten und entkoppelte unabhängige Funktion ermöglicht eine optimierte agile Softwareentwicklung wie Continuous Delivery und Integration.

Serviceorientierte Architektur (SOA) im Vergleich zu Microservices

Serviceorientierte Architektur und Microservices sind zwei Arten von Webservice-Architekturen höherer Ordnung. Microservices können als eine Lite-Version von SOA angesehen werden. Die Unterscheidung zwischen den beiden Architekturtypen besteht in der technischen Klassifizierung von Servicetypen. SOA verfügt über 4 grundlegende Servicetypen: Geschäfts-, Unternehmens-, Anwendungs- und Infrastrukturservices. Diese Typen definieren die zugehörige domänenspezifische Verantwortung der zugrunde liegenden Services. Im Vergleich dazu gibt es bei Microservices nur zwei Servicetypen: Funktionale und Infrastrukturservices.

Beide Architekturen haben die gleichen Standards auf verschiedenen Ebenen eines Unternehmens. Die Existenz von MSA beruht auf dem Erfolg des SOA-Musters. Daher ist das MSA-Muster eine Teilmenge von SOA. Hier liegt das Hauptaugenmerk auf der Laufzeitautonomie jedes Service.

Monolithische Anwendung im Vergleich zu Microservices

Ein Diagramm, das den Unterschied zwischen Monolithen und Microservices bei der Continuous Delivery zeigt.

Microservices entkoppeln wichtige spezifische Anliegen im Geschäftsbereich in separate unabhängige Codebasen. Eine monolithische Anwendungsarchitektur kann man sich als die Umkehrung von Microservices vorstellen. Ein Monolith ist eine Codebasis, die alle Geschäftsanliegen miteinander verbindet. Monolithen können früh in einem Projektleben praktisch sein, um den kognitiven Aufwand für das Codemanagement und Deployment zu erleichtern. Dadurch kann alles im Monolith auf einmal veröffentlicht werden.

Viele Projekte beginnen zunächst als Monolith und entwickeln sich dann zu einer Microservice-Architektur. Wenn einem Monolith neue Funktionen hinzugefügt werden, kann es umständlich werden, wenn viele Entwickler an einer einzigartigen Codebasis arbeiten. Codekonflikte werden immer häufiger und das Risiko steigt, dass Aktualisierungen einer Funktion Fehler bei einer nicht verwandten Funktion verursachen. Wenn diese unerwünschten Muster auftreten, ist es möglicherweise an der Zeit, über eine Migration zu Microservices nachzudenken.

So funktioniert Microservices-Architektur

Nehmen wir als Beispiel ein hypothetisches E-Commerce-Softwareprojekt. Es gibt einige klar definierte domänenspezifische Geschäftsfunktionen. E-Commerce-Websites verfügen über ein Authentifizierungssystem für die Benutzeranmeldung und -abmeldung. Ein Einkaufswagen enthält eine Liste von Produkten, an denen der Benutzer interessiert ist. Ein Abrechnungssystem ermöglicht den Benutzern, für ihre Einkäufe zu bezahlen.

In einer Microservice-Architektur wären diese Beispiel-Geschäftsdomänen unabhängige Services. Sehen wir uns das Abrechnungssystem als konkretes Beispiel an. Abhängig von der Anzahl der Mitarbeiter des Unternehmens kann es ein spezielles "Abrechnungsteam" geben, das für die Entwicklung und Qualitätssicherung dieses Abrechnungs-Microservices zuständig ist. Der Abrechnungs-Microservice hätte einen eigenen Release-Plan und eigene Deployment-Playbooks. Der Abrechnungsservice würde eine dokumentierte und versionierte API bereitstellen, damit andere Services kommunizieren und seine Funktionen nutzen können.

Vorteile und Nachteile von Microservices

+ Horizontale Skalierung

Microservices sind absichtlich dezentralisiert und können in Clustern bereitgestellt werden. Dies ermöglicht eine dynamische horizontale Skalierung über die Servicegrenzen hinweg. Wenn ein Microservice seine Belastungskapazität ausbaut, können neue Instanzen dieses Services schnell in den zugehörigen Cluster eingesetzt werden, um den Druck zu verringern.

+ Unabhängige Ausführung in den Teams

Die für Microservices zuständigen Teams können im Unternehmen unabhängig von anderen Feature-Teams arbeiten. Dies ermöglicht eine schnellere Ausführung und Bereitstellung neuer Funktionen.

+ Stärkerer Fokus auf Qualität

Die Trennung von geschäftlichen Zuständigkeiten in unabhängigen Microservices stellt sicher, dass sich das Serviceteam, dem dieser Service gehört, voll auf die Qualität konzentriert.

- Exponentielle Infrastrukturkosten

Jeder neue Microservice, den ein Unternehmen seinem Produktions-Deployment hinzufügt, verursacht eigene Kosten für Testsuite, Deployment-Playbooks, Hosting-Infrastruktur, Überwachungstools und mehr.

- Mehr organisatorischer Aufwand

Ein zusätzliches Maß an Kommunikation und Zusammenarbeit ist erforderlich, um Updates und Schnittstellen zwischen Microservices-Architekturteams zu koordinieren.

- Komplexität der Entwicklungsumgebung

Wenn ein Projekt in mehrere Microservices aufgeteilt wird, besteht die Herausforderung, die verteilte Architektur in der lokalen Entwicklungseinrichtung zu reproduzieren.

Zukunft der Microservices

Die Containerisierung und der Einsatz von Containern ist ein neues Muster der verteilten Infrastruktur. Tools wie Docker und Kubernetes werden verwendet, um einen Service in einen kompletten "Container" zu verpacken, der schnell bereitgestellt und verworfen werden kann. Diese neuen Infrastrukturtools ergänzen die Microservices-Architektur. Microservices können containerisiert und einfach mit einem Container-Management-System bereitgestellt und verwaltet werden.

Die Einführung von Microservices sollte als Weg und nicht als unmittelbares Ziel für ein Team angesehen werden. Fange klein an, um die technischen Anforderungen eines verteilten Systems kennenzulernen und zu verstehen, wie Services beim Auftreten von Fehlern ordnungsgemäß beendet und einzelne Komponenten skaliert werden können. Mit zunehmender Erfahrung und Kenntnis kannst du nach und nach immer mehr Services extrahieren.

Die Microservice-Architektur ist noch ziemlich jung, aber sie ist eine vielversprechende Art, Anwendungen zu entwickeln, und lohnt auf jeden Fall einen genaueren Blick. Denke aber auch daran, dass sie sich möglicherweise (noch) nicht gut für dein Team eignet.

Claire Maynard
Claire Maynard

Claire gehört zum Marketingteam von Atlassian und hat schon viele Projekte in den Bereichen Wachstum, Performance und Produktmarketing umgesetzt. Aktuell ist sie für die Marken-, Inhalts- und Go-to-Market-Strategie für Confluence Cloud zuständig. In ihrer Freizeit liebt es Claire zu surfen oder zu joggen, neue Restaurants in San Francisco auszuprobieren oder Städte auf der ganzen Welt zu bereisen.