DevOps und Microservicearchitekturen unter der Lupe

IT-Unternehmen wie Uber, Netflix und Spotify haben in relativ kurzer Zeit ein großes Wachstum erreicht. Möglich wurde dies u. a. durch die Verwendung von Microservicearchitekturen, die durch autonome Teams entwickelt und betrieben werden (Low 2021; Chacko 2022; Upadhyay 2021). Auf diese Teams werfen wir in diesem Beitrag einen Blick und stellen über die sechs DevOps-Prinzipien der DASA (DevOps Agile Skills Association) einen Bezug zu Microservicearchitekturen her. Uber dient uns als Veranschaulichungsbeispiel. Das Unternehmen betreibt eine Plattformtechnologie, über die Passagiere direkt mit Fahrern kommunizieren können, um eine Transportmöglichkeit zu buchen. Insbesondere geht es uns um Änderungen der Systemarchitektur und die Beschreibung technischer Zusammenhänge.

Moderne Gestaltung von Entwicklungsteams

Beginnen wir mir einem Blick auf die sechs DevOps-Prinzipien und die wertschaffenden Kommunikationsstrukturen in autonomen Teams:

Abbildung 1: Sechs DevOps-Prinzipien (in Anlehnung an DASA 2021) 

Die “End-To-End Responsibility” ist ein Kern der DevOps-Philosophie. Durch hohes Interesse und Eigenverantwortung in den Teams wird die Motivation auf das Produkt gestärkt. Wichtig dabei ist, dass die Teams auch nach der Entwicklung und Einführung die Verantwortung für das Produkt behalten. Die Teams übernehmen bis zum Ende des Lebenszyklus den Betrieb und die Weiterentwicklung des Produktes (DASA 2021). Ein zentrales Team für den Betrieb der gesamten Software wird vermieden (Tozzi 2022).

Zur Übernahme der Verantwortung auch im Betrieb des Produktes werden vertikal organisierte Teams benötigt. Neben der Entwicklung und der Bereitstellung des Produktes muss das Team in der Lage sein, das Produkt zu betreiben und zu verbessern. Um diese autonomen und vertikal organisierten Teams zu realisieren, müssen Fähigkeiten in unterschiedlichen Bereichen aufgebaut werden. Dafür ist es nicht zielführend einzelne Spezialisten zusammen zu bringen, sondern eine ausgewogene Teamstruktur mit verteilten Fähigkeiten aufzubauen. Neben Expertenwissen gelten die Soft-Skills der Teammitglieder und die Offenheit für andere Meinungen innerhalb der Teams als besonders wichtige Fähigkeiten (DASA 2021).

Durch den steigenden Einfluss der IT auf den Geschäftserfolg rückt in der Softwareentwicklung eine hohe Qualität des Produktes und eine kurze Lieferzeit in den Fokus. Aus diesem Grund werden Implementierungsprojekte weitestgehend mit agilen Projektmethoden umgesetzt (Shore 2021, S. 7–8). In der Folge kommt es häufig zu Änderungen in der Organisation von Entwicklungsteams im Sinne von autonom agierenden Einheiten.

Hierarchische Organisationsformen können Probleme in der Kommunikation manifestieren. So werden bspw. durch klassische Teamstrukturen einzelne Teams isoliert und die Kommunikationswege unnötig kompliziert.

Organisationsstrukturen in Projekten lassen sich üblicherweise in drei unterschiedliche Strukturen unterteilen:

1. Formale Struktur (Organisationschart)
2. Informelle Struktur (Austausch zwischen Individuen in der Organisation)
3. Wertschaffende Struktur (Austausch bezogen auf die Problemlösung)

Grundsätzlich gilt, dass der beste Austausch zwischen der informellen und wertschaffenden Struktur zustande kommt. Ziel einer Organisation sollte es daher sein, die Interaktion zwischen wertschaffenden Teams und individuellen Personen zu fördern (Pfläging 2014).

