Microservices: Wann lohnt sich der Umstieg für Unternehmen?

Netflix, Ebay und Spotify setzen sie ein, doch auch kleine und mittlere Unternehmen entdecken immer häufiger das Potenzial von Microservices. Denn in jeder Branche zieht das Innovationstempo an. Unternehmen müssen interne Prozesse und digitale Angebote immer häufiger und schneller anpassen, um wettbewerbsfähig zu bleiben. Und mit einer Microservices-Architektur gelingt das meist deutlich leichter als mit einer klassisch monolithischen IT-Infrastruktur.

Wir erklären, was sich hinter dem Konzept verbirgt, welche Vor- und Nachteile Unternehmen kennen sollten und welche Themen Sie bei einer Entscheidung für oder gegen Microservices durchdenken sollten.

Microservices sind kleine eigenständige Softwareelemente, die einzelne Funktionen einer Anwendung abbilden – entsprechend dem Unix-Grundsatz „Do one thing and do it well“. Komplexe Unternehmensanwendungen entstehen über die Kombination verschiedener Microservices, indem die Dienste über Schnittstellen miteinander verbunden werden.

Ein Beispiel: Bei einem Online-Shop könnten der Warenkorb, das Bestellformular und die Kundenkontoverwaltung über einzelne Microservices bereitgestellt werden, statt in einer umfassenden Anwendung programmiert zu werden.

Die verschiedenen Microservices werden meist von unterschiedlichen Entwicklerteams betreut, die die Dienste unabhängig voneinander weiterentwickeln, aktualisieren und bei Bedarf skalieren.

Was sind Microservice-Architekturen?

Als Mircoservice-Architekturen bezeichnet man den organisatorischen Ansatz eines Unternehmens, seine komplexen Anwendungen über einzelne, in sich unabhängige Microservices abzubilden. Im Gegensatz dazu stehen monolithische Software-Architekturen, die sämtliche Funktionen in einer einzigen Anwendung bzw. Datei abbilden.

Entwickler können sich unterschiedlicher Microservice Design Patterns bzw. Microservices Patterns bedienen. Entsprechend der Use Cases gehören zu den fünf wichtigsten:

1. Database Patterns
2. Observability Pattern
3. Decomposition Pattern
4. Cross-Cutting Concern Patterns
5. Integration Patterns

Diese Best Practices vereinfachen die Umsetzung von Funktion und haben sich für die jeweiligen Use Cases bewährt.

Für Unternehmen, die ihre Anwendungen schnell erweitern und verändern möchten, stellen Microservice-Architekturen meist eine attraktive Lösung dar, allerdings gehen mit ihnen auch Herausforderungen einher.

Warum Microservices? Die Vorteile

Flexible Skalierbarkeit: Da sich Microservices einzeln skalieren lassen, können Entwicklerteams die Bedarfe nach IT-Ressourcen nicht nur schneller erfüllen, Unternehmen sparen auch Kosten. Zudem können sie genauer nachhalten, welche Funktion welche Kosten verursacht und steuernd eingreifen.

Kürzere Time to Market: Die Entwicklerteams von Microservices sind klein und arbeiten weitgehend autonom. Damit sinkt der Overhead und Projekte können deutlich schneller als in klassischen Strukturen vorangetrieben werden. Dass die Teams parallel an einer Anwendung arbeiten können, beschleunigt die Time to Market zusätzlich. Für Anwender heißt das: Sie profitieren schneller als bisher von Funktionsverbesserungen.

Einfaches Deployment: Bei monolithischen Anwendungen muss das gesamte System deployed werden, auch wenn nur kleine Änderungen vorgenommen wurden. Bei Microservices können neue Funktionen einzeln deployed werden, in Kombination mit CI/CD-Pipelines lassen sich Änderungen ebenso schnell zurücknehmen.

Technologische Offenheit: Microservices können in unterschiedlichen Programmiersprachen entwickelt werden und dennoch problemlos über Schnittstellen miteinander kommunizieren. Das erleichtert Entwicklern die Arbeit, da sie ihre bevorzugten Sprachen einsetzen können.

Höhere Resilienz: Da Microservices unabhängig voneinander funktionieren, führen Probleme in einem Anwendungsbereich in der Microservices-Architektur nicht direkt zum Ausfall der gesamten Applikation. Unternehmen erreichen auf diese Weise eine höhere Systemverlässlichkeit und minimieren das Risiko von IT-bedingten Betriebsunterbrechungen.

Microservices: Die Nachteile der modularen Architektur

Höhere Kommunikationsanforderungen: Mit dem Wechsel zu Microservices verändert sich auch die Arbeitsweise, hin zu mehr Agilität und Integration. Damit die Entwicklung die erhofften Vorteile bringt, müssen die einzelnen Teams intensiver als bisher miteinander kommunizieren und sich abstimmen – für manche Entwickler anfänglich eine Umstellung.

Höhere technische Komplexität: Die Administration von Microservice-Architekturen wird mit steigender Anzahl der Dienste immer anspruchsvoller. Das System sollte zentral überwacht werden, um Fehler schnell zu identifizieren. Auch Protokollierung, Testing und Versionierungen sollten Administratoren anpassen.

Höhere Anforderungen an Plattformmanagement: Da die einzelnen Microservices in unterschiedlichen Programmiersprachen entwickelt werden können, steigt die Bedeutung der Dokumentation, damit Know-how personenunabhängig zur Verfügung steht. Entwickler sprechen nicht mehr zwingend dieselbe Sprache, ein flexibles Einspringen wird schwieriger.

Microservices vs. Monolith

Microservices und Monolith sind zwei entgegengesetzte Philosophien in der Software-Architektur. Hier noch einmal wesentliche Unterschiede:

Microservices-Architektur:

• Unabhängige Dienste werden verbunden und stellen die Funktionen einer Anwendung bereit.
• Ausfälle eines Microservices beeinträchtigen die anderen Funktionen nicht
• Microservices können in unterschiedlichen Programmiersprachen entwickelt werden
• Funktionsänderungen können einzelnen deployed werden
• Code bleibt unabhängig von der Größe der Gesamtanwendung übersichtlich, da modular organisiert

Monolitische Architektur:

• Eine Anwendung wird auf einer Datenbank angelegt
• Ausfälle in einer Funktion sorgen für den Komplettausfall einer Anwendung
• Alle Funktionen sind in einer Sprache geschrieben
• Änderungen an einer Funktion machen das Deployment einer neuen Anwendungsversion nötig
• Übersichtlichkeit der Codebasis leidet mit zunehmender Anwendungsgröße, da in einer Datei geschrieben

Microservices-Architekturen ziehen eine Reihe von technologischen, aber vor allem prozessualen Veränderungen nach sich. Die Entscheidung, Microservices einzuführen, will daher gut überlegt sein. Im Laufe der Jahre haben sich in unseren Kundenprojekten einige zentrale Themenfelder herauskristallisiert, mit denen sich Unternehmen vor einer Entscheidung für Microservices beschäftigen sollten.

Je nachdem, welche Ziele und Voraussetzungen Sie mitbringen, welche Investitions- und Lernbereitschaft im Unternehmen vorherrschen, kann ein Wechsel zu Microservices mehr oder weniger erfolgsversprechend sein. Werfen wir einen Blick auf die relevanten Fragen:

1. Funktionen technisch und fachlich abgrenzbar?

Microservices bieten sich für inhaltlich und technisch klar voneinander getrennte Anwendungskomponenten an. Ein Beispiel: Online-Shops. Hier ist der Produktkatalog eindeutig inhaltlich und technisch von Bezahlvorgang und Kundenkonto getrennt, obwohl dem Nutzer alle Funktionen im Rahmen des Website-Aufrufs dargestellt werden. Sobald zwischen Software-Komponenten eine enge technische Kopplung besteht, ist eine Umsetzung über Microservices zwar nicht ausgeschlossen, aber doch schwieriger zu realisieren.

2. Ausreichend großer Anwendungsumfang?

Zunächst bedeuten Microservices eine Investition: Denn bevor sich die Entwicklungszeiten verkürzen, verlängern sie sich zunächst meist. Entwickler müssen sich mit neuen Abläufen und Strukturen vertraut machen und Fachbereiche sich an die neue Art der Zusammenarbeit mit Development Teams gewöhnen. Der Architekturwechsel lohnt sich daher vor allem für größere Entwicklungen.

Für eine Unternehmenswebsite, die als Visitenkarte dient und ohne Shop oder umfassende Kontaktformulare auskommt, sind Microservices eher überdimensioniert. Wenn das Unternehmen aber überlegt, die Kontaktformulare auszuweiten oder zukünftig an andere Systeme anzubinden, kann eine solche Erweiterung und Optimierung über Microservices leichter erfolgen.

