Microservices als Teil der Digitalisierungsstrategie

15. August 2017

Die digitale Transformation stellt Unternehmen vor viele Herausforderungen. Zentrales Augenmerk liegt unter anderem auf Time to Market und Effizienzsteigerung. Lösungen sollen schneller am Markt sowie im Unternehmen platziert und Wettbewerbsvorteile für das Unternehmen gesichert werden. Gleichzeitig taucht in diesem Kontext das Stichwort “Microservices” immer häufiger auf. Was genau verbirgt sich dahinter und wie kann man Microservices erfolgreich als Baustein einer Digitalisierungsstrategie nutzen?

Dieser Beitrag ist der Auftakt einer Artikelserie zum Thema „Microservices“:

  1. Microservices als Teil der Digitalisierungsstrategie
  2. Microservices fachlich adäquat schneiden
  3. Geschäftsprozesse mit Microservices abbilden
  4. Time to Market mit Microservices DevOps reduzieren

Digitalisierung

Digitalisierung ist ein vielschichtiges und je nach Unternehmen individuelles Thema. Im Zentrum steht aber das Ziel, die Time to Market für Lösungen oder Produkte signifikant zu reduzieren, um sich dadurch Wettbewerbsvorteile am Markt zu verschaffen. Ein weiterer Aspekt ist die Steigerung der Effizienz von Geschäftsprozessen. Dies gilt für die Weiterentwicklung bestehender Lösungen genauso wie für neue, innovative Lösungen, die auf Basis von permanentem Input durch Kunden und Mitarbeiter entwickelt werden. Im Kontext dieses Beitrags beschränken wir uns auf digitale Lösungen. Das sind Anwendungen, die digitale Technologie gewinnbringend zum Zwecke der Marktdifferenzierung außerhalb und Effizienzsteigerung innerhalb des Unternehmens einsetzen. Zu den Zielen der Digitalisierungsstrategie im Unternehmen siehe auch die unten stehende Grafik.

Microservices als Teil der Digitalisierungsstrategie

Microservices

Um zu verstehen, wie Microservices den Prozess der Digitalisierung im Unternehmen unterstützten können, muss man diese zunächst grob erklären. Microservices werden oft nur auf technischer Ebene betrachtet. In Wahrheit sind diese fachlich getrieben; die Technik steht an zweiter Stelle.

Ein Microservice ist demnach, grob gesprochen, die Abbildung einer klar abgegrenzten Fachlichkeit innerhalb eines autonom entwickelten und betriebenen Softwarebausteins, der nach außen eine API für leichtgewichtige Kommunikationszwecke bereitstellt. Das bedeutet, dass der Fokus auf dem durch den Service bereitgestellten Business Value liegt, denn damit verdient das Unternehmen sein Geld. Wie der Service technisch umgesetzt ist, folgt einer geringen Anzahl allgemeiner Regeln, die seine Entkopplung von anderen Services (und damit anderer fachlicher Zusammenhänge) sicherstellen sollen:

  1. Ein Microservice ist autonom, d. h. unabhängig von anderen Services änderbar, wartbar, deploybar und skalierbar.
  2. Die Kommunikation mit Microservices erfolgt über klar definierte, technologieunabhängige APIs (in der Regel REST).
  3. Microservices folgen dem “Share Nothing”-Prinzip. Das heißt, dass jeder Microservice exklusive Hoheit über die von ihm verwendeten Daten hat. Auch die Fachlogik (Code) sollte nicht mit anderen Services (z. B. über gemeinsame Libraries) geteilt werden.

Der Microservices-Ansatz steht im Kontrast zum monolithischen Ansatz, der traditionell in der Softwareentwicklung eingesetzt wird. Monolithen vereinen oft mehrere fachlich in sich geschlossene Blöcke unter einem Dach. Individuelle Änderbarkeit, Wartbarkeit und Deployment einzelner Fachfunktionen ist hierbei nicht gegeben. Die aus technologischer Sicht geringere Komplexität von Monolithen steht dabei einer ungleich höheren fachlichen Komplexität gegenüber.

Chancen nutzen

