Cloud Native News #4: Volle Breitseite

Inhaltsverzeichnis

In den letzten Monaten hat sich auf breiter Front viel getan im Cloud-Native-Ökosystem

• Bei den Services Meshes geht es zur Sache,
  
• es gibt viele neue Projekte unter dem Schirm der CNCF,
• neue Ideen, wie Systemintegration Cloud-nativ funktionieren kann, haben sich entwickelt,
• CloudFoundry und Kubernetes rücken näher zusammen und
• beim CI/CD-Tooling ist eine ordentliche Dynamik festzustellen.

Service Mesh Bash

Istio als Projekt und Service Meshes als Konzept sind die großen Stars im Cloud-Native-Ökosystem. Lange Zeit schien Istio konkurrenzlos auf weiter Flur. Das ändert sich nun: Hashicorp, das Unternehmen hinter Vagrant, Consul, Vault und Nomad, hat mit Consul Connect ein eigenes Service Mesh veröffentlicht. Wie bei den anderen Open-Source-Projekten von Hashicorp auch liegt der Fokus auf der einfachen Verwendung und robusten Implementierung. Mit Linkerd existiert zudem noch ein weiterer Player, der die Service-Mesh-Bühne betritt. Lange Zeit war Linkerd kein echtes Service Mesh, da eine zentrale Control Plane fehlte. Die Macher haben jedoch mit Conduit ein Parallelprojekt gestartet, das die Lücke füllen soll. Das aktuelle Release 2 von Linkerd integriert Conduit und wertet es damit zum vollwertigen Service Mesh auf.

Das Istio-Projekt hat derweil die strategisch wichtige Version 1.0 veröffentlicht, die es als produktionsreif deklariert. Die Reife der Features spricht aber noch eine andere Sprache: 30 von 44 haben noch Alpha- oder Beta-Status. Dazu gehören auch Funktionen wie Ingress/Egress, das Helm-Deployment oder die Resilienzfunktionen. Zur echten Produktionsreife dauert es somit vermutlich noch ein paar Monate.

Neues unter dem CNCF-Schirm

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

Seit der letzten Ausgabe der Cloud Native News haben zahlreiche weitere Projekte ihren Platz unter dem Dach der Cloud Native Computing Foundation gefunden:

• NATS ist ein Messaging-System, das auf hoch performante und sichere asynchrone Kommunikation zwischen Microservices ausgelegt ist. NATS befindet sich seit sieben Jahren in der Entwicklung, und Unternehmen wie Pivotal, Siemens, HTC und GE nutzen es in Produktion.
• SPIFFE ist eine Spezifikation von Workload Identity, also einem Identitätsbegriff von Prozessen, und SPIRE ist dessen Implementierung.
• Rook ist ein Speicherservice für Kubernetes auf Basis des Ceph-Projekts für verteilten Storage.
• CloudEvents ist ein Standard, um Event-Daten einheitlich zu beschreiben und somit eine bessere Interoperabilität beim Austausch von Events zu ermöglichen.
• Telepresence will das Problem langer Roundtrip-Zeiten lösen, wenn Entwickler ihre Container auf einem entfernten Kubernetes-Cluster testen möchten. Der Trick dabei ist ein Proxy-Container im entfernten Cluster, der auf einen lokal laufenden Container tunnelt.
• Harbor ist eine Docker-Registry mit Fokus auf Sicherheit und Compliance. Administratoren können Zugriffsrechte fein steuern und Images einem automatischen Vulnerability-Scan durch Clair unterziehen. Harbor ist so gebaut, dass es produktionsreif auf einem Kubernetes-Cluster laufen kann.
• OpenMetrics ist eine Spezifikation zur einheitlichen Übertragung von Metrikdaten. Sie unterstützt als Format sowohl reinen Text als auch Protocol Buffers und standardisiert das bisher proprietäre Prometheus-Expositionsformat für Metriken.
• TiKV ist ein transaktionaler, verteilter Key-Value-Store und soll die Basis für High-Level-Datenbanken sein. Den Machbarkeitsbeweis dafür erbringt das Schwesterprojekt TiDB, eine verteilte, transaktionale SQL-Datenbank auf Basis der Schlüssel-Werte-Datenbank. TiKV nutzt den von etcd bekannten Raft-Algorithmus, um einen konsistenten Zustand zu erzeugen. Im Sinne des CAP-Theorems ist TiKV somit partitionstolerant und konsistent, aber nicht hochverfügbar.

