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

Die Cloud ist allgegenwärtig. Im Zuge der digitalen Transformation werden laufend neue Applikationen in der Cloud entwickelt, dort bereitgestellt und betrieben. Ansätze wie Cloud First und Cloud Native wirken hier als starke Treiber. Der Druck, alles in die Cloud zu verschieben, steigt. Doch ist das auch immer sinnvoll? Ist der Weg in die Cloud wirklich immer „der richtige Weg“? Oder gibt es speziell bei monolithischen Architekturen Ausnahmen und Besonderheiten zu beachten?

Ein Monolith ist in der Softwarearchitektur eine homogene, untrennbare Einheit. Diese Einheit wird in einem Stück gebaut, bereitgestellt und betrieben. Die Unteilbarkeit eines Monolithen ist der fehlenden Struktur bzw. Architektur geschuldet. Trotzdem ist ein Monolith aber nicht generell von Nachteil. Tatsächlich gibt es in der Praxis gute Gründe, um eine Software als Monolithen zu bauen und zu betreiben. Denn die Komplexität ist wesentlich geringer als in einer verteilten Architektur, was gerade am Anfang eines Projekts ein großer Vorteil ist.

Der Weg in die Cloud: Möglich und auch sinnvoll?

Technisch ist es fast immer möglich, einen Monolithen in die Cloud zu portieren: Die Applikation in einen Container oder auf einen virtuellen Server transferieren, die Datenbank als Managed-Service beim Cloudprovider aufsetzen, die Daten dorthin migrieren und schon ist man in der Cloud. Doch ist das so auch sinnvoll? Was bringt die Cloudmigration oder ein Cloud-Native-Ansatz als Unternehmensstrategie? Diese Fragen sollten geklärt sein, ehe man näher auf das „Wie“ der Migration zu sprechen kommt.

Die Welt der (fast) unendlichen Möglichkeiten

Oft gilt die Kostenersparnis als ein zentrales Argument für den Weg in die Cloud. Mittlerweile überwiegen andere Vorteile wie Flexibilität, Skalierbarkeit, Performance, schnelle Bereitstellung von Ressourcen, eine schnelle Time-To-Market für neue Features sowie eine verbesserte Applikations-Security. Außerdem ergeben sich in der Cloud völlig neue Möglichkeiten in der Entwicklung und in der Architektur, da es keine Restriktionen oder Verfügbarkeitsengpässe wie in einem klassischen Rechenzentrum gibt. Spezielle und hoch performante KI-Hardware für Machine Learning, High-Performance-Services für Daten, weltweit verteilte Availability-Zones (AWS) und Blockchains ermöglichen völlig neue innovative Lösungen. Es scheint so, als seien bei der Auswahl an Ressourcen und deren Verwendung keine Grenzen gesetzt. Aufgrund der kurzfristigen Verfügbarkeit dieser Ressourcen eignen sich diese sehr gut für Prototypen oder technische Machbarkeitsstudien. So lassen sich neue Ideen schnell und einfach verwirklichen. Mit dieser Selektion der verschiedensten Cloud-Ressourcen lässt sich die digitale Transformation effektiv vorantreiben.

Doch gelten diese Vorteile auch genauso für einen Monolithen?

Kostenersparnis oder Kostenfalle?

„The Cost of Cloud, a Trillion Dollar Paradox“[1] zeigt, dass viele Unternehmen in Relation zum Umsatz immer höhere Kosten für IT und Cloud Operations auf sich nehmen. Das bewegt manche dazu, Applikationen wieder ins klassische Rechenzentrum zu verlegen oder eine Mixed-Cloud-Strategie anzuwenden. Es ist somit kein Selbstläufer, dass die Kosten für die IT-Entwicklung und den Betrieb in der Cloud sinken.

Was sind dafür die Gründe? Häufig fehlt es hinsichtlich der Kosten an Transparenz. Dies liegt meist daran, dass diejenigen im Unternehmen, die die Kosten verursachen, in der Regel nicht die Rechnungen bezahlen. Die oben genannte Vielfalt an hoch performanten Auswahlmöglichkeiten verleiten so manchen dazu, nicht immer die günstigste bzw. kleinste Variante auszuwählen. Deshalb ist es zu empfehlen, KPIs für Cloud-Kosten anzuwenden oder zumindest den Entwicklerinnen und Entwicklern entsprechende Ziele zu stecken. Häufig lohnt es sich, zu selektieren und die Vorteile beider Welten zu kombinieren (Mix-Cloud-Strategie): Nicht so stark genutzte Funktionen mit geringen Auslastungsschwankungen sowie einer geringeren Anforderung im Service-Level-Agreement (SLA) sind häufig On-Premises günstiger aufgehoben, wohingegen sich bei hoch skalierbaren Bestandteilen mit einer hohen Verfügbarkeit in der Cloud Kosten einsparen lassen. Bei Applikationen, die in ihren Funktionalitäten trennbar sind, bietet es sich an, sie teilweise in die Cloud zu migrieren, um von Kostenvorteilen zu profitieren.

Bei einem Software-Monolithen wird dies jedoch ungleich schwieriger, da alle eingesetzten Ressourcen immer nur einmal und komplett für die Applikation verwendet werden. Bei einer klassischen, monolithischen Softwarearchitektur kommt dabei meist ein virtueller Server oder ein Container für die Applikation sowie eine Datenbank zum Einsatz. Um kostengünstige Ressourcen auszulagern, ist jedoch eine Zerlegung in eine Modulstruktur oder einzelne Artefakte wie bei den Microservices notwendig, um auch Kostenersparnisse erzielen zu können.

Horizontale Skalierung eines Monolithen

Wie bereits erwähnt gibt es allerdings noch weitere gute Gründe für die Cloudmigration – etwa die Performance und Skalierbarkeit. Die Performance einer Applikation lässt sich entweder mit einer höheren Anzahl von virtuellen Servern oder Containern steigern oder mit höherwertigen Cloud-Instanzen. Es wird hierbei zwischen horizontaler und vertikaler Skalierung unterschieden. Bei einer horizontalen Skalierung wird die Last auf viele kleine Ressourcen verteilt, wohingegen bei einer vertikalen immer auf eine noch leistungsfähigere Instanz gewechselt wird. Die vertikale Skalierung hat nach oben hin immer Grenzen und ist teurer als eine horizontale, weshalb letztere immer zu bevorzugen ist. So lassen sich bei einer horizontalen Skalierung beispielsweise Spotinstanzen verwenden, was einen zusätzlichen positiven Kosteneffekt hat.

Ein Monolith lässt sich jedoch nicht immer horizontal skalieren. Dies kann unter anderem an einer schlechten Modularisierung liegen, durch die die Abhängigkeiten zu eng gekoppelt sind, oder an einem geteilten State, wie bei einer gemeinsamen Datenbank. Klassische Datenbanken lassen sich meist nur schwer skalieren. Deshalb ist bei der Migration eines Monolithen in die Cloud auf eine gute Modularisierung zu achten, sodass einzelne Teile der Applikation separat von den anderen skalierbar sind. Dies verbessert die Effizienz, was wiederum die oben genannten Betriebskosten in der Cloud reduziert, da insgesamt weniger Ressourcen benötigt werden.

Optimierte Time-To-Market für neue Ideen und Lösungen – auch beim Monolithen?

Was die Flexibilität und den Innovationscharakter beim Cloud Computing angeht, gibt es beim Monolithen im Vergleich zu einer Microservices-Architektur auch einiges zu beachten: Aufgrund der Abhängigkeiten innerhalb eines Monolithen reduziert sich die Möglichkeit, der Nutzerin oder dem Nutzer schnell neue Funktionalitäten zur Verfügung zu stellen. So muss in einem modernen Umfeld mit kontinuierlicher Integration ein noch nicht produktionsreifer Code ausgeschaltet bzw. übersprungen werden, damit sich trotzdem kurzfristig neue Features in Produktion bringen lassen. Das erhöht allerdings die Komplexität in der Entwicklung und im anschließenden Test.

Die Komplexität erhöht sich außerdem mit der Anzahl der Teams, die gleichzeitig an der Monolithen-Applikation arbeiten. Wenn in dieser Architektur die Module und Schnittstellen dazwischen nicht ordentlich getrennt werden, sind nur fest geplante Auslieferungen von neuen Funktionen möglich. Dadurch reduzieren sich die Geschwindigkeit und die Flexibilität in der Entwicklung, also die Time-To-Market, in einem schlechten Applikationsdesign erheblich. Bei einem Monolithen ist deshalb immer auf einen sauberen, definierten Modulschnitt zu achten, um ungewollte Abhängigkeiten im Code zu vermeiden.

Diese Beispiele zeigen, dass viele der genannten Vorteile einer Migration in die Cloud für einen Monolithen nicht generell gültig sind. Trotzdem überwiegen auch bei dieser Software-Architektur die „Pros“ für den Weg in die Cloud. Allerdings ist entscheidend, diesen Weg nicht blind und ohne Planung zu beschreiten. Was wird also benötigt, um die versprochenen Vorteile einer Cloud-Lösung in der Praxis zu nutzen? Diese Frage wird im zweiten Teil des Artikels beschrieben.

Quellen:

[1] https://a16z.com/2021/05/27/cost-of-cloud-paradox-market-cap-cloud-lifecycle-scale-growth-repatriation-optimization/

Ein Gastbeitrag von: