Inhaltsverzeichnis
Microservices – der Weg aus dem Silo-Dilemma?
Wenn ich mir unsere IT Landschaft vor zwei Jahren angeschaut habe, dann wollte ich manchmal am liebsten alles einfach neu machen – die ganzen alten Silos und Monolithen abschalten, um mich gar nicht erst mehr weiter mit ihnen befassen zu müssen. Das war meiner Meinung nach alles zu komplex und zu unflexibel.
Das Bild unserer IT Landschaft war geprägt von selbstentwickelten Anwendungen, Standardsoftwares, Scripten, Open Source Software und hier und da mal eine Cloud Anwendung.
Das gesamte Bild war somit unglaublich komplex, da jede Anwendung für sich individuell betrieben werden musste.
Niemand hatte einen Überblick – oder gar Verständnis – über diese Silo-Landschaft. Die Anwender, Kunden und Mitarbeiter haben diese unübersichtliche Vielfalt zwar akzeptiert und sich damit abgefunden, dass Daten per Copy&Paste zwischen Systemen übertragen wurden, doch wirklich produktivitätsfördernd war das nicht.
Eine Zusammenarbeit zwischen einzelnen Bereichen wie Marketing, Sales, Entwicklung, Support etc. war zwar über direkte Kommunikation zwischen den MitarbeiterInnen, nicht aber über Systeme hinweg möglich.
Zum “Datenaustausch” blieben höchsten die beliebten “Küchengespräche”.
Die Schmerzen einer solch historisch “gewucherten” Systemlandschaft liegen auf der Hand, hier nur einige Beispiele:
- Geringe Flexibilität verhindern Fortschritt und Anpassungsfähigkeit,
- die Wartung ist teuer und intensiv,
- es gibt niemanden, der die einzelnen Monolithen wirklich versteht und eine (verständliche) Dokumentation ist oft nicht vorhanden.
- Neue Anwendungen sollen mit den bestehenden Komponenten integriert werden, es fehlen jedoch die nötigen Standardschnittstellen.
Daraus wird wieder schnell ein komplexes Softwareprojekt, meist nach dem klassischen Wasserfall-Ansatz 😉 und so dreht sich das Rad der Veränderung immer schneller, wohingegen unsere Systemlandschaft immer unflexibler wurde.
Unternehmen, die bereits agile Methoden in einer flexiblen Microservice-Landschaft einsetzen und durch Cloud Tools produktiv unterstützt werden, erfahren häufig einen Vorsprung im Vergleich zu ihren Mitbewerbern, die sich in ihrer Legacy-Anwendungen vergraben fühlen.
2018 haben wir begonnen, unsere IT-Landschaft vollständig in die Cloud zu migrieren und auf eine vollständig cloudbasierte Microservice-Architektur hinzuarbeiten.
Das Ziel war es, globalen Teams die Zusammenarbeit über unsere Tool-Landschaft so einfach und sicher wie möglich zu gestalten und dabei flexibel nach tatsächlicher Nutzung oder nach Anzahl der Anwender skalieren zu können – sowohl bezüglich Kosten als auch bezüglich Performance.
Durch den Einsatz von Cloud Tools wollten wir uns auch nicht für jede Anwendung selbst um Betrieb und Weiterentwicklung kümmern müssen, da es immer komplexer wurde, dieses Know-How selbst vorzuhalten.
Wir wollten unsere Mitarbeiter nicht für die Wartung zahlreicher Systeme bereithalten, denn niemand hatte darauf Lust und vor allem bindet es wertvolle Projektkapazitäten. Alle Tools und Anwendungen sollen in der Cloud laufen, voll integrierbar miteinander sein und flexibel skalieren, je nach Bedarf.
Sind wir da heute angekommen? Nein. Das werden wir sicher auch nie. Ankommen heißt Stillstand. Da wollen wir nicht hin.
Wir wollen volle Agilität, Flexibilität und Qualität in den Tools und Workflows, die wir einsetzen. Wir wollen eine Systemlandschaft, die der kontinuierlichen Veränderung mit Flexibilität und Anpassungsfähigkeit begegnet.
Mit vielen Tools sind wir heute bereits deutlich flexibler, schneller und durch integrierte Analyticsfunktionen auf integrierten Datenpools statt Daten-Silos auch wesentlich schlauer als noch vor zwei Jahren.
Methoden, die den Umbau von Monolithen zu Microservices unterstützen, möchte ich nun mit Ihnen teilen.
Wo fangen wir mit Microservices an?
Auch wenn der Drang vielleicht vorhanden ist, einfach alles neu zu machen und alte Komponenten direkt abzulösen, ist das für viele systemrelevante Komponenten nicht der bevorzugte Weg. Das Strangler Pattern ermöglicht es, Funktionen von Monolithen im einzelnen durch neue Microservices abzulösen – Step by Step. Zunächst braucht das Priorisierung. Das klingt banal, ist aber oft genau das, was zu Beginn fehlt.
Also: Liste mit Funktionen und Komponenten erstellen und diese in eine Reihenfolge bringen, die die Prioritäten abbildet.
Eine Unterteilung in “dringend” (da Sicherheitsupdates vorliegen, Features fehlen, die in der Arbeit behindern etc) und “wichtig” (Funktionen und Features, die das Unternehmen in der Entwicklung strategisch unterstützen) erstellen, um somit ein Bild der Prioritäten zu gewinnen. Von diesem Bild aus kann man mit dem einsteigen, was gerade am Wichtigsten zu sein scheint.
Legacy-Anwendungen haben häufig die folgenden Herausforderungen im Betrieb und der Wartung:
- Es fehlen Unit Tests der wichtigsten Funktionen.
- Monolithen sind komplex und es fehlt an der Kapselung wesentlicher Funktionen (Single Responsibility Principle).
- Einzelne Komponenten und komplette Anwendungen lassen sich mit steigendem Bedarf nicht oder nicht stufenlos skalieren.
- Deployments sind fehleranfällig, da viele Komponenten eng mit anderen “verwachsen” sind.
- Häufig wurden Monolithen nur zu 80% fertig gestellt und so wurden wegen Zeit- und Kostendruck „technische Schulden“ angehäuft und Funktionen mit der heißen Nadel gestrickt.
Gerade Deploymentvorgänge, die auf die Fertigstellung anderer Teams oder Komponenten angewiesen sind, verlangsamen den Fortschritt erheblich – und häufig blockieren sie ihn, wenn die Entwicklung nicht synchron und in enger Abstimmung verläuft.
Wird ein Monolith, der durch verschiedene Teams bearbeitet wird, deployed, so ist ein vollständiger Test der gesamten Applikation erforderlich. Das ist jedoch erst dann möglich, wenn alle Teams ihre Entwicklung für das nächste Release abgeschlossen haben. Monatliche oder quartalsweise Deployments sind die Folge. So lässt sich keine Geschwindigkeit erreichen.
Refactoring von Monolithen
Um einen Monolithen “from scratch” neu im Rahmen einer Microservice-Architektur zu entwickeln, ist zunächst einmal ein vollständiges Verständnis aller Funktionen nötig. Das klingt banal, ist aber häufig nicht vorhanden, zumal eine Dokumentation oft nicht vorhanden ist.
Die Fragen
“Was sind die 5 wichtigsten Funktionen des Monolithen, wer sind dessen Anwender, was passiert wenn diese Funktionen nicht mehr vorhanden ist, was ist der Output der Funktionen im Einzelnen und wer arbeitet mit diesem Output weiter?”
geben Aufschluss darüber, wie gut das Verständnis vorhanden ist. Je geringer das Verständnis über die Funktionen des Monolithen, desto größer das Risiko beim “Neubau”.
Wenn Sie beginnen, den Monolithen von Grund auf neu zu entwickeln, haben Sie Ungewissheit darüber, ob er überhaupt funktionieren wird – und das bis zur Fertigstellung und bis zum ersten Einsatz in dem reale Tests wirklich Aufschluss darüber geben.
Das dauert häufig viel zu lange und verhindert ebenfalls den Fortschritt. Und während Sie in 8-12 Monaten mit der Entwicklung beschäftigt sind, haben Sie meist keine Möglichkeit, weitere Verbesserungen zu entwickeln.
Sollten Sie das doch im Rahmen des alten Monolithen tun, wir dies schnell ein komplexes Unterfangen mit sich ständig änderndem Scope – eingepackt in einem statischen Vorgehensmodell. ACHTUNG!
Das Strangler Pattern
Das Strangler Pattern ist ein Cloud Design Pattern, das es ermöglicht, Monolithen in einem kontinuierlichen Prozess in eine Microservice-Architektur zu überführen. Alle Verbesserungen und neue Features werden direkt in der neuen Microservice Architektur entwickelt und NICHT in Monolithen. Jede Funktion, die in einen neuen Microservice überführt wird, wird also vom Monolithen entkoppelt, indem sie als Microservice entwickelt und über eine separate Pipeline unabhängig von anderen Komponenten deploybar gemacht wird. Das ist bereits die vollständige Idee des Strangler Patterns.
Damit das Risiko dieser Transformation möglichst gering und gut kontrollierbar bleibt, kann ein Einführungsprozess in drei Phasen unterteilt werden:
- Neuentwicklung des Microservices, der aus dem Monolithen herausgelöst werden soll.
- “Co-Existenz” beider Funktionen, um eine reibungslose Funktionen sicherzustellen.
- Abschalten der Nutzung der entsprechenden Funktion im Monolithen.
Für die Phasen “Co-Existenz” und “Abschalten” kann es nötig sein, ein Routing aus dem Monolithen in die neuen Funktion zu schaffen. So kann z.B auch die alte Benutzeroberfläche (UI) erhalten bleiben und die tatsächliche Funktion durch den Microservice ersetzt werden.
Priorisierung neuer Microservices
Die Transformation eines Monolithen in eine Microservice-Landschaft braucht Training und Tests. Am sichersten verfahren Sie, wenn Sie zunächst systemUNkritische Funktionen in einen Microservice überführen. So bleibt das Risiko gering und Ihr Team kann sich an die neue Arbeitsweise gewöhnen und die Plattform, auf der Ihre Microservices laufen, testen.
Zusätzlich sind Funktionen innerhalb eines Monolithen, die eine hohe Testabdeckung aufweisen, ein guter Startpunkt, da hier die bestehenden Tests Klarheit über die Funktionen, deren Input und Output bieten und diese Tests auf den neuen Microservice angewendet werden können.
Funktionen, die einen akuten Bedarf an Skalierbarkeit haben, können ebenfalls davon profitieren, wenn Sie diese bereits zu Anfang in die Cloud migrieren.
Sollten Sie Funktionen kennen, an die häufig neue Anforderungen durch Anwender im Unternehmen gestellt werden, können Sie diese priorisieren, um dem Wunsch nach mehr Flexibilität schnellstmöglich durch die neue Microservice-Architektur gerecht zu werden.
Der große Vorteile in der Anwendung des Strangler Patterns ist dadurch gegeben, dass Sie priorisierbar viele kleine Komponenten Schritt für Schritt migrieren können und damit das Risiko gut kontrollierbar wird.
Ich möchte Ihnen nicht vorenthalten, dass die Transformation von einem Monolithen zu einer Microservice-Architektur sicher keine kleine Herausforderung ist.
Wenn die zusätzliche Flexibilität und Skalierbarkeit in der Cloud für Sie jedoch einen wirklichen Businessvalue besitzt, wird sich der Umbau strategisch lohnen!
Lassen Sie uns gerne von Ihrer Herausforderungen wissen. Wir teilen unsere Erfahrung gerne mit Ihnen und wenn Sie wünschen, begleiten wir Sie gerne auf der Reise hin zu mehr Flexibilität und Skalierbarkeit durch die Transformation Ihrer Monolithen in eine Microservice-Architektur.
Dieser Beitrag wurde inspiriert durch unsere Erfahrung, durch dzone.com und durch Medium.com.
Dieser Artikel wurde von Manuel Pistner, CEO bei Bright Solutions, verfasst.
Umfassende Anleitung für Strategie, Umsetzung & Vermarktung von Web-, Mobile-& Cloud-Anwendungen.
Sie erhalten eine detaillierte Anleitung mit Methoden, Templates & Strategien für Konzeption, Umsetzung & Vermarktung von digitalen Produkten. Über 190 erfolgreiche Projekte zeigen: Es funktioniert.
