Was sind Microservices?

Gegensatz zu der loseren Verbindung der Elemente bei Microservices oder bei serviceorientierten Architekturen eng miteinander verbunden. Das Festhalten an diesem Ansatz führt zu folgenden Problemen:

• Eine stetig wachsende Codebasis lässt sich nur schwer verbessern und ändern. Das Refactoring der Codebasis stellt eine Herausforderung dar, da sich jede Änderung auf die gesamte Anwendung auswirken kann.
• Mehr Komplexität beim Testen und Umsetzen von Änderungen, da die gesamte monolithische Anwendung betroffen ist.
• Höheres Risiko: Wenn eine Komponente ausfällt, stürzt die komplette Anwendung ab.

Microservices bieten mehr Flexibilität als ein herkömmliches monolithisches System. Es gibt nicht den einen Weg zur Entwicklung von Microservices, aber es gibt allgemeine Richtlinien zur Verwaltung von Daten in Microservice-Architekturen. Wenn die Datenverwaltung so komplex ist, dass ein Entwicklungsteam Microservices in Betracht zieht, kann das viele Ursachen haben, wie z. B.:

• Das Arbeiten mit großen Teams
• Das Unterstützen vieler Benutzerinteraktionsmodelle
• Das unabhängige Entwickeln verschiedener Geschäftsbereiche
• Das Anbieten vieler verschiedener Web Services

Der größte Unterschied liegt jedoch in der Größe: Benutzer sind oft der Meinung, dass eine monolithische Anwendung zu groß ist, um verändert, eingesetzt und skaliert zu werden.

Die SOA eignet sich besser für Umgebungen mit großen und komplexen Geschäftsanwendungen, die in viele heterogene Anwendungen integriert werden müssen. Microservices sind jedoch besser für kleinere und gut strukturierte webbasierte Systeme geeignet, da sie den Entwicklern weitaus mehr Kontrolle bieten. Das Unterteilen von Anwendungen in kleine Einheiten ist keine neue Idee: Die serviceorientierte Architektur (SOA) ging den Microservices voran.

Gemäß dem SOA-Manifest:

• hat der Nutzen für das Unternehmen Vorrang vor technischen Strategien.
• sind strategische Ziele wichtiger als projektspezifische Vorteile.
• ist die intrinsische Interoperabilität wichtiger als die benutzerdefinierte Integration.
• sind Shared Services wichtiger als Implementierungen zu einem bestimmten Zweck.
• hat Flexibilität Vorrang vor Optimierung.
• hat Verfeinerung durch Weiterentwicklung Vorrang vor dem Streben nach sofortiger Perfektion.

Microservices sind Teil eines größeren Wandels in IT-Abteilungen in Richtung einer DevOps-Kultur, in der Entwicklungs- und Operations-Teams eng zusammenarbeiten, um eine Anwendung während ihres gesamten Lebenszyklus zu unterstützen. Unternehmen sollten die Implementierung von Microservices in Betracht ziehen, wenn eine SOA-Kultur bereits vorhanden ist.

Eine serviceorientierte Architektur ist im Grunde genommen eine Sammlung von Services, die miteinander kommunizieren. Die Kommunikation kann entweder die einfache Weitergabe von Daten beinhalten oder die Koordination einer Aktivität durch mindestens zwei Services.

Eine serviceorientierte Architektur ist eine effektive Strategie für flexible und sich schnell verändernde Entwicklungszyklen. Ein Hauptvorteil von Microservices besteht darin, dass Entwickler einen kontinuierlichen Bereitstellungszyklus nutzen können. Bevor Microservices eingeführt werden, muss ein Unternehmen zunächst die bereits vorhandene Technologie evaluieren. Dabei geht es nicht darum, welche Architektur die besseren Ergebnisse erzielt. Es ist vielmehr wichtig, den Zweck der zu erstellenden Anwendung zu evaluieren.

Ein Container ist ein Verfahren zur Bündelung, Bereitstellung und Ausführung eines Linux-Programms/-Prozesses. Ein Container kann eine riesige monolithische Anwendung sein. Andererseits können Sie auch eine Anwendung mit Microservices haben, die überhaupt keine Container verwendet.

Ein Container ist eine hilfreiche Ressourcenzuweisung, die für verschiedene Personen aus dem DevOps-Bereich besonders interessant ist. Ein Microservice ist ein Softwareentwurfsmuster, für das sich Entwickler begeistern können. Container und Microservices sind beide nützlich, aber sie sind nicht voneinander abhängig.