Warum sind Automonie, Entkopplung und fachlich sinnvolle Trennung wichtig? Wie unterstützen sie mein Unternehmen bei der Umsetzung von Digitalisierungsstrategien? Die Antwort ist vielschichtig.

Neue Features

Durch intelligenten fachlichen Schnitt, der damit einhergehenden geringen Größe und der Entkopplung von anderen Services lassen sich fachliche Anforderungen einfacher und schneller umsetzen als in einem großen, monolithischen System. Gleiches gilt auch für die spätere Produktivnahme (Deployment). Das reduziert nicht nur die Einstiegshürde für alle Beteiligten, sondern minimiert auch das Gesamtrisiko und die Time to Market. Gleichzeitig kann die Effizienz insgesamt gesteigert werden. Da jeder Microservice autonom entwickelt wird und keine Implementierungsdetails nach außen preisgibt, können je nach Anwendungsfall unterschiedliche Technologien zum Einsatz kommen.

Wartbarkeit

Fakt ist: Wer schon mit monolithischen Systemen gearbeitet hat, weiß, wie schwierig und langwierig es ist, diese zu ändern. Dies fängt bei unerwünschten Seiteneffekten an, geht über den erforderlichen Akzeptanztest der Anwendung als Ganzes und endet schließlich bei der Produktivnahme im Block. Hierbei sind organisatorische Prozesshürden noch gar nicht mitgerechnet.

Beim Microservices-Ansatz muss nur der Service geändert werden, den eine fachliche Änderung tatsächlich betrifft. Nur dieser Service muss später auch neu ausgerollt werden, ohne das Gesamtsystem zu beeinflussen. Dies reduziert auch das Risiko, das mit der Änderung einhergeht. Kommt es regelmäßig vor, dass fachliche Änderungen mehrere Microservices betreffen, sollte man über den fachlichen Schnitt nachdenken.

Innovation

Microservices unterstützen den Innovationsprozess sowohl fachlich als auch technisch. Durch die Aufteilung in fachlich abgegrenzte Blöcke entscheidet jeder Microservice zu einem guten Stück individuell über die spätere User Experience des Endanwenders. Neue, innovative Ideen können leichter und schneller umgesetzt werden. Hierdurch entsteht Marktdifferenzierung.

Gleiches gilt auch für technische Innovation. Neue Technologien und Frameworks können eingesetzt werden, ohne ständig das Gesamtsystem im Auge behalten zu müssen. Und noch besser: eine Technologieauswahl kann man je nach Fachlichkeit so treffen, dass sie dessen technische Implementierung optimal unterstützt. Hat man sich vertan, so ist die Entscheidung für ein “Refactoring” leichter getroffen als wenn man die möglichen Auswirkungen auf andere fachliche Blöcke zusätzlich beachten müsste.

Skalierbarkeit

In einer Welt, in der Kunden und Mitarbeiter auf immer neue Arten und auf verschiedenen Kanälen mit Teilen einer Anwendung interagieren, ist es nicht immer einfach, Konsequenzen für deren Verfügbarkeit und der damit verbundenen User Experience vorauszusehen. Man möchte die Möglichkeit haben, individuell auf ein sich änderndes Nutzungsverhalten reagieren zu können. Steigt die Last auf einem Service, da dessen Fachlichkeit vermehrt genutzt wird, möchte man diesen einen Service mehrfach redundant vorhalten und die Last gleichmäßig auf seine Instanzen verteilen können. Der Rest des Systems arbeitet normal weiter.

Fehlerisolation und Failover

Wenn es mal hart auf hart kommt, will man die potentiellen oder tatsächlichen Auswirkungen eines Fehlers auf das Gesamtsystem (und damit das Business) minimieren. Stichwort: “Graceful Degradation of Service”. Je autonomer ein Service gebaut ist, desto einfacher ist es, diesen mehrfach redundant vorzuhalten und im Fehlerfall auf eine Standby-Instanz umzuschalten. In der Zwischenzeit bleibt das Gesamtsystem verfügbar. Natürlich hilft Autonomie alleine nicht weiter. Aber in Kombination mit anderen Maßnahmen (z. B. Resilient Design) ist dies die Voraussetzung, um ein Höchstmaß an Verfügbarkeit zu gewährleisten. Das freut insbesondere die Benutzer des Systems, denn sie können (ggf. mit geringen Einschränkungen) weiterarbeiten. Auch das ist ein marktdifferenzierendes Merkmal und reduziert den potentiellen finanziellen Verlust im Fehlerfall!

