Wie Microservices mehr Innovationsfähigkeit in Digitalunternehmen bringen

Die technologische Entwicklung schreitet inzwischen so schnell voran, dass selbst die nicht mehr mitkommen, die sie eigentlich vorantreiben sollten: Die Software-Entwickler selbst und die von Ihnen abhängigen Interaktiv-Unternehmen mit digitalem Geschäftsmodell.

Agile Software-Entwicklung, Scrum und Kanban helfen das Problem zu lösen: Große Projekte werden in Teilfunktionen zerlegt, die sich in übersichtlichen Zeiträumen ("Sprints") erledigen lassen. So sind Erfolge schnell sicht- und prüfbar, Probleme zeigen sich frühzeitig. Zudem lassen sich Projekte noch während der Entwicklung an neue Anforderungen anpassen, um zu verhindern, dass der Anforderungskatalog zu Projektbeginn eingefroren werden muss und bei Projektende die Software bereits veraltet ist.

So wirksam der Ansatz in der Praxis ist, so kurz greift er architektonisch. Er modernisiert zwar das Projektmanagement, lässt das Softwarefundament jedoch unangetastet. Seit Jahren hat sich dort wenig getan. Zwar wurden zahlreiche neue Programmiersprachen, Frameworks und APIs eingeführt. Im Wesentlichen werden aber immer noch monolithische Software-Anwendungen erstellt - die sich inzwischen zu einem gewaltigen Bremsklotz entwickeln.

Microservice statt Monolith

Das Problem monolithischer Software ist Entwicklern seit Jahren so bekannt wie verhasst: Bei Projektstart werden einmalig Programmiersprache, Framework und grundlegende Architektur festgelegt. Das Projekt startet übersichtlich, ist leicht zu verstehen und einfach zu erweitern. Mit der Zeit wuchert es jedoch. Es werden neue Schichten, Abstraktionen, Module, Services und Schnittstellen eingeführt. Die ursprüngliche Architektur ist kaum noch zu erkennen, den geänderten Anforderungen aber sowieso nur noch schlecht gewachsen. Und zu allem Überfluss erweist sich selbst die gewählte Programmiersprache irgendwann als nicht mehr zeitgemäß.

Im Laufe nur weniger Jahre entsteht so eine typische Legacy-Software, die von der folgenden Entwicklergeneration verflucht wird. Aber schlimmer noch: Sie bremst auch den gesamten Betrieb:

• Neue Entwickler brauchen lange Anlernzeiten, um den unübersichtlichen Code und die gewachsenen Abhängigkeiten zu verstehen.
  
• Große Teams müssen geführt werden. Dies führt zu einem hohen, oft ineffizienten und fehlerbehafteten Abstimmungsbedarf.
  
• Die Software ist schwerfällig und kann kaum skalieren. Oft liegt die einzige Lösung zur Performance-Steigerung darin, die Anwendung mehrfach zu klonen und die Last auf mehrere Server zu verteilen (Load-Balancing).
  
• Die Wartbarkeit des Systems leidet, da sich ein Update immer auf die komplette Anwendung bezieht.
  
• Wartungsarbeiten sind häufig mit Ausfallzeiten verbunden.

Es liegt auf der Hand, dass diese Nachteile umso spürbarer werden, je dynamischer sich die umgebende technologische Landschaft
entwickelt, je häufiger Anpassungsarbeiten notwendig werden und je tiefgreifender die Änderungen sind.

Im derzeitigen digitalen Transformationsprozess ist der Innovationsdruck besonders hoch. Mit Smartphones, Internet-der-Dinge und Industrie 4.0 ändern sich sowohl die Zugangswege der Kunden als auch die Art der Geschäftsvorfälle. Schnelle und flexible Reaktionen sind notwendig - der Monolith entwickelt sich in einer solchen Umgebung vom lästigen Bremsklotz zur akuten Gefahr.

Nächste Ausfahrt: Microservice?

