Stellen wir uns vor, wir haben einen riesigen Kunststoffblock mit einer homogenen Struktur. Daneben befindet sich ein Block von gleicher Größe und Form, der jedoch aus mehreren kleineren Blöcken besteht.
In welchem der Blöcke wird es für uns einfacher sein, Änderungen vorzunehmen? So können wir einen Monolithen und Microservices beschreiben.
Veränderung der Unternehmensgröße und Microservices
Microservices sind unter anderem die Antwort auf das Problem, mit dem Unternehmenswachstum Schritt zu halten, wenn die bestehende IT/Software Architektur nicht mehr ausreicht. Die Skalierung einer solchen Architektur ist jedoch nicht einfach - es handelt sich um einen komplizierten Prozess, bei dem wir die Datenmenge, die Anzahl der Interaktionen und die Funktionalitäten ändern müssen.
Dies gilt umso mehr, als die Daten, die wir sammeln und verarbeiten, riesig sind und ständig zunehmen. Seit einiger Zeit kursiert der Begriff der "Informationsdiät", ein etwas dummes Konzept, das sich auf die Flucht vor großen Informationsmengen bezieht. Aber wenn Sie ein Unternehmen führen, sind alle Daten (Informationen) wertvoll.
Nehmen wir das Beispiel eines Bestellregisters eines Online Shops. Auch wenn es nach einiger Zeit an Bedeutung verliert, ist die Speicherung aus Sicht der Unternehmensführung wichtig: Das Register kann sich als nützlich erweisen, um spätere Analysen durchzuführen, die zur Verbesserung des Absatzes beitragen.
Die einfache Lösung wäre, die veraltete Auftragssammlung an einen anderen Ort zu verlegen. Bei der Verwendung eines Monolithen ist dies jedoch nicht einfach. Da es sich bei einem Monolithen um eine homogene Struktur handelt, die Integritätseinschränkungen unterliegt, ist es schwierig, Änderungen vorzunehmen und einen separaten Teil einer Anwendung zu testen oder zu skalieren.
Die Lösung ist, den Monolithen in Teile aufzuspalten, d.h. Microservices zu erstellen (oder die Service orientierten Architektur zu verwenden, aber das ist ein anderes Thema), aber das bedeutet, das gesamte Architekturmuster zu ändern, was natürlich hohe Kosten und Risiken mit sich bringt.
Microservice Architektur
Die Probleme beginnen, wenn ein Unternehmen neue Produkte oder Diensten (Services) innerhalb eines Monolithen entwickelt - oder neue Funktionen oder Änderungen an bestehenden Diensten (Services) hinzufügt.
Die Arbeit mit dem Code erweist sich als zeitaufwändig. Daher erscheint es sinnvoller, die Anwendung in kleinere Elemente zu unterteilen, anstatt einen Monolithen zu schaffen.
Dazu weisen wir jedem Team die Arbeit an einem bestimmten, relativ kleinen Teil der Anwendung zu. Es ist, als würde man ein riesiges Bauwerk aus Lego erschaffen, bei dem Kinder oder Erwachsene in kleinen Gruppen jedes Element einzeln vorbereiten.
Wir Auditieren. Wir Forschen. Wir Gestalten.
Was sind Microservices?
Ein Microservice ist eine kleine Anwendung, die nur eine Aufgabe gut erfüllt. Es handelt sich um eine kleine Komponente, die leicht ersetzt, unabhängig voneinander entwickelt und installiert werden kann. Ein Microservice ist Teil eines größeren Systems. Er wird gestartet und arbeitet mit anderen Microservices zusammen, um das zu erreichen, was sonst von einer großen, eigenständigen Anwendung erledigt werden würde.
Die Definition basiert auf dem Buch "Microservices" von Susan J. Fowler.
Giganten bevorzugen Microservices
Es ist kein Wunder, dass Amazon (Amazon Web Services), Twitter, Netflix, eBay und Uber monolithische Anwendungen aufgegeben haben.
Die oben genannten Unternehmen haben sich auf die Microservices Architektur konzentriert, weil sie festgestellt haben, dass sie damit große Hindernisse im Softwareentwicklung Prozess vermeiden können, die Susan J. Fowler in ihrem Buch erwähnt.
Nämlich:
- Unzureichende Effizienz des Systems.
- Langsame Entwicklung.
- Schwierigkeiten bei der Einführung neuer Technologien.
Susan J. Fowler warnt davor, dass Probleme entstehen, wenn wir versuchen, komplexe Softwaresysteme in einer großen monolithischen Anwendung zu implementieren. Trotz des oben genannten Risikos rät sie zur Übernahme dieser Architekturstil - der Microservices Architekturen.
Heutzutage besteht der übliche Ansatz darin, eine Anwendung in drei separate Elemente zu unterteilen: Frontend, d.h. die Kundenseite, Backend und Datenbank. Susan J. Fowler beschreibt die Zusammenarbeit zwischen jedem dieser Elemente als eine dreistufige Architektur:
"Anfragen an die Anwendung werden über den client-seitigen Teil gestellt, der Backend-Code übernimmt die gesamte Arbeit, und alle relevanten Daten, die gespeichert oder abgerufen werden müssen (ob vorübergehend im Speicher oder dauerhaft in einer Datenbank), werden an den Ort, an dem die Daten gespeichert sind, gesendet oder von dort abgerufen. Wir nennen das die dreistufige Architektur".
Susan J. Fowler, Microservices
Ein Beispiel für Programmierherausforderungen und Microservices bei einem Webentwicklungsunternehmen
Wie hilfreich Microservices sind, lässt sich am Beispiel eines jungen Webentwicklungsunternehmens verdeutlichen, das anfangs nur wenige Mitarbeiter beschäftigt und einfache Anwendungen erstellt, wobei sich die Zahl der Aufträge mit den dem Unternehmen zur Verfügung stehenden Personalressourcen überschneidet.
Doch schon nach wenigen Jahren Geschäftstätigkeit wächst das Webentwicklungsunternehmen deutlich und gewinnt immer mehr Kunden. Neue Mitarbeiter stoßen zum Team, und die Anwendungen erhalten zusätzliche Funktionen. Dies bringt neue Herausforderungen mit sich.
Susan J. Fowler erwähnt zunächst die erhöhte Belastung, die mit dem Start und der Pflege einer Anwendung verbunden ist. Danach müssen in der Regel zusätzliche Mitarbeiter eingestellt werden, z. B. Systemadministratoren, die den größten Teil der Hardware und Supportanfragen übernehmen.
Ein weiteres offensichtliches Element ist, dass mit dem Hinzufügen neuer Funktionen zu einer Anwendung die Komplexität und die Anzahl der Codezeilen zunimmt.
Das dritte Element bezieht sich auf die Zunahme des Datenverkehrs, die eine höhere Skalierbarkeit und Leistung der Anwendungen erzwingt - dies führt dazu, dass mehr Server eingesetzt werden müssen, weshalb die Cloud eine so gute Lösung ist, bei der unsere Informationen in kleinere Teile aufgeteilt werden, die jeweils auf einem anderen Server gespeichert sind.
Mit neuen Funktionen und anderen Änderungen in einer Anwendung wächst auch ihr Code enorm. Susan J. Fowler warnt davor, dass dies bedeutet, Hunderte oder Tausende von Tests zu schreiben, um zu prüfen, ob die vorgenommenen Änderungen die Integrität der bestehenden Tausenden von Codezeilen nicht beeinträchtigen, selbst wenn die Änderungen nur in einer oder zwei Codezeilen vorgenommen wurden.
Microservices und Monolith
Bei der Erstellung einer Microservices Architektur besteht unsere Aufgabe darin, eine Sammlung von kleinen Anwendungen zu erstellen, von denen jede für die Ausführung einer Funktion zuständig ist.
Der grundlegende Unterschied zwischen einer monolithischen Anwendung und Microservices besteht darin, dass eine monolithische Anwendung alle Merkmale und Funktionen in einer Anwendung und einer Codebasis enthält.
Außerdem werden sie gleichzeitig installiert, und jeder Server ist der Host für eine vollständige Kopie der Anwendung. Im Gegenzug enthalten Microservices nur eine Funktion oder ein Feature und funktionieren im Microservices-Ökosystem zusammen mit anderen Microservices, von denen jeder eine Funktion oder ein funktionales Feature ausführt.
Microservices - Vorteile
Betrachten wir abschließend die positiven Aspekte von Microservices:
- Verringerung der technischen Schulden.
- Verbesserung der Arbeitseffizienz der Programmierer.
- Bessere Testleistung.
- Erhöhte Skalierbarkeit und einfache Implementierung.
- Bewältigung von Skalierbarkeitsherausforderungen und organisatorischen Problemen.
Hero shot: FonsoSac / Flickr.com
