Entwickeln Sie noch Cloud-Agnostic oder schon Cloud-Native?

Nach zahlreichen Diskussionen bin ich überzeugt, dass IT-Architekten drei Begriffe klar unterscheiden sollten: Cloud-Ready, Cloud-Agnostic und Cloud-Native.

Warum? Das möchte ich in diesem Blog zeigen und ich bin gespannt, ob Sie es am Ende genauso sehen.

Auf der Suche nach einer Definition dieser Begriffe bin ich bei der Cloud Native Computing Foundation (CNCF) fündig geworden. Sie definiert „Cloud-Native“ über den Betrieb in der Cloud mit hoher Automatisierung und entkoppelten IT-Systemen.

Vereinzelt findet man auch die Gegenüberstellung von Cloud-Ready und Cloud-Native. Hier ein Beispiel:

A “cloud enabled” or “cloud ready” application is a legacy software program that has been modified to run on a cloud computing infrastructure (i.e. …). Cloud ready applications are distinct from “cloud native” or “cloud born” applications – which are developed from the ground up to run exclusively in cloud environments.

Die Trennlinie verläuft also zwischen einer Legacy-Anwendung, die so modernisiert wurde, dass sie auch in der Cloud betrieben werden und einer von Grund auf neu für und in der Cloud entwickelten Anwendung. Für mich ist das eine sehr unscharfe Unterscheidung, die in beiden Fällen zu einer Anwendung führt, die in der Cloud betrieben werden kann.

Dagegen folge ich gerne der Gegenüberstellung von Cloud-Agnostic und Cloud-Native aus diesem Blogbeitrag „Cloud native vs. Cloud agnostic – what conundrum behind the hype?“. Hier wird auf die wichtige Eigenschaft hingewiesen, ob eine Anwendung in jeder Cloud oder nur in einer bestimmten Cloud betrieben werden kann. Damit sind die Diskussionen, ob eine Anwendung in der Cloud ready, agnostic oder native ist, kein „Nerd-Talk“ mehr sondern fokussieren auf eine für Unternehmen wichtige Eigenschaft.

Für mich und letztlich wohl auch für die meisten Unternehmen macht es einen großen qualitativen Unterschied, ob man eine Anwendung mit der Eigenschaft Cloud-Agnostic oder Cloud-Native entwickelt:

1. Eine Anwendung ist Cloud-Agnostic, wenn sie in jeder(!) Cloud betrieben werden kann.
2. Eine Cloud-Native Anwendung nutzt intensiv native Services wie zum Beispiel aus den Service-Katalogen von AWS Lambda, MS Azure Functions oder Google Cloud Functions. Als Konsequenz kann die Anwendung nicht mehr in jeder Cloud betrieben werden. Sie ist also nicht Cloud-Agnostisch.
3. Sowohl Cloud-Native und Cloud-Agnostic schließen Cloud-Ready ein. Cloud-Ready ist eine Anwendung, wenn man sie ausschließlich per Konfigurationsänderung in der Cloud installieren und betreiben kann. Sie ist „ready“ für die Cloud.

Auswirkungen von Cloud-Anwendungen auf den Unternehmensbetrieb 

Unter nativen Services eines Cloud-Anbieters verstehen wir solche Services, die entweder nicht jeder Cloud-Anbieter anbietet oder die mit so unterschiedlichen Schnittstellen (APIs) angeboten werden, dass ein Umstieg nicht ausschließlich per Konfiguration möglich ist, sondern Änderungen im Quellcode der Software benötigen. Somit macht man sich abhängig von dem Cloud-Betreiber beziehungsweise von einem großen Hyperscaler wie Google, Amazon oder Microsoft. Wie hoch der Preis für diese Abhängigkeit ist, hängt auch davon ab, welchen Abhängigkeiten man als Unternehmen bereit ist zu akzeptieren.

Auf der Habenseiten lassen sich Cloud-Native Anwendungen schneller und damit auch preiswerter entwickeln, da intensiv native Services genutzt werden, die man ansonsten zusätzlich entwickeln oder zumindest  finden und integrieren müsste. Schneller und preiswerter kann ein großer Vorteil sein, wenn man dadurch eine Idee schneller an dem Markt bringen kann.

Cloud-Agnostic Anwendungen haben dagegen den Vorteil, dass man frei in der Wahl des Cloud-Anbieters bleibt. Von privater Cloud im eigenen Rechenzentrum über einen kleinen lokalen Cloud-Anbieter bis hin zu den großen, den Markt dominierenden Cloud-Anbietern aus Übersee bleibt alles möglich. Gerade in der öffentlichen Verwaltung müssen diese Überlegungen eine große Rolle spielen, um die angestrebte Souveränität zu erlangen beziehungsweise zu erhalten.

Um durch den Betrieb in der Cloud Betriebskosten zu sparen, reicht es aus, die Anwendungen Cloud-Ready zu entwickeln. Dann kann man bereits bei entsprechendem Lastprofil von den flexiblen Preismodellen des Typs „Pay-Per-Use“ profitieren und muss beispielswiese nur selten bei hoher Last benötigte Ressourcen nicht dauerhaft vorhalten und bezahlen.

Die Abgrenzung der drei Begriffe Cloud-Ready, Cloud-Agnostic und Cloud-Native ist für Unternehmen geschäftskritisch und somit keine Wortklauberei unter Spezialisten. Können Sie jetzt die Frage beantworten, ob Ihre Anwendungen noch Cloud-Agnostic oder schon Cloud-Native sind?

Diskutieren Sie mit mir über Ihre Ansichten und die damit verbunden Auswirkungen. Ich bin auf Ihre Kommentare gespannt.

Wenn Sie dieser Beitrag interessiert hat, könnte Sie auch mein Artikel zu Software Entwicklung 4.0 interessieren.