Cloud Native News #5: Es menschelt im Cloud-Native-Kosmos

Inhaltsverzeichnis

In den bisherigen Ausgaben der Cloud Native News standen die technischen Neuigkeiten des Cloud-Native-Ökosystems im Vordergrund. Die fünfte Auflage rückt den Mensch ins Zentrum – allen voran die Entwickler von Anwendungen, die auf Kubernetes laufen. Die Entwicklerzufriedenheit (Developer Happiness) wird gerade zum wichtigen Erfolgsfaktor für Cloud-Native-Techniken.

Kubernetes wird langweilig

Janet Kuo, Software Engineer bei Google, bezeichnete auf der Keynote der KubeCon/CloudNativeCon im Dezember in Seattle Kubernetes als "now very, very boring". Gleich im nächsten Satz schob sie hinterher, dass langweilig gut sei. In der Anfangszeit wurde Kubernetes nur von ein paar wenigen risikoorientierten Innovatoren eingesetzt. Die Zeiten von "Move fast and code breaks" sind Janets Meinung nach aber vorbei.

Kubernetes hat sich in vielen Unternehmen etabliert, die Versprechen an die Anwender haben sich erfüllt: Deployments sind einfacher geworden, der Betrieb von Anwendungen läuft stabiler und skaliert besser und die Betriebskosten sinken. In der Vergangenheit galt das laut Kuo nur für diejenigen, die direkt an der Entwicklung von Kubernetes beteiligt waren. Auch das sei durch das "Langweilige" an Kubernetes vorbei: "Es bedeutet, dass viele Unternehmen es inzwischen nutzen, und es einfach funktioniert. Das ist gut für die breite Nutzerbasis, die Geschäftswerte schaffen wollen, statt ihre Energie darauf zu verwenden, Kubernetes zu verbessern."

Gemessen am Technology Adoption Lifecycle sieht sich Kubernetes aus der Phase der Early Adopters entwachsen und im Block der Mehrheit angekommen. Eine Bestätigung davon konnte man auf der Konferenz in Seattle an den beeindruckenden 8000 Teilnehmern ablesen. Zusammen mit den Teilnehmern der CloudNativeCon und KubeCon in Asien und Europa ergeben sich für 2018 insgesamt 15.000 Teilnehmer [5].

Die auf der Expo vertretenen Firmen bestätigen das Bild: Fast alle großen IT-Unternehmen sind vor Ort und wittern das Geschäft der Zukunft. Was Ende des letzten Jahres mit Akquisitionen wie Red Hat durch IBM oder Heptio durch VMware begonnen hat, wird sich 2019 voraussichtlich fortsetzen. Die großen Player werden mit viel Kraft Cloud-Native-Know-how aufbauen oder einkaufen.

Nicht für Entwickler

Kubernetes ist aus zwei Gründen nicht für Entwickler geschaffen. Erstens sind die Abstraktionen von Kubernetes nicht auf Entwicklerniveau. Nachdem Kubernetes anfangs noch einigermaßen handhabbar war, ist es inzwischen groß und komplex geworden (vgl. Abb. 2). Anwendungsentwickler müssen sich vor dem ersten Deployment ihrer Anwendungen in einem Kubernetes-Cluster mit dem Datenmodell befassen. Daher stößt man im Kubernetes-Umfeld immer häufiger auf Platform Engineers. Sie sind die Mittler zwischen den Anwendungsentwicklern und den Kubernetes-Abstraktionen.

Dass Kubernetes noch zu wenig Techniken bietet, die auf Entwickler ausgelegt sind, ist der zweite Grund, warum es nicht für sie geschaffen ist. Im Ökosystem der Cloud Native Computing Foundation (CNCF) haben nicht nur Kubernetes, sondern auch seit kurzem Prometheus|, Envoy und CoreDNS den Stempel des höchsten CNCF Reifegrad "Graduated" erhalten. Sie haben das gemeinsame Ziel, Kubernetes besser betreiben zu können.

Entwickler brauchen aber eine Cloud-Native-PaaS (Platform as a Service), die sich über ein blankes Kubernetes-Cluster legt. Sie sollte Abstraktionen und Werkzeuge mitbringen, die Entwickler adressieren. Dafür sind Abstraktionen wie Build oder Release und Cloud-Native-Werkzeuge für CI/CD, APM oder gar vollständige IDEs erforderlich, mit denen Entwickler gerne arbeiten.

Zufriedene Entwickler

Wie das in der Praxis aussehen kann, hat Melanie Cebula, Software Engineer bei AirBnB, auf der CloudNativeCon vorgestellt: "Was sind die Herausforderungen bei Kubernetes?", sinnierte sie. "Die Konfiguration und die Werkzeuge sind komplex ... aber was ich heute betonen möchte ist, dass alles lösbare Probleme sind."

Dafür hat sie zehn Tipps aus der direkten Erfahrung bei AirBnB aufgestellt:

