Was ist eine Microservice-Architektur? Microservices erklärt

Microservice-Architekturen, auch Microservices genannt, sind eine spezielle Methode, um Softwaresysteme zu entwerfen, um eine einzelne Anwendung als eine Sammlung locker gekoppelter Services zu strukturieren. Anwendungen beginnen tendenziell als monolithische Architektur (dazu weiter unten) und wachsen im Laufe der Zeit zu einer Reihe miteinander verbundener Microservices heran. Die Hauptidee hinter Microservices ist, dass einige Anwendungstypen leichter zu bauen und zu warten sind, wenn sie in viele kleine Teile zerlegt werden, die zusammenarbeiten. Obwohl die Architektur komplexer geworden ist, bieten Microservices immer noch viele Vorteile gegenüber der monolithischen Struktur. Das Konzept der Mikrotechnologie stammt von der bestehenden monolithischen Infrastruktur, die die meisten Unternehmen genutzt haben, insbesondere wenn das Unternehmen seit einem Jahrzehnt oder länger existiert. Anstelle einer monolithischen Architektur hat jede Komponente einer Microservice-Architektur:

• Seine eigene CPU
• Seine eigene Laufzeitumgebung
• Oft arbeitet ein engagiertes Team daran, um sicherzustellen, dass jeder Service voneinander unterscheidet ist

Diese Architektur bedeutet, dass jeder Dienst:

• Einen eigenen, einzigartigen Prozess ausführen
• Kommunizieren Sie autonom, ohne auf die anderen Microservices oder die gesamte Anwendung angewiesen zu sein

Diese Fähigkeit, getrennt und neu zusammenzuführen, schützt das gesamte System vor Verfall und erleichtert agile Prozesse besser, was es für Organisationen attraktiv macht – insbesondere für solche, die noch monolithische Infrastrukturen nutzen. Dieser Artikel behandelt:

• Wie Microservices funktionieren
• Beispiele
• Monolithische vs. Mikroservice-Architekturen
• Vor- und Nachteile von Microservices
• Hilfreiche Ressourcen

Wie Microservices funktionieren

Microservices sind eine Reihe von Diensten, die zusammenarbeiten, um eine ganze Anwendung zum Laufen zu bringen. Diese Architektur nutzt APIs, um Informationen wie Benutzeranfragen oder einen Datenstrom von einem Dienst zum anderen weiterzugeben. Wie die zugrunde liegende Software funktioniert oder auf welcher Hardware der Dienst aufgebaut ist, hängt ausschließlich vom Team ab, das den Dienst entwickelt hat. Dies macht sowohl die Kommunikation zwischen Teams als auch das Aktualisieren von Diensten sehr dynamisch – ja sogar reaktiv – und ermöglicht es einem Softwareunternehmen oder Team, in seiner Entwicklung widerstandsfähiger zu sein. Kubernetes hat dazu beigetragen, die Sache der Microservices voranzubringen, ist aber kein notwendiger Baustein. Der Aufstieg von Cloud Computing und vernetzten Computern hat zwei Dinge bewirkt:

• Der Nutzer hat die Verantwortung genommen, einen leistungsstarken Computer für alle notwendigen Operationen auszuführen.
• Es liegt der Verantwortung beim Unternehmen, bei jedem Nutzer, wenn ein Nutzer die Anwendung ausführt, einzelne Server zu nutzen.

Im Fall von Microservices kann die Maschine des Nutzers für die grundlegende Verarbeitung verantwortlich sein, aber sie ist hauptsächlich für das Senden und Empfangen von Netzwerkanrufen an andere Computer zuständig. Wann immer Sie eine Anwendung verwenden, ist es vernünftig anzunehmen, dass es etwa fünf weitere Computer gibt, mehr oder weniger, die einfach eingeschaltet sind, um Ihr Erlebnis zu ermöglichen. Im Fall von etwas wie Facebook oder Uber ist es vielleicht vernünftiger, zu erwarten, dass weitere 10.000 Computer aktiv Informationen verarbeiten, um das Nutzererlebnis zu verbessern. Microservices werden oft als logische Weiterentwicklung der Service Oriented Architecture (SOA) betrachtet, aber es gibt klare Unterschiede zwischen beiden.

Beispiele für Microservices-Architekturen

Wie Martin Fowler hervorhebt, nutzen viele große Unternehmen mittlerweile Microservices in ihrer Architektur. Netflix ist einer der früheren und bekanntesten Anwender. Weitere bekannte Beispiele sind:

