Ein Monolith in der Cloud: Wie wird die Migration zum Erfolg?

Im Gastbeitrag der msg group geht es um die Besonderheiten der monolithischen Architekturen und wie sie sich in die Cloud migrieren lassen.

Typ:
Blogartikel
Rubrik:
Analytik & IT
Themen:
Cloud
Ein Monolith in der Cloud: Wie wird die Migration zum Erfolg?

Im ersten Artikel sind wir detailliert darauf eingegangen, warum wir Applikationen in die Cloud bringen möchten und welche Auswirkungen dies auf klassische Monolithen hat. Nun geht es um die Umsetzung: Wie lässt sich ein Monolith bestmöglich in die Cloud migrieren?

Entscheidend sind dafür ein methodisches und agiles Vorgehen und mehrere parallele Aktivitäten, die sich über einen längeren Zeitraum erstrecken. Das Ziel ist es,  jeden Microservice fachlich getrennt voneinander zu entwickeln und unabhängig von den anderen betreiben. Dies bringt uns die gewünschte Flexibilität und eine höhere Entwicklungsgeschwindigkeit.

Doch welche Methoden eignen sich, um diese Unabhängigkeit der einzelnen Microservices zu erreichen?

Domain-Driven-Design

Die Methode Domain-Driven-Design (DDD)[1] von Eric Evans eignet sich, um die fachliche Domäne innerhalb eines Migrationsprojekts detailliert zu analysieren. Mit dieser Methode lassen sich der richtige fachliche und technische Schnitt zwischen den Microservices erreichen sowie deren Abhängigkeiten minimieren.

Dafür unterteilen wir die Domäne in mehrere Subdomänen, die sich wiederum in ein oder mehrere Bounded Contexts abgrenzen. Ein Bounded Context hat die Verantwortung über genau eine Fachlichkeit in dessen jeweiliger Subdomäne. Zum Beispiel wären in der Subdomäne „Sales“ einer Domäne „Kfz-Versicherung“ „Tarifierung“ oder „Antrag“ denkbare Bounded Contexts. Parallel hierzu müssen die Beziehungen zwischen den Bounded Contexts betrachtet werden, um den richtigen Grad der gegenseitigen Kopplung auszuwählen. Hier wird entschieden, ob eine enge oder eine lose Kopplung erreicht werden soll. Je stärker die Kopplung, umso höher ist die Abhängigkeit  vom verbundenen Bounded Context. Die Flexibilität reduziert sich also mit einer hohen Abhängigkeit. Anhand der Bounded Contexts bauen wir dann die Mircoservice-Architektur auf, wobei sich in jedem Microservice mindestens ein Bounded Context wiederfindet.

Ein Team ist jeweils für ein oder mehrere der neu erschaffenen Bounded Contexts verantwortlich. Es sollten dabei nie mehr als ein Team für ein Bounded Context zuständig sein, da sonst unerwünschte Abhängigkeiten entstehen. Aus diesem Grund müssen wir die Teams analog den Microservices aufteilen.

Event-Storming

Doch wie finden wir die Bounded Contexts einer Domäne? Dafür eignet sich Event-Storming[2]. Bei dieser Methode beschreibt ein Team aus Entwicklerinnen und Entwicklern und Business-Expertinnen und -Experten die Domäne in Form von fachlichen Events und den zugehörigen Auslösern (Commands). Während des Event-Storming-Workshops bilden sich auf dem Board Anhäufungen von Events, die sehr eng beieinander liegen. Diese sind gute Kandidaten für Bounded Contexts, da diese fachlich zusammengehören und eine starke Kopplung untereinander vorweisen. Gleichzeitig entsteht ein gemeinsames fachliches Domänenmodell, mit dem die technische Umsetzung startet. So wird im Team gemeinsam die Domäne bzw. Subdomäne kontinuierlich erlernt und immer weiter verfeinert.

Das gemeinsam erstellte Domänenmodell ist dabei die Grundlage für die Zielarchitektur. Sobald wir ein erstes Modell für die Domäne (Subdomäne) und deren Bounded Contexts gefunden haben, bilden wir die Struktur des Monolithen auf den einzelnen Bounded Contexts ab. Wir bringen somit die Ist- mit der Zielarchitektur zusammen und identifizieren Abweichungen und Maßnahmen für die Migration.

Agilität

Agile Methoden wie Scrum oder Kanban sind mittlerweile schon fast selbstverständlich geworden. Auch bei Migrationsprojekten empfiehlt es sich, darauf zu setzen. Denn es gibt Synergien zwischen agilen Methoden, DDD und der angestrebten Microservice-Architektur. Wird die DDD-Methode eingesetzt, müssen wir in der Lage sein, kontinuierlich zu lernen. Ein klassisches Vorgehensmodell nach Wasserfall-Strukturen würde diesen Lernprozess erheblich behindern.

Mit Agilität, DDD und Event-Storming fokussieren wir uns stärker auf die Fachlichkeit einer Applikation, was ein klarer Benefit ist. Mithilfe dieser Methoden kommen wir dem Ziel näher, ein Optimum für den Cloud-Einsatz für eine bestehende, monolithischen Applikation zu erreichen. Die Vorteile der Cloud lassen sich so am besten nutzen.

 

[1] Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (Boston: Addison-Wesley, 2004).

[2] Brandolini A., Introducing Eventstorming

Rudolf Dodel
Lead IT-Consultant
msg
Rudolf Dodel ist Lead IT-Consultant bei msg. Er verfügt über mehrjährige Erfahrung als Softwarearchitekt bzw. Softwareengineer in verschiedenen Branchen. Seine Themenschwerpunkte setzt er auf moderne Softwarearchitektur und Cloud.

Themen Tags