Automatisierung

Je kleiner ein einzelnes Softwarepaket, desto einfacher ist es, dessen Deploymentprozess im Rahmen von Continuous Delivery zu automatisieren. Größe bezieht sich hier sowohl auf technische als auch auf fachliche Komplexität. Je abgegrenzter die Fachlichkeit, desto wahrscheinlicher ist es, dass man sogar Akzeptanztests automatisieren kann. Meine Erfahrung aus unzähligen Projekten: Manuelle Fachtests sind der Flaschenhals im Softwareproduktionsprozess. Automatisierung ist also ein weiterer Beitrag zur Reduzierung der Time to Market. Behaviour-Driven Testing Frameworks können dabei gute Dienste leisten.

Teams

Die Idee beim Microservices-Ansatz ist, dass ein Team bestehend aus Fachexperten, Entwicklern und Betrieb die fachliche und technische Gesamtverantwortung für einen Microservice übernimmt. Das Team ist, genau wie der Microservice selbst, weitgehend autonom. Das stärkt das Team Commitment, fördert die Motivation und baut Prozesshürden sowie Silodenken ab. Das gilt übrigens idealerweise auch für den Betrieb des Microservices: You build it, you run it!. Voraussetzung für all das ist, dass dem Team (in bestimmten Grenzen) Möglichkeiten und Befugnisse übertragen werden, die für die Übernahme der Gesamtverantwortung benötigt werden. Microservice-übergreifende Konzepte und Themen lassen sich über ein Macro-Architekturteam regeln.

Organisational Change

Neben autonomen und selbst-organisierenden Teams kann der Microservices-Ansatz auch Änderungsprozesse hin zu agilen Management- und Entwicklungsmethoden (Management 3.0, Scrum, etc.) unterstützen, die häufig im Kontext von Digitalisierungsstrategien vollzogen werden. Ziel hierbei ist, eine Kultur (Mindset) zu schaffen, die es dem Unternehmen ermöglicht, sich schneller an veränderte Marktbedingungen anzupassen.

Herausforderungen meistern

There is no free lunch! Microservices führen zu verteilten Systemen. Damit geht eine entsprechende technologische Komplexität einher, die bei der Anwendung dieses Architekturansatzes berücksichtigt werden muss. Dabei helfen Techniken, Tools, Patterns und Practices, denen ich mich jeweils in entsprechenden Folgebeiträgen widmen werde. Nicht zu verschweigen sind auch methodische Herausforderungen. Wie schneide ich meine Services fachlich “richtig”? Auch darauf werde ich eingehen.

Fazit

Microservices können ein möglicher Baustein bei der Umsetzung einer Digitalisierungsstrategie im Unternehmen sein. Zentraler Vorteil des Microservices-Ansatz ist seine Fokussierung auf fachliche Zusammenhänge mit dem Ziel, Business Value im Kontext der digitalen Wertschöpfungskette zu schaffen. Die Autonomie jedes einzelnen Microservice in Bezug auf Änderbarkeit, Skalierbarkeit und Deployment hilft, flexibel auf eine sich verändernde Umwelt zu reagieren, neue Technologien früh zu adaptieren und damit die Wettbewerbsfähigkeit des Unternehmens zu erhöhen. Fehler können isoliert werden; das reduziert das unternehmerische Risiko. Automatisiertes Continuous Delivery von kleinen, autonomen Einheiten erhöht zusätzlich die Time to Market. Die Aufstellung von autonomen Teams, die jeweils die Gesamtverantwortung für einen Microservice übernehmen, schafft Agilität und Entfaltungsmöglichkeiten.

Beim Einsatz von Microservices muss man die technische Komplexität verteilter Systeme beachten. Eine Vielzahl von Techniken hilft, diese zu beherrschen. Überlegt und schrittweise eingeführt überwiegen die Vorteile, gerade im Hinblick auf die Herausforderungen der Digitalisierung.