Was Cloud Native bedeutet – und was nicht

Cloud Native beschreibt ein modernes, agiles Konzept, bei dem Software für den Betrieb in der Cloud entwickelt wird. So können Unternehmen die Vorteile der Cloud voll ausschöpfen. Daher sind viele Entscheider bestrebt, ihre Applikationen und Prozesse so schnell wie möglich auf die neue Methode umzustellen. Allerdings gibt es auch einige falsche Vorstellungen und Missverständnisse rund um Cloud Native. Im Folgenden werden sie auf den Prüfstand gestellt.

Cloud Native wird vielerorts als neue Maxime für IT-Abteilungen ausgerufen. Cloud-native Software wird als robust, flexibel und frei skalierbar gehandelt, optimal für agil ausgerichtete Unternehmen. Und prinzipiell stimmt das auch. Nur ist die Sache nicht ganz so einfach – zumindest, wenn Cloud-native Architekturen im strengen Sinne gemeint sind: Anwendungen, die sich aus Microservices zusammensetzen, auf dynamischen Infrastrukturen betrieben werden und über Service Meshes kommunizieren.

Fünf Cloud-Native-Mythen im Faktencheck

Mythos #1: Nach einem Lift & Shift meiner Infrastruktur sind meine Workloads cloud-nativ.

Das trifft nicht zu. Migriert man Anwendungen nach dem Lift-and-Shift-Prinzip vom eigenen Rechenzentrum auf virtuelle Maschinen in die Cloud, ist das tatsächlich nur der erste Schritt auf dem Weg hin zu Cloud Native. Dieser relativ einfach zu erreichende Zustand wird auch als „cloud based" bezeichnet. Die Migration der Anwendung in die Cloud ist vollzogen, die Möglichkeiten der Cloud werden aber nur in begrenztem Umfang genutzt.

Cloud Native ist dagegen ein viel umfassenderer Ansatz (siehe auch /de/blog/was-ist-cloud-native), der neben der geänderten Infrastruktur auch eine neue Software-Architektur, neue Tools, neue Wege der Organisation und sogar eine ganz andere Arbeitskultur im Unternehmen bedeutet. Dabei werden beispielsweise kleine Entwicklerteams gebildet, die mit agilen Methoden und mit mehr Eigenverantwortung arbeiten. Ziel all dieser Maßnahmen ist ein deutlicher Zeitgewinn bei der Umsetzung neuer Projekte und eine allgemeine Steigerung der Agilität: Die IT kann insgesamt flexibler und schneller auf Veränderungen reagieren.

Mythos #2: Durch Cloud Native wird Komplexität abstrahiert.

Dies stimmt nur teilweise. Durch die Verlagerung von Anwendungen und Prozessen in die Cloud kann ein Unternehmen je nach Bereitstellungsmodell (IaaS, PaaS, SaaS etc.) mehr oder weniger Verantwortung an einen Managed Service Provider oder den Hyperscaler abgeben. Darüber hinaus kann nach dem Prinzip der geteilten Verantwortung (Shared Responsibility) mit Managed Service Providern vereinbart werden, dass sie weitere Aufgaben und Verantwortlichkeiten übernehmen und sich z. B. um die Überwachung oder den Support kümmern.

Neue Komplexitäten: Beispiel eines Cloud Native Stacks auf Basis von Kubernetes in der Public Cloud

Allerdings entstehen bei der Umsetzung des Cloud-Native-Prinzips zwangsläufig auch neue Herausforderungen:

• Neue Komplexitäten: Neue Technologien und die verteilte Natur von Cloud-Native-Anwendungen erfordern mehr Aufmerksamkeit der IT-Teams. Beispielsweise ist eine Orchestrierungssoftware wie Kubernetes erforderlich, um die Container der Microservices zu koordinieren. Darüber hinaus benötigt jeder Microservice Unterstützung für die Einbettung in das Gesamtsystem (Service Discovery). Die Tatsache, dass Microservices asynchron kommunizieren und nur lose gekoppelt sind, bedeutet auch, dass die Fehlersuche schwieriger ist als bei monolithischen Anwendungen. Ein weiterer Komplexitätsfaktor ist die lokale Datenhaltung, bei der jeder Dienst die von ihm benötigten Daten in seinem eigenen Container speichert. Dieses Prinzip führt dazu, dass die lokalen Daten immer erst zusammengeführt werden müssen, bevor ein Gesamtbild der Anwendungsdaten möglich ist - etwa für statistische Auswertungen.
• Höhere Taktung: Die Cloud-Plattformen und die verwendeten Tools werden ständig weiterentwickelt. Anders als bei klassischen Anwendungen kann man sich dieser hohen Taktrate nicht einfach entziehen, sondern muss seine eigenen Anwendungen und Prozesse laufend anpassen.
• Lifecycle Management: Die Aufteilung in viele Einzelkomponenten und die Vielzahl der verwendeten Technologien machen die Prozesse rund um den Lebenszyklus cloud-nativer Anwendungen erheblich aufwendiger.
• Governance: Die zunehmende Agilität in der Softwareentwicklung führt unweigerlich zu sehr unabhängig arbeitenden Teams. Daher müssen ein Regelwerk und organisatorische sowie technische Maßnahmen etabliert werden, um zu jeder Zeit die Kontrolle über Anwendungen und Daten zu behalten und ein konsistentes Gesamtsystem zu gewährleisten.
• Security: Die höhere Taktung und die neue Art von Software-Architektur bringen neue Bedrohungen und Herausforderungen im Bereich IT-Sicherheit mit sich, deren Ausmaß für unerfahrene IT-Teams kaum zu überblicken ist.

