Wenn ich mit Kollegen, Bekannten oder Kunden über Microservices spreche, kommt es nicht selten vor, dass „Tales from the trenches“ aus fehlgeschlagenen Microservices-Projekten ausgetauscht werden. Einige basieren zwar auf Hörensagen und klingen wie Mythen und Legenden, die sich gefallene Helden am Lagerfeuer erzählen. Allerdings lohnt es sich trotzdem, genau zuzuhören und unter die Oberfläche zu schauen, denn aus den gemachten Fehlern können wir meist lernen.

Kollege 1: „Wir hatten unvorhergesehene Probleme bei der Integration. Die zwischen den Services übergebenen Daten passten teilweise nicht zusammen.“

Kollege 2: „Das Gesamtsystem ist in Produktion viel langsamer geworden. Die einzelnen Module werden jetzt per HTTP aufgerufen.“

Bekannter 1: „Es gibt bei uns jetzt so viele einzelne Microservices. Das ist das absolute Chaos! Wir haben keinen Überblick mehr, wo welcher Service läuft.“

Bekannter 2: „Wir hatten unzählige Meetings, in denen wir über alle möglichen Detailentscheidungen diskutiert haben. Teilweise mit Leuten, die weder direkt beteiligt waren, noch Erfahrung in dem Bereich hatten.“

Kunde 1: „Manchmal hatte ich das Gefühl, die Leute haben Angst, Unbekanntes einfach auszuprobieren. Stattdessen wurden von möglichst vielen Leuten Meinungen eingeholt. Das hat natürlich zu endlosen Diskussionen geführt.“

Kunde 2: „Wir haben eine Architektur entworfen, aber keiner hat sich daran gehalten!“

In den allermeisten Fällen sind diese Probleme nicht technisch, sondern organisatorisch begründet. Oft liegt es daran, dass die Mitarbeiter nicht verstanden hatten, welche Ziele durch die Einführung von Microservices erreicht werden sollten. Deshalb hielten sie das Thema nur für eine weitere Sau, die durchs Dorf getrieben wird.

Gerade deshalb ist die Frage nach den Zielen aus meiner Sicht so wichtig: Warum wollen Sie Microservices einführen? Was wollen Sie dadurch erreichen? Was soll besser werden? Was soll sich verändern und warum? Wenn Sie diese Fragen für sich beantworten, verfassen Sie die Antworten so, dass sie jeder im Unternehmen versteht und sie als Leitlinien für spätere Diskussionen und Entscheidungen im Projektteam dienen können. Schauen wir uns einmal einige der Antworten an, die mir auf diese Fragen gegeben wurden.

Warum wollen Sie Microservices einführen?

Der am häufigsten genannte Grund für die Einführung von Microservices ist eine kürzere “Time to Market”. Das Unternehmen möchte neue Ideen schneller in Produktion bringen als heute. Auch dazu habe ich viele Kommentare gehört.

Warum sind die Lieferungen heute noch nicht schnell genug?

Entwickler: Der Zyklus von Idee bis Produktion dauert extrem lang – manchmal Wochen bis Monate. Da sind einmal die unzähligen Abstimmungsmeetings, bis die Konzepte fertig sind, und andererseits der lange Lieferprozess mit weiteren Meetings während der Entwicklung und mehrstufigen Abnahmeschritten.

Warum benötigen wir so viele Abstimmungsmeetings?

Entwickler: Die Meetings sind dazu da, die Idee mit dem Fachbereich zu besprechen und sie in einer Spezifikation oder einem Konzept niederschreiben zu können. Dieses Konzept muss dann anschließend auf technische Machbarkeit durch die Entwicklungsteams geprüft werden. Dieser Prozess kann mehrere Durchläufe erfordern. Durch Microservices wollen wir auch erreichen, dass wir unsere Ideen in kleinere Konzepte runterbrechen, die weniger Zeit in Erstellung und Umsetzung benötigen.

Warum dauert der Lieferprozess so lange?

Entwickler: Selbst wenn das System schon modularisiert zu sein scheint, werden immer noch Inbetriebnahmen von einzelnen fehlerhaften Modulen blockiert. Wenn bei einem der Module im Ende-zu-Ende-Test ein Fehler gefunden wird, geht keines der Module in Produktion.

Entwickler: Wir haben einen so genannten Deployment-Monolithen!

Entwickler: Wir versuchen, Fehler zu vermeiden, indem wir frühzeitig die Abhängigkeiten festhalten, z. B. die API-Aufrufe von einem Modul zum anderen. Jedes Team, dessen Modul ein anderes Modul aufruft, organisiert dann ein Abstimmungsmeeting mit dem Team des anderen Moduls. Diese Liste der Abhängigkeiten ist allerdings schon recht lang geworden.

