Die Meinungen darüber, welche Phasen es auf dem Weg in die Cloud gibt, variieren stark. Doch in einem Punkt ist sich der Markt einig: „Cloud Native“ ist die letzte Etappe der Reise und damit die Königsdisziplin der Softwareentwicklung und Migration von Anwendungen. Maximilian Breig, Senior Cloud Engineer bei Claranet, erläutert in diesem Beitrag das innovative Designprinzip und gibt Praxistipps aus erster Hand. Wer bis zum Ende liest, weiß nachher sogar, wie man mit Containern und Kubernetes den gefürchteten Vendor-Lock-in vermeidet, wie unser Experte die FaaS- und PaaS-Angebote der Hyperscaler bewertet und warum Cloud-native Applikationen ohne Continuous Delivery Pipeline nur die halbe Miete sind.
Eine Applikation muss nicht zwingend an die spezifischen Anforderungen und Schnittstellen einer bestimmten Cloud angepasst werden, um dort grundsätzlich lauffähig zu sein. So lässt sich nicht das Beste aus den jeweiligen Plattformen herausholen und die App kann auch nicht wirklich alle Vorteile nutzen, die z. B. die großen Public-Cloud-Anbieter wie AWS, Azure oder GCP bieten. Aber der im Vergleich gering erscheinende Aufwand war, zumindest auf den ersten Blick, verständlicherweise verführerisch für Unternehmen, die zu Beginn der Public-Cloud-Ära einer Cloud-First- oder All-In-Strategie folgten.
Cloud Enabled Apps sind derzeit noch populärer
Heute sieht man in der Regel eher „Cloud Enabled“ Apps, also Applikationen, die im Unterschied zum einfachen „Lift & Shift“, auch „Re-Hosting“ genannt, für den Betrieb in der Cloud optimiert wurden. Meistens dahingehend, dass sie bereits einige der angebotenen Services nutzen, die es so in der klassischen Infrastruktur nicht gibt.
Ein gutes Beispiel ist die Unterstützung von Object Storage wie S3. Statt Daten weiterhin auf blockbasiertem Speicher, also den lokalen Festplatten einer Instanz abzulegen, kann die Anwendung so mit einer relativ kleinen Anpassung von fast unbegrenztem Speicherplatz und einfacher Skalierung profitieren, was sich auch in der Performance und der Verfügbarkeit bemerkbar macht. Denn im Vergleich zu einer einzelnen VM, deren Festplatten je nach Anbieter teilweise ohne Replikation und Redundanz nur in einem einzelnen Rechenzentrum vorhanden sind, werden beim klassischen Object Store die Daten in der Regel automatisch in andere Verfügbarkeitszonen gespiegelt. So stehen sie selbst beim kompletten Ausfall eines Datacenters noch zur Verfügung.
Aber was genau ist „Cloud Native“? Ein Definitionsversuch
Vereinfacht könnte man sagen, je mehr dieser von den Plattformen angebotenen „Managed Services“ eine Applikation nutzt, desto näher kommt sie dem Cloud Native-Zustand. Für eine etwas komplexere Definition des Begriffs zitiert man wohl am besten die Cloud Native Computing Foundation, kurz CNCF:
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”
Im Kern geht es also um die Entwicklung moderner Applikationen mit agilen Methoden – und darum, diese dynamisch, skalierend und fehlertolerant in einer oder mehreren Clouds zu deployen. Dabei ist es wichtig, dass die Architektur anders als bei klassischen monolithischen Ansätzen besonders modular und flexibel ist. Möglichst autonome Microservices, die über solide (Restful) APIs und Queues miteinander kommunizieren und Daten austauschen, bilden hierbei die Grundlage. Denn nur so ist gewährleistet, dass ein Entwickler oder ein Team, das an einer Komponente arbeitet, keine negativen Auswirkungen auf andere Services hat oder womöglich sogar andere Teams blockiert. Hilfreich ist hierbei, die Microservices ganz nach dem Motto „KISS – Keep it simple and stupid!“ in ihrem Funktionsumfang möglichst stark zu beschränken.
Die großen Player machen es vor
Einer der Pioniere dieses Ansatzes ist definitiv Netflix. Der Streaming-Anbieter, der früh ausschließlich auf die AWS Cloud von Amazon setzte, hat verstanden, dass für den Betrieb einer globalen Videoplattform in Zeiten der Public Clouds keine eigene Infrastruktur mehr benötigt wird. Stattdessen ging Netflix früh „All in“ und entwickelte im Laufe der Zeit wohl nicht nur eine der ersten, sondern vor allem eine der größten Cloud Native-Applikationen der Welt. Im Nachhinein betrachtet hat die Nutzung von Amazon Web Services als IaaS-Plattform das Netflix-Wachstum der letzten Jahre wohl überhaupt erst ermöglicht. Denn neben der schnellen Skalierung von Ressourcen spielten für den globalen Rollout in dieser Geschwindigkeit die weltweit einheitlichen APIs eine entscheidende Rolle. So konnte der gleiche Code ohne Anpassungen einfach in weiteren Ländern ausgerollt werden – eine unglaubliche Zeit- und Kostenersparnis.
Ein weiterer nicht zu vernachlässigender Faktor für den Erfolg von Netflix ist allerdings, dass das Unternehmen sich nicht davor scheute, seinen Service im Rahmen der Cloud Migration von Grund auf neu zu entwickeln und dabei so viel native Services von AWS zu verwenden wie möglich. Hätte Netflix versucht, seine Applikation von der vorhandenen Infrastruktur eins zu eins in die Cloud zu migrieren und so die bestehende Architektur so gut es geht abzubilden, wären die Probleme aus dem Rechenzentrum gleich mit umgezogen. Das ist auch die wohl wichtigste Abgrenzung zu „Cloud Enabled“ Applikationen. Im Gegensatz zum Cloud Native-Ansatz werden diese nicht für die Cloud entwickelt und später nur soweit angepasst, dass sie auch in der Cloud lauffähig sind. Leider ist es dann in den allermeisten Fällen so, dass sie kaum Vorteile der Clouds nutzen. Getreu der Devise „No pain, no gain!“ darf man sich also nicht vor der Arbeit scheuen, die ein solches Refactoring des Codes mit sich bringt – von nichts kommt eben auch nichts.
Das Problem mit dem Lock-in – und mögliche Lösungsansätze
Bei aller Euphorie sei natürlich noch auf einen wichtigen Punkt hingewiesen, der gerne auch als schlagendes Argument gegen den Cloud Native-Ansatz angeführt wird: Je mehr native Services eines bestimmten Cloud-Anbieters in der Architektur einer App genutzt werden, desto abhängiger macht man sich durch die Nutzung der proprietären APIs und speziellen Eigenheiten der Services von der ausgewählten Plattform. Wenn man sich also beispielsweise wie Netflix für AWS entscheidet und im großen Stil die serverlose Datenbank DynamoDB einsetzt, kann man nur mit sehr hohem Aufwand zu einem vergleichbaren Service einer anderen Cloud migrieren, also zum Beispiel stattdessen Googles Cloud Datastore auf GCP nutzen – obwohl beide eigentlich „Fully Managed NoSQL database services“ sind. Das Problem ist die unterschiedliche Syntax für Datenbank-Abfragen, die im Falle eines Umzugs dazu führt, dass große Teile des Codes neu oder zumindest umgeschrieben werden müssen.
Um solche Situationen soweit es geht zu vermeiden, ist die Nutzung von Containern im Allgemeinen und Kubernetes im Speziellen bei der Entwicklung und später auch dem Betrieb dieser Microservices oft das Mittel der Wahl. Neben der Kostenersparnis ist der größte Vorteil von containerisierten Anwendungen ihre Portabilität – schließlich bringen sie normalerweise alle Abhängigkeiten mit. Da es sich bei Containern dank der Open Container Initiative (OCI) nicht mehr nur um „Docker”, sondern um einen Standard handelt, sind die Container überall lauffähig und jeder größere Public-Cloud-Anbieter hat entsprechende Container as a Service (CaaS) Plattformen im Portfolio, die das Betrieben einer solchen App stark vereinfachen.
Sollen jetzt aber Daten aus dem Container in einen nativen Service der jeweiligen Cloud ausgelagert werden, steht man schnell vor demselben Problem: Wenn der Code im Container direkt einen S3 Bucket bei AWS anspricht, wird er auf der Google Cloud Platform ohne weitere Anpassungen nicht funktionieren.
Abhilfe schafft hier der Einsatz von Kubernetes, da K8s, wie die Container-Orchestration-Lösung von Google auch abgekürzt wird, entsprechende Abstraktionsschichten mitbringt. Mit diesen lässt sich z. B. Speicherplatz von den verschiedenen Storage Backends der Clouds transparent an die Applikation weiterreichen. Dadurch ist es dem Container egal, ob er bei AWS die Daten auf einem EBS Volume oder bei GCP auf einer Persistent Disk ablegt.
Damit das funktioniert, kümmert sich Kubernetes im Hintergrund um das entsprechende Mapping der verfügbaren Storage Provider. Man kann hier von einer Unified Control Plane sprechen, da die APIs in Richtung Entwickler oder DevOps Engineer gleich bleiben – egal auf welcher Cloud die Applikation am Ende läuft. Kubernetes abstrahiert dies komplett und macht die Cloud somit transparent zum Anwender. Hierfür werden seitens der CNCF sowie durch weitere unabhängige Entwickler im Kubernetes-Kontext ständig Anpassungen vorgenommen, um auf die Änderungen der verschiedenen Public Clouds zu reagieren.
Darf’s noch ein bisschen weniger sein? Functions as a Service
Neben diesen containerbasierten Services haben die großen Public-Cloud-Anbieter allerdings auch Function as a Service (FaaS) sowie Platform as a Service (PaaS) Angebote, die ebenso bestens für Cloud-Native-Anwendungen geeignet sind. Lambda, Google Cloud Functions oder Azure Functions sind hier als Beispiele für FaaS, Elastic Beanstalk, AppEngine und App Service als Beispiele für PaaS zu nennen.
Doch wie grenzen sich diese Konzepte voneinander ab? FaaS-Dienste wie Lambda sind die aktuell wohl kleinste deploy- und abrechenbare Einheit für Applikationen. Dabei werden Code Snippets in Form von Funktionen einer Programmiersprache wie z. B. node.js bei der Plattform hochgeladen und untereinander sowie mit anderen Services, z. B. vollständig verwalteten Datenbanken, verknüpft. Dieser Ansatz wird auch als „Serverless“ bezeichnet, da man sich im Betrieb nicht mehr um Server, also VMs (bzw. Instanzen) und deren Betriebssysteme kümmern muss.
Stattdessen sorgt der Betreiber der Plattform dafür, dass immer genügend Serverkapazitäten zur Verfügung stehen, um die benötigte Anzahl an Funktionen in Abhängigkeit von der zur verarbeiteten Last auszuführen, und die Systeme aktuell und sicher sind. Abgerechnet wird in der Regel nach Dauer (z.B. Laufzeit in Schritten von 100 Millisekunden) sowie den benötigten Ressourcen (Arbeitsspeicher, z.B. 128, 256 oder 512 MB).
Anders als bei einem Kubernetes Cluster, bei dem immer eine gewisse Anzahl an virtuellen Maschinen für die Control Plane und die Grundlast laufen müssen und eine Skalierung auch nur in Schritten von mindestens einem weiteren Node mit vergleichsweise vielen Ressourcen und entsprechender zeitlicher Verzögerung erfolgen kann, liegt der große Vorteil bei Services wie Lambda in der Granularität. Wenn es keine Events gibt, die verarbeitet werden müssen, werden auch keine Funktionen gestartet. Da in diesem Fall nichts ausgeführt wird, entstehen auch keine Kosten – gar keine. Müssen im nächsten Moment 100.000 Events parallel verarbeitet werden, ist das aber auch kein Problem. Serverless-Architekturen sind „Pay as you go“ in Perfektion und deshalb besonders für stark schwankende Lasten geeignet. Hier ist das Einsparpotenzial gegenüber „klassischen“ VM-basierten Lösungen besonders hoch.
Um diese FaaS-Angebote jedoch effektiv nutzen zu können, müssen bestehende Apps in ihre Einzelteile (Funktionen) zerlegt und neu „verdrahtet“ oder, unter Beachtung der Paradigmen agiler Softwareentwicklung, gleich komplett neu geschrieben werden. Dabei wird oft auch noch einmal die ursprünglich gewählte Programmiersprache in Frage gestellt: Klassische Sprachen wie C, C++ finden in der Serverless-Welt in den seltensten Fällen Anwendung. Aber auch modernere Sprachen wie Java werden immer mehr verdrängt, obwohl Frameworks wie Spring Boot eigentlich problemlos Microservices-Architekturen ermöglichen. Stattdessen sind JavaScript (node.js) oder Golang für viele Entwickler heutzutage das Mittel der Wahl, denn das Ökosystem ist groß und die Einstiegshürden sind vergleichsweise niedrig – wenn da nicht die Asynchronität bei JavaScript wäre, die so vielen enorme Kopfschmerzen bereitet…
Sobald eine oder mehrere Applikationen für eine FaaS-Plattform entwickelt wurden, profitieren sie sofort von den beschriebenen Vorteilen. Allerdings ist dafür auch der bereits angesprochene Vendor Lock-in bei der Nutzung einer Functions-as-a-Service-Plattform besonders hoch, man ist zunächst regelrecht in dieser Cloud “gefangen”. Ein Wechsel, z. B. von GCP zu Azure, ist nur mit Anpassungen und damit verbundenem hohen Aufwand möglich.
Daher haben verschiedene Initiativen diese Thematik aufgegriffen: Man kombiniert alle Layer miteinander: IaaS, PaaS und FaaS. Kubernetes stellt hier wieder die Basis und mittels verschiedener Frameworks kann auf dieser Basis FaaS bereitgestellt werden – auf jeder Kubernetes-fähigen Cloud. Somit bleibt die Applikation komplett portabel und kann jederzeit auf einer anderen Cloud deployed werden. Typische Technologien in diesem Kontext sind Kubeless, Knative und Dapr.
Die Rahmenbedingungen müssen stimmen
Zum Cloud Native-Konzept gehört jedoch nicht nur der Entwicklungsprozess. Auch das Deployment der Microservices muss betrachtet werden. Denn während bei Monolithen gerne klassische Methoden wie (S)FTP zum Ausrollen von neuen Applikationsversionen genutzt werden, setzt man bei Cloud Native Apps ausschließlich auf Continuous Integration und Continuous Delivery: Sogenannte Delivery Pipelines werden hochgradig automatisiert und mit autonom ablaufenden Tests versehen, sodass der Entwickler auf Knopfdruck seine Applikation in die Cloud “pushen” kann, ohne sich mit Upload-Mechanismen oder anschließenden Neustarts einzelner Dienste auseinandersetzen zu müssen.
Auf reinen IaaS-Plattformen ist dies nur mit sehr hohem Aufwand möglich, so dass auch hier gerne auf CaaS-, FaaS- oder PaaS-Angebote zurückgegriffen wird. Hat man diese Delivery Pipelines jedoch erst einmal etabliert, sind auch vollautomatische Deployments möglich. Diese können dann z. B. jede Nacht ausgeführt und auch im Rahmen von Unit-Tests oder für QA-Teams benutzt werden.
Safety first!
Gerade solche CI/CD-Pipelines können sich auch extrem positiv auf die Sicherheit auswirken. Durch automatisierte Checks auf Schwachstellen im Code wie beispielsweise den Einsatz veralteter Libraries und Frameworks oder klassische Programmierfehler, die vor jedem Deployment ausgeführt werden, lässt sich die Code-Qualität ohne viel Aufwand noch einmal deutlich steigern.
Doch auch ganz allgemein gesprochen sind Cloud Native-Applikationen insgesamt oft sicherer als ihre klassisch betriebenen Vorgänger. Denn abgesehen von der Sicherheit der Anwendung, für die natürlich weiterhin die Entwickler selbst verantwortlich sind, gehen im DevOps-Kontext bei den FaaS- und PaaS-Modellen große Teile der Betriebsverantwortung an Betreiber der Plattformen über. So müssen sich Inhouse Teams je nach Betriebsmodell gegebenenfalls gar nicht mehr um die Sicherheit des Betriebssystems, das zeitnahe Einspielen von Patches oder den Einsatz aktueller Versionen bei der Middleware kümmern. Damit bleibt Zeit für das Wesentliche: Die Weiterentwicklung der Applikation.
Im CaaS-Kontext ist die Situation ähnlich: Wird ein „fully managed“ Service wie z. B. die Google Kubernetes Engine (GKE) auf GCP oder der Elastic Kubernetes Service von AWS für den Container-Betrieb gewählt, ist man selbst hauptsächlich für die Container-Sicherheit und eine sichere Konfiguration der vom Cluster bereitgestellten Services verantwortlich. Um die Sicherheit des Clusters selbst und der ihn umgebenden Infrastruktur kümmert sich dann wieder der Anbieter.
Generell spricht man hier von den 4 C: Code, Container, Cluster, Cloud. Es existiert also eine so genannte „Shared Responsibility“ 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 3 C abgedeckt werden – teilweise können das beim Einsatz entsprechender Services wie beschrieben die Anbieter übernehmen, trotzdem gilt es aber immer mindestens noch kleine Aufgaben zu erledigen. So müssen beispielsweise zu bestätigende Version-Upgrades zeitnah durchgeführt werden. Auch wenn es sich dabei oft nur um einen Klick handelt, werden diese „lästigen“ Aufgaben von internen Teams gerne auf die lange Bank geschoben – meist nicht aus böser Absicht, es fehlt in fast allen Fällen schlicht an Zeit. Diese Zeit wird jedoch dringend benötigt, da die Änderungen selbst bei kleinen Versionssprüngen oftmals signifikant sind.
Da mehr und mehr Verantwortliche realisieren, dass nicht erst seit der DSGVO Datenpannen fatal enden können, werden diese Tätigkeiten immer öfter an erfahrene Dienstleister wie Service Provider ausgelagert, die sich dann zuverlässig um diese Aufgaben kümmern und die Verantwortung übernehmen, auch mit Blick auf die Haftung. Natürlich entstehen in den Firmen selbst auch immer mehr eigene DevOps Teams, wichtig ist hier aber das kontinuierliche Monitoring auftauchender Schwachstellen in Verbindung mit den eingesetzten Software-Versionen. Nur so lässt sich mit Sicherheit sagen, wo wirklich Handlungsbedarf besteht – eine Aufgabe, die sich, gerade in kleineren Firmen, zur Umsetzung in Eigenregie aus finanzieller Sicht oft nicht rentiert.
Der greifbare Business Value
Zusammenfassend lässt sich sagen, dass der Cloud Native-Ansatz für viele Unternehmen bereits seit Jahren völlig zu Recht eine entscheidende Rolle spielt und in Zukunft in allen Branchen immer wichtiger werden wird.
Cloud Native-Applikationen ermöglichen es einem Unternehmen, seine Ausrichtung schnell anzupassen und so agil auf Veränderungen des Geschäfts reagieren zu können. Die Wertschöpfungskette in der IT wird signifikant beschleunigt, während sich gleichzeitig auch noch Kosten einsparen lassen. Dies kann vielen Firmen deutliche Wettbewerbsvorteile gegenüber ihren Mitbewerbern ermöglichen.
Zum Glück ist „Cloud Native“ zur Abwechslung mal kein kurzlebiges, gehyptes Buzzword. Es ist langfristig der einzige Weg, die großen Public Clouds wie auch kleine PaaS-Plattformen effizient zu nutzen. Die wirtschaftliche Seite haben Analysten von ISG im Auftrag von Claranet untersucht. Ihre Antworten finden Sie in diesem Whitepaper.
