Per Anhalter durch das Cloud-native-Universum

Die Cloud-Landscape: Bestandsaufnahme der Cloud-native-Technologien

Dr. Josef Adersberger

©Shutterstock.com/ ISKRA_design/ Vik_Kay

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.

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) 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.

 

Abb. 1: Der Cloud-native-Stack aus 100 Kilometern Höhe

Abb. 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).

 

Abb. 2: Der Cloud-native-Stack aus 10 Kilometern Höhe

Abb. 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 ob das Cluster ein einzelner, aber riesiger Computer sei, dem man Container zur Ausführung übergibt. Damit dies gelingt, müssen die Clusterressourcen virtualisiert werden. Zum einen müssen die Betriebssystemressourcen über eine Cloud-native Runtime virtualisert werden. Diese Runtime besteht zunächst aus einem minimalen Trägerbetriebssystem für alle Knoten im Cluster und einer darauf laufenden Container-Runtime. Solche Container-Runtimes sind z. B. Docker oder rkt.

Bei den Betriebssystemen handelt es sich gewöhnlich um Linux-Varianten, die darauf optimiert und reduziert sind, nur noch eine Container-Runtime zu betreiben. Zum anderen muss auch der übergreifende Zustand in einem Cloud-native Storage (z. B. Rook, Ceph oder GlusterFS) und einem Configuration-and-Coordination-Dienst (z. B. ZooKeeper, etcd oder Consul) virtualisiert werden. Ein Cloud-native Storage ist ein verteiltes Dateisystem, das elastisch skalieren kann, große Datenmengen verkraftet und tolerant mit Ausfällen einzelner Knoten umgeht. Ein Configuration-and-Coordination-Dienst ist das Herzstück der CaaS-Ebene zur konsistenten Koordination und Konfiguration von vielen Knoten in einem Cluster.

Eine Form der Koordination ist dabei z. B., dass alle Knoten im Cluster einen führenden Knoten wählen oder sich auf einen verteilten Lock einigen. Bei der Konfiguration geht es darum, Konfigurationswerte und schwebenden Zustand konsistent im Cluster zu verteilen und zu halten. Konzeptionelle Basis dabei sind Konsensprotokolle wie Raft oder Paxos. Und zu guter Letzt muss auch das Netzwerk über ein Cloud-native Network (z. B. Calico, Flannel, Weave oder OVS) virtualisiert werden. Damit werden über das physikalische Netzwerk ein oder mehrere virtuelle Netzwerke gelegt, die sich flexibel per Software erzeugen und modifizieren lassen.

Der Cluster-Scheduler (z. B. Mesos, Kubernetes Scheduler, Nomad oder Docker Swarm) hat die Aufgabe, die einzelnen Container auf den virtualisierten Clusterressourcen zuverlässig und ressourcenschonend auszuführen. Er ermittelt die zur Ausführung eines Containers notwendigen Ressourcen über einen geeigneten Scheduling-Algorithmus (z. B. Bin Packing oder Dominant Resource Fairness), allokiert sie für einen bestimmten Zeitraum und führt die Container darauf aus. Re-Scheduling erfolgt bei Bedarf, z. B. beim Ausfall einer Ressource, dem Absturz eines Containers oder beim Freiwerden von alternativen, passenderen Ressourcen.

Der Cluster-Orchestrator (z. B. Marathon, Kubernetes-Controller oder Kontena) steuert und überwacht die Ausführung aller Container einer Anwendung. Er verwaltet den gesamten containerisierten Workload einer Anwendung, während der Cluster-Scheduler nur einzelne Container kennt. Die Orchestrierung von Cloud-native-Anwendungen hat den Anspruch, alle Betriebsprozeduren einer Anwendung zu automatisieren, wie Roll-out, Roll-back, Upgrade, Skalierung, Konfiguration und Exposition von Endpunkten. Ein guter Cluster-Orchestrator sollte sich auch um eigene automatisierte Betriebsprozeduren erweitern lassen. Bei K8s nennt sich dies Operators.

Zur CaaS-Ebene gehört darüber hinaus eine Image Registry (z. B. Docker Distribution, Artifactory, Nexus, Atomic Registry oder Harbor), aus der sich Cluster-Orchestrator und Cluster-Scheduler mit den zur Container-Runtime passenden Images bedienen können.

