Was bedeutet eigentlich Cloud Native?
(Bild: everything possible / shutterstock)
Aber was genau ist Cloud Native?
Vereinfacht könnte man sagen: Je mehr Plattform-Services der Cloud die Applikation nutzt, desto näher kommt sie dem Cloud-Native-Zustand. Eine etwas komplexere Definition des Begriffs gibt die Cloud Native Computing Foundation (CNCF): „Cloud-Native-Technologien ermöglichen es Unternehmen, skalierbare Anwendungen in modernen, dynamischen Umgebungen zu implementieren und zu betreiben. Dies können Public, Private und Hybrid Clouds sein.“ Best Practices wie Container, Service-Meshs, Microservices, immutable Infrastruktur und deklarative API unterstützen diesen Ansatz.
Im Kern geht es also um die Entwicklung moderner Applikationen mit agilen Methoden – und darum, sie dynamisch, skalierend und fehlertolerant in einer oder mehreren Clouds bereitzustellen. Dabei ist wichtig, dass die Architektur modular und flexibel ist. Microservices bilden hierbei die Grundlage. Software wird in kleineren, voneinander unabhängigen Einheiten entwickelt, die granularer aktualisiert und schneller ausgeliefert werden können.
Die großen Player machen es vor
Einer der Pioniere dieses Ansatzes ist Netflix. Der Streaming-Anbieter erkannte, dass für den Betrieb einer globalen Videoplattform in Zeiten der Public Clouds keine eigene Infrastruktur notwendig ist. Stattdessen ging Netflix früh „all in“ und entwickelte im Laufe der Zeit eine der größten Cloud-Native-Applikationen der Welt. Im Nachhinein betrachtet hat die Nutzung von Amazon Web Services als Plattform das Netflix-Wachstum der letzten Jahre wohl erst ermöglicht. Denn neben der schnellen Skalierung von Ressourcen spielten die weltweit einheitlichen Schnittstellen eine entscheidende Rolle. So konnte der gleiche Code ohne Anpassungen einfach in weiteren Ländern ausgerollt werden – eine immense Zeit- und Kostenersparnis.
Ein weiterer Erfolgsfaktor war, dass Netflix seinen Service im Rahmen der Cloud-Migration von Grund auf neu entwickelte und möglichst viele native Services von AWS verwendete. Hätte Netflix versucht, seine Applikation von der vorhandenen Infrastruktur eins zu eins in die Cloud zu übertragen, wären die Probleme aus dem Rechenzentrum gleich mit umgezogen.
Das Problem mit dem Lock-in – und mögliche Lösungsansätze
Als Argument gegen den Cloud-Native-Ansatz wird oft die Abhängigkeit von der gewählten Plattform angeführt. Wenn man sich beispielsweise wie Netflix für AWS und die serverlose Datenbank Dynamo-DB entscheidet, kann man nur mit sehr hohem Aufwand zu einer anderen Cloud wechseln. Das Problem ist die unterschiedliche Syntax für Datenbank-Abfragen. Sie führt bei einem Umzug dazu, dass große Teile des Codes neu oder zumindest umgeschrieben werden müssen.
Abhilfe schafft hier der Einsatz von Containern. Denn neben der Kostenersparnis ist der größte Vorteil von containerisierten Anwendungen, dass sie portabel und überall lauffähig sind. Insbesondere Kubernetes/K8s, die Container-Orchestration-Lösung von Google, ist durchgängig flexibel einsetzbar. Die Schnittstellen in Richtung Entwickler oder Devops-Engineer bleiben gleich – egal, auf welcher Cloud die Applikation am Ende läuft.
Darf’s noch ein bisschen weniger sein? Functions-as-a-Service
Neben diesen containerbasierten Services (CaaS) haben die großen Public-Cloud-Anbieter allerdings auch Function-as-a-Service (FaaS)- sowie Platform-as-a-Service (PaaS)-Angebote, die ebenfalls für Cloud-Native-Anwendungen geeignet sind.
Bei FaaS-Diensten wie Lambda, Google Cloud Functions oder Azure Functions werden Code-Snippets in Form von Funktionen einer Programmiersprache bei der Plattform hochgeladen und verknüpft. Dieser Ansatz wird auch als Serverless bezeichnet, da man sich im Betrieb nicht mehr um Server und deren Betriebssysteme kümmern muss.
Serverless-Architekturen sind „pay as you go“ in Perfektion und besonders für stark schwankende Lasten geeignet. Solange keine Funktionen ausgeführt werden, entstehen auch keinerlei Kosten. Um diese FaaS-Angebote jedoch effektiv nutzen zu können, müssen bestehende Apps in ihre Einzelteile (Funktionen) zerlegt und neu „verdrahtet“ oder komplett neu geschrieben werden.
Der Vendor-Lock-in ist bei FaaS wiederum hoch – man ist zunächst regelrecht in der jeweiligen Cloud „gefangen“. Daher haben verschiedene Initiativen diese Thematik aufgegriffen: Man kombiniert alle Layer miteinander: IaaS, PaaS und FaaS. So ermöglicht K8s die Nutzung von FaaS auf jeder Kubernetes-fähigen Cloud. Die Applikation bleibt portabel und kann jederzeit auf einer anderen Cloud betrieben werden.
Zum Cloud-Native-Konzept gehört jedoch nicht nur der Entwicklungsprozess, sondern auch das Ausrollen von neuen Applikationsversionen. Bei Cloud-Native-Apps setzt man ausschließlich auf Continuous Integration und Continuous Delivery: Sogenannte Delivery-Pipelines werden komplett automatisiert und mit autonom ablaufenden Tests versehen, sodass der Entwickler auf Knopfdruck seine Applikation in die Cloud pushen kann.
Safety first!
Gerade solche CI/CD-Pipelines können sich auch positiv auf die Sicherheit auswirken. Durch automatisierte Checks auf Schwachstellen im Code oder klassische Programmierfehler vor jedem Deployment lässt sich die Code-Qualität ohne viel Aufwand deutlich steigern.
Generell sind Cloud-Native-Applikationen oft sicherer als ihre klassisch betriebenen Vorgänger. Denn abgesehen von der Sicherheit der Anwendung, für die die Entwickler selbst verantwortlich sind, gehen bei den FaaS- und PaaS-Modellen große Teile der Betriebsverantwortung an die Betreiber der Plattformen über. So müssen sich Inhouse-Teams teils nicht mehr um die Sicherheit des Betriebssystems und das zeitnahe Einspielen von Patches kümmern.
Generell spricht man hier von den vier C:
- Code
- Container
- Cluster
- Cloud
Es existiert also eine geteilte Verantwortlichkeit zwischen Cloud-Kunde und -Anbieter. Das ist auch gut so, denn viele Entwickler haben nur Erfahrung mit dem Code. Doch um keine böse Überraschung zu erleben, müssen auch die anderen drei C abgedeckt werden. Wichtig ist beispielsweise, zu bestätigende Version-Upgrades zeitnah durchzuführen, da die Änderungen selbst bei kleinen Versionssprüngen oft signifikant und sicherheitsrelevant sind.
Fazit
Cloud Native bietet ein hohes Maß an Flexibilität und ermöglicht, die Vorteile der Cloud in vollem Umfang zu nutzen. Es gibt verschiedene Alternativen, die Transformation der eigenen Applikationen durchzuführen. Ein Unternehmen muss hier abwägen, welcher Ansatz seine konkreten Anforderungen erfüllt und welche Gewichtung die unterschiedlichen Faktoren beim Weg in die Cloud haben.
Bitte beachte unsere Community-Richtlinien
Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.
Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.
Dein t3n-Team
So viel schöne Buzzwords und Abkürzungen. Geil.
„Das Problem ist die unterschiedliche Syntax für Datenbank-Abfragen. Sie führt bei einem Umzug dazu, dass große Teile des Codes neu oder zumindest umgeschrieben werden müssen.
Abhilfe schafft hier der Einsatz von Containern. “
Dafür würde ich eine 6 geben. Oder anders gesagt, inhaltlich falsch.
Danach habe ich aufgehört zu lesen.
Der Code muss nämlich umgeschrieben werden, wenn man zu einer anderen DB wechselt. Da ändert auch nicht die Auslieferung von Container nichts dran.
@Stefan, danke für das Feedback. Damit ist nicht gemeint, dass Container, die eine DynamoDB konsumieren, plötzlich auf einer anderen Cloud oder on-premise problemlos laufen. Die genannte DB war nur ein Beispiel von vielen Services, die die Hyperscaler anbieten und eine Einleitung zu Containern/K8s.
Die Idee ist, diesen Lock-In mit Hilfe von Container von Beginn an bewusst zu umgehen und keinen dieser (ggf. proprietären) Services zu nutzen. Die Abhängigkeiten liefert man direkt mit und konsumiert lediglich Dienste wie z.B. s3, welches man anderswo auch z.B. mit minio abbilden könnte.