Weiterführend beschreibt Conway’s Gesetz ein Phänomen, welches besagt, dass das Design eines Systems abhängig von der Organisationsstruktur des Entwicklungsteams ist (Kwan et al. 2012). Dabei ist vor allem die wertschaffende Struktur ausschlaggebend für das Design des Produktes. Hier kann die Führungsebene eines Unternehmens Einfluss auf das Design eines Produktes nehmen, indem die Organisationsstruktur für die Zusammenarbeit betrachtet und wenn nötig angepasst wird. In der Folge ändern sich auch die  Kommunikationsstrukturen; dieses Prinzip wird als “Reverse Conway Maneuver” bezeichnet.

Abbildung 2: Teams für unabhängige Microservices und Datenbanken

Abbildung 2 zeigt das Design von Teams für die Architektur unabhängiger Microservices in unabhängigen Datenbanken. Die Kommunikationswege sind klar definiert und lösungsbezogen. Dadurch können nicht wertschöpfende Kommunikationen entfallen und die Effizienz in der Umsetzung des Zielbildes wird gesteigert. Dieses Prinzip lässt sich auf verschiedenste Zielarchitekturen anwenden, sodass einerseits eine Überarbeitung der Kommunikation in den Entwicklungsteams stattfinden, aber auch eine Einschätzung über Engpässe in den Teams vorgenommen werden kann.

Eine kurze Einführung in Microservices

Durch die immer komplexere Struktur von IT-Systemen hat sich eine Entkoppelung einzelner Services oder Funktionen als Möglichkeit zur Steigerung der Effizienz und der Stabilität des Gesamtsystems erwiesen. Das Verwenden einer solchen Architektur von vielen einzelnen Services wird als Microservicearchitektur beschrieben (Namiot Dmitry et al. 2014).

Im Folgenden betrachten wir kurz die Unterschiede im Architekturdesign, gehen auf die technische Realisierung einer Microservicearchitektur ein und fassen Vor- und Nachteile von Microservices zusammen.

Unterschiede zwischen einer klassischen Architektur und einer Microservicearchitektur

Die Aufteilung eines komplexen IT-Systems in einzelne Funktionen wird als Microservicearchitektur bezeichnet. Dabei ist die Aufteilung in die Funktionen ein Hauptbestandteil der Architektur. Die Entkoppelung einzelner Services zu losen gekoppelten Funktionen birgt Vorteile in der Wartbarkeit, der Testbarkeit und der Bereitstellung. Diese Funktionen werden in den meisten Fällen um die Anwendungsfälle der Fachbereiche entworfen und von kleinen, autonomen Entwicklungsteams entwickelt (Richardson 2021).

Gleichzeitig birgt die Aufteilung der gesamten Lösung in einzelne Funktionen Herausforderungen, die für mehr Aufwand in der Entwicklung sorgen können. In erster Linie werden die Entwickler durch die hinzugefügte Komplexität in der Kommunikation und durch die Bereitstellung der einzelnen Funktionen belastet. Außerdem müssen die Entwickler und die Stakeholder aus dem Fachbereich auf ein neues Testvorgehen vorbereitet werden. Dabei verändern sich in erster Linie die übergreifenden Tests, bezogen auf den fachlich abgebildeten Prozess (Chen 2018).

Eine besondere Herausforderung stellt die Definition des Systems in die einzelnen Funktionen dar. Bei der neuen Einführung der Architektur muss dabei ein Design für die Abtrennung festgelegt werden, bevor die Umsetzung gestartet werden kann. Hierfür bieten sich verschiedene Ansätze der Partitionierung an:

1. über die Anwendungsfälle der Fachbereiche,
2. über die genutzten Funktionen,
3. über die genutzten Ressourcen und Entitäten.

Bei diesen drei Ansätzen geht es vor allem darum, die Verantwortlichkeiten der Services möglichst klar abzugrenzen, um gezielte Verbesserungen und Anpassungen durchführen zu können, ohne Einfluss auf andere Funktionen zu nehmen (Namiot et al. 2014).

Die Kommunikation der aufgetrennten Services spielt beim Design der Architektur eine weitere große Rolle. Abbildung 3 zeigt gängige Methoden zur Kommunikation in einer Microservicearchitektur.

Abbildung 3: Kommunikationsmethoden Microservices (in Anlehnung an Namiot et al. 2014)