1. Kubernetes Boilerplate reduzieren,
2. Standardisierung von Umgebungen und Namespaces,
3. Alles über einen Microservice sollte in einem Quellcode-Repository abgelegt sein,
4. Wrapper für kubectl-Befehle,
5. Umsetzen von Best Practices durch sinnvolle Defaults in der Konfiguration,
6. Automatisierung alle gängige Kubernetes-Workflows,
7. CI/CD sollten die gleichen Befehle wie Anwendungsentwickler lokal in einem Container ausführen,
8. Validieren der Anwendungskonfigurationen in den CI/CD-Pipelines,
9. Code und Konfiguration sollten vom gleichen Prozess bereitgestellt werden und
10. der Einsatz von Kubernetes Custom Resources und Custom Controller ermöglicht eine einfache Integration in die Infrastruktur, beispielsweise Loadbalancer, Observability.

Viele Entwickler wünschen sich in Kubernetes-Plattformen immer mehr Serverless-Ansätze. Das bedeutet nicht automatisch Function-as-a-Service (FaaS), sondern zunächst eine abstrakte Sicht auf Ressourcen. Beispiele für dringenden Abstraktionsbedarf für Entwickler sind Millicores bei der Definition von Ressourcenlimits, Definition automatischer Skalierungsregeln oder IP-Blöcke bei der Definition von Netzwerk-Policies.

Werkzeuge für die Abstraktion

Da immer mehr Platform Engineers für Kubernetes Custom Resource Definitions (CRDs) einsetzen, lässt sich die offizielle API durch eigene Objekte ergänzen, was die Definition eigener Abstraktion ermöglicht. Folgende neue Werkzeuge sind gute Beispiele dafür, wie man das Abstraktionsniveau von Kubernetes für Entwickler heben kann:

Knative: In der Cloud Native Community bekommt das im Rahmen eines Artikels auf heise Developer vorgestellte Open-Source-Tool steigende Aufmerksamkeit. Aus Sicht der Anwendungsentwickler bieten die Build- und Runtime-Komponenten von Knative eine geeignete und für die meisten Anwendungen ausreichende Abstraktionsschicht, bei der beispielsweise ein Build der Software ein natives Kubernetes Objekt ist. Ansätze wie Flagger gehen hier sogar noch einen Schritt weiter und bieten Objekte für komplexe Release-Verfahren wie Canary Releases. Es ist davon auszugehen, dass immer mehr Cloud-Provider ihre Serverless-Angebote auf Knative aufsetzen werden.

Odo : Mit dem Kommandozeilenwerkzeug von Red Hat können Entwickler komfortabel mit einem OpenShift-Cluster interagieren. Lokale Code-Änderungen lassen sich automatisch in laufende Anwendungen auf einem OpenShift-Cluster überführen. Das Werkzeug überwacht Änderungen an den Quellcodecateien, erkennt die benötigte Laufzeitumgebung, baut den passenden Container und verteilt die Anwendung ohne Zutun der Entwickler. Ferner hilft das Tool beim Provisionieren von Diensten wie Datenbanken auf OpenShift.

Crossplane: Hinter dem neuen Open-Source-Projekt steckt die Firma Upbound, die zuvor Rook zu einem erfolgreichen CNCF-Projekt überführt hat. Sie bezeichnet Crossplane als Multi-Cloud-Steuerebene für Cloud-Native-Workloads. Aktuell unterstützt es die großen Cloud-Provider Google, Amazon und Microsoft.

Mehr Infos

Cloud Native News

1. Rise of the Kubernaut
2. Konferenzeindrücke
3. Endlich Produktion
4. Volle Breitseite
5. Es menschelt im Cloud-Native-Universum
   

Das Tool bietet eine Abstraktion für Kubernetes-Workloads und die benötigten, von den Cloud-Providern angebotenen Infrastrukturkomponenten wie Datenbanken, Storage oder Message Queues. Dadurch können Entwickler Workload-Definitionen schreiben, ohne sich um Implementierungsdetails, Umgebungseinschränkungen oder Richtlinien seitens der Cloud-Provider einerseits und den eigenen CloudOps-Kollegen andererseits kümmern zu müssen. Letztere können wiederum Umgebungsspezifikationen und Richtlinien definieren. Das recht junge Open-Source-Projekt Crossplane ist definitiv einen Blick wert.

CodeReady Workspaces: Red Hat hat Anfang Februar eine Entwicklungsumgebung auf Basis von OpenShift beziehungsweise Kubernetes mit dem Namen CodeReady Workspaces veröffentlicht. Die IDE basiert auf Eclipse Che, läuft direkt auf einem Kubernetes-Cluster und lässt sich per Browser bedienen. Entwickler können damit Cloud-Native-Anwendungen kollaborativ und direkt auf dem Ziel-Cluster erstellen.