Einer für Alle oder Alle für Einen? - Migrationsleitfaden

Zunächst wollen wir ein paar Annahmen zur Ausgangssituation festlegen.

Wir gehen von einem Projekt aus, das schon mehrere Jahre läuft und an dem mehrere Teams arbeiten. Die Teams, die zum Einsatz kommen, sollen möglichst Full-Stack Teams sein und einen kompletten Durchstich für die Microservices sowie den Monolithen bedienen können. Im Weiteren gehen wir davon aus, dass wir bereits in einer agilen Form von Projektmanagement organisiert sind. Dabei spielt es erst einmal keine Rolle, ob es sich dabei um Scrum, Kanban oder etwas ähnliches handelt.

Die Entscheidung zu einer neue Microservice Architektur zu wechseln, wurde aufgrund steigender Entwicklungskosten im monolithischen Ansatz getroffen. Diese können zum Beispiel durch verschleppte technische Schulden und fehlender Flexibilität in diesem Ansatz verursacht worden sein.

Zuerst stellt sich die Frage, wie wir mit dem neuen Ansatz einsteigen wollen. Soll es ein Greenfield Projekt werden oder Hand in Hand mit der alten Software wachsen. Dabei gibt es für beide Varianten verschiedene Szenarien, die man sich vorstellen kann.

Mit einem Greenfield Ansatz können wir ohne jegliche Altlasten eine saubere Architektur erstellen und komplett auf moderne Technologien setzen. Hier kann man sich vorstellen Microservice für Microservice zu entwickeln und diese dann Stück für Stück in den bereits bestehenden Monolithen zu integrieren, um Synergieeffekte zu erzielen. Nachteil ist, dass wirklich alles komplett neu entwickelt werden muss, was einen beträchtlichen Aufwand an Zeit und Kosten bedeutet.

Ein andere Ansatz ist, nur bestimmte Teile aus dem Monolithen zu schneiden, um bestehende Schmerzen zu lösen. Das könnte bedeuten den Monolithen so weit zu reduzieren bis nur noch die absolute Kernfunktionalität oder die größten Stärken, die dieser mit sich bringt, übrigbleiben. Wobei ein Nachteil dabei ist, dass der Monolith auch weiter Kosten verursacht, z.B. durch Infrastruktur oder Lizenzkosten.

Wurde sich für einen Ansatz entschieden, wirft das jedoch weitere Fragen auf: Wie können benötigte Weiter- und Neuentwicklungen parallel bedient werden? Wie kann die Transformation zum neuen System sinnvoll ablaufen? Oder wie ist mit Logik umzugehen, die sowohl vom Monolithen als auch von den Microservices benötigt wird?

Zur Parallelentwicklung haben wir eine klare Meinung: Sie sollte so weit wie möglich vermieden werden. Wahrscheinlich wird eine gewisse Zeit benötigt, um Grundlagen für die Microservices zu erstellen, bevor die meisten oder alle Teams diesen Ansatz verfolgen können. Diese Zeit ist aber möglichst kurz zu halten, um zu vermeiden, dass neue Features in beiden Systemen entwickelt werden oder bestehende Features in beiden angepasst werden müssen. Denn das würde im schlimmsten Fall zu einem Endlosprozess führen, in dem der neue Ansatz niemals beendet werden kann, weil die alte Lösung stetig weiterwächst. Wir haben tatsächlich schon Migrationsprojekte erlebt, die deswegen gescheitert sind und letztlich gestoppt wurden.

Dadurch ergibt sich auch das Thema Transformation. Neue Features sollten möglichst nicht mehr auf der alten Basis entstehen, sondern nur noch als Microservice erstellt werden. Dadurch kann man sich so stark wie möglich auf die neuen Ansätze fokussieren und redundante Implementierungen in alt und neu vermeiden. Der Übergang kann so reibungsarm erfolgen.

Hier ergibt sich dann möglicherweise bald ein Problem wie mit Logik umzugehen ist, die von beiden verwendet wird. Zum Beispiel könnte es dabei in einem eCommerce Umfeld um die Sichtbarkeit von Produkten gehen. Aus unserer Sicht ist der bevorzugte Weg, dass solch eine Logik in einen Microservice migriert wird und dass dann der Monolith diesen Microservice konsumiert. Andere Ansätze verursachen Schmerzen durch redundante oder abweichende Implementierungen und fortlaufende Pflege.