Zwei wichtige Herausforderungen des Microservice-Ansatzes sind die individuellen Arbeitsstile voneinander unabhängiger Teams und der Umstand, dass Sie nie den Eindruck haben, wirklich fertig zu sein. Während Microservices eine höhere Produktivität und eine bessere Tool-Auswahl ermöglichen, bevorzugen Teams oft unterschiedliche Programmiersprachen, Frameworks und Bibliotheken. Das kann Teams ausbremsen, wenn sie für eine solche Unabhängigkeit nicht bereit sind.

Zweitens liegt der Reiz monolithischer Architekturen darin, dass Änderungen zu einem großen Projekt werden, das einen eindeutigen Start- und Endzeitpunkt hat. Bei Microservices sind Änderungen an der Tagesordnung. Ständige Änderungen sind kein "Fehler", sondern ein Merkmal eines lebendigen, sich entwickelnden Systems. Teams, die an diese Art dauernder Veränderungen nicht gewöhnt sind, haben unter Umständen Anpassungsschwierigkeiten.

Eine dritte Herausforderung ist die Komplexität von Microservices, deren Monitoring einen strategischen Ansatz erfordert.

Ein Hauptgrund für den Wechsel zu Microservices liegt darin, dass man sich aufgrund des erhöhten Innovationstempos besser auf Business-Prioritäten konzentrieren kann. Das Aufkommen der DevOps-Kultur, bei dem ein ähnlicher Fokus auf Geschwindigkeit und Resultaten liegt, hat auch das Interesse an Microservices befeuert.

Viele Unternehmen haben von einer monolithischen Architektur auf eine Microservice-Struktur umgestellt. Dazu gehören beispielsweise Amazon, Spotify, Uber, Groupon und Karma. Mithilfe von Microservices stellen die Entwickler bei Netflix täglich Tausende von Codeabschnitten bereit, um mehr als 139 Millionen Abonnenten und 10 Milliarden Stunden an Filmen und Fernsehserien zu verwalten.

Die Vorteile von Microservices liegen z.B. im schnelleren Entwickeln und Einsetzen von Software, was Kosten spart und der Organisation einen Wettbewerbsvorteil verschaffen kann. Die Microservice-Architektur eignet sich perfekt für Entwickler, die nicht vorhersagen können, auf welcher Art Gerät die Anwendung am Ende ausgeführt wird. Entwickler können schnell und kontrolliert Upgrades bereitstellen, ohne dass die Anwendung dafür gestoppt werden muss. Zu den weiteren Vorteilen zählen folgende Aspekte:

• Stabilität. Funktionale Zerlegung bedeutet, dass jede Komponente der Anwendung unabhängig von anderen Komponenten hoch- und runterskaliert werden kann. Damit können Fehler isoliert werden, sodass der Ausfall einer einzigen Komponente nicht die komplette Anwendung zum Abstürzen bringt.
• Keine Anbieter- oder Technologiebindung. Sie können potenziell für verschiedene Microservices unterschiedliche Technologie-Stacks auswählen.
• Leichter zu erstellen und zu verwalten. Dass ihr Design einem bestimmten Zweck dient, bedeutet, dass die Komponenten von kleineren Teams erstellt und verwaltet werden können. Jedes Team kann mehrere Funktionen haben. Jeder Microservice kann individuell eingesetzt werden.
• Qualitativ hochwertigerer Code. Durch die Modularisierung einer Gesamtlösung in einzelne Komponenten können sich Anwendungsentwicklungsteams jeweils nur auf einen kleinen Teil konzentrieren. Das vereinfacht den Codierungs- und Testprozess insgesamt.
• Einfachere teamübergreifende Koordination. Anders als herkömmliche serviceorientierte Architekturen (SOAs), bei denen in der Regel schwergewichtige prozessinterne Kommunikationsprotokolle eine Rolle spielen, arbeiten Microservices mit Event-Streaming-Technologien, die eine leichtere Integration ermöglichen.
• Echtzeitverarbeitung. Der Kern einer Microservice-Architektur ist ein Publish-/Subscribe-Framework, das Datenverarbeitung in Echtzeit ermöglicht und unverzüglich Ergebnisse und Erkenntnisse liefert.
• Schnelle Projektentwicklung. Microservices arbeiten unabhängig, sodass Sie zum Ändern der Features nicht die Codebasis ändern müssen. Sie können eine Komponente einzeln ändern, testen und einsetzen. Auf diese Weise können Sie die Anwendung schneller bereitstellen.
• Sie sind skalierbarer. Skalierbarkeit ist mehr als nur die Möglichkeit, ein größeres Volumen zu verarbeiten. Es geht dabei auch um den erforderlichen Aufwand. Mit Microservices lassen sich Skalierungsengpässe leichter identifizieren und für jeden Microservice einzeln beheben.

