Probleme mit der Cloud vermeiden

Gerade zu Beginn eines Projektes ist es natürlich sehr angenehm, einfach die Service-Angebote der großen Cloud-Anbieter zu nutzen. Doch wenn die Architektur einer Anwendung mit der Zeit komplexer wird, reichen die zuschaltbaren Services oft nicht mehr aus.

Auch datenschutzrechtlich sind Cloud-Native-Strategien nicht unumstritten: Je nach Herkunftsort des App- oder Service-Anbieters unterscheiden sich die dort zu Grunde liegenden Bestimmungen zum Datenschutz erheblich von denen der darauf basierenden Anwendungen.

Eine Frage der Kosten

Cloud Native ist auch wegen der damit verbundenen Kosten nicht immer die beste Wahl. Cloud-Anbieter locken mit sehr lukrativen Angeboten für kleine Anwendungen. Skalieren die Projekte oder erhöht sich der Traffic einzelner Services, können die Kosten recht schnell explodieren. Mit erheblichen finanziellen Belastungen müssen Projektleiter insbesondere bei einem gewünschten Wechsel des Cloud-Providers rechnen: Nicht selten vergessen Unternehmen beim Festlegen ihrer Cloud-Native-Strategie, einen Wechsel einzuplanen – und setzen voll auf einen Anbieter.

Auch technisch ist der Umzug in eine andere Cloud meistens nicht ohne weiteres möglich. Erst in einer solchen Situation zeigt sich, ob das womöglich nicht „Cloud Native“, sondern eher „AWS Native“ oder „Azure Native“ gearbeitet wurde.

Die Spezialisierung der Entwickler selbst spielt in einer solchen Situation ebenfalls eine Rolle: Haben sie sich komplett auf das Arbeiten mit einem Provider spezialisiert, müssen sie neue Skills erst erlernen, denn jede Cloud ist anders. Die Bindung an einen bestimmten Service und damit an einen Cloud-Anbieter kann eine Cloud-Native-Strategie quasi in zweiter Instanz zum Scheitern verurteilen.

Microservices als Alternative

Um nicht in Kostenfallen und einen Vendor-Lock-in zu geraten, sind andere Vorgehensweisen empfehlenswert, ohne dabei zwangsläufig auf die Nutzung der Cloud verzichten zu müssen: Domain-driven Design ist eine geeignete Methode zur Modellierung komplexer Software. Im Kern geht es bei DDD darum, monolithische Software-Architekturen zu vermeiden und die Anwendung stattdessen in fachliche Komponenten aufzuteilen. Diese Komponenten, die Entwickler heutzutage gerne als sogenannte Microservices implementieren, kommunizieren dann via Schnittstellen (etwa über „Rest“) miteinander.

Sind diese Microservices in Docker-Container verpackt, kann das Unternehmen Clouds nutzen, ohne sich von einer bestimmten abhängig zu machen – Docker-Container laufen nämlich praktisch überall gleich. Ändert ein Cloud-Anbieter seine Angebote, gelingt ein Umzug in eine andere Cloud einfacher und kostengünstiger. Wächst die Anwendung, sucht sich das Unternehmen für den neuen Container ganz einfach die passende Umgebung aus – on-premises oder online.

Man muss sich im Klaren sein, dass die Kosten für einen Umzug steigen, je Cloud-spezifischer die Services genutzt werden. Daher ist eine möglichst unabhängige Strategie empfehlenswert – und eine Nutzung der Standarddienste von Cloud-Anbietern nur dann, wenn die Abhängigkeit an dieser Stelle vertretbar ist. Vor allem die Businesslogik sollten Unternehmen nicht komplett an einen Anbieter binden: Diese ist in einem Docker-Container besser aufgehoben.