Microservices erfreuen sich bei vielen Entwicklern nach wie vor grosser Beliebtheit. Das liegt auch daran, dass die Vorteile schwerer wiegen als deren nachgesagte Komplexität. Microservices-Architekturen sind schliesslich kein völlig neuer Ansatz für das Software-Engineering, sondern eine Kombination aus verschiedenen erfolgreichen und bewährten Konzepten. Dieser Ansatz soll einerseits Innovationen fördern, und andererseits die Wartbarkeit und Skalierbarkeit von Softwareanwendungen verbessern. Unternehmen, die Software und Dienstleistungen bereitstellen, könnten ausserdem von zusätzlichen Skaleneffekten profitieren, indem sie diesen agilen Ansatz verfolgen, der verschiedenen Teams auch erlaubt, unabhängig voneinander zu arbeiten. Dieser Architekturansatz für Software birgt noch weitere Vorteile, es gibt jedoch ein paar Dinge, die man dabei nicht ausser Acht lassen sollte.
Wesentliche Eigenschaften und Merkmale von Microservices sind in untenstehender Abbildung zu finden. Ein fundamentaler Punkt bei Microservices ist, dass eine Architektur bestehend aus diesen Services polyglott sein kann, es können also unterschiedliche Sprachen und Frameworks genutzt werden, die für die spezifische Domäne am besten geeignet sind. Jeder Service sollte – von aussen betrachtet – eine Black Box sein: die eigentliche Implementierung der Businessfunktionalitäten ist für den Aufrufer irrelevant, einzig die wohldokumentierte Schnittstelle zählt. Darüber hinaus sollte jeder Service auch nur eine Funktionalität implementieren. Falls sich mehr als eine Domäne in einem Service befindet, sollte das Domänenmodell überprüft und der Service eventuell aufgeteilt werden. Services sind unabhängig voneinander, es können also auch neue Versionen unabhängig ausgerollt werden. Es existiert auch kein zentraler Service in einer solchen Architektur für die Steuerung der übrigen, die Orchestrierung findet auf einer anderen Eben statt. Ein wichtiger DevOps-Aspekt bei Microservices besteht darin, dass das Team, das einen Service baut, auch für den produktiven Betrieb verantwortlich ist.
Polyglot: Unterschiedliche Sprachen und Frameworks in Kombination – Do one thing well: Jeder Service implementiert eine Funktionalität – You build it, you run it: Entwicklerteams sind verantwortlich für den produktiven Betrieb – Black box: Die Schnittstelle ist relevant, nicht die Implementierung – Independent: Services können unabhängig voneinandern ausgerollt werden – Decentralized: Es existiert kein zentraler Service für die Orchestrierung. (Quelle: Amazon Web Services (AWS))
Ein Vorteil von Microservices ist, dass verschiedene Teams im Software Engineering auch unabhängig voneinander arbeiten können. (Quelle: Unsplash)
Conway’s Law und der kontrollierte Kontrollverlust
Eine häufig gestellte Frage ist: Was muss ich machen, damit ich eine Microservices-Architektur im Unternehmen erfolgreich einführen kann? Conways Gesetz gibt dazu erste Anhaltspunkte. Diese Regel ist nach dem Programmierer Melvin Conway benannt, der die Idee 1967 einführte. Das Gesetz basiert auf der Überlegung, dass mehrere Autoren häufig miteinander kommunizieren müssen, damit ein Softwaremodul funktioniert. Daher spiegeln die Schnittstellen von Software eines Systems auch die kommunikativen Grenzlinien der Organisation wider, die sie hervorgebracht haben. Nehmen wir an, wir haben eine Situation, in der die Struktur der Organisation und der Software voneinander abweichen. Typischerweise ist das der Fall, wenn ein verteiltes Team an einer monolithischen Quelltextbasis arbeitet. Die Alternative – in Form von Microservices – besteht in einer modularen Quelltextbasis, an der mit verteilten, kleinen Teams gearbeitet werden kann. Jedes Team ist somit verantwortlich für einen kleinen Baustein des Gesamtsystems, was auch den produktiven Betrieb eines Service betrifft.
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.
Fazit
Microservices-Architektur ist ein Designansatz für verteilte Software, der die Grenzen traditioneller monolithischer Architekturen überwinden soll. Microservices helfen bei der Skalierung von Anwendungen und Unternehmen und verringern gleichzeitig die Zeit zwischen Software Releases. Sie stellen jedoch auch eine Reihe von Herausforderungen dar, die zu zusätzlicher architektonischer Komplexität auf der Ebene der Orchestrierung führen können. Ein aktuelles Whitepaper über die Implementierung von Microservices-Architekturen in AWS kann unter https://d1.awsstatic.com/whitepapers/microservices-on-aws.pdf gefunden werden.
Der Autor
Sascha Möllering arbeitet seit mehr als vier Jahren als Solutions Architect und Solutions Architect Manager bei Amazon Web Services EMEA in der Niederlassung Deutschland. Zuvor war er als Team Lead und Software Architect bei Zanox in Berlin tätig. Er teilt seine Expertise mit dem Fokus auf die Bereiche Automation, Infrastructure as Code, Distributed Computing, Container und JVM regelmässig in Beiträgen verschiedener IT Magazine im deutschsprachigen Raum.
(Quelle: Amazon Web Services (AWS))