• eBay
• Amazon
• Twitter
• PayPal
• SoundCloud
• Gilt
• Der Wächter

  In jedem dieser Unternehmen gibt es ein Netzwerk von Microservices. Zum Beispiel könnte SoundCloud einen neuen Nutzer-Microservice haben, der einen Nutzer in seine Anwendung einführt. Der Microservice aktiviert das Konto des Benutzers im Backend und ist möglicherweise dafür verantwortlich, eine Willkommens-E-Mail an den Nutzer zu senden sowie eine Walkthrough zu zeigen, wenn der Nutzer sich erstmals in die Anwendung einloggt. Ein weiterer Microservice für Soundcloud könnte das Hochladen und Speichern eines Songs auf der Plattform sein. Ein weiterer Aspekt ist die Suchfunktion und empfohlene Künstler. Da ein Unternehmen in Abteilungen unterteilt ist, mit unterschiedlichen Aufgaben, wie ein Vertriebsagent, ein Finanzier und ein Bankangestellter, die alle Ansprechpartner bei derselben Bank sind, teilen die Microservices eines Unternehmens die Verantwortung des gesamten Unternehmens in einzelne Maßnahmen auf. Der Unterschied zwischen diesem Microservice-Design und einem Monolithen besteht darin, dass Soundcloud keine einzige Anwendung für jeden dieser Teile hat, die im Frühjahr eines Jahres veröffentlicht und beispielsweise auf einer CD-ROM verteilt wird. Stattdessen gilt jeder Teil (Microservice):

• Arbeitet autonom, um zum Ganzen beizutragen
• Kann auf moderne Weise der kontinuierlichen Entwicklung und Integration (CI/CD) aufgerüstet werden.

(Entdecken Sie Best Practices für Microservices , die Ihnen helfen, erfolgreich in Betrieb zu bleiben.)

Monolithische Architektur vs. Mikroservice-Architektur

Das monolithische Architekturmuster war der Architekturstil, der in der Vergangenheit verwendet wurde, also vor Kubernetes und Cloud-Services. In einer monolithischen Architektur ist die Software eine einzige Anwendung, die auf einer CD-ROM verteilt wird und einmal jährlich mit den neuesten Updates veröffentlicht wird. Beispiele sind Photoshop CS6 oder Microsoft 2008.

Dieser Stil war die Standardmethode, Software zu entwickeln. Doch mit der technologischen Entwicklung muss sich auch der Architekturstil weiterentwickeln. In einem Zeitalter von Kubernetes und CI/CD-Workflows stößt die monolithische Architektur auf viele Einschränkungen – Unternehmen müssen auf Microservices umsteigen. Merkmale einer monolithischen Architektur:

• Veränderungen sind langsam
• Veränderungen sind kostspielig
• Es ist schwer, sich an eine bestimmte oder sich verändernde Produktlinie anzupassen

Monolithische Strukturen machen Änderungen an der Anwendung extrem langsam. Die Änderung nur eines kleinen Codeabschnitts kann eine komplett neu aufgebaute und bereitgestellte Softwareversion erfordern. (Erfahren Sie mehr über die Komplexität der App-Modernisierung und Code-Refaktorisierung.) Wenn Entwickler bestimmte Funktionen einer Anwendung skalieren möchten, müssen sie die gesamte Anwendung skalieren, was Änderungen und Aktualisierungen zusätzlich erschwert. Microservices helfen, diese Herausforderungen zu lösen.

Vorteile von Microservices

Anwendungen, die als Satz unabhängiger, modularer Komponenten gebaut sind, sind leichter zu testen, zu warten und zu verstehen. Sie ermöglichen es Organisationen:

• Erhöhung der Agilität
• Workflows verbessern
• Verkürze die Zeit, die zur Verbesserung der Produktion benötigt wird

Während jede unabhängige Komponente die Komplexität erhöht, kann die Komponente auch zusätzliche Überwachungsfunktionen haben, um dem entgegenzuwirken. Hier sind die häufigsten Vorteile von Microservices und erklären, warum so viele Unternehmen sie bereits nutzen.

Unabhängigkeit der Entwickler

Jeder Microservice wird oft einem einzigen Entwicklerteam zugewiesen, das ihn betreut. Dadurch gibt es größere Entwicklerfreiheit und Unabhängigkeit. Kleine Teams, die parallel arbeiten, können schneller iterieren als größere Teams. Wenn ein einzelner Service an Popularität gewinnt, kann das kleinere Team die Services auch selbst skalieren, ohne auf ein größeres und komplexeres Team warten zu müssen.

Isolation & Resilienz

Wenn eine der Komponenten aufgrund von Problemen wie veralteter Technologie oder der Unfähigkeit, den Code weiterzuentwickeln, ausfällt, können Entwickler eine weitere Komponente starten, während der Rest der Anwendung unabhängig weiterarbeitet. Diese Fähigkeit gibt Entwicklern die Freiheit, Dienste nach Bedarf zu entwickeln und bereitzustellen, ohne auf Entscheidungen bezüglich der gesamten Anwendung warten zu müssen.

Skalierbarkeit

Da Microservices aus deutlich kleineren Komponenten bestehen, benötigen sie weniger Ressourcen und können daher leichter skalieren, um der steigenden Nachfrage nach genau dieser Komponente gerecht zu werden. Durch ihre Isolation können Microservices auch bei großen Größen- und Volumenänderungen ordnungsgemäß funktionieren, was sie ideal für Unternehmen mit einer Vielzahl von Plattformen und Geräten macht.

Autonom entwickelt

Im Gegensatz zu Monolithen lassen sich einzelne Komponenten viel leichter in kontinuierliche Bereitstellungspipelines und komplexe Bereitstellungsszenarien integrieren. Nur der gezielte Dienst muss modifiziert und neu bereitgestellt werden, wenn eine Änderung erforderlich ist. Wenn ein Dienst fehlschlägt, funktionieren die anderen weiterhin unabhängig. Seine autonome Natur kommt Teams zugute, weil er:

• Ermöglicht Skalierung und Entwicklung
• Erfordert nicht viel Koordination mit anderen Teams

Microservices sind ein besonderer Vorteil, wenn Unternehmen stärker verteilt werden und die Mitarbeiter mehr remote sind.

Beziehung zum Unternehmen

Microservice-Architekturen sind entlang der Geschäftsdomänengrenzen aufgeteilt und nach Fähigkeiten wie Logistik, Abrechnung usw. organisiert. Dies erhöht die Unabhängigkeit und das Verständnis in der gesamten Organisation: Verschiedene Teams können ein bestimmtes Produkt nutzen und es dann für die gesamte Lebensdauer besitzen und warten.

Evolutionär

Jede Microservice-Architektur ist hochgradig evolutionär. Microservices sind eine ausgezeichnete Option für Situationen, in denen Entwickler nicht vollständig vorhersagen können, auf welche Geräte die Anwendung in Zukunft Zugriff haben wird. Sie ermöglichen auch schnelle und kontrollierte Änderungen an der Software, ohne die gesamte Anwendung zu verlangsamen – so kann man iterativer Funktionen und neue Produkte entwickeln.

Nachteile von Microservices

Natürlich bringt die Microservice-Architektur eine Lernkurve mit sich. Erstnutzer könnten Schwierigkeiten haben, Folgendes zu bestimmen:

• Die Größe jedes Microservices
• Optimale Grenzen und Verbindungspunkte zwischen Mikroservices
• Der richtige Rahmen zur Integration von Dienstleistungen

Allgemein haben Microservices folgende Nachteile:

• Erhöhte Komplexität
• Teurer
• Größere Sicherheitsrisiken

Erhöhte Komplexität

In erster Linie sind Microservices ein viel komplexeres System. Es hat eine Lernkurve, die steil zu erklimmen sein kann, aber sobald man es gelernt hat, lässt es sich wie bei den meisten Dingen problemlos nutzen. Neue Lösungen sind nicht immer besser, und das ist die Schuld vieler Berater und junger Ingenieure, die versuchen, verschiedene Probleme mit denselben Lösungen zu lösen. Die Microservice-Architektur ist nicht immer die beste Lösung für eine Anwendung. Für manche ist sie vielleicht zu komplex, als nötig ist.

Teurer

Microservices können auch teurer sein. Sie laufen meist in ihren eigenen Umgebungen mit eigenen CPUs. Sie arbeiten über API-Aufrufe , die einen Preis haben. Und schließlich erfordert die Komplexität der Umgebung ein Team von Ingenieuren, die sie bauen können, sodass die Arbeitskosten höher sind.

Größere Sicherheitsrisiken

Schließlich bieten Microservices, da sie durch verschiedene Umgebungen auf unterschiedlichen laufenden Rechnern mit unterschiedlichen API-Aufrufen existieren, mehr Kontaktpunkte, damit ein Angreifer eindringen und das System beschädigen kann.

Microservices unterstützen DevOps

Letztlich sind Microservices Teil des umfassenden Wandels zu DevOps , auf den viele Organisationen hinarbeiten. DevOps-Umgebungen fördern starke Kooperationen zwischen Entwicklungs- und Betriebsteams, um IT agiler zu machen – also ist auch das Geschäft agil. Microservices sind lediglich eine Technologie, die genutzt werden sollte. Stattdessen sind sie Teil eines größeren Konzepts, dass Organisationen Kultur, Wissen und Strukturen für Entwicklungsteams übernehmen müssen, um Geschäftsziele zu unterstützen.

Verwandte Literatur

• BMC DevOps Blog
• Microservices vs. Miniservices: Die Wahl des richtigen Frameworks
• Microservices vs. Serverless: Was ist der Unterschied?
• Kubernetes Guide, eine Reihe von Artikeln und Tutorials
• Kubernetes vs. Docker Swarm: Vergleich von Container-Orchestrierungstools
• DevOps-Engineer-Rollen und -Verantwortlichkeiten

Diese Beiträge sind meine eigenen und spiegeln nicht unbedingt die Position, Strategien oder Meinung von BMC wider.