Derzeit wird unter dem Namen Microservices ein Konzept populär, das mit allen genannten Nachteilen radikal aufräumen kann. Es handelt sich dabei um die komplette Zerlegung einer (serverbasierten) Anwendung in ihre einzelnen Funktionen. Jedes Feature (etwa: Suche, Warenkorb, Navigation etc.) wird dabei als eigene Anwendung konzipiert, die über APIs (in der Regel RESTfull) kommunizieren. Ein typischer Microservice ist dabei so klein und übersichtlich, dass er von einem überschaubaren Team (etwa fünf bis sechs Entwickler) und in einem kurzen Zeitraum (etwa einem Monat) komplett neu entwickelt werden kann.

Auf diese Weise bleibt die Einarbeitungszeit extrem kurz, der zu bearbeitende Code ist immer übersichtlich. Es gibt keine versteckten Abhängigkeiten und keinen Code-Wildwuchs in ungepflegten Bibliotheken. Dadurch sinkt der Kommunikationsaufwand im Team enorm, die Entwicklungszeiten sind extrem kurz und das Testing deutlich vereinfacht. Die Eigenständigkeit und Unabhängigkeit der einzelnen Microservices ist so hoch, dass sogar problemlos die Programmiersprache gewechselt werden kann.

Aber das ist noch nicht alles. Weitere Vorzüge sind:

• Microservices benötigen aufgrund ihrer geringen Größe keine schwergewichtigen Frameworks.
  
• Sie lassen sich völlig unabhängig voneinander entwickeln, testen und live schalten. Dadurch wird Continuous Delivery möglich.
  
• Die Architektur unterstützt die Arbeit in unabhängigen Teams, die sich flexibel auslagern lassen.
  
• Der geringe Entwicklungsaufwand erleichtert Experimente - sei es eine neue Sprache, ein neues Framework oder eine neue Funktion.
  
• Unbrauchbare Lösungen lassen sich jederzeit mit vertretbarem Aufwand durch eine Neuentwicklung ablösen, ohne dass der Betrieb leidet.
  
• Die Skalierbarkeit des Gesamtsystems gewinnt deutlich, da sich jeder Service unabhängig von anderen Services skalieren lässt.
  
• Die grundlegende Architektur der Software kann nicht durch Nachlässigkeiten und Work-Arounds leiden, da sie durch die APIs definiert ist.
  
• Microservices kommen der agilen Entwicklung entgegen. Überschaubare Teams, überschaubare Aufgaben und überschaubarer Aufwand minimieren Reibungsverluste.

Selbstverständlich gibt es auch einige Nachteile und Einschränkungen. So erhöht die verteilte Architektur die Komplexität im Netzwerk, an das zusätzliche Anforderungen gestellt werden (Latenzen, Fehlertoleranz, Lastverteilung). Manch eine versteckte Abhängigkeit wird nicht aufgehoben, sondern verlagert sich lediglich in die Netzwerk-Ebene. Dadurch werden doch wieder abschließende Ende-zu-Ende-Tests nötig und es bedarf einer nicht nicht immer ganz trivialen Versions-Verwaltung der Einzelmodule. Außerdem muss gut überlegt werden, auf welche Daten zentral zugegriffen werden muss (was das Konzept der eigenständigen Microservices aufweicht) und welche repliziert werden können.

Hoher strategischer Nutzen

Auch wenn das Microservice-Konzept nicht frei von Nachteilen ist und in der Praxis einige Einschränkung erfährt, zeigt sich doch, dass schon aus Entwicklersicht die Vorzüge überwiegen. Das Unternehmen wird insgesamt schneller, die Software flexibler und anpassungsfähiger. Dies ist schon für sich genommen ein strategischer Vorteil.

