DevOps meets Microservices - Eine Hand wäscht die andere!

Die meisten Computersysteme führen mehrere Aufgaben unter der Verwendung gemeinsam genutzter Ressourcen aus. Daher stellt sich die Frage, wie eng verschiedene Softwarekomponenten miteinander verknüpft sein sollen. Eine mögliche Antwort auf diese Fragen liegt in der Microservice-Architektur:

Hier interagieren viele kleine, diskrete Funktionsblöcke über Schnittstellen, um ein größeres System zu erstellen.

Obwohl die Grundidee solcher diskreten Komponenten nicht neu ist, macht die Art und Weise, wie Microservices implementiert werden, sie zu einer natürlichen Grundlage für beide modernen Cloud-basierten Anwendungen. Microservices passen auch zur DevOps-Philosophie, die die schnelle und kontinuierliche Einführung neuer Funktionen fördert.

Microservices-Architektur vs. monolithische Architektur

Microservices werden oft als „Microservices-Architektur“ bezeichnet. Dieser Begriff umfasst nicht nur die Microservices selbst, sondern auch Komponenten für Management und Service Discovery sowie ein API-Gateway, das die Kommunikation zwischen Microservices und der Außenwelt übernimmt.

Eine „monolithische Anwendung“ ist das Gegenteil: Es ist ein Retronym für eine Anwendung, bei der sich der gesamte Code in einer großen ausführbaren Binärdatei befindet. Eine monolithische Anwendung, schwieriger zu skalieren und schwieriger zu verbessern. Da es jedoch als einzelne zusammenhängende Anwendung erstellt wurde, erfordert es nicht so viel Verwaltung wie eine Microservices-Architektur.

Microservices-Kommunikation

Ein Schlagwort, das Sie oft über Microservices-Architekturen hören werden, ist, dass sie „intelligente Endpunkte und dumme Pipes“ aufweisen sollten. Mit anderen Worten:  Microservices sollten darauf abzielen, grundlegende und etablierte Kommunikationsmethoden zu verwenden, anstatt eine komplexe und enge Integration.

Im Allgemeinen sollte die Kommunikation zwischen Microservices asynchron sein, in dem Sinne, dass Code-Threads nicht blockiert werden und auf Antworten warten. (Es ist immer noch in Ordnung, synchrone Kommunikationsprotokolle wie HTTP zu verwenden, obwohl asynchrone Protokolle wie AMQP (Advanced Message Queuing Protocol) in Microservices-Architekturen ebenfalls üblich sind). Diese Art der losen Kopplung macht eine Microservices-Architektur angesichts des Ausfalls einzelner Komponenten um ein weites flexibler.

Microservices und Container: Docker, Kubernetes und mehr

Die zugrunde liegende Technologie, die am weitesten dazu beigetragen hat, Microservices in den Mainstream zu bringen, sind Container. Ein Container ähnelt einer VM-Instanz, aber anstatt ein vollständiges, in sich geschlossenes Betriebssystem zu enthalten, ist ein Container nur ein isolierter Benutzerbereich, der den Kernel des Host-Betriebssystems nutzt, aber ansonsten den darin ausgeführten Code in sich abgeschlossen hält. Container sind viel kleiner als VM-Instanzen und können einfach und schnell bereitgestellt werden, entweder lokal oder in der Cloud, und können hoch- oder heruntergefahren werden, um der Nachfrage und den verfügbaren Ressourcen gerecht zu werden.

Die Attraktivität von Containern für Microservices sollte offensichtlich sein: Jeder einzelne Microservice kann in einem eigenen Container ausgeführt werden, was den Aufwand für die Verwaltung von Diensten erheblich reduziert. Die meisten Containerimplementierungen verfügen über ergänzende Orchestrierungstools, die die Bereitstellung, Verwaltung, Skalierung, Vernetzung und Verfügbarkeit containerbasierter Anwendungen automatisieren. Es ist die Kombination aus kleinen, einfach zu erstellenden Microservices und einfach bereitzustellenden Containern, die die DevOps - Philosophie möglich macht. Es gibt mehrere Implementierungen des Containerkonzepts, aber die bei weitem beliebteste ist Docker, das im Allgemeinen mit Kubernetes als Orchestrierungsplattform gekoppelt wird.