Kubernetes ist eine wunderbare Basis für die CaaS-Ebene: Es bietet Cluster-Orchestrator und Cluster-Scheduler, nutzt als Container-Runtime Docker oder rkt und bietet viele Treiber für Cloud-native-Storage- und Cloud-native-Network-Lösungen. Es wirkt damit wie ein Betriebssystem für die Cloud. Kein Wunder, dass sich die CNCF als Heimat von Kubernetes unter dem Dach der Linux Foundation befindet. Genau wie bei Linux gibt es auch verschiedene Distributionen, die Kubernetes bereits integriert haben und produktionsreif als vollwertige CaaS- oder gar PaaS-Lösung bieten, wie OpenShift, Tectonic, Giantnetes, Rancher oder Kismatic. Eine Alternative dazu ist DC/OS, das auf Mesos als Scheduler und Marathon als Orchestrator aufsetzt. Was man aber auch sieht: Ein Cloud-native Stack ist deutlich mehr als K8s und Docker, gerade wenn es in Richtung PaaS geht.

CaaS dient der PaaS, um Workloads auszuführen. PaaS ist das Territorium der Entwickler. Dabei gibt es verschiedene Plattformen, je nach Art der Anwendung, die man entwickelt. Es gibt Microservices-Plattformen für die klassischen Cloud-native-Anwendungen, die dem Microservices-Paradigma folgen (z. B. Spring Cloud, Lagom oder Eclipse MicroProfile). Außerdem gibt es Nanoservice-Plattformen – auch bekannt als Lambda Platform oder Function as a Service –, die Anwendungen auf der Dekompositionsebene von einzelnen Funktionen eine Heimat bieten (z. B. OpenWhisk, Fission, IronFunctions oder Gestalt). Und es gibt Data-Service-Plattformen, die für Anwendungen geschaffen sind, die schnelle, smarte und umfangreiche Daten verarbeiten (z. B. Spark, Flink, Spring Cloud Data Flow oder Kafka Streams).

Daneben gibt es auch Anwendungen, die nicht nativ für die Cloud geschaffen sind, sich gemäß Cloud-native Maturity Model also unterhalb des Reifegrads Cloud-native tummeln. Diese Cloud-Immigrant-Systeme laufen in der Regel außerhalb der PaaS direkt auf CaaS-Ebene, da dort die größte Flexibilität herrscht. Ihnen stehen dabei aber oft auch die typischen PaaS-Bausteine zur Verfügung, die sich die PaaS-Plattformen teilen. Ein API-Gateway sorgt für die Exposition von APIs (z. B. Kong, Tyk, Traefik, Zuul oder Envoy). Ein solches API-Gateway bietet Funktionen wie Authentifizierung, Autorisierung und Rate Limiting. Ein IAM-Baustein (Identity and Access Management) verwaltet die Benutzeridentitäten und bietet Authentifizierung und Autorisierung von Benutzern und nutzenden Applikationen (z. B. Keycloak oder Lightwave).

Eine Service-Discovery (z. B. Consul, Eureka oder CoreDNS) registriert die Endpunkte von Anwendungen unter einem symbolischen Namen und macht sie zugreifbar. Service-Discovery per DNS bringen Cluster-Orchestrators wie K8s bereits direkt mit. Ein Service-Mesh (z. B. linkerd, Istio oder Ribbon plus Hystrix) dient als Bindeglied zwischen einzelnen Services. Für den Servicenehmer fungiert das Service-Mesh als Proxy des Servicegebers und fügt in der Cloud notwendige Zusatzfunktionalität bei Aufrufen hinzu, z. B. Service-Look-ups, Load Balancing, Circuit Breaking oder Monitoring. Für den Servicegeber dient das Service-Mesh als Reverse Proxy und kümmert sich z. B. um TLS-Terminierung und Deadlines.

Die Cloud-native-Messagingdienste (z. B. Kafka, NATS, RabbitMQ oder RocketMQ) sorgen für skalierbare asynchrone Kommunikation zwischen einzelnen Services. Die Cloud-native Databases (z. B. Presto, CockroachDB, Vitess oder Drill) kümmern sich um das Speichern und Abfragen von großen strukturierten Datenmengen. In-Memory Data Grids (z. B. Ignite oder Hazelcast) verarbeiten Daten im Hauptspeicher über ein gesamtes Grid an Services hinweg.