Tipp: Sie müssen eine Entscheidung für oder gegen Microservices nicht bei Einführung einer neuen Anwendung final treffen. Es ist immer möglich, auch Produktivanwendungen oder Legacy-Systeme in eine Microservice-Architektur zu überführen.

3. Mehrfachnutzung?

Wenn Sie Komponenten nur für eine einzige Anwendung benötigen, können Microservices das spätere Debugging und die Weiterentwicklung vereinfachen. Der Effizienzvorteil wird aber größer, wenn mehrere Systeme auf dieselben Funktionsbausteine zugreifen. Statt die Komponenten doppelt zu implementieren, können mehrere Anwendungen über Schnittstellen auf zentrale Microservices zugreifen.

Entwicklerteams von Unternehmensgruppen können dann wiederverwendbare Softwarekomponenten über eine gemeinsame Plattform beziehen, Betreiber mehrerer Online-Shops ihren Versand vollständig über eine gemeinsame Plattform abwickeln und Authentifizierungen können wesentlich schneller realisiert werden, wenn ein zentraler Service für verschiedene Unternehmensanwendungen greift.

4. Skills zu Domain Driven Design, Moderation und Kommunikation vorhanden?

Sollen Microservices die Time-to-Market senken, muss sich auch das Mindset der Mitarbeiter verändern. Fachbereich und IT arbeiten wesentlich enger als früher zusammen. Statt Anforderungen durchzugeben und auf das Ergebnis zu warten, findet das Development iterativ und in enger Abstimmung mit dem Fachbereich statt. Es braucht neue Prozesse und Routinen – und ein strategisches Change Management. Je komplexer die Microservices-Architektur, desto anspruchsvoller ist es, Projektmanagement und Kommunikation zwischen den beteiligten Akteuren im Unternehmen erfolgreich zu meister.

Gibt es Mitarbeiter, die Erfahrungen als Scrum-Moderatoren haben oder sind Teams agile Arbeitsweisen aus anderen Kontexten bekannt? Dann wird die Lernkurve deutlich steiler ausfallen und werden positive Effekte der Umstellung schneller sichtbar.

5. Motivation der Fachbereiche?

Weil es zentral ist, wollen wir es an dieser Stelle noch einmal betonen: Die veränderte Software-Architektur allein garantiert keine wirtschaftlichen Vorteile, keine schnelleren Releasezyklen und kein höheres Innovationstempo. Diese Effekte treten nur ein, wenn die Verantwortlichen in den Fachbereichen sich aktiv in die Arbeit an der Software einbringen, wenn sie motiviert sind für gemeinsame Abstimmungen mit den Entwicklern, wenn sie Bugs zeitnah melden, Verbesserungsbedarfe und Ideen teilen und Tests übernehmen.

Für Unternehmen, die bisher in klassischen Silos gearbeitet haben und in denen Mitarbeiter über Jahre und Jahrzehnte hierarchische Strukturen gewohnt ware, ist das ein radikales Umdenken. Wie offen und veränderungsbereit sind Ihre Teams? Welche Erfahrungen konnten Sie in anderen Projekten sammeln? Überwiegen die Skeptiker und Unwilligen, wird es schwer Mehrwerte aus Microservices zu generieren.

6. Bereitschaft, Verantwortung abzugeben?

Trotz ihrer sprachlichen Verwandtschaft: Microservices und Micromanagement gehen nicht zusammen. Wer sich entscheidet, komplexe Plattformen zu splitten und Entwicklungen auf mehrere Teams zu verteilen, die Bug Fixes und Upgrades unabhängig voneinander erarbeiten, kann die Unternehmens-IT nicht mehr nach globalen Top-down-Anweisungen organisieren.

Vorgaben zu Entwicklungs- und Technologiestandards sind zwar notwendig und wichtig, aber sie sollten nicht als Gesetze, sondern als Richtlinien kommuniziert werden. Dieses Vorgehen erfordert Vertrauen in die Mitarbeiter und den verantwortungsvollen Umgang mit den neuen Freiheiten. Doch dieser lohnt sich: Denn Teams erhalten so die Möglichkeit, auf Technologien zurückzugreifen, mit denen sie Routine haben, kreative Workarounds zu schaffen und auch neue Tools und Programmiersprachen finden mit diesem flexiblen Ansatz leichter in die Produktivsysteme.

7. Standards für Querschnittsaspekte vorhanden?

Um die Geschwindigkeitsvorteile von Microservices zu realisieren, müssen sich Unternehmen Zeit für die Grundlagenarbeit nehmen. Denn trotz der erwähnten Freiheit der einzelnen Entwicklerteams braucht es gemeinsame Standards. Das gilt auf technologischer Ebene insbesondere für Querschnittsaufgaben wie Authentifizierung und Logging.

