Stellen Sie Ihr Team zusammen

Architekturlernkurve für die Private Cloud

Was bekommen wir, wenn wir diesen gesamten Technologiestack integriert und aufeinander abgestimmt nutzen können? Damit wird eine Private Cloud geliefert, die nicht nur erste Gehversuche bewältigt, sondern auch echten harten Anforderungen für eine ernsthafte strategische und produktive Nutzung im größeren und großen Umfang standhält.

Viele Leute kennen Docker. Bei Kubernetes sinkt der Bekanntheitsgrad schon auf weniger als die Hälfte, aber wer kennt beispielsweise Istio, Helm oder Prometheus? Docker und Kubernetes bilden die Basis für Ihre Private Cloud – aber damit nicht genug.

Es gibt sehr interessante und leicht zugängliche Zahlen. Wenn man bei Twitter nachforscht, findet man für Docker 304k und für Kubernetes 121k Follower. Aber für Helm, Istio und Prometheus Monitoring sind wir bei jeweils unter 15k Followern. Zu Terraform hat Twitter gar keine Zahlen. Die Verhältnisse sehen ähnlich aus, wenn man die Google-Keyword-Suche oder Stack-Overflow-Fragen betrachtet. Es ist ein verbreiteter Konsens in der IT-Community, dass Container-Technik sinnvoll ist und Zukunft hat. Zudem nutzen viele Entwickler bereits für sich die Vorteile von Docker, das erklärt sicher die hohen Zahlen. Aber warum der starke Abfall bereits bei Kubernetes und warum so wenige Follower bzw. Fragen bei den anderen Technologien?

Wir haben eine These: Zum einen gibt es eine zeitliche Entwicklung, in der die Themen populär werden. Zum anderen gibt es eine Lernkurve der Architekten. Beide korrelieren.

Lernkurve?

Wie kommen wir Architekten denn mit den Themen üblicherweise in der Praxis in Berührung? Wir entdecken mit Begeisterung Docker und sehen dann rasch den Nutzen in der Kombination mit Kubernetes. Aber wir müssen noch einen Weg gehen und Erfahrung sammeln, bis wir bemerken, dass unsere Cloud-Plattform noch etwas mehr können muss, um unseren wachsenden und zukünftigen Anforderungen Stand zu halten. Wer kann schon von sich behaupten: „Ich wusste gleich, was Istio, Helm und Prometheus können, aber ich habe bewusst beschlossen, mich damit erst später zu beschäftigen.“?

Wie sagte es der Kollege die Tage so treffend: „Um Istio zu verstehen, musste ich erst Kubernetes verstehen. Und um Kubernetes zu verstehen, musste ich erst Docker verstehen.“ Die Dinge bauen aufeinander auf und lösen Probleme, welche die grundlegenderen Technologien noch anderen Projekten zur Lösung überlassen. Das ist weder in der IT noch bei Open-Source-Projekten ein Novum. Warum über solch selbstverständliche Muster in der IT einen Artikel schreiben?

Wenn man weiß, was man lernen muss, kann man dies planen.

Ein Vorschlag

Sie haben den Wert von Containern z.B. im spezifischen Fall von Docker für sich erkannt. Warum sich nicht von Anfang an vornehmen, sich z.B. mit Kubernetes, Helm, Istio und Prometheus zu beschäftigen? Warum denn diese Technologien? Dies betrachten wir im Anschluss.

Wer mit Docker beginnt, merkt rasch, dass sich die Container vermehren. Über kurz oder lang laufen viele Container und um deren Lebenszyklus oder Hochverfügbarkeit zu managen, hat man immer mehr Aufwand und steckt Grips und Zeit in seine Skripte. Diesem Zustand kann abgeholfen werden. Kubernetes kommt aus dem Griechischen und bedeutet Steuermann. Das Open-Source-Projekt Kubernetes (Abk.: K8s) steuert Docker Container und hat sich diesbezüglich zum Quasistandard entwickelt. Entwickler oder Administratoren geben K8s per YAML-File vor, welche Docker-Images laufen sollen und wie oft. Zudem erlaubt das System ein Roll-Forward und Roll-Back von Container-Versionen. Auch automatisiert man über redundant laufende Docker-Instanzen und Keep-alive-/Auto-Restart-Mechanismen eine bessere Verfügbarkeit und eine horizontale Skalierung der Docker-Images in Kubernetes Pods (z.B. bei einer erhöhten Last). Dank dem eingebauten Load Balancer muss man sich um viele Aspekte nicht mehr weiter kümmern. In jedem ernsthaften Docker-Betriebsumfeld ist die Funktionalität von Kubernetes eigentlich unverzichtbar. In einfachen Fällen kommt man natürlich auch mit Docker Swarm zu Rande.