Ebenso wie auf CaaS-Ebene gibt es auch auf Ebene der PaaS vorgefertigte Lösungen, wie OpenShift, Cloud Foundry, Deis Workflow und Flynn. Diese unterscheiden sich jedoch im Innenleben erheblich. OpenShift und Deis setzen auf K8s als CaaS auf. Cloud Foundry und Flynn kommen mit einer eigenständigen CaaS-Lösung.

Entlang der Ebenen IaaS, CaaS und PaaS gibt es die DevOps-Werkzeugkette. Sie besteht aus Diagnosewerkzeugen für Laufzeitanomalien (z. B. Prometheus, Zipkin oder ELK/EFK) auf allen Ebenen (IaaS, CaaS, PaaS) und mit allen relevanten Diagnoseinformationen (Metriken, Traces und Logs). Weiterer Teil der DevOps-Werkzeugkette sind Werkzeuge zur Provisionierung von Infrastruktur (z. B. Terraform oder Ansible) und Containertopologien (z. B. Habitat, Brooklyn, Docker Compose oder Helm) sowie zur Continuous Delivery von Anwendungen (z. B. GitLab, Jenkins, Drone, Redspread, Spinnaker oder GoCD). Letztere haben das Ziel, die Zeit vom Commit von Codeänderungen bis zum laufenden Code in Produktion möglichst kurz zu halten. Continuous-Delivery-Werkzeuge sind oft bereits direkt in eine PaaS integriert.

Das war ein Überflug über einen Cloud-native Stack in 10 Kilometern Flughöhe. Nun wollen wir die Flughöhe nochmals reduzieren und einen Blick speziell auf die Microservices-Plattform aus einem Kilometer Flughöhe werfen (Abb. 3).

Abb. 3: Die Microservices-Plattform aus einem Kilometer Flughöhe

Abb. 3: Die Microservices-Plattform aus einem Kilometer Flughöhe

 

Eine Microservices-Plattform läuft auf einer CaaS-Lösung. Die Ausführungsumgebung für einen einzelnen Microservice ist dabei das Microservices-Chassis (z. B. Spring Boot, WildFly Swarm oder Payara Micro). Die Verbindung zwischen zwei Microservices wird durch das Service-Mesh geschaffen. Das Service-Mesh nutzt dabei die Service-Discovery, um die Endpunkte der genutzten Services zu finden. Für die Kommunikation zwischen Services werden neben REST auch gerne effizientere RPC-Protokolle wie gRPC oder Thrift genutzt. Bestimmte Services sind als APIs nach außen freigegeben. Diese werden über das API-Gateway exponiert und Benutzer bei Aufruf der APIs beim IAM-Baustein authentifiziert und autorisiert. Die Schnittstellen zu den Entwicklern sind bei der Microservices-Plattform die Continuous-Delivery-Lösung sowie die Diagnosewerkzeuge auf Ebene der Services und Applikationen.

Damit geht unsere Reise durch den Cloud-native Stack zu Ende. Der beschriebene Stack basiert nicht nur auf Erfahrungen, sondern ist auch Synthese verschiedener Quellen, nämlich der Cloud Native Landscape (und der QAware Cloud Native Landscape), dem ClouNS-Referenzmodell sowie den Microservices-Patterns. Der Cloud-native-Stack ist am Ende des Tages nur eine Hülle, die erst durch konkrete Technologien mit Leben befüllt wird. Das Universum der Cloud-native-Technologien ist jung, ungestüm und sprunghaft. Um ein Gefühl für den aktuellen Zustand im Universum zu bekommen, betrachten wir, welche Bereiche sich technologisch bereits stabilisiert haben und wo noch ordentlich Dynamik bis hin zu Chaos herrscht. Es handelt sich dabei um eine nicht abschließende Auswahl und größtenteils subjektive Eindrücke.

Welche Bereiche sich bereits stabilisiert haben

Der Hype um Docker ist abgeflacht, und es wird zunehmend klarer, dass es sich dabei um einen kleinen, aber zentralen Baustein eines Cloud-native-Stacks handelt, der möglichst schnell Commodity werden sollte. Indiz dafür ist die OCI (Open Container Initiative), die die Container-Runtime und das zugrunde liegende Imageformat standardisiert. Die Version 1.0 ist diesen Juli erschienen. Damit werden Container-Runtimes wie Docker, rkt, containerd oder runV austauschbar. Die Abhängigkeit von der dominanten Urtechnologie Docker schwindet.