Es schafft unnötig technische Komplexität, wenn jede Anwendung mit anderen Frameworks und Sprachen arbeitet. Unter diesem Wildwuchs leiden Skalierbarkeit und Wartbarkeit und auch die Usability profitiert nicht. Standards schaffen dagegen Klarheit und tragen zur Sicherheit bei.

8. Erfahrung mit Infrastructure as Code und CI/CD?

Software ist heute in den meisten Fällen ein Prozess und kein Produkt. Das Tempo des technologischen Fortschritts ist hoch, die Erwartungen der Kunden verändern sich rasant. An Anwendungen wird daher kontinuierlich gearbeitet. Mit den Konzepten von Infrastructure as Code und CI/CD lassen sich Feature Updates kurzfristig umsetzen und die Bereitstellungszeit stark verkürzen.

Wenn Ihre Teams bereits mit dem CI/CD-Konzept vertraut sind oder mit CI/CD-Pipelines gearbeitet haben, ist das ein großer Vorteil in der Einführung von Microservices. Produktivitätseinbußen durch die Transformation fallen dann wesentlich geringer aus.

9. Aktuelles Skillset im Development Team?

Es ist das Hauptargument für Microservices: Neueste Technologien lassen sich besonders schnell in Anwendungen integrieren. Das setzt allerdings voraus, dass Entwickler das nötige Skillset beherrschen. Wenn sie noch keine oder wenig Erfahrung mit Design Patterns, modernen Webstandards und Tools wie Swagger gemacht haben, müssen sich Unternehmen auf einen längeren Lernweg einstellen, bis sie die Früchte ihrer Microservices-Transformation ernten. Gleiches gilt auch für die Unternehmenskultur und die Prozessorganisation. Vorerfahrung senkt die Kosten.

Schulungen und Trainings können die Teams zwar bei den Veränderungen unterstützen. Um schneller einen Return on Invest zu sehen, bietet es sich für Unternehmen mit niedrigem Wissensstand aber an, Teilentwicklungen – zumindest vorübergehend – auszulagern.

Sie sehen, mit drei einfachen Fragen können Sie nicht erkennen, ob Microservices einen Mehrwert für Ihren Anwendungsfall liefern. Denn selbst wenn Sie in vielen Aspekten noch keine optimalen Bedingungen vorfinden, ist das kein Ausschlusskriterium. Es bedeutet einfach, dass Sie eine längere Phase für den internen Knowhow-Aufbau einplanen müssen oder zunächst mit Mehrkosten für externe Dienstleister kalkulieren müssen.

Hier die Zusammenfassung der wichtigsten Entscheidungsfaktoren als Checkliste:

Microservices-Architekturen werden oft als neueste und bessere Software-Architektur beschrieben. Wie unsere Entscheidungsmatrix aber zeigt, bergen sie eine Vielzahl eigener Herausforderungen. Sie sind längst nicht für jeden Use Case und jedes Unternehmen die optimale Wahl. Gerade bei kleinen Entwicklerteams und überschaubarer IT-Infrastruktur schaffen Microservices oft mehr Probleme als Nutzen.

Wenn Unternehmen über Microservices nachdenken, raten wir deshalb auch von einer Schwarz-weiß-Perspektive ab: Nicht jede Anwendung muss modular aufgebaut werden und selbst wenn dies das langfristige Ziel ist, können Microservices zunächst in einem Unternehmensbereich eingeführt und kann ihr Einsatz sukzessive ausgeweitet werden. So sammeln Teams praktische Erfahrungen und können prüfen, ob das Modell für sie funktioniert, ehe bewährte Prozesse in der Breite eingedampft und nach kurzer Zeit wieder zusammengeflickt werden müssen. Denkbar sind auch dauerhafte Mischformen wie serviceorientierte Architekturen.

Was jedoch feststeht: Unsere Welt wird immer vernetzter und Märkte verändern sich immer schneller. Es ist nur folgerichtig, dass sich diese Rahmenbedingungen auch im Software Development widerspiegeln. Microservices beschleunigen mit ihrer agilen, vernetzten Arbeitsweise die Weiterentwicklung digitaler Produkte. Für Unternehmen sind sie damit eine interessante Option, um mit dem Tempo des Marktes Schritt zu halten, wettbewerbsfähig zu bleiben und innovativer zu werden.