Table of Contents
In diesem Blog der DevOps-Beratungsserie schauen wir uns an, was eine Microservices-Architektur ist und wie der strukturelle Stil dies ermöglicht:
Wir werden uns auch mit möglichen Fehlern befassen, die bei einem Microservices-Ansatz gemacht werden können, und mit der Frage, wann er nicht die richtige Wahl für eine Anwendung ist.
Agile und DevOps-Entwickler, Teamverstärkung und Berater
Nach Ihren individuellen Bedürfnissen!
Der Begriff „Microservices“ bezieht sich auf einen service-orientierten Strukturstil der Softwarearchitektur, bei dem eine Anwendung in eine Sammlung von lose gekoppelten Services aufgeteilt wird. Derek Comartin beschreibt Microservices als:
„Loosely coupled service-oriented architecture with bounded contexts.“
Sowie Bounded Context, ein Begriff aus dem Domain-Driven Design, welcher definiert ist als:
„If you have to know too much about surrounding services you don’t have a bounded context.“
Bei Microservices werden Codeteile logisch so voneinander getrennt, dass sie unabhängig voneinander laufen können und möglichst wenig voneinander abhängig sind. Die einzelnen Microservices können aber dennoch miteinander „sprechen“ und zusammenarbeiten, um aus der Summe ihrer Microservices eine komplexe Anwendung zu bilden.
Die Aufteilung von Code-Blöcken in autarke Microservices bedeutet, dass Abhängigkeiten und die Notwendigkeit, Änderungen an den einzelnen Services mit anderen zu koordinieren, minimiert werden. Das bedeutet auch, dass der Ausfall eines Service weniger Auswirkungen auf das Funktionieren der Anwendung als Ganzes hat.
Vor dem Aufkommen von Microservices tendierten Entwickler, die mit der Implementierung der Unterstützung von Drittanbieterdiensten über API und verschiedene Clients beauftragt waren, zur Verwendung monolithischer Architekturmuster. Dies war der naheliegendste Weg, um solche Anwendungen zu implementieren, und trug zu einer effizienteren Nutzung der Hardwareressourcen bei.
Im Jahr 2021 sind Microservices, die die CI/CD-Priorität eines DevOps-Ansatzes für die Webentwicklung unterstützen, nun der bevorzugte Ansatz.
Microservices werden oft im Zusammenhang mit Containern, Docker, Kubernetes und Serverless-Architekturen diskutiert. Es sollte jedoch klargestellt werden, dass es sich hierbei um Tools und Technologien handelt, die von Backend-Architekten für die physische Bereitstellung von Microservices verwendet werden. Microservices beziehen sich auf die logische Trennung von Code-Blöcken in autonome Services. Container, Docker, Kubernetes und Serverless-Architektur sind Tools und Ansätze für die physische Bereitstellung von Microservices.
Wenn Sie eine neue Softwareanwendung von relativer Größe und Komplexität planen, ist die Wahrscheinlichkeit groß, dass ihre Backend-Architektur auf Microservices aufbaut.
Relativ neue Entwicklungen in der Software- und Hardwaretechnologie haben es ermöglicht, dass eine Anwendung in mehrere gleichzeitige Prozesse und Services aufgeteilt werden kann, anstatt aus einer einzigen monolithischen Architektur zu bestehen. Als der architektonische Ansatz, Software als Suiten von lose gekoppelten, aber unabhängig voneinander einsetzbaren Services zu entwerfen, entwickelt wurde und an Popularität gewann, begann man, ihn als Microservices-Architektur zu bezeichnen.
Beachten Sie jedoch, dass das Microservices-Muster kein allgemeingültiger Ansatz ist, der für jedes Softwaresystem umgesetzt werden sollte. In vielen unserer Projekte bei K&C kombinieren wir Microservices mit CQRS, Event Sourcing und DDD-Mustern, wenn wir die Architektur einer neuen Unternehmens-Webanwendung entwerfen.
Während eine Microservices-Architektur viele Vorteile und Kosteneinsparungen mit sich bringt, besteht eine der wichtigsten Entscheidungen darin, zu entscheiden, wie weit Sie mit der Komponentisierung Ihrer Anwendung gehen sollten. Es gibt zahlreiche Kriterien, die Sie abwägen müssen, zum Beispiel:
Eine Microservices-Architektur bietet zwar viele Vorteile, ist aber bei weitem nicht für jede Art von Anwendung die richtige Wahl. Zudem lassen Microservices bei schlechter Ausführung viel Raum für Fehler. Wir hatten einen Fall, in dem ein Kunde zu uns kam, um Hilfe für eine Anwendung zu erhalten, die in Dutzende von Komponenten aufgeteilt war. Wenn die Dinge reibungslos liefen, führte dieser detaillierte Ansatz zu starken Leistungsindikatoren. Das Entwicklungsteam, das die Anwendung wartete, sah sich jedoch häufig mit Problemen und Fehlern konfrontiert, die durch falsche Interaktion zwischen den Microservices verursacht wurden.
In diesem speziellen Fall war die Anwendung übermäßig stark in mehr Microservices aufgeteilt worden, als sie hätte sein sollen. Die Aufteilung der Funktionalitäten in zu viele Microservices führte zu zusätzlichem Zeit- und Kostenaufwand für Wartung, Support und Updates, statt das Gegenteil zu bewirken. Außerdem wirkte sich ein Mangel an Ressourcen zur Bewältigung dieser Schwierigkeiten letztlich auf die Leistung der App aus.
1. Sobald die Geschäftslogik des zukünftigen Produkts definiert ist, ziehen wir es vor, die App zunächst in größere Komponenten aufzuteilen, die später wieder in weitere Microservices aufgeteilt werden können, wenn dies von Vorteil ist.
2. Kleinere Teile der ursprünglichen Komponenten, die sich als kritisch in Bezug auf die Leistung erweisen, können als eigenständiger Service ausgegliedert werden.
3. Ein Proof-of-Concept der zur Implementierung vorgeschlagenen Architektur (oder zumindest der wichtigsten Teile davon) sollte erstellt und Eckfälle analysiert werden.
4. Wir verwenden bekannte Bibliotheken und Frameworks, um die Kosten für die Aktualisierung von Snapshot-Versionen und die Behebung von Fehlern zu minimieren.
5. Wir testen den Code der Services streng und implementieren Integrationstests für API-Kontrollen.
6. Wir bauen und verwenden eine gut organisierte kontinuierliche Integrationspipeline mit „Ein-Knopf“-Einsatz und Freigabe.
7. Wir erwägen den Einsatz von Docker und Kubernetes zur Orchestrierung von Services.
Auch wenn ein solcher Ansatz recht einfach klingt, zeigt unsere Erfahrung, dass dies für die meisten Unternehmensprodukte die kosten- und zeiteffizienteste Entwicklungsstrategie ist.
Die meisten unserer Unternehmenskunden mit leistungsstarken Anwendungen bevorzugen aus den folgenden Gründen eine Microservices-Architektur:
Da der Ausfall eines Services keine Auswirkungen auf andere Services hat, können Sie sicher sein, dass nicht die gesamte Anwendung wegen eines kleinen Fehlers im Code einer Komponente ausfällt.
Services, die kritische Funktionen bereitstellen, können leicht auf weitere Server skaliert werden (was sogar im laufenden Betrieb möglich ist), während Sie bei monolithischen Anwendungen Zeit und Ressourcen in die gleichzeitige Skalierung des gesamten Systems investieren müssen.
Die Entwicklung kann von verschiedenen Entwicklern oder Teams parallel durchgeführt werden, so dass neue Mitarbeiter schnell hinzukommen können, wenn der Entwicklungsprozess beschleunigt werden muss.
Die Microservices-Architektur erfordert zwar DevOps-Fachwissen in einem Entwicklungsteam, macht aber die Bereitstellung einfacher und zuverlässiger, insbesondere bei Verwendung von Technologien wie Docker.
Wenn Sie ein neues Softwareentwicklungsprojekt besprechen möchten, von dem Sie glauben, dass es von einem Microservices-Architekturansatz profitieren könnte, bzw. wenn Sie erwägen, eine alte monolithische Anwendung auf Microservices zu migrieren, dann nehmen Sie doch gerne Kontakt mit uns auf. Wir würden uns freuen, von Ihnen zu hören und Ihnen unsere Einschätzung der Eignung von Microservices in Ihrem speziellen Kontext mitzuteilen!
Lesen Sie auch, warum und wie wir dem weltweit größten Veranstaltungsunternehmen geholfen haben, sein zentrales, mehrfach gemietetes CMS von einer monolithischen zu einer Microservices-Architektur zu migrieren.
K&C - Wir schaffen innovative Tech-Lösungen seit über 20 Jahren.
Kontaktieren Sie uns, um Ihre individuellen Bedürfnisse oder Ihr nächstes Projekt zu diskutieren.