Im Gegensatz zu anderen Bausteinen der Clustervirtualisierung geht es technologisch bei Configuration and Coordination ruhig zu. Es gibt ZooKeeper, etcd und Consul – und das stabil seit fast Anbeginn der Cloud-native-Ära.

Die momentane Lage beim Cluster-Scheduling und der Orchestration kann man in etwa so beschreiben: Kubernetes, lange nichts, DC/OS, lange nichts, und dann ein paar ambitionierte Neulinge wie Nomad und Kontena, die aber kaum Land gewinnen. Die Dominanz von K8s hat sich über das vergangene Jahr entwickelt und scheint sich durch die große Community, den offenen Entwicklungsprozess, das Marketing von Google und technische Innovationen weiter auszubauen. Gerade in Form von vorgefertigten Distributionen wie OpenShift oder Tectonic erobert K8s gerade die Unternehmen. DC/OS hat gegenüber Kubernetes aktuell noch den Vorteil, dass es gerade für Data-Services viele vorintegrierte Lösungen (z. B. Spark oder Kafka) bietet, die man bei K8s erst mühevoll und fehleranfällig selbst integrieren muss.

Das magische Dreieck der Diagnostizierbarkeit ist: Metriken, Logging, Tracing. In allen drei Bereichen festigen sich Technologien. Bei den Metriken ist dies Prometheus mit Grafana zur Visualisierung. Beim Logging sind dies der ELK/EFK-Stack bestehend aus Logstash oder Fluentd zur Logistik von Logevents, Elasticsearch als Logspeicher und Kibana zur Loganalyse. Und beim Tracing sind dies OpenTracing-Implementierungen – allen voran Zipkin und Jaeger.

Bei JVM-basierten Microservices ist Spring Boot der Platzhirsch mit den aufkommenden JEE-Mikrocontainern wie WildFly Swarm als ernst zu nehmende Herausforderer.
Das absolute Fundament des Cloud-native-Stacks hat sich also mittlerweile gefestigt. Auf dem Weg zu einem vollwertigen, Enterprise-fähigen Cloud-native-Stack gibt es aber noch eine Reihe an turbulenten Regionen.

Die stabilen Teile des Cloud-native-Stacks
• Container-Runtime
• Configuration und Coordination
• Cluster-Scheduling und Orchestration
• Diagnosability
• Microservices-Chassis

Welche Bereiche noch im Fluss sind

Im Bereich der Storage- und Netzwerkvirtualisierung geht es wild zu, wenngleich es mit CSI (Container Storage Interface) und CNI (Container Network Interface) bereits Standardisierungsbemühungen der CNCF an den Schnittstellen dazu gibt. Bei der Storage-Virtualisierung ging der Pionier ClusterHQ pleite, und CoreOS stellte nach nur wenigen Monaten das groß angekündigte Torus-PIm Bereich der Storage- und Netzwerkvirtualisierung geht es wild zu, wenngleich es mit CSI (Container Storage Interface) und CNI (Container Network Interface) bereits Standardisierungsbemühungen der CNCF an den Schnittstellen dazu gibt.

Bei der Storage-Virtualisierung ging der Pionier ClusterHQ pleite, und CoreOS stellte nach nur wenigen Monaten das groß angekündigte Torus-Projekt ein. Die Hoffnung ruht nun auf den Open-Source-Haudegen GlusterFS und Ceph mitsamt Rook als Überbau und Newcomern wie Infinit. Daneben hat sich eine Reihe an kommerziellen Lösungen etabliert wie Quobyte und Portworx. Bei der Netzwerkvirtualisierung gibt es ein breites Feld an konkurrierenden Open-Source-Lösungen wie Calico, Flannel, Weave, OVS, Romana, Cilium und Contiv. Calico hat gefühlt aktuell ein wenig die Nase vorne, doch das Verfolgerfeld ist nah.

Als Image Registry gab es für die Private-Cloud einige Zeit lang entweder die Docker Registry (nun Docker Distribution) oder die altbekannten Maven Repositories, die sich hin zu generischen Binär-Repositories entwickelt haben (Artifactory, Nexus). Gerade das Thema Security von Images treibt nun weitere Registries wie VMware Harbor oder die Atomic Registry an.

