© Excellent backgrounds/Shutterstock.com
Bestandsaufnahme Cloud-native-Technologien

Per Anhalter durch das Cloud-Universum


Cloud-native-Technologien entspringen dem Herzen der digitalen Disruption bei Google, Facebook, Twitter und Konsorten. Sie bieten eine Infrastruktur, mit der man Anwendungen der Generation Cloud entwickeln und betreiben kann. Der Siegeszug von Docker hat auch dazu geführt, dass Cloud-native-Technologien nun im großen Stil Einzug bei vielen Unternehmen halten – egal, ob Start-up oder DAX-Konzern. Das Cloud-native-Universum ist aktuell kurz nach dem ­Urknall. Beste Zeit also zu schauen, welche Strukturen sich bereits gebildet haben und was noch im Fluss ist.

Video: Weniger ist mehr – Serverless Cloud Architectures

Im Juli 2015 war ich auf der OSCON-Konferenz in den USA, vornehmlich, um möglichst tief in die damals noch recht neue Docker-Technologie einzutauchen. Schon nach dem ersten Tag war klar: Docker ist nur ein kleiner Baustein. Es geht um das große Ganze. Das große Ganze, das sind Cloud-native-Stacks, die auf Basis von Docker-Containern und viel Infrastruktur außen herum die Entwicklung und den Betrieb von Anwendungen im Stil der großen Cloud-Unternehmen ermöglichen. Es sind Anwendungen, die auch technisch radikal auf Erfolg getrimmt sind, durch Dinge wie Hyperskalierbarkeit, Continuous Feature Delivery, Antifragilität und keine Opportunitätskosten. Hyperskalierbarkeit ist die Kombination aus Skalierbarkeit und Elastizität. Das bedeutet, dass neben der Skalierbarkeit per se auch noch der Aspekt hinzukommt, wie schnell eine Anwendung nach oben und unten skalieren kann. Continuous Feature Delivery ist die Fähigkeit, neue Features als kontinuierlichen Strom bis in Produktion zu bringen. Die Kernidee: Man startet mit einem MVP (Minimum Viable Product) und legt kontinuierlich Features nach. Antifragilität ist die Eigenschaft von Systemen, tolerant auf Fehler zu reagieren und die Toleranzschwelle dabei kontinuierlich zu steigern. Die Software benötigt idealerweise kein menschliches Zutun, um stabil in Produktion zu laufen. Und zu guter Letzt fallen keine Opportunitätskosten an, da die verfügbaren Ressourcen nur temporär angemietet werden und dabei so gut wie möglich ausgelastet werden.

Auf der OSCON ist für mich der Cloud-native-Urknall passiert. Google et al. haben dort die Cloud Native Computing Foundation (CNCF [1]) gegründet und Kubernetes (K8s) in der Version 1.0 Open Source veröffentlicht – und das auch ordentlich zelebriert. Spätestens, als bei der K8s-Launchparty ein Darth Vader im Schottenrock auf einem Einrad mit feuerspeiendem Dudelsack seine Runden drehte, war mir klar, dass da gerade etwas Großes passiert. Aus der Docker-Singularität ist ein junges Cloud-native-Universum entstanden. GIFEE ist da: Google’s Infrastructure for Everyone Else.

Keine Frage, technologisch ist das Ganze höchst attraktiv. Was mir damals aber noch nicht klar war: Wie bewerten klassische digitale Unternehmen den Trade-off aus Komplexität der Einführung in Entwicklung und Betrieb versus dem oben beschriebenen Nutzen? Hat Cloud-native Computing das Zeug, zum Mainstream zu werden?

Nun, zwei Jahre später ist die Antwort gegeben: Cloud-native Computing wird Mainstream werden. Technologien wie Docker, K8s und andere sind bereits bei vielen Unternehmen, ob groß, ob klein, im Einsatz – oft bereits auch schon in Produktion. Der Geschäftsnutzen ist derart groß, dass man momentan davon ausgehen kann, dass die Entwicklung und der Betrieb von Anwendungen auf einem Cloud-native-Stack alternativlose Zukunft für fast alle Anwendungen sein wird. Es werden also auch Legacy-Anwendungen im großen Stil migriert werden. Denn nicht jede Anwendung auf dem Cloud-native-Stack muss auch Cloud-native sein: Es laufen auch Cloud-Immigrant-Systeme auf Cloud-native-Stacks, also Anwendungen, die ursprünglich nicht für diesen Stack gebaut wurden, dort aber trotzdem laufen sollen, um die Vorteile zu nutzen.

So kurz nach dem Urknall gibt es erwartungsgemäß noch viel Unordnung. Technologien und Begriffe kommen und gehen in hoher Anzahl und mit hoher Geschwindigkeit. Da verliert man schnell den Überblick. Der folgende Artikel will genau dies verhindern. Er beschreibt eine erkennbare Struktur im Cloud-native-Universum, den Cloud-native-Stack, aus mehreren Flughöhen.

Die Struktur des Cloud-native-Universums: der Cloud-native-Stack

Als Cloud-native-Stack bezeichnen wir die Blaupause zur Integration von Cloud-native-Technologien, die in Summe eine Entwicklungs- und Ausführungsumgebung für Anwendungen bietet. Jahrelang bestand Cloud Computing aus drei Ebenen: IaaS (Infrastructure as a Service) für den Betrieb, PaaS (Platform as a Service) für die Entwickler und SaaS (Software as a Service) für die Anwender. IaaS war Amazon, PaaS war Heroku und SaaS waren Google und Salesforce – allesamt Lösungen in der Public-Cloud mit Gefahr des Vendor Lock-ins.

Mit dem Advent von Docker hat sich zwischen IaaS und PaaS eine neue Ebene geschoben: CaaS (Container as a Service). Diese Ebene ist dafür zuständig, containerisierten Workload auf den Ressourcen auszuführen, die eine IaaS-Cloud zur Verfügung stellt. Die Technologien dieser Ebene wie Docker, Kubernetes oder Mesos sind allesamt quelloffen verfügbar. Somit kann man sich seine private Cloud ohne Gefahr eines Vendor Lock-ins aufbauen.

Aus 100 Kilometern Flughöhe betrachtet besteht ein Cloud-native-Stack aus den Ebenen IaaS über CaaS zu PaaS (Abb. 1). Das ist ein vollständiger Stack, auf den Cloud-native-Anwendungen entwickelt werden können. Flankiert wird dieser Stack von DevOps-Tools, die die Schnittstelle zwischen Mensch (Dev und Ops) und Cloud-native-Stack sind.

adersberger1.tif_fmt1.jpgAbb. 1: Der Cloud-native-Stack aus 100 Kilometern Höhe

So weit, so einfach. Richtig spannend wird das Ganze, wenn wir den Cloud-native-Stack aus 10 Kilometern Flughöhe betrachten (Abb. 2).

adersberger2.tif_fmt1.jpgAbb. 2: Der Cloud-native-Stack aus 10 Kilometern Höhe

Auf unterster Ebene werden Ressourcen zur Verfügung gestellt. Dies kann über eine IaaS-Cloud erfolgen, man kann die CaaS-Ebene aber auch auf blankem Metall oder einer klassisch virtualisierten Infrastruktur betreiben.

Auf CaaS-Ebene wird so gut es geht davon abstrahiert, dass die bereitgestellten Ressourcen von einem beliebig großen Cluster zur Verfügung gestellt werden. Es soll für den Nutzer möglichst so aussehen, als ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang