1Revolution in der Cloud
Es gab nie einen Zeitpunkt, an dem die Welt angefangen hat, weil sie immer wie in einem Kreis herumgeht. Auf einem Kreis gibt es aber keinen Punkt, wo er beginnt.
– Alan Watts
Eine Revolution findet statt. Eigentlich sind es sogar drei Revolutionen zugleich.
Die erste Revolution ist das Entstehen der Cloud – und wir werden noch erläutern, um was es sich da handelt und warum das wichtig ist. Die zweite ist das Aufkommen von DevOps, zu dem Sie erfahren werden, was darin steckt und wie es Operations verändert. Die dritte Revolution ist der Einsatz von Containern. Zusammen schaffen diese drei Wellen eine neue Software-Welt: die Cloud Native-Welt. Und das Betriebssystem für diese Welt nennt sich Kubernetes.
In diesem Kapitel werden wir kurz auf die Geschichte und Bedeutung dieser Revolutionen eingehen und aufzeigen, wie die Veränderungen die Art und Weise beeinflussen, nach der wir Software deployen und betreiben. Wir werden zeigen, was Cloud Native bedeutet und welche Unterschiede Sie in dieser neuen Welt erwarten können, wenn Sie im Software Development, in Operations, Deployment, der Entwicklung, im Networking oder im Sicherheitsumfeld tätig sind.
Wir denken, dass die Zukunft des Computing dank der Auswirkungen dieser miteinander verbundenen Revolutionen in cloudbasierten, containerisierten, verteilten Systemen liegt, die dynamisch per Automatisierung verwaltet werden und auf der Kubernetes-Plattform (oder etwas sehr Ähnlichem) laufen. Die Kunst des Entwickelns und Ausführens dieser Anwendungen – Cloud Native DevOps – wollen wir dann im weiteren Verlauf dieses Buches unter die Lupe nehmen.
Sind Sie mit diesem Hintergrund schon vertraut und wollen einfach mit Kubernetes loslegen, dürfen Sie gerne direkt zu Kapitel 2 springen. Wenn nicht, machen Sie es sich bequem, schnappen Sie sich eine Tasse Kaffee (oder was Sie gerne mögen) und dann legen wir los.
1.1Die Entstehung der Cloud
In den Anfängen (okay, in den 1960ern) füllten Computer Rack um Rack in großen, abgelegenen, klimatisierten Rechenzentren. Die Anwender bekamen sie nie zu sehen und konnten auch gar nicht direkt mit ihnen interagieren. Stattdessen reichten die Entwickler ihre Jobs aus der Ferne an den Computer ein und warteten auf die Ergebnisse. Viele Hunderte oder Tausende von Anwendern nutzten alle die gleiche Rechen-Infrastruktur und jeder erhielt eine Rechnung für die genutzte Prozessorzeit oder die verwendeten Ressourcen.
Für einzelne Unternehmen oder Organisationen lohnte es sich nicht, ihre eigene Rechenhardware zu kaufen und zu warten, daher entstand ein Geschäftsmodell, bei dem die Anwender die Rechenleistung auf woanders untergebrachten Computern gemeinsam nutzten, die jemand anderem gehörten, der sich auch um sie kümmerte.
Wenn sich das so anhört, als ob das nicht aus dem letzten Jahrhundert stammt, sondern hochaktuell ist – stimmt, das ist kein Zufall. Das Wort Revolution bedeutet »kreisförmige Bewegung« und die Computer sind, in gewisser Hinsicht, wieder dort gelandet, wo es begann. Sie sind zwar im Laufe der Jahre viel leistungsfähiger geworden – die aktuelle Apple Watch entspricht in etwa drei der Mainframes, die Sie in Abbildung 1–1 sehen – aber ein Pay-per-Use-Zugriff auf gemeinsam genutzte Rechenressourcen ist eine sehr alte Idee. Jetzt nennen wir das die Cloud und die Revolution, die mit Timesharing-Mainframes begann, hat ihren Kreis geschlossen.
Abb. 1–1Frühes Cloud Computing: Das IBM System/360 Model 91 im Goddard Space Flight Center der NASA
1.1.1Zeit einkaufen
Die zentrale Idee der Cloud ist folgende: Statt einen Rechner zu kaufen, kaufen Sie Rechenleistung. Statt also große Mengen an Kapital in realen Maschinen zu versenken, die sich schlecht skalieren lassen, kaputtgehen und schnell obsolet werden, kaufen Sie einfach Zeit auf dem Rechner von jemand anderem und lassen ihn sich um das Skalieren, Warten und Aktualisieren kümmern. In den Tagen der »Bare-Metal«-Geräte – dem »Eisenzeitalter«, wenn Sie so wollen – handelte es sich bei Rechenleistung um Anlagekosten. Jetzt sind es Betriebsausgaben, was einen großen Unterschied ausmacht.
Bei der Cloud geht es aber nicht nur um woanders stehende, gemietete Rechenleistung. Es geht auch um verteilte Systeme. Sie kaufen vielleicht reine Rechenressourcen (wie eine Google-Compute-Instanz oder eine AWS-Lambda-Funktion) und nutzen sie, um Ihre eigene Software auszuführen, aber zunehmend mieten Sie auch Cloud Services – im Prinzip den Einsatz von Software von jemand anderem. Verwenden Sie zum Beispiel PagerDuty, um Ihre Systeme zu monitoren und Sie zu benachrichtigen, wenn etwas nicht läuft, setzen Sie einen Cloud Service ein (manchmal auch als Software as a Service oder SaaS bezeichnet).
1.1.2Infrastructure as a Service
Nutzen Sie die Cloud-Infrastruktur, um Ihre eigenen Services laufen zu lassen, kaufen Sie Infrastructure as a Service (IaaS). Sie müssen kein Kapital binden, um sie zu kaufen, Sie müssen sie nicht aufbauen und auch nicht aktuell halten. Es ist einfach ein Rohstoff, so wie Strom oder Wasser. Cloud Computing ist eine Revolution in der Beziehung zwischen Unternehmen und ihrer IT-Infrastruktur.
Das Outsourcen der Hardware ist nur ein Teil der Geschichte – die Cloud ermöglicht es Ihnen zudem, die Software outzusourcen, die Sie nicht schreiben: Betriebssysteme, Datenbanken, Clustering, Replikation, Networking, Monitoring, Hochverfügbarkeit, Queue und Stream Processing und all die Unmengen an Software- und Konfigurations-Schichten, die die Lücke zwischen Ihrem Code und der CPU füllen. Managed Services können sich um so gut wie all das undifferenzierte »Heavy Lifting« für Sie kümmern (mehr zu den Vorteilen von Managed Services finden Sie in Kapitel 3).
Die Revolution in der Cloud hat auch eine Revolution bei den Leuten ausgelöst, die sie nutzen: die DevOps-Bewegung.
1.2Der Aufstieg von DevOps
Vor DevOps handelte es sich beim Entwickeln und Betreiben von Software mehr oder weniger um zwei getrennte Jobs, die von zwei verschiedenen Gruppen durchgeführt wurden. Entwickler schrieben Software, die sie dann an die Operations-Kollegen gaben, die die Software in der Produktivumgebung ausführten und betreuten (also echte Anwender bedienten, statt nur unter Testbedingungen zu laufen). Wie Computer, die eine eigene Etage im Gebäude brauchten, hat diese Trennung ihre Wurzeln in der Mitte des letzten Jahrhunderts. Software-Entwicklung war eine Aufgabe für Spezialisten, genauso wie das Betreiben der Computer, und es gab zwischen beidem nur wenig Überschneidungen.
Die beiden Abteilungen hatten dabei ziemlich unterschiedliche Ziele und Anreize, die öfter mal miteinander in Konflikt gerieten (Abbildung 1–2). Entwickler konzentrieren sich gerne darauf, schnell neue Features zu liefern, während es Operations-Teams wichtiger ist, Services langfristig stabil und zuverlässig zu machen.
Abb. 1–2Getrennte Teams können zu miteinander in Konflikt stehenden Anreizen führen. (Foto von Dave Roth)
Als die Cloud am Horizont erschien, wurde es anders. Verteilte Systeme sind komplex und das Internet ist sehr groß. Die Formalitäten beim Betreiben des Systems – Wiederherstellen nach Ausfällen, Umgang mit Timeouts, flüssiges Aktualisieren auf neuere Versionen – lassen sich nicht so einfach vom Design, der Architektur und Implementierung des Systems trennen.
Zudem ist »das System« nicht mehr länger nur Ihre Software: Es besteht aus In-House-Software, Cloud Services, Netzwerkressourcen, Load Balancern, Monitoring, Content Distribution Networks, Firewalls, DNS und so weiter. All diese Dinge sind eng miteinander verbunden und voneinander abhängig. Die Leute, die die Software schreiben, müssen verstehen, wie sie mit dem Rest des Systems im Zusammenhang steht, und die Leute, die das System betreiben, müssen verstehen, wie die Software funktioniert – oder auch nicht funktioniert.
Die Ursprünge der DevOps-Bewegung liegen in den Versuchen, diese beiden Gruppen zusammenzubringen – um zusammenzuarbeiten, ein gemeinsames Verständnis zu schaffen, die Verantwortung für die Zuverlässigkeit des Systems und die Korrektheit der Software zusammenzutragen und die Skalierbarkeit sowohl der Software-Systeme als auch der Teams zu verbessern, die sie bauen.
1.2.1Keiner versteht DevOps
DevOps wird gelegentlich als sehr umstrittene Sache angesehen, sowohl von Leuten, die darauf bestehen, dass es sich um nicht mehr als...