Warum haben die Module so viele Abhängigkeiten?

Entwickler: Die Modularisierung erfolgte entlang bisheriger Modulgrenzen im Bestandssystem. Wir möchten jetzt einen neuen Modulschnitt umsetzen, der auf fachliche Kohärenz und Use Cases fokussiert, damit weniger Abhängigkeiten zwischen den Modulen und ihren Teams existieren. Dadurch hoffen wir weniger Abstimmungs- und Koordinationsaufwand zu haben und natürlich keine Inbetriebnahme-Blocker mehr.

In diesem Gespräch haben wir also nicht nur das Ziel identifiziert, Ideen schneller in Produktion zu bringen, sondern gleich auch Rahmenbedingungen definiert:

Risiken minimieren

Auch wenn es auf den ersten Blick nicht offensichtlich ist, geben viele Entwickler als Ziel an, Risiken reduzieren zu wollen. Hierbei sind vor allen Dingen die Risiken von so genannten Big-Bang-Releases gemeint.

Entwickler: Dadurch, dass Microservices unabhängig deploybar sind, können sie auch einzeln, also Schritt für Schritt, in Produktion gebracht werden. Gleichzeitig können wir sie so klein halten, dass die Risiken ihrer Inbetriebnahme für alle Beteiligten überschaubar sind.

Warum betonen Sie die Risiken bei der Inbetriebnahme?

Entwickler: Wir haben sehr schlechte Erfahrungen mit Softwarereleases gesammelt, da uns größere Änderungen immer zu Big-Bang-Releases gezwungen haben. Diese Releases bargen zu viele Risiken, da niemand die Auswirkungen der im Release enthaltenen Änderungen aufeinander abschätzen konnte. Mit Microservices wollen wir keine Big Bangs mit unvorhersehbaren Fehlern mehr haben.

Warum glauben Sie, werden mit Microservices weniger unvorhersehbare Fehler in Produktion passieren?

Entwickler: Wir sehen zwei verschiedene Arten von Fehlern. Erstens Fehler in der Kommunikation zweier Services und zweitens Fehler innerhalb eines Service. Punkt eins wollen wir über entsprechende Kontrakte zwischen den Services beikommen. Punkt zwei adressieren wir, da unsere Microservices weniger Programmcode enthalten werden. Dadurch gibt es schlicht weniger Platz für Fehler, sich beim Testen in der Blackbox zu verstecken. Und wenn sich ein Bug einschleicht, müssen die Entwickler weniger Code durchgehen und weniger Varianten und Pfade durchlaufen, um ihn zu finden und zu beheben. Das sollte die Dauer der Fehlerbehebung senken.

Warum ist Ihnen die Dauer der Fehlerbehebung so wichtig?

Entwickler: Dadurch, dass die Dauer bis zur Fehlerbehebung sinkt, erreichen wir eine kürzere MTTR (Mean Time to repair). Die MTTR gibt an, wie lange es dauert, einen Fehler im Produktivsystem zu beheben, sodass das System wieder stabil läuft. Wie John Allspaw schrieb [1], ist die MTTR fast immer wichtiger als die MTBF (Mean Time between Failure), da sie letztlich das größte Risiko adressiert: Je kürzer die Zeit eines Produktionsfehlers oder -stillstands, desto weniger Geld und Prestige verlieren wir.

Die Konsequenz daraus wäre: Wir priorisieren die Stabilität höher als die Inbetriebnahme neuer Features.

Entwickler: Ja, mit Microservices wollen wir die MTTR so kurz wie möglich halten. Im Optimalfall würden wir die fehlerhafte Funktion in Produktion einfach abschalten – Stichwort: Feature Toggles. Wir verzichten lieber auf bestimmte Funktionen für einen gewissen Zeitraum, als die Stabilität des Systems zu riskieren.

Die in den Gesprächen identifizierten Rahmenbedingungen sind also:

Kosten senken

Ein weiterer Grund, der oft in Zusammenhang mit Modernisierungsprojekten genannt wird, ist das Senken von Kosten.

In welchen Bereichen erwarten Sie eine Senkung der Kosten durch die Einführung von Microservices?

Entwickler: Wir erwarten sowohl eine Senkung der Wartungskosten – wobei wir Betrieb und First- bis Third-Level-Support mit einbeziehen – als auch der Kosten für die Entwicklung und Inbetriebnahme von Features.

