© Rawpixel.com/Shutterstock.com
Architekturlernkurve für die Private Cloud

Stellen Sie Ihr Team zusammen


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.

In Bezug auf Cloud- und Containertechnologien stehen sehr interessante und leicht zugängliche Zahlen zur Verfügung (Abb. 1). Wer bei Twitter nachforscht, findet für Docker 304 000 und für Kubernetes 121 000 Follower. Aber für Helm, Istio und Prometheus Monitoring sind wir bei jeweils unter 15 000 Followern.

gucker_architekturlernkurve_1.tif_fmt1.jpgAbb. 1: Vergleich Twitter Follower (blau), Stack Overflow Searches (rot) und Google Keyword Searches (grün) der jeweiligen Technologien

Zu Terraform bietet uns 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 Containertechnologie sinnvoll ist und Zukunft hat. Zudem nutzen viele Entwickler bereits 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? Meine These dazu lautet: Einerseits gibt es eine zeitliche Entwicklung, in der die Themen populär werden. Andererseits gibt es eine Lernkurve der Softwarearchitekten. Beide korrelieren.

Was heißt Lernkurve?

Wie kommen wir Softwarearchitekten mit den Themen üblicherweise in der Praxis in Berührung? Wir entdecken mit Begeisterung Docker [1] und sehen dann rasch den Nutzen in der Kombination mit Kubernetes. Wir müssen zuerst noch Erfahrung sammeln, bis wir bemerken, dass unsere Cloud-Plattform noch etwas mehr können muss, um unseren wachsenden und zukünftigen Anforderungen standzuhalten. 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“?

Ein Kollege hat es treffend formuliert: „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, die grundlegendere Technologien noch anderen Projekten zur Lösung überlassen. Das ist weder in der IT noch bei Open-Source-Projekten ein Novum. Warum über solche selbstverständlichen Muster in der IT also einen Artikel schreiben? Die Antwort lautet: Wenn man weiß, was man lernen muss, kann man es planen.

Fangen wir mit Kubernetes an

Wer mit Docker beginnt, merkt rasch, dass sich die Container vermehren. Über kurz oder lang laufen viele Container. Um deren Lebenszyklus oder Hochverfügbarkeit zu verwalten, wächst der Aufwand immer mehr an, und man steckt Grips und Zeit in seine Skripte. Dafür lässt sich Abhilfe schaffen. Das Open-Source-Projekt Kubernetes [2] steuert Docker-Container und hat sich diesbezüglich als Quasistandard etabliert. Entwickler oder Administratoren geben Kubernetes per YAML-File vor, welche Docker Images laufen sollen und wie oft. Zudem erlaubt das System ein Roll-forward und Roll-back von Containerversionen. Auch lassen sich ü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 automatisieren. Das trifft beispielsweise bei einer erhöhten Last zu. Dank des eingebauten Load Balancers muss sich der Anwender 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 zurecht.

In einer IT-Landschaft, die zunehmend stärker modularisiert und Funktionen entsprechend konsequent in mehrere unterschiedliche Container-Images aufspaltet, fehlt aber bei K...

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