Die erste dargestellte Methode stellt direkte Aufrufe der App durch die Services dar. Dabei hat diese Methode die größte Flexibilität bei der Anbindung neuer Services. Das Problem bei der direkten Anbindung der Services stellen die hohe Anzahl der Aufrufe der App dar. Dies kann bei komplexer werdenden Produkten zu Verzögerungen in der Abarbeitung führen (Namiot et al. 2014). Diese Herausforderung kann durch einen hybriden Abarbeitungsmodus der Aufrufe (synchrone Aufrufe mit Nachrichtenwarteschlangen) oder einer anderen Architektur gelöst werden (Karabey et al. 2021). Weitere Ansätze zur Kommunikation in der Microservicearchitektur sind Gateway- und Kommunikationsbuslösungen. Dadurch können Aufrufe strukturierter abgearbeitet werden. Die Kommunikationsbuslösung ist vor allem in der Maschinenkommunikation (Internet der Dinge) oft verortet (Namiot et al. 2014).

Die drei Ansätze zur Kommunikation zwischen Microservices sind unabhängig voneinander und können in verschiedenen Situationen Vor- oder Nachteile bieten. Eine Gateway-Lösung erweitert die direkte Kommunikation zwischen Apps und Services um eine Softwarelösung, die das Verarbeiten der gesendeten Nachricht übernimmt und dann gezielt an die Zielsysteme weiterleitet. Eine Kommunikationsbuslösung stellt die Nachricht für alle Teilnehmer des Systems bereit, sodass eine Erweiterung der Kommunikation durch neue Teilnehmer vereinfacht wird.

Grundsätzlich gilt, dass die direkte Anbindung der App die größte Popularität bei der Umsetzung von Microservicearchitekturen hat, da sie eine hohe Flexibilität und für DevOps Teams einfach zu entwickeln ist (Karabey et al. 2021).

Möglichkeiten der Umsetzung von Microservices

Bei der Umsetzung einer Microservicearchitektur ist zu beachten, dass verschiedenste Technologien zum Einsatz kommen. Daraus folgt auch, dass die dafür benötigten Fähigkeiten im Team aufgebaut werden müssen, bevor eine Implementierung starten kann. Auch hier ist wichtig, dass die zuvor genannten 6 DevOps-Prinzipien von Entwicklungsteams angewendet werden, um eine optimale Entwicklung zu gewährleisten. Natürlich sollte von Anfang an der Betrieb der Microservices bedacht werden, um bei einer resultierenden Komplexität der Architektur eine Struktur für das Monitoring und das Fehlerhandling der Services nutzen zu können. (Lauer und Augsten 2018).

Zu beachten ist, dass eine Lösung sich im Normalfall aus verschiedensten Tools zusammensetzt und nicht von einer Technologie gelöst wird. Abbildung 4 zeigt eine Auswahl von Aufgabenbereichen in der Entwicklung von Microservices mit gängigen Anbietern zur Umsetzung der Lösung.

Abbildung 4: Gängige Tools zur Entwicklung von Microservices (in Anlehnung an Thorpe 2018)

Als grundsätzliche Unterteilung der Technologien springen die Themenblöcke API-Management und Tests, Datentransfer zwischen Services (Messaging), Monitoring, Serverlose Tools und Toolkits für die Umsetzung von Microservices ins Auge. Auffällig ist, dass große Cloud-Anbieter wie Amazon, Microsoft und Google in vielen Bereichen der Entwicklung eigene Produkte bereitstellen, um die Entwicklung zu unterstützen (Thorpe 2018).

Das API-Management und Tests der Services beschreibt einerseits die Verwaltung der Microservices im gesamten System sowie die Tests der Services bei der Entwicklung. Die dafür vorgestellten Tools zeichnen sich über eine einfachere Benutzeroberfläche aus, in der nachvollzogen werden kann, welche Services aktiv sind und wie häufig diese genutzt wurden. Außerdem lassen sich ohne großen Aufwand einzelne Testfälle vor der kompletten Implementierung durchspielen. Diese Tools sind besonders für große IT-Landschaften wichtig, sodass ein Überblick zwischen den Abhängigkeiten der Services geschaffen werden kann.