Das Monitoring ist ein wichtiger Bestandteil einer Microservice-Architektur. Das Aufsplitten von Anwendungen in einzelne Microservices bringt zwar viele Vorteile, erhöht aber auch die Komplexität. Microservices müssen miteinander kommunizieren, und jede einzeln erstellte und aktualisierte Komponente muss mit einem Minimum an Latenz mit anderen Komponenten zusammenarbeiten. Wenn Sie also eine aus Microservices bestehende Anwendung verwalten, dann verwalten Sie ein Netz von Komponenten, die miteinander in Beziehung stehen. Ein effektives Management dieses Netzes ist für die Zuverlässigkeit insgesamt unerlässlich.

Wer als Entwickler bereits ein DevOps-Mindset mitbringt, dem fallen die Aspekte Monitoring und Observability leicht. Wie im Bereich DevOps setzen Microservices auf Automatisierung und Zusammenarbeit über alle Facetten des Softwareentwicklungszyklus (SDLC) hinweg. Konfigurationsmanagement, CI/CD-Server, APM, Netzwerk-Monitoring, Dashboards, Benachrichtigungsautomatisierung und Incident Management sind die Grundlagen für Teams, die Microservices betreiben.

Zwei unerlässliche Komponenten des Monitorings von Microservices bestehen im Basic-Monitoring und in der schnellen Anwendungsbereitstellung.

• Basic-Monitoring: Es ist von entscheidender Bedeutung, Probleme, die in der Testphase nicht festgestellt wurden, schnell erkennen zu können. Dabei geht es in erster Linie darum, technische Probleme zu identifizieren (Zählfehler, Serviceverfügbarkeit etc.), aber auch das Monitoring geschäftlicher Probleme lohnt sich (wie z.B. das Erkennen eines Auftragsrückgangs). Wenn plötzlich ein Problem auftritt, können Sie individuelle Services und Betriebssysteme schnell zurücksetzen.
• Schnelle Anwendungsbereitstellung: Bei so vielen Services, die verwaltet werden müssen, müssen Administratoren in der Lage sein, sie schnell und meist in nur wenigen Stunden bereitzustellen – sowohl in Testumgebungen als auch in der Produktionsumgebung. Es ist im frühen Stadium vielleicht in Ordnung, manuell eingreifen zu müssen, aber schon bald werden Sie um eine Automatisierung nicht herumkommen.

Diese Funktionen bringen einen bedeutenden organisatorischen Wandel wie in der DevOps-Kultur mit sich – die enge Zusammenarbeit zwischen Entwicklern und Operations-Teams. Diese Zusammenarbeit ist erforderlich, um sicherzustellen, dass die Bereitstellung und die Verteilung schnell erfolgen können. Außerdem ist es wichtig, dafür zu sorgen, dass Sie schnell reagieren können, wenn sich beim Monitoring ein Problem zeigt.

Mit verteilten Systemen können verschiedene Teams gemeinsam an einer Observability-Kultur arbeiten – wie etwa an einer besseren Orchestrierung, einem besseren Lastenausgleich und einer besseren Fehlerisolation.

Natürlich ist das Monitoring die vorwärts gerichtete Reaktion auf die Aufrechterhaltung einer Microservice-Architektur. Wenn eine Anomalie festgestellt wird, müssen Sie auch reagieren. Es ist wichtig, dass Sie über einen Alarmprozess und einen Incident Response-Plan verfügen, der es Ihnen ermöglicht, prompt und effektiv zu reagieren.

Die Microservice-Architektur ist noch relativ neu, aber sie wird im Laufe der Zeit immer populärer werden. Mithilfe von Microservices können Teams unabhängig von der Skalierung von Produkten und Anwendungen wachsen. Ganz gleich, wie Sie Microservices implementieren – eines der Hauptziele sollte dabei eine schnellere Markteinführung sein. Das allein macht den Wechsel für viele Teams zur richtigen Entscheidung.