Cloud-Native-Integration

Mit zunehmender Verbreitung Cloud-nativer Ansätzen stellt sich die Frage, was die passende Variante von Integrationstechniken wie ESBs (Enterprise Service Bus) ist. Der Wettbewerb um gute Ideen ist im vollen Gange. Eine äußerst charmante verfolgt WSO2 mit einer eigenen Sprache (Ballerina), die speziell für die Systemintegration ausgelegt ist und deren Ausführungsumgebung Container sind. Dabei handelt es sich um eine Sprache, die für die leidigen Mapping-Logiken, Ablaufsteuerungen und Protokollanbindungen bei der Systemintegration eine elegante Notation bietet. Sie ist textuell, und zusätzlich existiert eine grafische Notation. Für Ballerina sind eine dedizierte Entwicklungsumgebung sowie ein Plug-in für Visual Studio Code verfügbar.

CloudFoundry herzt Kubernetes

Trotz seiner großen Verbreitung wird CloudFoundry bei einem Kampf mit Kubernetes um die Container-Orchestrierung vermutlich den Kürzeren ziehen. Kubernetes ist dort schlicht zu dominant und hat das größere und aktivere Ökosystem. Daher bleibt nur die Umarmung, die sich durch mehrere Open-Source-Projekte andeutet:

• Das Projekt Eirini im CloudFoundry-Inkubator lässt die CloudFoundry-Kommandozeile auf ein Kubernetes-Cluster zeigen. Damit können Entwickler transparent mit demselben Befehl ein Deployment sowohl auf einem CloudFoundry- als auch auf einem Kubernetes-Cluster durchführen.
• Das Projekt CF Containerization hat das Ziel, CloudFoundry auf Kubernetes laufen zu lassen.
• Das buildpacks.io-Projekt entwickelt einen Standard für Buildpacks. Ein Buildpack erzeugt aus dem Anwendungscode ein lauffähiges Container-Image. Es erkennt, welche Art von Laufzeitumgebung der Code in einem Repository benötigt, baut die Anwendung und verpackt das Ergebnis schließlich in ein Image mit der passenden Umgebung – beispielsweise einen Servlet-Container. In ähnliche Richtung marschieren bereits die Projekte Draft von Microsoft und Skaffold) von Google.

Mittelfristig ist zu erwarten, dass CloudFoundry als Container-as-a-Service-Layer (CaaS) Kubernetes nutzt und darauf seine bewährten Platform-as-a-Service-Funktionen (PaaS) aufsetzt.

Cloud Native CI/CD

Obschon eine CI/CD-Toolchain (Continuous Integration/Continuous Delivery) zur Standardausstattung gehört, sind viele Nutzer sich bei der Wahl der richtigen Werkzeuge unsicher. Jenkins war lange Zeit der Platzhirsch, hat den Umschwung von CI- zu CD-Pipelines jedoch verschlafen. Zudem ist die Software nach wie vor recht sperrig auf Kubernetes zu betreiben. Beide Faktoren sprechen dafür, dass ein frischer Nachfolger das Ruder übernehmen kann. Als Ersatz bieten sich einige Projekte an:

• Drone ist ein einfach gehaltener CI/CD-Dienst, der auf den Betrieb im Container ausgelegt ist. Ein skalierbares und hochverfügbares Deployment auf einem Kubernetes-Cluster kann es jedoch noch nicht verwalten. Die Entwicklungsaktivität für Drone lässt allerdings seit einem Jahr deutlich nach beziehungsweise verlagert sich auf die kommerzielle Enterprise-Edition. Das junge zugehörige Projekt KubeCI hat das Ziel, Drone sauber auf Kubernetes laufen zu lassen und dem Projekt Schub zu geben. Ob das gelingt, bleibt abzuwarten.
• Concourse von Pivotal ist ein ausgereiftes und funktional mächtiges Werkzeug für CI/CD. Wie Jenkins läuft es aktuell nur widerwillig auf einem Kubernetes-Cluster. Ein passendes Helm Chart steht jedoch zur Verfügung, und der offizielle Support von Kubernetes als Laufzeitumgebung ist angekündigt.
• Knative von Google kommt aus der Serverless-Ecke. Die Hauptfunktionsweise liegt derzeit jedoch bei der CI/CD-Strecke von Anwendungen als Source-to-Container-Build-Orchestrierung. An der Stelle verschmelzen Serverless und CI/CD-Ansätze. Das ist genau betrachtet kein Wunder, denn Serverless ist die radikal einfachste Form von CI/CD: Eine standardisierte, vollautomatisierte Pipeline, in die auf der einen Seite Code hinein- und auf der anderen eine laufende Anwendung herauskommt.
• Spinnaker positioniert sich im Bereich Continuous Delivery (Release, Deploy, Rollback) und nicht im Bereich Continuous Integration (Build, Analyze, Package). Spinnaker ist im CI/CD-Angebot der Google Cloud verbaut: CI übernimmt Google Cloud Build, CD Spinnaker. Die Stärke des Tools liegt in komplexen Release-Workflows, die vor allem größere Unternehmen benötigen: von Vieraugenfreigaben über Green/Blue-Deployments bis hin zu Canary-Releases.

Mehr Infos

Serverless Computing London

heise Developer veranstaltet zusammen mit The Register vom 12. bis zum 14. November in London eine englischsprachige Konferenz zum Thema Serverless Computing und Cloud Native. Der Autor dieses Artikels hat das Programm im Beirat der Entwicklerkonferenz mitgestaltet.

Neben den Herausforderern findet sich auch in der Jenkins Foundation kräftiger Cloud-Native-Schub: Nach dem Vorbild der Kubernetes-Community entstand eine Special Interest Group Cloud Native mit dem Ziel, Jenkins Schritt für Schritt besser auf Kubernetes lauffähig zu machen. Mit dem JenkinsX-Projekt entstand zudem eine CI/CD-Anwendung, die ähnlich wie Knative ausgerichtet ist. Es besteht aus einem Kommandozeilenwerkzeug zur Steuerung der CI/CD-Arbeitsabläufe und einer vorgefertigten Toolchain rund um Jenkins, Nexus und Helm, die sich auf Kubernetes deployen lässt.

Im Schatten der CI/CD-Ansätze sind mittlerweile wichtige Bausteine für einen reibungslosen CI/CD-Workflow auf Kubernetes entstanden wie Image Builder, die ohne Docker Daemon auskommen (Buildah, Kaniko) und Image-Tester (CST, dgoss).

Fazit

Istio hat inzwischen die Version 1.0 erreicht, wohl vor allem produktpolitisch, und bekommt nun Konkurrenz von Consul Connect und Linkerd 2. Die CNCF hat viele neue Projekte aufgenommen von Standards wie SPIFFEE (Workload Identity), CloudEvents (Events) und OpenMetrics (Metriken) bis zu Techniken wie NATS (Messaging), Rook (Storage), Telepresence (lokale Entwicklung), Harbor (Image Registry) und TiKV (Key-Value Store). Mit Ballerina kommt eine domänenspezifische Programmiersprache zur Systemintegration, die direkt zu Microservices kompiliert. CloudFoundry rückt näher an Kubernetes heran und wird vermutlich bald als PaaS-Modell direkt darauf aufsetzen. Zu guter Letzt gibt es ordentlich Dynamik beim CI/CD-Tooling mit neuen Werkzeugen wie Drone, KubeCI, Concourse, Knative und Spinnaker sowie einem wieder erstarkenden Jenkins-Ökosystem.

Josef Adersberger
ist CTO und Mitgründer der QAware, einem Softwarehaus aus München mit rund 100 Mitarbeitern, das Cloud-Native-Applikationen entwickelt und bestehende Anwendungen auf Cloud-Native-Plattformen migriert. Er hält seit 2011 Vorlesungen zum Thema Cloud (Native) Computing und ist CNCF-Mitglied. (rme)