Wodurch sollten sich die Kosten für die Entwicklung und Inbetriebnahme von Features reduzieren?

Entwickler: Wir haben uns auf Ihr Anraten hin die Improvement Approaches in AIM42 [2] angesehen. Vor allem der Change-by-Extraction-Ansatz scheint uns für die Modernisierung gut geeignet, da wir hierbei neue Funktionalität in neuen Services implementieren können.

Das betrifft die Modernisierung der Altanwendung. Welche Ansprüche bestehen für neue Features?

Entwickler: Bisher dauert die Entwicklung neuer Features im monolithischen Bestandssystem relativ lang. Dadurch sind wir nicht flexibel genug, neue Ideen schnell ausprobieren zu können. Da die neuen Services kleiner und überschaubarer sind, versetzen sie uns in die Lage, neue Ideen als kleine Experimente [3] schnell und dadurch mit deutlich geringeren Kosten in Produktion zu bringen. Hinzu kommt, dass wir ohne große Risiken ausprobieren können, ob eine Idee überhaupt bei den Kunden ankommt. Ist das nicht der Fall, kann der neue Service einfach wieder abgeschaltet werden. Aus dem Gelernten, also den erhaltenen Informationen über das Benutzerverhalten, können wir dann einen neuen, besseren Service entwickeln und so kontinuierlich unsere Dienste verbessern.

Sie erwähnten auch eine Senkung der Wartungskosten und bezogen sich auf Betrieb und First- bis Third-Level-Support. Wie sollen Microservices hier unterstützen?

Entwickler: Durch Standardisierung wie bei einer PaaS-Lösung erwarten wir mittelfristig eine Kostensenkung für die Betriebsprozesse von Roll-out und Monitoring. Die Kosten des Third-Level-Supports wollen wir senken, da wir die Fehlersuche und -behebung beschleunigen sowie wiederkehrende Anfragen beim Support durch Customer-Self-Service-Tools oder Tooling für den First-Level-Support reduzieren wollen. Diese Tools könnten dann auch Microservices sein.

Microservices benötigen nachweislich mehr Infrastruktur und vor allem einen hohen Grad an Automatisierung. Wie sehen Sie diese Kosten?

Entwickler: Wir gehen davon aus, dass durch diese Punkte initial höhere Kosten entstehen, die uns mittel- und langfristige Einsparungen in anderen Bereichen bringen wie das Aufsetzen neuer Umgebungen für Tests oder auch die potenzielle Wiederherstellung der Produktionsfähigkeit. Hinzu kommt, dass diese Maßnahmen die Zuverlässigkeit des Systems erhöhen sollten.

Und erneut die identifizierten Rahmenbedingungen:

Es sei zu diesem Punkt noch gesagt, dass Kosteneinsparungen nicht das Primärziel für die Einführung von Microservices sein sollten. Je nach Implementierung werden die Kosten im klassischen Betriebsteam auf Grund der Automatisierungsnotwendig und der zusätzlichen Infrastruktur eher steigen. Anders ausgedrückt: Wenn die Definition von Betriebskosten ausschließlich das Betriebsteam und die Infrastruktur einbezieht, bin ich mir sicher, dass wir keine Kosteneinsparung erleben werden. Wenn wir aber Support und den Software-Delivery-Prozess einbeziehen, sieht das aus meiner Sicht anders aus.

Attraktiver für Kunden und Bewerber werden

Ein anderer Grund für die Einführung von Microservices ist, dass ein Unternehmen für Kunden und potenzielle Bewerber attraktiver werden möchte. Im so genannten “War for Talent” zählt immer mehr, was Unternehmen den Bewerbern bieten können. Moderne Technologien zählen hier ebenso sehr wie Weiterbildungsmöglichkeiten und eine gute Firmenkultur. Wirbt ein Marktbegleiter mit attraktiven, neuen Technologien, kann ein Unternehmen in Zugzwang kommen, diese auch anzubieten, damit weder neue Bewerber abgeschreckt, noch bestehende Mitarbeiter abgeworben werden.

Die Motivation ist hierbei allerdings eine völlig andere als bei den zuvor genannten Szenarien. Das kann dazu führen, dass ein Unternehmen die Technologie nur als Alibi einführt und gar nicht in Produktion bringt. Sozusagen, um das Häkchen auf der Marketingcheckliste zu setzen. Solche halbherzigen Ansätze können allerdings schmerzhaft bestraft werden. Denn Mitarbeiter wollen den Sinn hinter ihrer Arbeit erkennen. Der Sinn einer Technologie, die keine fachlichen Aufgabenstellungen löst, sondern als Selbstzweck existiert, ist nicht groß genug, um nachhaltig Mitarbeiter zu begeistern. Das ist ganz ähnlich wie bei „Eine neue Sau durchs Dorf treiben“.

