Rückblickend auf die Vergangenheit vor rund fünf Jahren zeigt sich, wie sehr sich die Einstellung zur Architektur von Microservices seitdem verändert hat. Anfangs waren sie sehr beliebt. Nach dem Erfolg von Netflix, Amazon und Gilt.com stellten die Entwickler fest, dass sich die tatsächliche Entwicklung von Mikrodiensten nicht von der Anwendungsentwicklung unterscheidet. Jetzt haben alle verstanden, dass Microservices ein neuer architektonischer Stil sind, der zur Lösung bestimmter Probleme effektiv ist und Vor- und Nachteile hat.
Um zu verstehen, was Microservices sind und in welchen Fällen sie verwendet werden sollten, wandten wir uns an Jaime Buelta, Autor von Hands-On Docker für Microservices mit Python. Er sprach über die Vorteile dieser Architektur und gab Empfehlungen für Entwickler, die von Monolithen auf diese Architektur umsteigen möchten.
Nutzen und Risiken
Eine traditionelle monolithische Anwendung vereint alle Funktionen in einem einzigen verbundenen Modul. Bei Microservices ist das Gegenteil der Fall. Die Anwendung ist in kleinere eigenständige Dienste unterteilt, die unabhängig voneinander bereitgestellt, aktualisiert und ersetzt werden können. Jeder Mikrodienst wird für einen Geschäftszweck erstellt und kann mithilfe einfacher Mechanismen mit anderen Mikrodiensten interagieren.
Buelta erklärt: „Die Microservice-Architektur ist eine Möglichkeit, ein System zu strukturieren, in dem mehrere unabhängige Dienste auf eine bestimmte Weise miteinander kommunizieren (in der Regel erfolgt dies mithilfe von RESTful-Webdiensten). Ein wichtiges Merkmal ist, dass jeder Mikrodienst unabhängig von den anderen aktualisiert und bereitgestellt werden kann. “
Die Microservice-Architektur definiert nicht nur, wie Sie Ihre Anwendung erstellen, sondern auch, wie Ihr Team organisiert ist.
„Ein unabhängiges Team kann vollständig für den Mikroservice verantwortlich sein. Auf diese Weise können Unternehmen wachsen, ohne die Entwickler zusammenzubringen “, erklärt Buelt.
Einer der Hauptvorteile von Microservices ist, dass Sie damit Innovationen einführen können, ohne dass dies besondere Auswirkungen auf das Gesamtsystem hat. Mithilfe von Microservices können Sie eine horizontale Skalierung durchführen, klare Modulgrenzen festlegen, eine Vielzahl von Technologien verwenden und parallele Entwicklungen durchführen.
Auf die Frage nach den mit Microservices verbundenen Risiken antwortete Buelta: „Die Hauptschwierigkeit bei der Implementierung der Architektur (insbesondere beim Übergang von einem Monolithen) besteht darin, ein Design zu erstellen, bei dem die Services wirklich unabhängig sind. Wenn dies nicht erreicht werden kann, wird die dienstübergreifende Kommunikation schwieriger, was zu zusätzlichen Kosten führt. Microservices brauchen Profis, die langfristig die Entwicklungsrichtung bestimmen. Ich empfehle Organisationen, die zu einer solchen Architektur wechseln möchten, um jemanden zu bestimmen, der für das Gesamtbild verantwortlich ist. Wir müssen uns Mikrodienstleistungen genauer ansehen “, sagte Jaime.
Übergang vom Monolithen zum Mikrodienst
Martin Fowler, ein bekannter Autor und Softwareberater, rät dazu, das Prinzip „first is monolith“ zu befolgen. Dies liegt daran, dass die Verwendung einer Microservice-Architektur von Anfang an riskant ist, da sie in den meisten Fällen nur für komplexe Systeme und große Entwicklungsteams geeignet ist.
„Das Hauptkriterium, das Sie ermutigen sollte, auf eine neue Architektur umzusteigen, ist die Größe Ihres Teams. Kleine Gruppen sollten dies nicht tun. Unter solchen Bedingungen verstehen Entwickler bereits alles, was mit der Anwendung geschieht, und können einem Kollegen jederzeit eine klärende Frage stellen. Der Monolith funktioniert in diesen Situationen perfekt, und daher fängt fast jedes System damit an “, sagte Jaime. Dies bestätigt die "Zwei-Pizza-Regel" von Amazon, wonach das für einen Microservice zuständige Team mit zwei Pizzen gefüttert werden kann - sonst ist es zu groß.
„Wenn das Unternehmen wächst und die Entwicklungsteams wachsen, ist möglicherweise eine bessere Koordination erforderlich. Programmierer beginnen oft, sich gegenseitig zu stören. Das Verständnis des Zwecks eines bestimmten Codeteils wird immer schwieriger. In solchen Fällen ist der Übergang zu Microservices sinnvoll - dies wird dazu beitragen, die Zuständigkeiten zu teilen und das Gesamtbild des Systems zu verdeutlichen. Jedes Team kann seine eigenen Ziele festlegen und hauptsächlich unabhängig arbeiten, wobei eine klare externe Schnittstelle zur Verfügung steht. Damit ein solcher Übergang Sinn macht, muss es jedoch viele Entwickler geben “, fügt Buelt hinzu.
Empfehlungen für die Migration zu Microservices
Buelta beantwortete die Frage, welche praktischen Empfehlungen Entwickler beim Wechsel zu Microservices verwenden können: "Der Schlüssel zu einer erfolgreichen Microservice-Architektur ist, dass jeder Service so unabhängig wie möglich ist."
Es stellt sich die Frage: "Wie können Sie die Dienste unabhängig machen?" Der beste Weg, um die gegenseitige Abhängigkeit eines Systems zu erkennen, besteht darin, über neue Möglichkeiten nachzudenken: „Wenn Sie eine neue Funktion hinzufügen möchten, können Sie diese implementieren, indem Sie nur einen Dienst ändern? Welche Arten von Funktionen erfordern die Koordination mehrerer Mikrodienste? Werden sie oft oder selten verwendet? Es ist unmöglich, das perfekte Design zu erstellen, aber zumindest können Sie damit die richtigen und fundierten Entscheidungen treffen “, erklärt Buelt.
Jaime rät zur korrekten Umstellung auf Architektur, damit Sie später nicht alles wiederholen müssen. „Sobald der Übergang abgeschlossen ist, wird es schwieriger, die Grenzen von Microservices zu ändern. Es lohnt sich, mehr Zeit in die Anfangsphase des Projekts zu investieren “, fügt er hinzu.
Der Übergang von einem Entwurfsmuster zu einem anderen ist ein schwerwiegender Schritt. Wir fragten, auf welche Probleme Jaime und sein Team während der Migration zu Microservices stießen, worauf er antwortete:
„Tatsächlich hängen die Hauptschwierigkeiten mit den Menschen zusammen. Diese Probleme werden normalerweise unterschätzt, aber der Wechsel zu Microservices verändert die Arbeitsweise der Entwickler. Die Aufgabe ist nicht einfach! “ Er fügt hinzu: „Ich persönlich bin auf ähnliche Probleme gestoßen. Zum Beispiel musste ich Entwickler schulen und beraten. Es ist besonders wichtig zu erklären, warum bestimmte Änderungen notwendig sind. Dies hilft den Menschen, die Gründe für die Einführung all der Innovationen zu verstehen, die sie möglicherweise nicht mögen.
Beim Übergang von einer monolithischen Architektur können beim Bereitstellen einer Anwendung, die zuvor als einzelnes Modul veröffentlicht wurde, viele Schwierigkeiten auftreten. Eine gründlichere Analyse ist erforderlich, um die Abwärtskompatibilität sicherzustellen und Risiken zu minimieren. Diese Aufgabe zu bewältigen ist manchmal sehr schwierig. "
Gründe, Docker, Kubernetes und Python als Ihren Technologie-Stack zu wählen
Wir haben Buelt gefragt, welche Technologie er für die Implementierung von Microservices bevorzugt. In Bezug auf die Wahl der Sprache war die Antwort einfach: „Python ist die beste Option für mich. Dies ist meine Lieblingsprogrammiersprache! .. Diese Sprache ist gut für Microservices geeignet. Es ist bequem zu lesen und einfach zu bedienen. Darüber hinaus verfügt Python über umfangreiche Funktionen für die Webentwicklung und ein dynamisches Ökosystem von Modulen von Drittanbietern für alle Anforderungen. Diese Anforderungen umfassen die Verbindung zu anderen Systemen wie Datenbanken, externen APIs usw. “
Docker wird oft als eines der wichtigsten Werkzeuge für Microservices angepriesen. Buelta erklärte, warum:
„Mit Docker können Sie die Anwendung in praktischen standardisierten Paketen kapseln und kopieren. Dies verringert die Unsicherheit und Komplexität der Umgebung. Dies vereinfacht auch den Übergang von der Entwicklung zur Anwendungsproduktion erheblich. Darüber hinaus wird der Zeitaufwand für die Verwendung der Geräte reduziert. Sie können mehrere Container in unterschiedlichen Umgebungen (auch auf unterschiedlichen Betriebssystemen) in einer physischen Box oder virtuellen Maschine platzieren. “
Über Kubernetes:
„Mit Kubernetes können Sie mehrere Docker-Container auf koordinierte Weise bereitstellen. Dies lässt Entwickler in einem Cluster denken und sich an die Produktionsumgebung erinnern. Außerdem können Sie einen Cluster mithilfe von Code definieren, sodass neue Bereitstellungen oder Konfigurationsänderungen in Dateien definiert werden. All dies ermöglicht Methoden wie GitOps (über die ich in meinem Buch geschrieben habe), während die vollständige Konfiguration im Versionskontrollsystem beibehalten wird. Jede Änderung wird auf spezifische und umkehrbare Weise vorgenommen, da es sich um eine regelmäßige Git-Zusammenführung handelt. Dank dessen ist es sehr einfach, die Infrastruktur wiederherzustellen oder zu duplizieren. “
„Man muss Zeit damit verbringen, Docker und Kubernetes zu lernen, aber es lohnt sich. Beide Tools sind sehr leistungsfähig. Außerdem ermutigen sie Sie, so zu arbeiten, dass Probleme während der Produktion vermieden werden “, sagt Buelt.
Mehrsprachige Microservices
Bei der Entwicklung von Microservices können Sie eine Vielzahl von Technologien einsetzen, für die im Idealfall jeweils ein unabhängiges Team zuständig ist. Buelta teilte seine Meinung zu mehrsprachigen Microservices mit: „Mehrsprachige Microservices sind großartig! Dies ist einer der Hauptvorteile der Architektur. Ein typisches Beispiel für einen mehrsprachigen Mikrodienst ist die Übertragung von in einer Sprache verfasstem Legacy-Code in eine neue Sprache. Ein Microservice kann jeden anderen ersetzen, der dieselbe externe Schnittstelle bietet. Sein Code wird jedoch völlig anders sein. Ich habe zum Beispiel von alten PHP-Anwendungen gewechselt und sie durch in Python geschriebene Analoga ersetzt. " Jaime fügte hinzu: "Wenn Sie mit zwei oder mehr Plattformen gleichzeitig arbeiten, können Sie diese besser verstehen und verstehen, in welchen Fällen es besser ist, sie zu verwenden."
Die Möglichkeit, mehrsprachige Microservices zu verwenden, ist ein großer architektonischer Vorteil, kann aber auch die Transaktionskosten erhöhen. Buelta rät: „Wir müssen die Maßnahme kennen. Es macht keinen Sinn, jedes Mal ein neues Tool zu verwenden und dem Team die Möglichkeit zu nehmen, Wissen miteinander zu teilen. Bestimmte Zahlen können von der Größe des Unternehmens abhängen, aber in der Regel ist es nicht sinnvoll, ohne guten Grund mehr als zwei oder drei verschiedene Sprachen zu verwenden. Sie müssen den Technologie-Stack nicht aufblasen - dann können die Entwickler ihr Wissen teilen und die verfügbaren Tools am effektivsten nutzen.
Über den Autor
Jaime Buelta ist ein professioneller Programmierer und Python-Entwickler, der im Laufe seiner Karriere auf viele verschiedene Technologien gestoßen ist. Er hat Software für verschiedene Bereiche und Branchen entwickelt, darunter Luft- und Raumfahrt, Netzwerk und Kommunikation sowie industrielle SCADA-Systeme, Online-Videospieldienste und Finanzdienstleistungen.
Als Teil verschiedener Unternehmen beschäftigte er sich mit Funktionsbereichen wie Marketing, Management, Vertrieb und Spieledesign. Jaime ist ein begeisterter Befürworter der Automatisierung und möchte, dass Computer die ganze harte Arbeit erledigen, damit sich die Leute auf wichtigere Dinge konzentrieren können. Derzeit lebt er in Dublin und spricht regelmäßig auf PyCon-Konferenzen in Irland.