Entwurfsmuster für Microservices

Unabhängig davon, welche Sprache Sie zum Entwickeln von Microservices verwenden, werden Sie mit Problemen konfrontiert, auf die andere Entwickler zuvor gestoßen sind. Entwurfsmuster sind formalisierte, abstrakte Lösungen für wiederkehrende Probleme in der Informatik, und einige davon sind speziell für Microservices. Devopedia hat eine großartige Liste, die Folgendes beinhaltet:

• Service Registry: zum Verbinden von Clients mit verfügbaren Instanzen von Mikrodiensten
• Circuit Breaker: um zu verhindern, dass ausgefallene Dienste wiederholt aufgerufen werden
• Fallback: zum Bereitstellen einer Alternative zu einem fehlgeschlagenen Dienst
• Sidecar: Zur Bereitstellung eines Hilfsdienstes für den Hauptcontainer, z. B. zum Protokollieren, Synchronisieren von Diensten oder Überwachen
• Adapter: um die Schnittstelle zwischen dem Hauptcontainer und der Außenwelt zu standardisieren oder zu normalisieren
• Ambassador: Um den Hauptcontainer mit der Außenwelt zu verbinden, z. B. um localhost-Verbindungen an externe Verbindungen weiterzuleiten

Warum Microservices so gut mit DevOps zusammenpassen

Die Microservices-Architektur ist mit ihrem Service-basierten Ansatz, maßgeschneidert für DevOps. Microservices ermöglichen es Teams, Ihre Anwendungen in kleine Dienste zu unterteilen. Jeder dieser Dienste kann unabhängig gewartet und weiterentwickelt werden. Durch gut dokumentierte Abhängigkeiten und API-Schnittstellen wird das unabhängige Testen der Services um ein Vielfaches vereinfacht.

Ein weiterer Aspekt ist die Zuordnung von Verantwortung. So können verschiedenen Teams die Verantwortung für das Betreiben und Entwickeln einzelner Microservices übernehmen.

• Bereitstellungsfähigkeit: Microservices bieten eine erhöhte Agilität, die die Fähigkeit fördert, neue Versionen eines Dienstes bereitzustellen. Diese Agilität ist auf kürzere Build-, Test- und Bereitstellungszyklen zurückzuführen. Microservices können auch die Flexibilität beinhalten, die erforderlich ist, um dienstspezifische Sicherheits-, Replikations-, Persistenz- und Überwachungskonfigurationen einzusetzen.
• Zuverlässigkeit: Ein Fehler bei einem Microservice wirkt sich nur auf diesen Microservice und seine Verbraucher aus. Wenn bei monolithischen Anwendungen ein Fehler auftritt, kann der gesamte Monolith ausfallen.
• Verfügbarkeit: Die Veröffentlichung einer neuen Version eines bestimmten Microservice erfordert nur sehr geringe Ausfallzeiten, während die Einführung einer neuen Version eines Service in der monolithischen Anwendung normalerweise einen vollständigen Neustart des gesamten Monolith erfordert.
• Skalierbarkeit: Microservices können mithilfe von Pools, Clustern und Grids unabhängig voneinander skaliert werden. Diese Bereitstellungseigenschaft macht Microservices zu einer großartigen Ergänzung für die Elastizität der Cloud.
• Modifizierbarkeit: Microservices bieten die Flexibilität, neue Frameworks, Bibliotheken, Datenquellen und andere Ressourcen zu nutzen. Als lose gekoppelte, modulare Komponenten erweisen sich Microservices, als einfacher zu handhaben und unterstützen die dynamische Erkennung und Bindung über eine Registrierung.
• Management: Microservices können die agile Methodik nutzen, bei der der Aufwand für die Anwendungsentwicklung auf kleinere Teams aufgeteilt wird, die unabhängiger arbeiten.