Der Transfer der Daten zwischen Services beschreibt die geordnete Abarbeitung und Verteilung an die unterschiedlichen Ziele. Dazu werden Technologien verwendet, die alle Aufrufe sammeln und in einer Reihenfolge – auch Warteschlange genannt – abarbeitet. Dabei werden zusätzlich in der Warteschlange der Start und die Ziel-Services angegeben.

Das Monitoring der etablierten Microservices beschreibt eine technologische Unterstützung für den Betrieb der Services. Während der Nutzung der Services werden viele individuelle Aufrufe stattfinden. Zur Überprüfung der Aufrufe und zum Nachvollziehen der ausgetauschten Daten muss eine Überwachung der Services möglich sein.

Serverlose Tools beschreiben Cloud-Lösungen von Anbietern, die ohne eine eigene Umgebung auskommt. Nach dem Prinzip “Pay-per-Use” können Unternehmen in den Anbieter-Lösungen die Microservices aufrufen und die Funktionen ausführen, ohne dauerhafte Kosten tragen zu müssen. Außerdem bieten die Anbieter eine eigene Benutzeroberfläche, in der die Funktionen entwickelt werden können, ohne tiefgreifende Programmierkenntnisse vorweisen zu müssen.

Die Toolkits für den Aufbau von Microservices beschreiben eine komplette Lösung von Anbietern. Sie stellen viele unterschiedliche Technologien bereit und zeichnen sich häufig durch offene Schnittstellen aus, an denen man vorhandene Technologien anbinden kann.

Vorteile und Nachteile einer Microservicearchitektur

Eine Microservicearchitektur bietet einige Vorteile, hat aber auch einige Nachteile.

Die Verfügbarkeit unterschiedlicher Technologien gilt als ein großer Vorteil. Wie im Kapitel zuvor kurz dargestellt, stehen für verschiedenste Problemfelder mehrere Technologien zur Verfügung, sodass Teams die freie Wahl haben und sich für eine passende Technologie entscheiden können. Dies wird durch vorhandene Standards in den Bereich der Integration und Kommunikation unterstützt, so dass viele Technologien parallel genutzt werden können (Kappagantula 2018).

Auch der die Betrachtungsmöglichkeit des Geschäftswerts einzelner Services ist ein Vorteil. Services ohne echten Wert für das Unternehmen werden schlicht nicht entwickelt und betrieben. Dieser Eigenschaft ermöglicht es, den direkten Einfluss des Microservices auf das operative Geschäft darzustellen (Kappagantula 2018).

Weitere Vorteile, die durch die möglichst lockere Kopplung der Microservices entstehen, sind das unabhängige und parallele entwickeln und bereitstellen der Funktionen, die Möglichkeit vereinfacht regelmäßig neue Softwarereleases bereitzustellen und die höhere Sicherheit der gesamten Systemarchitektur durch eine Abkapselung (Kappagantula 2018).

Zusammengefasst bietet eine Microservicearchitektur folgende Vorteile:

• Freiheit über Technologie-Wahl
• Definierter Geschäftswert pro Service
• Unabhängiges Deployment
• Regelmäßiger Softwarerelease
• Erhöhte Sicherheit durch Abkapselung
• Parallele Entwicklung und Deployment

Eine Microservicearchitektur bietet aber nicht nur Vorteile, sondern hat auch einige Nachteile. Bspw. wird die Fehlersuche erschwert, da der Betrieb der Microservices häufig durch autonome Produktteams durchgeführt wird, und so bei  produktübergreifenden Fehlern die Komplexität der Suche steigt (Kappagantula 2018).

Ein Nachteil – oder sollten wir Herausforderung sagen – kann die hohe Last in einem System darstellen. Bei der Skalierung der Microservices muss daher eine verzögerte Reaktionsgeschwindigkeit des Systems beachtet werden (Kappagantula 2018).

Und auch die Entkopplung der Services birgt zentrale Nachteile. Herauszustellen ist dabei der erhöhte Konfigurationsaufwand bei der Entwicklung einer solchen Architektur. Außerdem gilt es während des Betriebs, die Sicherheit jedes einzelnen Microservices aufrecht zu erhalten. Übergreifende Sicherheitslücken müssen dann ggf. durch jedes Produktteam individuell gelöst werden. Des Weiteren kann es passieren, dass auf Grundlage von Performance-Einbrüchen und/oder der erhöhten Schwierigkeit eines Daten- und Code-Austauschs zwischen den Services, Daten doppelt gehalten werden müssen (Kappagantula 2018).

