Time to Market, Skalierbarkeit und Kosteneffizienz sind die Merkmale der Cloud. Wer wettbewerbsfähig bleiben will braucht eine Cloud Strategie. Sonnenklar? Kubernetes? Läuft? Dieser Post versucht zu erklären warum heute kein Weg an Kubernetes vorbei geht.
tl;dr: ☝️ Check yourself before you wreck yourself!
Cloud Computing
Public Cloud Computing war 2018 ein USD 182 Mrd. USD Markt. Gartener erwartet bis 2022 weiter starkes Wachstum. Vor diesem Hintergrund also kein Wunder das man heute beim Wettbewerb der Giganten Amazon, Microsoft Google und IBM von Cloud Wars spricht – aktuelles Schlachtfeld unter anderen On-Premise/Hybrid. Trends der einzelnen Segmente findet man u.a. im Gartner Hype Cycle for Cloud Computing, 2018. Weiterhin prognostiziert Gartner, dass viele Softwarehersteller bis zum Jahr 2020 “Cloud-first”-Strategien durch “Cloud-only“ ersetzen
Konkret heißt das für Anwender:
Organizations that do not have a high-level cloud strategy driven by their business strategy will significantly increase their risk of failure and wasted investment. (David W. Cearley, Vice President and Gartner Fellow, Gartner Research)
Traditionell dient Datenschutz in Europa oft als Totschlag-Argument gegen die Public Cloud. Ich bin kein europäischer Datenschützer und ich möchte hier auch nicht auf das Thema eingehen. Denjenigen welchen das Thema am Herz liegt finden vielleicht Antworten in den Success Stories OTTO goes AWS – Teil 1 , OTTO goes AWS – Teil 2 oder der Keynote “From COBOL to Kubernetes: A 250 Year Old Bank’s Cloud-Native Journey”.
Um schnell ein grobes Gefühl für das aktuelle High-End im Cloud Computing zu bekommen kann man einen Blick auf das obere Ende der Skala – also auf die Produkte des Marktführers Amazon Cloud werfen.
Cloud Native
Cloud Native ein essentieller Begriff im Kubernetes Kontext:
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone. (Definition 1.0)
In diesem wenigen Worten steckt so unglaublich viel, dass an dieser Stelle nur ganz kurz darauf eingegangen werden soll. Es ändert alles. Wirklich ALLES. Durch und durch. Das jedenfalls ist mein Empfinden als jemand der Linux seit 1995 nutzt.
Die neuen Building Blocks sind Container die “überall” laufen können und die hochdynamisch vernetzt werden. Technisch hilft die CNCF Cloud Native Interactive Landscape hilft bei der Orientierung aus der Vogelperspektive. Datenbanken, Storage, Security, Networking, Workload Scheduling, Observability, Packaging, Automation – alles ist anders. Ganz anders. Microservices Pattern reflektieren das auf Architektur-Ebene. Neue Richtlinien wie Twelve-Factor App oder das Reactive Manifesto sind entstanden. Techniker die bisher nur mit klassischen Monolithen und SOA gearbeitet haben sind gut beraten sich frühzeitig mit diesen Dingen vertraut zu machen. In Kubernetes begegnen sie einem ununterbrochen und es hilft ungemein wenn man die DNA der Dinge versteht.
Dinge die man bis dato gut verstanden zu haben schien werden plötzlich Neuland – z.B. Storage. Die größten Erdbeben scheinen aktuell im Netzwerk Umfeld zu liegen. Auf der KubeCon / Cloud Native Con 2019 in Barcelona schien es mir so als ob die Hälfte der Talks im Umfeld Service Mesh, API Gateway und Service Proxy waren. Man traut sich da kaum über den Tellerrand zu blicken und sich zu fragen wann und wie Änderungen an den Building Blocks des Networking wie EBPF durchschlagen. Die Tatsache, dass man inzwischen oft schon von DevSecOps spricht lässt erahnen wie gigantisch das Thema Sicherheit ist. Und wie es darum steht. ?
Stichwort DNA: Die Cloud Native Definition signalisiert bereits die DevOps DNA der Dinge (s. DevOps or die!). Ich würde behaupten, wertschöpfende Nutzung von Kubernetes ist ohne DevOps Kultur nicht möglich und man sollte es besser sein lassen wenn man nicht bereit ist DevOps zu leben.
Kubernetes
Das mit der Dynamik trifft im Übrigen auch auf die Entwicklung von Kubernetes zu. Es ist zusammen mit Linux “fastest moving project in Open Source history” (Dan Kohn, CNCF executive director).
Aber was genau ist eigentlich Kubernetes und warum genau geht es so durch die Decke?
Kubernetes ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen.
Es ist entstanden aus “Borg” – einem Google internen Projekt zur Verwaltung von Containern. Es wurde 2014 von Google als Open Source freigegeben. In diesem Zuge wurde die Cloud Native Computing Foundation unter dem Dach der Linux Foundation gegründet. Zu diesem Zeitpunkt gab es bereits viele verschiedene Lösungen für vergleichbare Probleme. Die Ursache für den kometenhaften Aufstieg liegen in Open Source und der Demokratisierung – Niemand macht sich gerne abhängig von einem Anbieter (Vendor Lock-In), alle lieben Open Source.
Wo anfangen? Was gibt es zu tun?
Um das zu beantworten sollte man sich Zeit nehmen ein paar Fragen beantworten:
- Welche Kubernetes-/DevOps-/Linux-/Go Skills habe ich im Unternehmen?
- Welche Dinge möchte ich bis wann erledigen und welche Kapazitäten habe ich?
- Welche Themen (Infrastruktur, Plattform, Entwicklung, Betrieb) möchte ich langfristig in House behalten? Bin ich damit wettbewerbsfähig?
- Überblicke ich den Blast-Radius der Dinge und habe ich Backup & Recovery im Griff?
- Wie sieht der Markt für Produkte und Dienstleitungen aus?
- Wo gehe ich Top Down, wo Bottom Up vor?
- Was erwarte ich an Total Cost of Ownership?
Man sollte unbedingt wissen wo man steht, was die erste Station der Reise sein soll, wie weit der zur ersten Station und wie der initiale Kurs ist. “Kubernetes is a Journey, not a destination”.
Auch hier schadet der eine oder andere Blick an das obere Ende der Skala nicht. In Sachen Betrieb ist das aktuell zum Beispiel Site Reliability Engineering :
Wie viel Infrastruktur und Betrieb kann ich mir selbst zumuten?
Management Protip: Man macht den Bock nicht über Nacht zum Gärtner. Anwendungs-Entwickler sind in der Regel keine guten Infrastruktur Entwickler. Im Gegenteil: Anwendungs-Entwickler sollten möglichst wenig von Infrastruktur sehen. Dieser Anspruch ist insbesondere auch Gegenstand von Serverless … das gerade auch deswegen (und wegen der Kosten) ebenfalls durch die Decke geht – und zwar so, dass die CNCF diesem Segment eine dedizierte Karte spendiert hat.
Fazit: Kubernetes erobert die Cloud im Sturm. Widerstand ist zwecklos. Man sollte sich frühzeitig Zeit nehmen ein wenig Verständnis für die Dinge im Großen und Ganzen zu bekommen und eine Cloud Strategie zu erarbeiten. Dienstleister können helfen. ?