Aufgaben- vs. Verantwortungsdelegation

Auf den ersten Blick sieht es vielleicht so aus, als sei die klare Kommunikation und das Verinnerlichen von Zielen und Rahmenbedingungen vielleicht nicht für alle Projektmitglieder notwendig. Passiert das aber nicht, können daraus resultierende oder eben ausbleibende Aktionen zum Scheitern von Projekten führen. Um das zu verdeutlichen, machen wir einen kurzen Exkurs in den Projektalltag.

Die These: In den allermeisten Fällen kennen Mitarbeiter die Details des Tagesgeschäfts besser als ihre Vorgesetzten. Das ist auch notwendig, da sie jeden Tag Entscheidungen zu Details treffen müssen, z. B. auf welche Art sie ein bestimmtes Problem lösen. Müsste ihr Vorgesetzter diese Entscheidungen treffen, würden wir von Mikromanagement sprechen.

Nehmen wir an, ein Vorgesetzter gibt nun aber vor, wie eine Aufgabe zu erledigen ist, ohne das dahinterliegende Ziel und Rahmenbedingungen zu nennen: „Baue eine Hängebrücke über den Fluss.“ Wie kann der Mitarbeiter dann prüfen, ob die Entscheidungen, die er im Tagesgeschäft trifft, mit dem Ziel im Einklang sind oder die Zielerreichung vielleicht sogar erschweren? Soll er zu jeder Entscheidung Rücksprache mit seinem Vorgesetzten halten?

Autonomie, Meisterung und Sinnhaftigkeit

In Spotifys Engineering Culture (Video unter [4]) dreht sich vieles um die Aussage „High autonomy, high alignment“. Im Video sagt der Manager, gesprochen von Agile Coach Henrik Kniberg: „Wir müssen den Fluss überqueren. Findet heraus, welcher Weg der beste ist.“ Der Vorgesetzte verlässt sich hierbei auf das tiefere Detailwissen seiner Mitarbeiter, mit dem sie die beste Art finden, die Aufgabe zu lösen. Stephen Covey schreibt dazu, dass Menschen nach „Autonomie, Meisterung und Sinnhaftigkeit“ streben [5]. Das bedeutet, sie wollen Dinge aus eigener Kraft erledigen können. Sie wollen in dem, was sie machen, besser werden und vor allem den Sinn dessen erkennen, was sie tun. Aus diesem Grund propagiert Covey die Verantwortungsdelegation gegenüber der Aufgabendelegation.

Bei der Verantwortungsdelegation wüsste ein Mitarbeiter, welches Ziel sein Vorgesetzter oder das Unternehmen mit der Einführung von Microservices verfolgt. So ist er in der Lage, seine Entscheidungen im Alltag im Kontext dieser Zielerreichung zu überprüfen. Er kann eigenständig (Autonomie) prüfen, ob sein Tun dem Ziel dient (Sinnhaftigkeit) und die Art, wie er es macht, stetig verbessern (Meisterung). Es geht also um selbstbestimmtes Arbeiten. Dieses benötigt ein Verständnis der Ziele und der Rahmenbedingungen, innerhalb derer diese Ziele erreicht werden sollen.

Fazit

In diesem Artikel habe ich versucht zu verdeutlichen, warum es wichtig ist, die Gründe für die Einführung von Microservices aktiv zu kommunizieren, und welches die am häufigsten genannten Gründe sind. Im nächsten Artikel wollen wir uns ansehen, welchen Herausforderungen wir in solchen Einführungsprojekten gegenüberstehen können. Ich werde beschreiben, wie wir ihnen begegnen können und welche Ansätze bei mir bisher funktioniert und welche versagt haben. Ich danke an dieser Stelle meinen Kollegen Sven Johann und Eberhard Wolff für das Feedback zu einer frühen Version dieses Artikels.

Literatur & Links

  1. http://www.kitchensoap.com/2010/11/07/mttr-mtbf-for-most-types-of-f/  ↩

  2. http://aim42.github.io/#improve-approaches/  ↩

  3. https://www.innoq.com/de/articles/2016/10/microservices-deployment-und-monitoring/#kleineexperimente/  ↩

  4. https://youtu.be/4GK1NDTWbkY/  ↩

  5. Covey, Stephen R.: „Die 7 Wege zur Effektivität“: Gabal, 2010  ↩

TAGS