Außerdem muss man bedenken, wie das Operating gehandhabt wird. Besteht ein klassisches externes Operating Team oder übernehmen die Entwickler eines Full-Stack Teams einen Teil oder sogar das komplette Operating?

Die Voraussetzung: Das Operating Team muss sich mit den Systemen und der Architektur auskennen und in engem Austausch mit dem Entwicklungsteam stehen, da sonst der Einblick in die aktuellen Strukturen und der Überblick über mögliche Probleme fehlt. Dies führt dann nämlich wiederum zu einer schweren und langwierigen Fehleranalyse. Die Entwicklungsteams könnten dadurch ausgebremst werden und der Entwicklungsfortschritt wird negativ beeinflusst.

Der Vorteil des externen Operating ist allerdings, dass bei gutem Knowhow über die Systeme schnelle Hilfe geleistet werden kann und die Entwicklungsteams sich selbst nicht mit Aufgaben eines Operating Teams befassen müssen und sich somit auf die reine Entwicklung konzentrieren können.

Gehen wir allerdings davon aus, dass die Entwickler der Microservices auch Aufgaben des Operating Teams übernehmen, kann das auch wesentliche Vorteile mit sich bringen. Die Aufgaben des Operatings beschränken sich damit nämlich primär auf den von den Microservices betroffenen Scope. Hinzu kommt, dass gute Kenntnisse über die entwickelten Softwarebestandteile vom Team schon bestehen und Fehler oder Problemlösungen vom Team selbst am schnellsten analysiert und durchgeführt werden können.

Sinnvoll kann es hierbei vermutlich dennoch sein, ein extra Operating Team zu haben, welches sich um die Gesamt-Systemarchitektur kümmert und das Zusammenspiel mit Dritt-Systemen sicherstellt.

Nachdem wir jetzt unser grundsätzliches Vorgehen, wie der Entwicklungsansatz ablaufen kann, beschrieben haben, wenden wir uns dem Projektmanagement zu.

Wir haben angenommen, dass wir mit einem agilen Ansatz starten. So weit so gut. Klassisches Scrum oder Kanban mag auch gut funktionieren sofern sich die Teams untereinander abstimmen. Bei einem Microservice Ansatz kann sich allerdings mehr Planungs- und Abstimmungsbedarf ergeben. Zum Beispiel entstehen potenziell viele Abhängigkeiten unter den Teams bei der Feature Entwicklung. Das hat im Monolithen möglicherweise keine so große Bedeutung, da jedes Team den Durchstich bei der Implementierung selbst machen kann.

Bei der neuen Architektur mögen aber Verantwortlichkeiten für verschiedene Microservices bei verschiedenen Teams liegen. Das macht Sinn, da sich so jedes Team auf seinen Aufgabenbereich konzentrieren kann. Komplexe Features müssen oft verschiedene Services konsumieren. Und oft müssen Teile dieser Services erst noch angereichert werden, um neue Anforderungen zu erfüllen. Wie kann mit diesen Problemen umgegangen werden?

Es haben sich verschiedene Formen von skalierten agilen Methoden etabliert. Drei gängige sind LeSS, SAFe und Scrum@Scale. Eine Aussage zu treffen, was besser oder schlechter geeignet wäre, ist pauschal kaum möglich. Das hängt von der konkreten Situation und den Umständen ab. Wir haben bisher gute Erfahrung mit SAFe machen können. Egal für welche Methodik sich entschieden wird, es sollte immer ein Augenmerk auf das Vermeiden von Inseldenken gelegt werden.

Letzten Endes muss das Ziel sein eine ordentliche und verlässliche Planung und Abstimmung über alle Teams und Stakeholder zu ermöglichen. Dabei müssen alle Teilnehmer ernst genommen werden und ein möglichst hohes Maß an Transparenz erreicht werden. So kann sichergestellt werden, dass alle an einem Strang ziehen und das gemeinsame Ziel verstanden wird.