Technologien für Service-Meshing sind gerade sehr en vogue. Die sichtbarsten Vertreter dabei sind linkerd und Envoy, wobei auch die Kombination von Netflix Hystrix und Ribbon als Service-Mesh durchgehen kann. All diese Lösungen regeln aber nur Punkt-zu-Punkt-Verbindungen. Istio ist eine ganze Open-Source-Plattform oberhalb von Envoy und linkerd, die das gesamte Servicekommunikationsnetz managt und so z. B. Policies anwenden und Traces visualisieren kann. Die noch sehr jungen Technologien gepaart mit dem offensichtlichen Nutzen versprechen noch viel Dynamik an dieser Ecke.

Die Welt ringt aktuell noch damit, ob Nanoservices wirklich eine gute Idee abseits von Alexa Skills sind. Das merkt man auch den hier verfügbaren Plattformen an. Frühe Vertreter wie OpenWhisk und Gestalt kommen nicht recht voran, und die neuen Plattformen, die nativ auf K8s ausgelegt wurden, wie Fission und IronFunctions, wirken noch sehr junior.

Wie man mit der Identität, den Zugriffsrechten und dem Kontext von Benutzern in Cloud-native-Anwendungen umgeht, ist noch ein recht unbestelltes Feld. Es gibt Protokolle wie OpenID und OAuth 2.0 sowie Trägerformate wie JWT. Auch gibt es mit Keycloak und VMware Lightwave erste IAM-Lösungen mit Cloud-Anspruch. Doch der Bedarf wird mit zunehmendem Enterprise-Einsatz des Cloud-native-Stacks derart steigen, dass es im Bereich IAM und allgemein im Bereich der Cloud-native-Security noch turbulent zugehen wird.

Die Situation bei den API-Gateways erinnert an SOA-Zeiten: Große kommerzielle Hersteller preisen funktionsreiche Produkte für das API-getriebene Unternehmen an, von denen aber in der Realität nur verschwindend wenige Features genutzt werden. Das lässt oft angemessene Open-Source-Lösungen wie Kong, Traefik, Tyk und Zuul ein wenig im Schatten stehen.

Die Werkzeugkette zur Continuous Delivery befindet sich gerade in einer Zeitenwende. Da gibt es zum einen Jenkins, den zuverlässigen und lieb gewonnenen Diener für den Bau von Software. Zum anderen gibt es Werkzeuge, die nativ auf Continuous Delivery ausgelegt sind und in deren Richtung sich Jenkins nur träge bewegt. Diese Werkzeuge bieten flexible Delivery-Pipelines, die per Code definiert werden, kurzlebige Build-Agenten in Containern und Images als First-Class Citizens.

Die volatilen Bereiche des Cloud-native-Stacks

• Storage- und Netzwerkvirtualisierung
• Image-Registry
• Service-Mesh
• Nanoservice-Plattform
• IAM
• API-Gateway
• Continuous Delivery

Fazit

Der Cloud-native-Stack ist unausweichliche Zukunft für viele aktuelle und kommende Anwendungen. Der Stack ordnet und stabilisiert sich. Es gibt auch turbulente Technologiebereiche, die einen produktiven Einsatz in der Breite aber nicht verhindern. Gerade hier ist auch mit den Anstrengungen der CNCF Besserung in Sicht: Für alle wichtigen Bausteine des Cloud-native-Stacks soll es Open-Source-Projekte unter den Fittichen der CNCF geben. Ein stabiler Cloud-native-Stack ist aber nur der Anfang: Je mehr Anwendungen ein Unternehmen auf einen solchen Stack bringt, desto intensiver stellt sich die Frage, wie ganze Cloud-native-Anwendungslandschaften aussehen und bebaut werden sollten. Es bleibt also spannend.

Dem geneigten Entwickler sei zum Einstieg in den Cloud-native-Stack ein Couchprojekt empfohlen: Zunächst in die relevanten Informatikgrundlagen einarbeiten – insbesondere was Betriebssystemvirtualisierung, Scheduling-Algorithmen, Konsensprotokolle anbelangt –, dann eine Spielwiese schaffen (z. B. lokale CaaS- oder PaaS-Installationen mit Minikube und Minishift) und eine Microservices-Plattform der Wahl anprogrammieren.

Geschrieben von
Dr. Josef Adersberger
Dr. Josef Adersberger
Dr. Josef Adersberger ist technischer Geschäftsführer der QAware GmbH, einem IT-Projekthaus mit Schwerpunkt auf Cloud-nativen Anwendungen und Softwaresanierung.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.