Microservices - Best Practices und Patterns

Microservices - Best Practices und Patterns

Artikel erschienen in IT Magazine 2019/11
In Unternehmen mit einem klassischen Ansatz der Softwareentwicklung implementieren und testen einzelne Teams Funktionalitäten in einer monolithischen Anwendung. Nach erfolgreichen Tests durch die einzelnen Entwicklungsteams wird die Software an das Betriebsteam übergeben, das die neue Version der Software auf der Infrastruktur ausrollt und betreibt. Eine grosse Herausforderung der Softwareentwicklung in einem solchem Umfeld besteht darin, dass unterschiedliche Teams an einer Quelltextbasis arbeiten, was eine hohe Kommunikationsleistung erfordert. Oft kommt es auch vor, dass für das nächste Release der Software Entwicklerteams Modifikationen an denselben Stellen vornehmen, was zu sogenannten Merge-Days führt, bei denen die konkurrierenden Änderungen aufgelöst werden müssen. Software, die unter solchen Bedingungen entstanden ist, ist oft fehleranfällig und schwer wartbar. Jeder neue Release bei monolithischen Anwendungen birgt grosse Risiken, da viele Änderungen in einen Release fliessen. Das ist auch der Grund, weshalb die Anzahl der Releases pro Jahr eher gering ist und ein zentrales Releasemanagement existiert. Die Einführung von Microservices führt zwangsläufig zu stärkerer Autonomie der einzelnen Teams: Diese sind für die Implementierung, die Tests, das Deployment und den Betrieb der Software selbst verantwortlich. All das führt im Idealfall zu einer deutlich höheren Anzahl von Software Releases. Wenn zudem noch weitere DevOps-Prinzipien implementiert werden, können Teams – je nach Service sogar hochgradig automatisiert – mehrfach täglich kleine Änderungen in Produktion bringen und somit signifikant schneller auf Kundenanforderungen reagieren.

Die Herausforderungen von Microservices

Neben den vielen Vorteilen haben Microservices auch einige Herausforderungen, die es zu beachten gilt: die Komplexität der Anwendung verschwindet bei dem Wechsel von einer monolithischen Architektur hin zu Microservices nicht auf magische Art und Weise, sondern verlagert sich von der komplexen Anwendung weg hin zur Orchestrierung der einzelnen kleinen Services, die in der Gesamtheit die vollständige Geschäftslogik abbilden. Teil der Anwendung muss also eine Orchestrierungsschicht werden, die die Microservices in der korrekten Reihenfolge mit den richtigen Parametern aufruft und sich auch um wichtige Aspekte wie die Fehlerbehandlung kümmert. Da eine Microservices-Architektur per Definition ein verteiltes System ist, gelten auch an dieser Stelle die sogenannten "Fallacies of distributed Computing", also Irrtümer bei der verteilten Datenverarbeitung.

Aufgrund der Tatsache, dass die einzelnen Services miteinander kommunizieren müssen, um die Geschäftslogik abzubilden, muss zwangsläufig mit höherem Netzwerktraffic gerechnet werden, was auch die Latenz erhöht. Um diese Herausforderungen meistern zu können, existieren generelle Entwurfsmuster für die Konzeption und Implementierung solcher Architekturen.

Neuen Kommentar erfassen

Anti-Spam-Frage Wie hiess im Märchen die Schwester von Hänsel?
Antwort
Name
E-Mail
SPONSOREN & PARTNER