Die Cloud ist das Sehnsuchtsziel vieler Unternehmen. Und nicht nur das: Die gesamte Entwicklung soll nach Möglichkeit Cloud Native ablaufen. Doch der Traum von Cloud Native platzt meistens dann, wenn Unternehmen bereits mit der Umsetzung begonnen haben. Dann nämlich tauchen viele Lücken im Plan und Probleme in der Praxis auf, die zuvor noch nicht sichtbar waren.
Warum Cloud Native nicht immer die beste Idee ist und welche Alternativen existieren, verrät Avision.
Gerade zu Beginn eines Projektes ist es natürlich sehr angenehm, einfach die Service-Angebote der großen Cloud-Anbieter verwenden zu können. 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 laut Avision nicht ganz 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
Ein weiterer Faktor, warum Cloud Native nicht immer die beste Wahl ist, sind die damit verbundenen Kosten. Cloud-Anbieter locken mit sehr lukrativen Angeboten für kleine Anwendungen. Skalieren Unternehmen ihre Projekte allerdings oder erhöht sich der Traffic der einzelnen 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 Unternehmen womöglich nicht „Cloud Native“ sondern eher „AWS Native“ oder „Azure Native“ gearbeitet hat. 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 mühsam 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, können Unternehmen andere Vorgehensweisen nutzen. Es ist wichtig zu erwähnen, dass sie dabei nicht zwangsläufig auf die Nutzung der Cloud verzichten müssen: Domain-driven Design (DDD) ist eine geeignete Methode zur Modellierung komplexer Software.
Im Kern geht es bei DDD darum, monolithische Softwarearchitekturen 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 dann auch noch 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, also on-premise oder online.
„Unternehmen müssen sich im Klaren sein, dass die Kosten für einen Umzug steigen, je Cloud-spezifischer sie Services nutzen“, warnt Nadine Riederer, CEO bei Avision. „Sie sollten sich daher eine möglichst unabhängige Strategie überlegen und Standarddienste der Cloud-Anbieter nur nutzen, 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.“