Zusammengefasst kann eine Microservicearchitektur also folgende Nachteile mit sich bringen:

• Erschwerte Fehlersuche
• Verzögerte Reaktionsgeschwindigkeit
• Erhöhter Konfigurationsaufwand
• Hoher Aufwand im Betrieb (Sicherheit)
• Datenabhängigkeiten und Datenduplizierung
• Code-Austausch zwischen Services

Ein Blick in die Uber Microservicearchitektur

Werfen wir nun einen Blick in die Uber Microservicearchitektur. In der ersten Systemarchitektur von Uber wurde auf ein klassisches monolithisches Vorgehen gesetzt. Dies war zu dem Zeitpunkt die einfachste Umsetzungsmöglichkeit für die Erstellung eines Prototyps in einer ausgewählten Stadt. Diese Systemarchitektur wurde jedoch im Laufe der Expansion durch verschiedene Hindernisse und Probleme von Uber überdacht. Vor allem im Betrieb war keine Skalierbarkeit gewährleistet und das kontinuierliche Integrieren und Weiterentwickeln des Systems konnte unter der Systemarchitektur nicht sichergestellt werden (Low 2021). Abbildung 5 zeigt den gewählten monolithischen Ansatz und schematisch die moderne Microservicearchitektur.

Abbildung 5: Uber Systemarchitekturen im Vergleich (In Anlehnung an Kappagantula 2018)

Die hier dargestellte monolithische Architektur setzt sich aus drei Grundkomponenten zusammen. Zur Kommunikation zwischen Fahrer und Passagier wurde eine REST API entworfen, sodass ein möglichst schneller Austausch der Daten zwischen beiden Individuen sichergestellt ist. Außerdem wurden zu Beginn drei Adapter genutzt, die einzelne Aktionen durchgeführt haben. Dazu gehört das Versenden von E-Mails an die Benutzer der App, das Bezahlen per App und die Rechnungsstellung. Die Daten wurden alle in einer Datenbank zusammengeführt und verarbeitet. Die Entwicklung fand in Technologie bezogenen Teams statt (Kappagantula 2018).

Die einzelnen Funktionen für das Passagiermanagement, die Rechnungsstellung und die Benachrichtigungen wurden in einem Framework zusammengeführt. Uber bestätigte, dass dieses Gefüge von Funktionen sehr hohe Abhängigkeiten in der Weiterentwicklung und der Fehlerbehebung der einzelnen Lösungen verursacht. Außerdem wurde die Entwicklung neuer Funktionen durch die Systemarchitektur erschwert (Shivang 2019).

Zur Lösung dieser Herausforderungen wurde entschieden, dass die monolithische Architektur durch eine Microservicearchitektur abgelöst wird. Die rechte Seite von Abbildung 5 zeigt die Microservicearchitektur. Jedes Element der Architektur wird dabei durch ein eigenes Team betreut und weiterentwickelt. Zum Einsatz kommt ein API-Gateway. Dadurch wird die Kommunikation zwischen Fahrer und Passagier zu den einzelnen Services organisiert. Die Abbildung zeigt vor allem die Aufteilung der Adapter aus der monolithischen Architektur in einzelne Services sowie die Erweiterung der Architektur um weitere Services, um eine möglichst große Unabhängigkeit zwischen den Services zu erlangen (Kappagantula 2018).

Durch die Unterteilung in die Benutzeroberfläche und das Management von Fahrern und Passagieren wird es möglich, Anpassungen am Auftritt des Unternehmens in der App oder im Web vorzunehmen, ohne Einfluss auf die Logik des Managements zu nehmen (Shivang 2019).

Außerdem wird durch die Aufteilung in die einzelnen Services eine hohe Skalierbarkeit der einzelnen Funktionen erlangt. So können Ressourcen für das Passagiermanagement, welches deutlich häufiger genutzt wird als der Bezahlvorgang, besser organisiert und genutzt werden (Shivang 2019).