Noch gewichtiger wird dieser strategische Aspekt aber durch den technologischen Wandel, der sich ringsherum vollzieht. Immer mehr Geräte werden mit dem Internet vernetzt. All diese Geräte - und die damit verbundene Vielfalt an Apps - müssen auf Services zugreifen. Aber nicht nur Geräte, auch Software-Agenten, die immer zahlreicher in Messenger, Lautsprecher und Smartphones integriert werden, benötigen einen möglichst niederschwelligen Zugang zu Services und Ressourcen, wenn sie nahtlos angebunden werden sollen.

• Distributed Computing. Eine Microservice-Architektur ermöglicht es, selbst Dienste anzubieten oder auf Drittdienstleistungen zuzugreifen. So kann etwa eine Fahrplanabfrage oder eine Recommendation-Engine per externem Microservice angeboten oder eingebunden werden, als wäre sie Bestandteil der eigenen Applikation.
  
  
• Internet der Dinge. Auf API-Ebene lassen sich Informationen aus einer Vielzahl von Quellen entnehmen. So können IoT-Geräte in die eigene Applikation eingebunden werden und eine Bestellung beispielsweise durch den Druck auf einen physischen Knopf - à la Dash Button - entgegennehmen. Sensoren aus vernetzten Maschinen, Smarthome-Geräten, Connected Cars oder Wearables können problemlos in die Applikation eingewoben werden.
  
  
• Headless-Service. Umgekehrt wird auch die Informationsbereitstellung und -aufbereitung getrennt. Ein Shopsystem kann den Lieferstatus beispielsweise über Microservice und API direkt aus seiner Datenbank an eine Smartwatch-Applikation ausliefern. So kann die Anfahrt des Lieferdienstes sogar kontinuierlich aktualisiert werden, ohne dass jedesmal ein Visit ausgelöst werden muss. Der Microservice stellt nur die Daten für das Frontend bereit, die Aufbereitung übernimmt die Applikation.
  
  
• Agenten-Schnittstelle. Auf dieselbe Weise lassen sich auch sehr leicht Schnittstellen schaffen, auf die Software-Agenten zugreifen können - sei es für eine Reiseplanung, das Kinoprogramm oder um die Bestellung einer Tintenpatrone zu platzieren. Der Austausch mittels API erfolgt dabei deutlich schneller und schlanker, als wenn ein Webinhalt geparst werden soll.
  
  
• Prozesslogik. Da mit Microservices ein Geschäftsvorgang optimalerweise ohnehin schon in seine einzelnen Prozessschritte zerlegt ist, können sehr einfach neue Geschäftsmodelle modelliert werden. Wenn ein Shopbetreiber beispielsweise ein Abo-Modell ausprobieren möchte, muss er die bestehenden Microservices nur neu gruppieren und nur sehr wenige (Aboverwaltung) neu programmieren. Auf diese Weise kann sehr flexibel auf neue Geschäftsvorfälle reagiert werden.

Die Auflistung zeigt, dass ein konsequenter Einsatz von Microservices nicht nur die Performance der Entwicklungsabteilung beschleunigt und die Time-to-Market verkürzt, sondern zusätzlich die Vernetzung von internen und externen Prozessen deutlich vereinfacht. Gerade in letzterer Eigenschaft liegt ein besonderer strategischer Vorteil. Sowohl auf der Backend- als auch auf der Frontendseite werden beide Fähigkeiten in naher Zukunft wichtiger. Im Frontend, weil die Gerätevielfalt der Kunden drastisch zunimmt. Die Fähigkeit von Microservices, Daten headless bereitzustellen, erleichtert die Integration neuer Plattformen erheblich. Auf der Backend-Seite zählen dagegen die Flexibilität bei der Verknüpfung und Umgestaltung von Anwendungen zu den großen Vorzügen.

In jedem Fall bilden Microservices jedoch auch eine neue Herausforderung für das Change-Management des Unternehmens. Denn nicht nur Entwicklungsabteilungen müssen komplett umdenken - ein Wandel in der Prozesslogik erfasst fast immer auch Teile der Unternehmensstruktur. Und das stößt fast immer auf erhebliche Widerstände.