Mythos #3: Cloud Native ist „secure by design“.

Das ist eine Fehleinschätzung. Und eine gefährliche noch dazu. Im Vergleich zu monolithischen Anwendungen ergibt sich tatsächlich eine neue Sicherheitssituation mit neuen Angriffspunkten. Diese ergeben sich allein schon aus der Vielfalt der verwendeten Technologien. Mit den neuen Konzepten werden auch zahlreiche neue Komponenten ins Spiel gebracht, wie etwa erforderliche Tools, Drittanbieter-Bibliotheken oder APIs. Mit all diesen Elementen steigt auch die Zahl der denkbaren Angriffsvektoren, die von unerfahrenen Teams nur schwer zu überblicken sind.

Dass Cloud Native dennoch sicher betrieben werden kann, ist den ebenfalls weiterentwickelten Methoden zur Bedrohungsabwehr zu verdanken. Auf jeder Granularitätsstufe, vom Programmcode über Container bis hin zur gesamten Cloud, gibt es Maßnahmen und Tools, um die Sicherheit zu gewährleisten. Gefragt sind dafür jedoch maßgeschneiderte Sicherheitskonzepte, verbunden mit klaren Verantwortlichkeiten, die definieren, welche Teams und Rollen welche Aufgaben zu übernehmen haben.

The 4 C's of Cloud Native Security: Das Waffenarsenal für sichere Cloud Native Stacks

Mythos #4: Bei Cloud Native geht es vor allem um Kostensenkung.

Das ist irreführend. Die Kostensenkungseffekte sind oftmals nur kurzfristig. Im Detail bedeutet das: Ein Lift-and-Shift-Umzug von Workloads auf eigener Infrastruktur in die Cloud bringt in der Regel zunächst Kostenvorteile, z. B. weil keine ungenutzten Serverkapazitäten mehr vorgehalten werden müssen (elastische Skalierbarkeit durch Pay-as-you-grow-Abrechnungsmodelle) und Investitionsausgaben durch Betriebskosten abgelöst werden (OPEX statt CAPEX). Und durch Cloud-native Applikationen lassen sich zusätzliche Kostenvorteile durch effizientere Ressourcennutzung und schnelle Umsetzungszeiten erzielen. Diese sind jedoch weniger signifikant als im erstgenannten Fall. Was dabei jedoch häufig außer Acht bleibt: Die vermeintlichen Einsparungen relativieren sich in den meisten Fällen durch im weiteren Verlauf höhere Betriebskosten aufgrund der gestiegenen Komplexität (Stichwort: Day 2 Operations).

Viel wichtiger als positive TCO-Effekte sind die Potenziale von Cloud Native in Bezug auf Effizienz und Geschwindigkeit. Unternehmen können die digitale Transformation vorantreiben und innovativ bleiben, indem sie ihre eigenen Anwendungen kontinuierlich modernisieren, um ihr Geschäftsfeld weiterzuentwickeln. Dieser Zugewinn an Wettbewerbsfähigkeit ist deutlich wertvoller als eine Senkung der IT-Kosten.

Mythos #5: Cloud Native bedingt kein neues Betriebsmodell.

Diese Annahme ist falsch. Für den Cloud-Native-Betrieb müssen geeignete Modelle und Konzepte gefunden werden, die den veränderten Rahmenbedingungen gerecht werden. Dass Entwickler, dem DevOps-Gedanken folgend, auch für den Betrieb der Anwendungen mitverantwortlich sind, muss bei Cloud Native jedoch überdacht werden. Denn die neuen Komplexitäten machen es Entwicklern schwer, das gesamte Feld der Anforderungen abzudecken. Es gibt auf Cloud Native abgestimmte Best Practices für eine neue Rollenverteilung, die diese Herausforderung adressieren.

Fazit: Unternehmensanwendungen neu denken

Eine ausführlichere Widerlegung dieser fünf Mythen finden Sie im Video der Keynote von Fabian Dörk auf der Cloud Native Conference 2021. Doch auch an dieser Stelle sollte deutlich geworden sein, dass Cloud-native Softwarestacks neue Prozesse und Ansätze jenseits des engeren Feldes des Application Managements erfordern. Dennoch ist der Cloud-Native-Ansatz eine wesentliche Voraussetzung dafür, dass Unternehmen die digitale Transformation erfolgreich meistern und ihre Anwendungen und die Anwendungsentwicklung selbst dauerhaft modern halten können.

Wenn die digitale Transformation gelingen soll, müssen Unternehmen mit einem soliden IT-Konzept starten und das richtige digitale Fundament schaffen. Cloud Native ist dafür ein wesentlicher Baustein. Denn das Konzept bietet eine ganz neue Ebene an Innovationspotenzial für Unternehmensanwendungen.

Cloud-Native-Computing ist mehr als ein evolutionärer Schritt, es ist vielmehr ein Paradigmenwechsel. Das bedeutet auch, dass die damit verbundenen Prozesse, Werte und Technologien in die Strategie, die Organisation und die Unternehmenskultur integriert werden müssen. Diese nichttechnischen Punkte entscheiden in der Praxis maßgeblich darüber, ob die jeweilige Cloud-Native-Strategie letztlich zum Erfolg führt.