Durch dieses Vorgehen ist es Uber außerdem gelungen 2.200 Microservices zu orchestrieren ohne kritische Abhängigkeiten in der Entwicklung und Fehlerbehebung der einzelnen Services aufzubauen. Uber setzt dabei heute auf eine Domänen-Orientierte Microservicearchitektur (DOMA). Hier geht es Uber darum, nicht die einzelnen Services zu betrachten, sondern Gruppen von Services als Domänen zusammen zu fassen und diese möglichst einfach zu organisieren, um den bereits geschilderten Nachteilen der Microservicearchitektur entgegenzuwirken (Gluck 2020).

In Abbildung 6 sehen sie, wie unterschiedlichste Technologien durch die neue Architektur genutzt werden. Uber hat sich bewusst dazu entschieden den Teams die Freiheit über die genutzten Technologien zu lassen (Shivang 2019).

Abbildung 6: Ausschnitt Technologienutzung Uber

Neben dem Monitoring durch Flink, dem Fehlerhandling durch ELK und den Datenbanksystemen Hadoop und Apache Hive wird vor allem Kafka als Kommunikationsdienst genutzt. Zusätzlich wird zur Organisation der einzelnen Services Edge Gateway als selbst entwickeltes API Management Technologie genutzt. Diese beiden Technologien sind für die Microservicearchitektur besonders relevant.

Apache Kafka ist eine Open-Source-Technologie zur Verarbeitung und Weiterleitung von Nachrichten. Kafka kommuniziert dabei über das TCP-Protokoll und kann als Nachrichtendienst, zum Tracking für Aktivitäten einer Webseite, zum Monitoring der bearbeiteten Daten und zur Protokollierung der Aufrufe genutzt werden (Apache Kafka 2021).

Uber nutzt Kafka als einen Eckpfeiler der Systemarchitektur. Außerdem gibt das Unternehmen an, eine der größten Implementierung von Apache Kafka im Einsatz zu haben. Täglich werden Billionen Nachrichten im Petabyte Bereich bearbeitet. Auch die Weiterleitung der Nachrichten zwischen Fahrer und Passagier findet über Apache Kafka statt. In erster Linie wird Kafka bei Uber als Nachrichtendienst genutzt. Weiterhin werden die Protokollierung und das Monitoring von Kafka eingesetzt, um eine Nachvollziehbarkeit bei Fehlern zu gewährleisten.

Seit 2014 setzt Uber auf eine vielseitige Nutzung von APIs im Kontext der Microservices. Dabei steht auch die Dokumentation der einzelnen Endpunkte im Fokus. Dazu wurde ein eigenes API Management Tool entwickelt. Edge Gateway befasst sich mit der Dokumentation und Organisation der einzelnen APIs. Seit 2018 wird Edge Gateway für alle Uber Unternehmen und nicht nur für das klassische Geschäftsmodell genutzt. Durch die Technologie lässt sich das verantwortliche Team und die grundlegende Funktion der API übergreifend darstellen (Thangavelu 2020).

Fazit

Bei der Betrachtung der vorliegenden Literatur wird schnell klar, dass eine Microservicearchitektur auch einen Wandel in der Organisation mit sich bringt. Wissenschaftliche Arbeiten und auch Uber als Beispielunternehmen zeigen, dass eine Veränderung der Systemarchitektur großen Einfluss auf die gesamte Organisation der IT-Bereiche eines Unternehmens hat.

Der Einfluss der Teamorganisation auf den Erfolg einer neuen Architektur wurde auch bei Uber festgestellt, sodass durch verschiedene Technologien das autonome Arbeiten an unterschiedlichen Funktionen ermöglicht wurde. Die selbst entwickelte Gateway-Lösung von Uber ermöglicht es, dass alle Teams die Microservices auf eine vergleichbare Weise dokumentieren können, während unterschiedliche Technologien in der Entwicklung der Microservices verwendet werden (Thangavelu 2020).

Bei Uber hat sich nach der Prototypphase gezeigt, dass eine monolithische Architektur keine Lösung für das digitale Geschäftsmodell des Unternehmens ist. Die Weiterentwicklung und Skalierung hatten ein so hohes Tempo, dass an verschiedenen Stellen gleichzeitig gearbeitet werden musste. Die Einführung der Microservicearchitektur mit vorhandenen und selbstentwickelten Technologien führte zu der gewünschten Anpassbarkeit des Systems.

Zu beachten ist, dass die Anzahl von verwendeten Technologien durch die Microservicearchitektur deutlich zunimmt. Das zeigt einerseits einen Vorteil der Microservices, denn jeder Entwickler kann eigenständig entscheiden, welche Lösung er präferiert. Andererseits entsteht dadurch aber auch eine unübersichtliche Technologie-Nutzung, die zusätzlichen Aufwand in der Kommunikation der Services verursacht. Uber hat dies erkannt und schafft sich mithilfe der DOMA einen Überblick über die Abhängigkeiten der 2.200 Microservices.

Das Beispiel von Uber zeigt ebenfalls einige Nachteile der Microservicearchitektur auf. Während der Erweiterung und der Neuentwicklung der Services wurde bspw. festgestellt, dass neben der hohen Anzahl an Technologien die große Menge an Services zur Unübersichtlichkeit der Systemlandschaft beiträgt. Dies erhöht den Aufwand im Betrieb des Systems. Vor allem bei der Kommunikation zwischen den Services sorgen beide Faktoren für Probleme.

In der Praxis lässt sich zudem ein stetiger Wandel bei den genutzten Technologien erkennen. Insbesondere große Unternehmen investieren inzwischen vermehrt in Plattformen zur Unterstützung von Microservicearchitekturen – doch das ist ein Thema für einen anderen Artikel.

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!

Apache Kafka (2021): DOCUMENTATION: Getting Started.
Chacko, Alan (2022): System Design of Spotify.
Chen, Lianping (2018): Microservices: Architecting for Continuous Delivery and DevOps. In: 2018 IEEE International Conference on Software Architecture (ICSA): IEEE.
DASA (2021): DASA DEVOPS PRINCIPLES. DevOps is about experiences, ideas and culture to create high-performing IT organizations.
Gluck, Adam (2020): Introducing Domain-Oriented Microservice Architecture. https://eng.uber.com/microservice-architecture/
Kappagantula, Sahiti (2018): Microservice Architecture — Learn, Build, and Deploy Applications. Get a better understanding of microservice architecture and, as an example of its benefits, how Uber broke down their monolith into microservices.
Karabey Aksakalli, Işıl; Çelik, Turgay; Can, Ahmet Burak; Teki̇nerdoğan, Bedir (2021): Deployment and communication patterns in microservice architectures: A systematic literature review. In: Journal of Systems and Software 180, S. 111014. DOI: 10.1016/j.jss.2021.111014.
Kwan, Irwin; Cataldo, Marcelo; Damian, Daniela (2012): Conway’s Law Revisited: The Evidence for a Task-Based Perspective. In: IEEE Softw. 29 (1), S. 90–93. DOI: 10.1109/ms.2012.3.
Lauer, Georg; Augsten, Stephan (2018): Microservices – Ein Einstieg in die Praxis.
Low, Jin (2021): Uber System Architecture
Namiot Dmitry; Sneps-Sneppe Manfred; Dmitry, Namiot; Manfred, Sneps-Sneppe (2014): On micro-services architecture. In: International Journal of Open Information Technologies 2 (9), S. 24–27.
Pfläging, Niels (2014): Organize for complexity.
Richardson, Chris (2021): What are microservices?
Shivang (2019): An Insight Into How Uber Scaled From A Monolith To A Microservice Architecture.
Shore, James (2021): The art of agile development. Unter Mitarbeit von Diana Larsen, Gitte Klitgaard und Shane Warden. Second edition. Beijing, Boston, Farnham, Sebastopol, Tokyo: O’Reilly.
Thorpe, Stefan (2018): Top Tools for Building Microservices on All Levels. These tools come together to help you orchestrate your microservices’ messaging, testing, monitoring, and more.
Tozzi, Chrsitopher (2022): How to Construct the Ideal DevOps Team Structure.
Upadhyay, Anu (2021): System Design Netflix – A Complete Architecture.

Dieser Beitrag ist ein gemeinsames Werk von Dierk Söllner und Adrian Schaub.

Dierk Söllner hat im t2informatik Blog weitere Beiträge veröffentlicht, u. a.:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.