In einer IT-Landschaft, die zunehmend stärker modularisiert und Funktionen dann konsequent in mehrere unterschiedliche Container-Images aufspaltet, fehlt aber bei Kubernetes der „Blick für das größere Ganze“. Welche Services bzw. Module ergeben zusammen eine vollständige Anwendung und in welcher Beziehung stehen diese Container? Hier kommen die Helm Charts ins Spiel.

Vielfach nennt man Helm den Package Manager für Kubernetes. Üblicherweise setzt Helm auf K8s auf und erweitert die Fähigkeiten des Systems. Zum Beispiel, indem Versionsabhängigkeiten einer komplexeren Applikation zwischen unterschiedlichen Docker-Images berücksichtigt werden. Bei Updates und Roll-Backs im größeren Stil, welche selbst aus unterschiedlichen Containern aufgebaut sind und Services weiterer, unabhängig vorhandener, Container nutzt. Mit Helm wird diese Komplexität deutlich beherrschbarer. Einfach zu pflegende und zu versionierende Helm Charts beschreiben die Beziehungen zwischen den Komponenten. Anders gesagt: wie liefert man zukünftig eine komplexe modulare Applikation aus? Man liefert die Docker-Images, die Kubernetes-Skripte und ein Helm Chart bzw. stellt sein Chart in ein entsprechendes Repository ein.

Mit Kubernetes und Helm managen wir den Lebenszyklus, die Abhängigkeiten und den Betrieb unserer Container. K8s bietet virtuelles Networking in und zwischen den Pods. Alles läuft und kommuniziert gut. Sind wir jetzt fertig? Nicht ganz.

Über die Zeit laufen immer mehr unserer Funktionen und Systeme in der Container-Welt. Wir entwickeln neue Systeme nach einer Microservice- oder Cloud-native-Architektur und betreiben sie ebenda, wobei wir möglichst wenige Komponenten in einen Container packen. Hiermit steigt die Anzahl unserer Container und der Kommunikationsbeziehungen. Zudem verfolgen wir doch alle das Ziel eines Continuous Deployment: so ergeben sich für jede Komponente immer mehrere Versionen und Varianten in unseren Stages der CI/CD-Pipeline mit – muss man es noch erwähnen – jeweils dedizierten Containern.

Neben einer großen Container-Landschaft erhalten wir auch ein „Service Mesh“. Dies ist der Begriff für die Vielzahl an (Micro-)Services in Kombination mit den Kommunikationsbeziehungen zwischen den Services.

Das Vorhandensein von effizienter Netzwerkfunktionalität ist in solchen Umgebungen nicht mehr genug. Spätestens in diesem Entwicklungsstadium müssen wir die Kommunikation beherrschen, managen und absichern. Hierfür wollen wir unsere bislang gewählte Plattform oder Architektur nicht verlassen. Wir wollen sie ergänzen. Und zwar so, dass wir unseren Entwicklern möglichst wenig zusätzliche Komplexität oder Restriktionen aufbürden.

Istio tritt an, diese Anforderungen zu meistern. Genau wie Helm ist es so ein „Juwel, das kaum einer kennt“. Dabei löst es uns nicht nur Probleme, sondern eröffnet uns neue Möglichkeiten.

