Microservices und Microservices-Architektur
Erfahre mehr über die Vor- und Nachteile von Microservices und wie sie sich von Monolithen unterscheiden.
Noch vor Kurzem war die bevorzugte Methode zur Entwicklung von Softwareanwendungen die Nutzung einer monolithischen Architektur, d. h. einer einzelnen, autonomen Einheit. Dieser Ansatz funktionierte für viele Entwickler gut, bis die Komplexität der Anwendungen zunahm. Wenn in einem monolithischen System an einem kleinen Codeabschnitt Änderungen vorgenommen werden, muss das gesamte System neu erstellt werden. Dies ist mit Tests am gesamten System und dem Deployment einer völlig neuen Version der Anwendung verbunden.
Dann kamen Microservices ins Spiel – ein Ansatz, der Softwaresysteme in kleinere Einheiten aufteilt, die autonom entwickelt und bereitgestellt werden. Die Entwicklung von Microservice-Architekturen wurde durch die DevOps-Bewegung vorangetrieben, die nach der häufigen Bereitstellung von Updates wie neuen Funktionen, der Behebung von Bugs und Sicherheitsverbesserungen strebt. In vielen Fällen bot dies Unternehmen auch die Möglichkeit, mit modernen Programmiersprachen und Updates an einem Technologie-Stack Legacy-Anwendungen neu zu schreiben.
Microservices sind eine Ansammlung kleiner Einheiten, durch die kontinuierlich große, komplexe Anwendungen realisiert und bereitgestellt werden.
Was sind Microservices?
Eine Microservice-Architektur, die auch einfach als "Microservices" bezeichnet wird, ist ein Ansatz, bei dem eine Anwendung aus einer Reihe von unabhängig bereitstellbaren Services besteht, die dezentral und autonom entwickelt werden. Diese Services sind lose verbunden, können unabhängig voneinander bereitgestellt werden und sind leicht zu warten. Eine monolithische Anwendung wird als einzelne unteilbare Einheit erstellt, während Microservices diese Einheit in eine Ansammlung unabhängiger Einheiten aufteilen, die zum großen Ganzen beitragen. Microservices sind ein wesentlicher Bestandteil von DevOps, schließlich bilden sie die Grundlage für Continuous-Delivery-Praktiken, die Teams eine schnelle Anpassung an Benutzeranforderungen ermöglichen.
Ein Microservice ist ein Webservice, der für ein Teilstück der Domain-Logik verantwortlich ist. Mehrere Microservices bilden zusammen eine Anwendung, wobei jeder von ihnen eine Funktion für eine Domain bereitstellt. Microservices interagieren mithilfe von APIs wie REST oder gRPC miteinander, haben jedoch keine Kenntnisse über die interne Funktionsweise der anderen Services. Dieses harmonische Zusammenspiel von Microservices ist eine Microservice-Architektur.
Eine Microservice-Architektur ermöglicht Entwicklern, sich in kleineren Teams zu organisieren, die auf verschiedene Services spezialisiert sind, mit unterschiedlichen Stacks und entkoppelten Deployments. Beispielsweise basiert Jira auf mehreren Microservices, die jeweils spezifische Funktionen bereitstellen, darunter das Suchen nach Vorgängen, Anzeigen von Vorgangsdetails, Kommentieren, Weitergeben von Vorgängen und mehr.
Merkmale von Microservices
Auch wenn es keine formale Definition für eine Microservice-Architektur gibt, haben Microservices einige gemeinsame Muster oder Merkmale, die du kennen solltest.
Autonome Komponenten
Der Grundbaustein einer Microservice-Architektur ist eine Komponente, bei der es sich um ein Softwarepaket, einen Webservice oder eine Ressource, eine Anwendung oder ein Modul handeln kann, das eine Reihe verwandter Funktionen enthält. Oder einfacher ausgedrückt gemäß Martin Fowler: "Softwarekomponenten sind Dinge, die unabhängig voneinander ersetzbar und aktualisierbar sind."
In einer Microservice-Architektur kann jede Komponente entwickelt, bereitgestellt, betrieben, geändert und neu bereitgestellt werden, ohne die Funktion anderer Services oder die Integrität einer Anwendung zu beeinträchtigen.
Komponenten werden zusammen mit anderen Komponenten verwendet, um eine Kundenerfahrung oder einen Geschäftswert zu bieten. Am häufigsten sind dies Services und Bibliotheken, es können jedoch auch CLI-Tools, mobile Apps, Front-End-Module, Daten-Pipelines, Modelle für maschinelles Lernen und viele andere Konzepte enthalten sein, die innerhalb einer Microservice-Architektur anwendbar sind.
Übersichtliche Schnittstellen
Sobald die einzelnen Komponenten erstellt sind, ist eine erhebliche Menge an Logik erforderlich, damit sie über einen Kommunikationsmechanismus wie RPC, REST über HTTP oder ein ereignisbasiertes System miteinander kommunizieren können. Hierzu können in einer Microservice-Architektur synchrone oder asynchrone Methoden oder eine Kombination aus beidem verwendet werden.
Am wichtigsten ist, dass jeder Microservice einen klaren, intuitiven Vertrag bietet, der beschreibt, wie ein Verbraucher diesen Service nutzen kann. Dies erfolgt normalerweise über eine API, die zusammen mit dem Service veröffentlicht wird.
You build it, you run it
Die DevOps-Philosophie "You build it, you run it" unterstreicht, dass bei der Umwandlung einer Architektur zu Microservices die Struktur der Teams berücksichtigt werden muss. DevOps richtet die Anreize für alle funktionalen Rollen neu aus – Entwickler, QS-Mitarbeiter, Release Engineers, Betriebstechniker – und verbindet sie zu einem Team mit dem gemeinsamen Ziel, qualitativ hochwertige Software zu erstellen. DevOps-Praktiken wie CI/CD, automatisierte Tests und Feature-Flags beschleunigen das Deployment und tragen zur Aufrechterhaltung der Systemstabilität und -sicherheit bei. Außerdem kann jedes Team eigene Microservices entwickeln und bereitstellen, ohne andere Teams zu beeinträchtigen.
Die Weiterentwicklung der Cloud hat die Entwicklung, das Deployment und den Betrieb von Microservices vereinfacht. Teams werden durch Methoden zur Automatisierung von Infrastruktur wie Continuous Integration, Continuous Delivery und automatisierte Tests unterstützt.
Serviceorientierte Architektur im Vergleich zu Microservices
Eine serviceorientierte Architektur (SOA) und Microservices sind zwei Arten von Webservice-Architekturen. Wie Microservices umfasst eine SOA wiederverwendbare, spezialisierte Komponenten, die unabhängig voneinander einsetzbar sind. Die Unterscheidung zwischen den beiden Architekturtypen besteht in der technischen Klassifizierung von Servicetypen.
Eine SOA verfügt über vier grundlegende Servicetypen:
- Business
- Enterprise
- Anwendung
- Infrastrukturservices
Diese Typen definieren die zugehörige domainspezifische 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 einer Microservice-Architektur beruht auf dem Erfolg eines SOA-Musters. Daher ist das Microservice-Architektur-Muster eine Teilmenge von SOA. Hier liegt das Hauptaugenmerk auf der Laufzeitautonomie jedes Service.
Vorteile von Microservices
Flexibilität
Da die Services in einer Microservice-Architektur in der Regel von kleinen, unabhängigen Teams entwickelt werden, fördert dies die Anwendung von agilen Praktiken. So sind die Teams in der Lage, unabhängig zu arbeiten und schnell zu handeln, wodurch die Entwicklungszyklen verkürzt werden.
Flexible 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 die Grenzen seiner Belastbarkeit erreicht, können neue Instanzen dieses Service schnell im zugehörigen Cluster bereitgestellt werden, um Abhilfe zu schaffen.
Häufige Releases
Ein wichtiger Vorteil von Microservices sind die häufigen und schnelleren Release-Zyklen. Als ein wichtiges Element von Continuous Integration und Continuous Delivery (CI/CD) ermöglichen Microservices Teams, mit neuen Funktionen zu experimentieren und Änderungen rückgängig zu machen, wenn etwas nicht funktioniert. Auf diese Weise kann Code einfacher aktualisiert und die Einführung von neuen Funktionen beschleunigt werden.
Flexible Technologie
Bei der Nutzung einer Microservice-Architektur müssen Teams nicht unbedingt einem festgelegten Ansatz mit einer Toolkette folgen, sondern haben die Möglichkeit, ihre bevorzugten Tools auszuwählen.
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.
Hohe Zuverlässigkeit
Durch die Trennung von Funktionen reduzieren Microservices das Risiko, dass bei der Veröffentlichung von Updates eine ganze Anwendung oder Codebasis beschädigt wird. Fehler und Bugs lassen sich in einzelnen Services einfach isolieren und beheben. Änderungen können nur für einen bestimmten Service bereitgestellt werden, ohne zu riskieren, dass die gesamte Anwendung zum Erliegen kommt. Dies sorgt für eine höhere Zuverlässigkeit.
Herausforderungen der Microservice-Architektur
Unkontrollierte Entwicklung
Mit dem Wechsel von einer monolithischen Architektur zu Microservices nimmt die Komplexität zu, da es an mehreren Orten mehr Services gibt, die von mehreren Teams erstellt werden. Das macht es schwierig herauszufinden, welchen Bezug verschiedene Komponenten zueinander haben, wer für eine bestimmte Komponente zuständig ist oder wie verhindert werden kann, dass abhängige Komponenten beeinträchtigt werden. Wenn die unkontrollierte Entwicklung nicht eingedämmt wird, führt dies zu einer langsameren Entwicklungsgeschwindigkeit und einer schlechten Betriebsleistung. Ein zunehmend komplexes System erfordert ein erfahrenes Operations-Team, das die kontinuierlichen neuen Deployments und häufigen Änderungen in der Architektur verwaltet.
Keine klaren Zuständigkeiten
Bei der Nutzung einer Microservice-Architektur entsteht Verwirrung darüber, wer wofür zuständig ist. Ein DevOps-Team kann eine Kombination aus APIs, Komponentenbibliotheken, Überwachungstools und Docker-Images für Benutzer ausführen, um eine Anwendung bereitzustellen. Es ist wichtig, einen Einblick in Informationen zu den Komponenten zu haben, einschließlich ihrer Besitzer und Ressourcen und den sich entwickelnden Beziehungen zwischen anderen Komponenten. Damit alle Beteiligten das zum Verständnis eines Produkts erforderliche Wissen leicht finden können, ist eine klare Kommunikation und Koordination zwischen den zahlreichen Teams erforderlich.
Exponentielle Infrastrukturkosten
Jeder neue Microservice, der dem Produktions-Deployment hinzufügt wird, verursacht eigene Kosten für Testsuite, Deployment-Playbooks, Hosting-Infrastruktur, Überwachungstools und mehr.
Zusätzlicher organisatorischer Aufwand
Ein zusätzliches Maß an Kommunikation und Zusammenarbeit ist erforderlich, um Updates und Schnittstellen zwischen Microservice-Architekturteams zu koordinieren.
Fehlerbehebung
Es kann schwierig sein, Fehler in einer Anwendung zu beheben, die mehrere Microservices mit jeweils eigenen Protokollen enthält. Ein einzelner Geschäftsprozess kann auf mehreren Computern zu unterschiedlichen Zeiten ausgeführt werden, wodurch die Fehlerbehebung noch komplizierter wird.
Reaktion auf Vorfälle
Es ist wichtig, Informationen zur Incident Response für einen Microservice zu haben, wie z. B., wer den Microservice nutzt, wo und wie der Microservice bereitgestellt wurde und an wen du dich wenden kannst, wenn etwas schiefgeht.
Microservices und DevOps: ein unzertrennliches Paar
Angesichts der zunehmenden Komplexität und der Abhängigkeiten zwischen Microservices wird die Anwendung von DevOps-Praktiken zur Automatisierung des Deployments, der Überwachung und des Lebenszyklus als wesentlicher Bestandteil von Microservice-Architekturen betrachtet. Aus diesem Grund werden Microservices oft als erster Schritt zur Einführung einer DevOps-Kultur angesehen, die Folgendes ermöglicht:
- Automatisierung
- Bessere Skalierbarkeit
- Verwaltbarkeit
- Flexibilität
- Beschleunigung von Auslieferung und Deployment
Wichtige Technologien und Tools für eine Microservice-Architektur
Container, Docker und Kubernetes
Ein Container ist vereinfacht nichts anderes als ein Paket, in dem eine Anwendung und all ihre Abhängigkeiten verpackt sind, sodass sie einfach und konsistent bereitgestellt werden kann. Da Container kein eigenes Betriebssystem enthalten, sind sie kleiner und leichter als herkömmliche virtuelle Maschinen. Sie lassen sich schneller hoch- und wieder herunterfahren, sodass sie perfekt zu den kleineren Services in Microservice-Architekturen passen.
Angesichts der hohen Anzahl von Services und Containern ist die Orchestrierung und Verwaltung großer Gruppen von Containern unerlässlich. Docker ist eine beliebte Containerisierungs-Plattform und Container-Laufzeit, mit deren Hilfe Entwickler Container erstellen, bereitstellen und ausführen können. Doch mit Docker allein wird die Ausführung und Verwaltung von Containern im größeren Maßstab eine Herausforderung. Hier schaffen Kubernetes und andere Lösungen wie Docker Swarm, Mesos und HashiCorp Nomad Abhilfe.
Die Containerisierung und das Deployment von Containern ist ein neues Muster der verteilten Infrastruktur. Docker and Kubernetes verpacken einen Service in einen kompletten Container, der schnell bereitgestellt und verworfen werden kann. Diese neuen Infrastrukturtools ergänzen die Microservice-Architektur. Microservices können containerisiert und einfach mit einem Container-Management-System bereitgestellt und verwaltet werden.
API-Gateways
Die einzelnen Services in einer Microservice-Architektur kommunizieren miteinander über klar definierte APIs. Ein API-Gateway fungiert als Reverse-Proxy, indem es API-Aufrufe entgegennimmt, die erforderlichen Services zusammenführt und die entsprechenden Ergebnisse ausgibt. API-Gateways bieten eine Abstraktion in Form eines einzelnen API-Endpunkts, obwohl APIs von mehreren Microservices bereitgestellt werden. API-Gateways können auch Aufgaben wie Ratenbegrenzung, Überwachung, Authentifizierung, Autorisierung und Weiterleitung an den entsprechenden Microservice konsolidieren.
Messaging und Streaming von Ereignissen
Aufgrund der verteilten Architektur von Microservices benötigen Teams eine Möglichkeit, Statusänderungen und andere Ereignisse miteinander auszutauschen. Messaging-Systeme übertragen Informationen zwischen Microservices, sodass einige Microservices Ereignisse innerhalb ihrer primären Schnittstelle verarbeiten können. Beispielsweise führen Änderungen an Confluence-Seiten zu einem Ereignis, das eine Neuindizierung für die Suche und Benachrichtigungen an die Benutzer auslöst, die die Seite gerade ansehen.
Protokollierung und Überwachung
In einer Microservice-Architektur ist es schwieriger, Probleme zu identifizieren und diese für mehrere Services zu beheben. Daher ist es wichtig, Observability-Tools für die Protokollierung, Überwachung und Nachverfolgung zu haben. So kannst du nachvollziehen, wie sich Microservices verhalten und potenzielle Probleme, Probleme bei der Fehlerbehebung sowie Fehler beim Debuggen identifizieren.
Continuous Integration/Continuous Delivery
Ein wichtiger Vorteil von Microservices sind die häufigen und schnelleren Release-Zyklen. Als ein wichtiges Element von CI/CD ermöglichen Microservices Teams, mit neuen Funktionen zu experimentieren und Änderungen rückgängig zu machen, wenn etwas nicht funktioniert. Auf diese Weise kann Code einfacher aktualisiert und die Einführung von neuen Funktionen beschleunigt werden.
Entwicklerportal
Da verteilte Architekturen immer komplexer werden, profitieren Entwicklungsteams von einem Tool, das Informationen über Entwicklungsergebnisse und die Teamzusammenarbeit an einem Ort konsolidiert. Beispielsweise ist Atlassian Compass darauf ausgelegt, die ungebremste Verbreitung von Microservices einzudämmen, indem Daten und Erkenntnisse über DevOps-Toolketten hinweg bereitgestellt werden.
Zukunft der Microservices
Die Containerisierung und das Deployment von Containern ist heute ein gängiges Muster der verteilten Infrastruktur. Tools wie Docker und Kubernetes verpacken einen Service in einen kompletten Container, der schnell bereitgestellt und verworfen werden kann. Diese neuen Infrastrukturtools ergänzen die Microservice-Architektur, da Microservices containerisiert und einfach mit einem Container-Management-System bereitgestellt und verwaltet werden können.
Die Einführung von Microservices sollte als Weg und nicht als unmittelbares Ziel für ein Team angesehen werden.
Es kann hilfreich sein, klein anzufangen, um die technischen Anforderungen eines verteilten Systems kennenzulernen und zu verstehen, wie einzelne Komponenten skaliert werden können. Mit zunehmender Erfahrung und Kenntnis kannst du nach und nach mehr Services extrahieren.
Navigation deiner Microservices mit Compass
Compass von Atlassian hilft dir, bei der Arbeit mit Microservices die Komplexität einer verteilten skalierbaren Architektur im Griff zu behalten. Die Lösung ist eine erweiterbare Developer-Experience-Plattform, die unzusammenhängende Informationen über die gesamten Entwicklungsergebnisse und die Teamzusammenarbeit an einem zentralen, durchsuchbaren Ort zusammenführt. Compass hilft dir nicht nur dabei, mit dem Komponentenkatalog die ungebremste Verbreitung von Microservices einzudämmen. Die Lösung kann dich auch dabei unterstützen, Best Practices zu erstellen und den Zustand deiner Software mit Scorecards zu messen. Sie gibt dir mithilfe von Erweiterungen, die in die Atlassian Forge-Plattform integriert sind, Daten und Einblicke in die gesamte DevOps-Toolkette an die Hand.