Nach längerer gemeinsamer Vorarbeit gingen die Initiatoren Google, IBM und Lyft am 24.05.2017 mit Istio an die Öffentlichkeit und voll in Open Source. Jeder der Founder brachte Konzepte und Code ein, so z.B. Lyft ihren Envoy Proxy, der bei ihnen damals bereits für zehntausende VMs und hunderte Microservices im Einsatz war – auch in Produktion. Ziele waren und sind: “traffic flow management, access policy management enforcement und telemetry data aggregation between microservices […] without requiring developers to make changes to application code”(“https://istio.io/docs/concepts/what-is-istio/”, Oct 2018).

Nach acht 0.x-Releases erschien am 31.07.2018 die Version 1.0 “production ready” von Istio.

Eng integriert mit K8s, wird der Envoy Proxy automatisch in jeden Container als so genanntes Sidecar injiziert und ermöglicht dort, jeglichen Netz-Traffic via HTTP 1.1, HTTP/2, Websockets und gRPC zu kontrollieren. Nebenbei erwähnt, sind noch weitere Protokolle z.B. für asynchrone Kommunikation im Backlog der Istio- und Envoy-Entwickler. Mit diesen Mechanismen können wir nun z.B. leicht Canary Deployments realisieren. Dabei kann man die neue Version bereits deployen, aber nur z.B. 10% der Aufrufe an diese weiterleiten. Dadurch können neue Features bereits unter realistischen Bedingungen getestet werden. Auch A/B-Testing oder Red/Black-Deployments werden stark vereinfacht. Istio erlaubt, den Traffic prozentual zu splitten und per Konfiguration von Circuit Breakers, Timeouts und Retries zu steuern. Zu jeglichem Steuern bedarf es üblicherweise eines Verständnisses des Ist-Zustands und der vorangegangenen Entwicklung. Istio liefert hierfür ein umfassendes Monitoring, Logging und Tracing bis zum Überwachen der Service Levels. Ein zentraler mächtiger Bestandteil von Istio sind Policies, die erweiterbar und customizable sind. So sind eine Reihe an Anbietern von API-Management-Lösungen bereits dabei, ihre Technik mit Istio zu verknüpfen und die Policies der APIs auf die Istio-Policies der zugrundeliegenden Services zu mappen. Das ist nicht nur eine sehr schöne, saubere Architektur sondern zeigt auch, dass diese API-Management-Projekte vom Erfolg von Istio überzeugt sind.

Istio kann den Entwicklern auch viel Komplexität im Bereich Security abnehmen. Es realisiert sichere Kommunikationskanäle und verwaltet die Authentifizierung, Autorisierung und Verschlüsselung auch für sehr große Umgebungen, voll integriert mit Kubernetes und anderen Komponenten. Es ist ein Designziel von Istio, plattformneutral zu sein und so wenig Code-Change wie möglich zu erfordern. Nicht immer will man aber die Funktionen von Istio völlig transparent für den Code realisieren. So können z.B. Java EE-Entwickler mit Microprofile.io-Klassen völlig im Jakarta EE-Standard ihre Circuit Breaker auch mit eigener Logik bereichern, denn Microprofile.io bedient sich in so einem Fall wieder der Istio-APIs.

Wenn Sie langsam begeistert sind, was mit Istio möglich ist und einen Eindruck von der Eleganz der Architektur haben, dann sorgen Sie sich vielleicht, ob es schwer ist, Istio in Ihre Landschaft zu installieren. Wie schon mehrfach erwähnt, integriert sich Istio vorbildlich. Wenn Sie möchten, installieren Sie schlicht und einfach nur das zugehörige Helm Chart für die Istio-Runtime. Zudem sollten Sie wissen, dass Public-Cloud-Anbieter wie z.B. AWS und IBM für Ihre lokale Istio-Instanz entsprechende Konnektoren haben und dass die Public Cloud Runtimes von Google und Co Istio selbst nutzen und für Sie nutzbar machen. Private-Cloud-Angebote wie IBM Cloud Private unterstützen heute schon Istio 1.0; andere wie Red Hat OpenShift haben es nun auf ihren öffentlichen Roadmaps. Auch wenn Cloud Foundry Teil Ihrer Cloud-Strategie ist, können Sie beruhigt sein. Pivotal, IBM und die anderen Mitstreiter arbeiten dort an der Integration mit Istio. Kurz gesagt, können Sie eigentlich nur einen Fehler machen: Istio und Helm nicht in Ihre Planungen aufnehmen.

Auch hier wurde die griechische Mythologie bemüht. Wörtlich der „Vorausdenker“, brachte Prometheus gegen den Willen des Göttervaters Zeus den Menschen das Feuer und wurde hierfür schwerstens bestraft. Wir verlassen die Götterwelt und fragen: Was bringt nun dieses Open-Source-Projekt der Cloud Native Computing Foundation (nebenbei bemerkt, auch das o.g. Envoy ist ein solches Projekt) für unsere Private-Cloud-Architektur?

Ziel des Projektes ist ein absolut hochverfügbares System- und Service-Monitoring anzubieten, das nicht nur vordefinierte Alerts liefert, sondern jederzeit ermöglicht, auf Basis der gesammelten Daten auf Problem- und Fehlersuche zu gehen. Bitte überlesen Sie hierbei auch nicht den Aspekt Service-Monitoring. Je moderner die Architektur, desto zentraler ist die Qualität der Services; der Zustand der Infrastruktur darunter wird als „immer ausreichend gut“ vorausgesetzt. K8s-Umgebungen sind das Hauptziel und hier ist Prometheus auch besonders gut geeignet, das Monitoring zu realisieren. Damit ging das Projekt im Januar 2015 ans Licht der Öffentlichkeit und hat zwischenzeitlich eine sehr hohe Dynamik, Verbreitung und Akzeptanz. So hat z.B. RedHat eine tiefere Integration auf seiner öffentlichen OpenShift Roadmap und IBM Cloud Private integriert Prometheus quasi vollständig, seitdem diese Plattform 2017 auf den Markt kam. Auch Istio Metrics lassen sich in Prometheus nutzen. Pivotal zeigt auch die Nutzung von Prometheus für Cloud Foundry-Umgebungen.

Wer es mit seiner Private-Cloud-Plattform ernst meint, kommt an einem ausgefeilten und universellen Monitoring, das die Technologiekomponenten dieser Plattform explizit im Fokus hat, nicht vorbei. Prometheus ist diesbezüglich unserer Meinung nach nicht nur „the place to be“ ̵ warum sollte man die eigenen initialen Private-Cloud-Projekte anfänglich im „Blindflug“ betreiben, wenn einem solche Tools zur Verfügung stehen?

Auch über Terraform könnte man einen ganzen Artikel, ach was, ganze Fachbücher schreiben. Dessen Thema ist „Reproducable Infrastructure-as-Code“. Wie passt das zu den bislang hier diskutierten Technologiekomponenten? Zum einen ergänzt Terraform unsere versammelten Möglichkeiten für eine Private Cloud, um die Fähigkeiten, Services und Runtimes in Public-Cloud-Angeboten gut integriert und automatisiert dienstbar zu machen. Wer eine Multi-Cloud-Strategie verfolgt, muss nicht nur eine Plattform haben, die zu vielen bzw. in viele Clouds passt. Man muss auch daran denken, wie man mit den Diensten dieser Clouds arbeitet, ohne wieder alles „per Hand“ zu tun. Zum anderen werden Sie sicher feststellen – außer Sie arbeiten für ein kürzlich gegründetes Start-Up – Ihre IT ist noch nicht durchgängig entsprechend einer Cloud-native-Architektur gebaut. Da gibt es Applikationen und Komponenten, welche bestenfalls als Gruppe von VMs zu handhaben sind. Da gibt es gar Applikationen, die echte Bare-Metal-Compute- oder Storage-Anforderungen haben. Diese mögen aber zukünftig bitte wohlintegriert und automatisiert in Ihrem CI/CD und Ihren Konzepten für Ihre Private Cloud „mitspielen“. Voilá, Terraform à votre service. Es gibt auch Anbieter, die Terraform mit Helm Charts integrieren, so dass nicht nur die Docker-Welt sondern eben auch alles, was man mit Terraform erreichen kann, transparent in ein Chart kommen kann. Sie sollten sich also umgehend auch mit Terraform beschäftigen.

All together now!

Was bekommen wir, wenn wir diesen gesamten Technologie-Stack integriert und aufeinander abgestimmt nutzen können? Dies liefert eine Private Cloud, welche nicht nur erste Gehversuche bewältigt, sondern echte harte Anforderungen für eine ernsthafte, strategische und produktive Nutzung im größeren und großen Umfang.

Auch in Public Clouds?

Alles was wir hier diskutiert haben, ist sowohl für Ihre Private Cloud als auch für die meisten und namhaften Public Clouds relevant. Wenn ihr Anbieter noch nicht da ist, dann sind Sie einfach besser für die Zukunft einer auf offenen Standards-basierenden Cloud vorbereitet, als dieser. Aber der Erfahrung nach ziehen solche Anbieter bald nach, wenn der Markt sie drängt – auch die größten.

Dieser Artikel ist zugegeben eine Achterbahnfahrt entlang der Lernkurve. Wenn Sie uns folgen konnten, dann können Sie sich auf die echte Fahrt freuen und aktiv werden. Es ist Zeit, zu handeln.

Ihr Ansprechpartner

   Joachim Gucker
   IT-Architekt und CEO
   +49 89 32468-190
   joachim.gucker@ars.de

Original Fachartikel

Erschienen am 09.01.2019 im Java Magazin 2.19:

Sonderdruck_JM2_19_ARS (.pdf)