Cloud Native DevOps mit Kubernetes, 2. Auflage

Kapitel 1. Revolution in der Cloud

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Es gab nie einen Zeitpunkt, an dem die Welt begann, denn sie dreht sich immer weiter wie ein Kreis, und es gibt keinen Ort auf einem Kreis, an dem sie beginnt.

Alan Watts

Es ist eine Revolution im Gange. Eigentlich sind es drei Revolutionen.

Die erste Revolution ist die Entstehung der Cloud, und wir erklären, was das ist und warum sie wichtig ist. Die zweite ist der Beginn von DevOps, und du erfährst, was das bedeutet und wie es den Betrieb verändert. Die dritte Revolution ist die breite Einführung von Containern. Zusammen schaffen diese drei Wellen des Wandels eine neue Softwarewelt: die Cloud Native World. Das Betriebssystem für diese Welt heißt Kubernetes.

In diesem Kapitel gehen wir kurz auf die Geschichte und die Bedeutung dieser Revolutionen ein und untersuchen, wie sich die Veränderungen auf die Art und Weise auswirken, wie wir alle Software einsetzen und betreiben. Wir erläutern, was Cloud Native bedeutet und welche Veränderungen du in dieser neuen Welt erwarten kannst, wenn du in der Softwareentwicklung, im Betrieb, in der Bereitstellung, im Engineering, im Netzwerk oder in der Sicherheit tätig bist.

Dank der Auswirkungen dieser miteinander verknüpften Revolutionen glauben wir, dass die Zukunft des Computings in cloudbasierten, containerisierten, verteilten Systemen liegt, die dynamisch durch Automatisierung auf der Kubernetes-Plattform (oder einer ähnlichen Plattform) verwaltet werden. Die Kunst, diese Anwendungen zu entwickeln und zu betreiben - CloudNative DevOps -werden wir im weiteren Verlauf dieses Buches erkunden.

Wenn du bereits mit all diesem Hintergrundmaterial vertraut bist und einfach nur Spaß mit Kubernetes haben willst, kannst du gerne zu Kapitel 2 übergehen. Wenn nicht, mach es dir mit einer Tasse deines Lieblingsgetränks gemütlich und wir fangen an.

Die Entstehung der Cloud

In den Anfängen (zumindest in den 1960er Jahren) füllten die Computer ein Rack nach dem anderen in riesigen, abgelegenen und klimatisierten Rechenzentren, ohne dass die Benutzer sie jemals zu Gesicht bekamen oder direkt mit ihnen interagieren konnten. Stattdessen übermittelten die Entwickler ihre Aufträge per Fernzugriff an die Maschine und warteten auf die Ergebnisse. Viele Hunderte oder Tausende von Nutzern teilten sich dieselbe Recheninfrastruktur und erhielten lediglich eine Rechnung für die genutzte Prozessorzeit oder Ressourcen.

Da es für jedes Unternehmen oder jede Organisation nicht kosteneffizient war, eigene Computerhardware zu kaufen und zu warten, entstand ein Geschäftsmodell, bei dem die Nutzerinnen und Nutzer die Rechenleistung von Remote-Rechnern nutzen, die einer dritten Partei gehören und von ihr betrieben werden.

Wenn das nach jetzt und nicht nach letztem Jahrhundert klingt, ist das kein Zufall. Das Wort Revolution bedeutet "kreisförmige Bewegung", und die Computertechnik ist gewissermaßen dorthin zurückgekehrt, wo sie begann. Zwar sind die Computer im Laufe der Jahre viel leistungsfähiger geworden - die heutige Apple Watch entspricht etwa drei Großrechnern, wie sie in Abbildung 1-1dargestellt sind -, aber die Idee des gemeinsamen, kostenpflichtigen Zugangs zu Rechenressourcen ist uralt. Heute nennen wir sie Cloud, und die Revolution, die mit Time-Sharing-Großrechnern begann, schließt den Kreis.

Abbildung 1-1. Früher Cloud-Computer: das IBM System/360 Model 91 im Goddard Space Flight Center der NASA

Zeit kaufen

Die zentrale Idee der Cloud ist folgende: Anstatt einen Computer zu kaufen, kaufst du Rechenleistung. Das heißt, anstatt große Mengen an Kapital in physische Maschinen zu stecken, die schwer zu skalieren sind, mechanisch kaputt gehen und schnell veralten, kaufst du einfach Zeit auf dem Computer eines anderen und überlässt ihm die Skalierung, Wartung und Aufrüstung. In den Tagen der Bare-Metal-Maschinen - dem "Eisernen Zeitalter", wenn du so willst - war Rechenleistung eine Kapitalausgabe. Jetzt ist sie eine Betriebsausgabe, und das hat den Unterschied gemacht.

Bei der Cloud geht es nicht nur um entfernte, gemietete Rechenleistung. Es geht auch um verteilte Systeme. Du kannst Rechenressourcen kaufen (z. B. eine Google Compute Instance oder eine AWS Lambda-Funktion) und sie für deine eigene Software nutzen, aber zunehmend mietest du auch Cloud-Dienste: im Wesentlichen die Nutzung der Software von jemand anderem. Wenn du zum Beispiel PagerDuty benutzt, um deine Systeme zu überwachen und dich zu benachrichtigen, wenn etwas nicht funktioniert, nutzt du einen Cloud-Dienst (manchmal auch Software as a Service oder SaaS genannt). Der Erfolg dieser SaaS-Dienste ist zum Teil auf die jüngste Revolution der Cloud zurückzuführen. Jetzt kann fast jeder eine neue App oder Website erstellen, sie bei einem öffentlichen Cloud-Provider hosten und sie bei Erfolg auf ein weltweites Publikum ausweiten.

Infrastruktur als Dienstleistung

Wenn du eine Cloud-Infrastruktur nutzt, um deine eigenen Dienste zu betreiben, kaufst du eine Infrastruktur als Service (IaaS). Du musst kein Kapital aufwenden, um sie zu kaufen, du musst sie nicht bauen und du musst sie nicht aufrüsten. Sie ist einfach eine Ware, wie Strom oder Wasser. Cloud Computing ist eine Revolution in der Beziehung zwischen Unternehmen und ihrer IT-Infrastruktur.

Die Auslagerung der Hardware ist nur ein Teil der Geschichte. Die Cloud ermöglicht es dir auch, die Software auszulagern, die du nicht selbst schreibst: Betriebssysteme, Datenbanken, Clustering, Replikation, Netzwerke, Überwachung, Hochverfügbarkeit, Warteschlangen- und Stream-Verarbeitung und all die unzähligen Software- und Konfigurationsebenen, die die Lücke zwischen deinem Code und der CPU überbrücken. Managed Services können dir fast alle dieser undifferenzierten Aufgaben abnehmen (mehr über die Vorteile von Managed Services erfährst du in Kapitel 3).

Die Revolution in der Cloud hat auch eine andere Revolution bei den Menschen ausgelöst, die sie nutzen: die DevOps-Bewegung.

Die Morgendämmerung von DevOps

Vor DevOps waren die Entwicklung und der Betrieb von Software im Wesentlichen zwei getrennte Aufgaben, die von zwei verschiedenen Personengruppen ausgeführt wurden. Die Entwickler/innen schrieben die Software und gaben sie an die Betriebsmitarbeiter/innen weiter, die die Software in der Produktion betrieben und warteten (d.h. für echte Nutzer/innen, anstatt sie nur intern zu Testzwecken oder zur Entwicklung neuer Funktionen einzusetzen). Wie die riesigen Großrechner, die eine eigene Etage im Gebäude benötigten, hatte diese Trennung ihre Wurzeln in der Mitte des letzten Jahrhunderts. Die Softwareentwicklung war ein sehr spezieller Job, ebenso wie der Betrieb von Computern, und es gab nur wenige Überschneidungen zwischen diesen beiden Rollen.

Die beiden Abteilungen hatten ganz unterschiedliche Ziele und Anreize, die oft miteinander kollidierten. Die Entwickler konzentrierten sich darauf, neue Funktionen schnell bereitzustellen, während sich die Betriebsteams vor allem darum kümmerten, die Dienste langfristig stabil und zuverlässig zu machen. In manchen Fällen gab es Sicherheitsrichtlinien, die es den Softwareentwicklern nicht einmal erlaubten, auf die Logs oder Metriken ihrer eigenen Anwendungen zuzugreifen, die in der Produktion laufen. Sie mussten das Betriebsteam um Erlaubnis bitten, um die Anwendung zu debuggen und Korrekturen vorzunehmen. Und oft war es das Betriebsteam, dem die Schuld gegeben wurde, wenn es ein Problem mit einer Anwendung gab, unabhängig von der Ursache.

Als Cloud Computing immer beliebter wurde, veränderte sich die Branche. Verteilte Systeme sind komplex, und das Internet ist sehr groß. Die technischen Aspekte dieser verteilten Systeme - wenn es darum geht, Ausfälle zu beheben, mit Zeitüberschreitungen umzugehen und Versionen reibungslos zu aktualisieren - lassen sich nicht so einfach von Design, Architektur und Implementierung des Systems trennen.

Außerdem ist "das System" nicht mehr nur deine Software: Es besteht aus interner Software, Cloud-Diensten, Netzwerkressourcen, Load Balancern, Monitoring, Content Distribution Networks, Firewalls, DNS und so weiter. All diese Dinge sind eng miteinander verknüpft und voneinander abhängig. Die Leute, die die Software schreiben, müssen verstehen, wie sie mit dem Rest des Systems zusammenhängt, und die Leute, die das System betreiben, müssen verstehen, wie die Software funktioniert und wie sie fehlschlägt.

Verbesserung der Rückkopplungsschleifen

Die Ursprünge der DevOps-Bewegung liegen in dem Versuch, diese beiden Gruppen zusammenzubringen: zusammenzuarbeiten, ein gemeinsames Verständnis zu entwickeln, die Verantwortung für die Zuverlässigkeit der Systeme und die Korrektheit der Software zu teilen und die Skalierbarkeit sowohl der Softwaresysteme als auch der Teams, die sie erstellen, zu verbessern.

Bei DevOps geht es darum, die Feedbackschleifen und Übergabepunkte zu verbessern, die zwischen den verschiedenen Teams bestehen, wenn sie Code schreiben, Anwendungen entwickeln, Tests durchführen und Änderungen bereitstellen, um sicherzustellen, dass die Dinge reibungslos und effizient ablaufen.

Was bedeutet DevOps?

Die Definition des BegriffsDevOps ist gelegentlich umstritten, sowohl bei denjenigen, die darauf bestehen, dass es nichts weiter als ein modernes Etikett für bestehende gute Praktiken in der Softwareentwicklung ist, als auch bei denjenigen, die die Notwendigkeit einer stärkeren Zusammenarbeit zwischen Entwicklung und Betrieb überhaupt ablehnen.

Es gibt auch ein weit verbreitetes Missverständnis darüber, was DevOps eigentlich ist: Eine Berufsbezeichnung? Ein Team? Eine Methodik? Eine Fähigkeit? Der einflussreiche DevOps-Autor John Willis hat vier Grundpfeiler von DevOps identifiziert, die er Culture, Automation, Measurement und Sharing (CAMS) nennt. Unternehmen, die DevOps praktizieren, haben eine Kultur, die die Zusammenarbeit fördert, die es ablehnt, Wissen zwischen Teams zu isolieren, und die Wege findet, um zu messen, wie sie sich ständig verbessern können. Brian Dawson hat die DevOps-Dreieinigkeit genannt: Menschen und Kultur, Prozesse und Praktiken sowie Tools und Technologien.

Manche Leute denken, dass wir dank Cloud und Containern kein DevOps mehr brauchen - eine Sichtweise, die manchmal auch als NoOps bezeichnet wird. Der Gedanke dahinter ist, dass Unternehmen keine Vollzeitmitarbeiter für den Betrieb benötigen, da der gesamte IT-Betrieb an einen Cloud-Provider oder einen anderen Drittanbieter ausgelagert ist.

Der NoOps-Irrtum basiert auf einer falschen Vorstellung davon, was DevOps-Arbeit eigentlich beinhaltet:

Bei DevOps findet ein Großteil der traditionellen IT-Betriebsarbeit statt, bevor der Code die Produktion erreicht. Jede Veröffentlichung beinhaltet Überwachung, Protokollierung und A/B-Tests. CI/CD-Pipelines führen bei jeder Übertragung automatisch Unit-Tests, Sicherheitsscanner und Richtlinienprüfungen durch. Die Bereitstellung erfolgt automatisch. Kontrollen, Aufgaben und nicht-funktionale Anforderungen werden jetzt vor der Veröffentlichung implementiert, anstatt in der Hektik und nach einem kritischen Ausfall.

Jordan Bach(AppDynamics)

Im Moment findest du viele Stellenausschreibungen für den Titel "DevOps Engineer" und eine große Bandbreite an Erwartungen an diese Rolle, je nach Unternehmen. Manchmal ähnelt sie eher einer traditionellen "Systemadministrator"-Funktion und hat nur wenig mit Softwareentwicklern zu tun. Manchmal ist die Rolle in die Arbeit von Entwicklern eingebettet, die ihre eigenen Anwendungen entwickeln und bereitstellen. Es ist wichtig, dass du dir überlegst, was DevOps für dich bedeutet und wie du es dir in deinem Unternehmen vorstellst.

Das Wichtigste an DevOps ist, dass es in erster Linie ein organisatorisches, menschliches und nicht ein technisches Problem ist. Das stimmt mit Jerry Weinbergs zweitem Gesetz der Beratung überein:

Egal, wie es auf den ersten Blick aussieht, es ist immer ein menschliches Problem.

Gerald M. Weinberg, Die Geheimnisse der Beratung

Und DevOps funktioniert wirklich. Studien zeigen regelmäßig, dass Unternehmen, die DevOps-Prinzipien anwenden, bessere Software schneller veröffentlichen, besser und schneller auf Fehler und Probleme reagieren, agiler auf dem Markt sind und die Qualität ihrer Produkte drastisch verbessern:

DevOps ist keine Modeerscheinung, sondern die Art und Weise, wie erfolgreiche Unternehmen heute die Bereitstellung von Qualitätssoftware industrialisieren, und sie wird morgen und in den kommenden Jahren die neue Grundlage sein.

Brian Dawson, CloudBees

Infrastruktur als Code

Früher kümmerten sich die Entwickler um die Software, während sich die Betriebsteams um die Hardware und die Betriebssysteme kümmerten, die auf dieser Hardware laufen.

Jetzt, wo die Hardware in der Cloud ist, ist in gewissem Sinne alles Software. Die DevOps-Bewegung bringt die Fähigkeiten der Softwareentwicklung in den Betrieb ein: Werkzeuge und Arbeitsabläufe für die schnelle, agile und gemeinschaftliche Entwicklung komplexer Systeme. Dies wird oft als Infrastructure as Code (IaC) bezeichnet.

Anstatt Computer und Switches physisch aufzustellen und zu verkabeln, kann die Cloud-Infrastruktur automatisch durch Software bereitgestellt werden. Anstatt Hardware manuell zu installieren und zu aktualisieren, schreiben die Betriebsingenieure die Software, die die Cloud automatisiert.

Der Verkehr ist nicht nur eine Einbahnstraße. Die Entwickler/innen lernen von den Betriebsteams, wie man Ausfälle und Probleme in verteilten, cloudbasierten Systemen voraussieht, wie man ihre Folgen abmildert und wie man Software so gestaltet, dass sie sich nicht verschlechtert und sicher ausfällt.

Gemeinsam lernen

Sowohl die Entwicklungsteams als auch die Betriebsteams lernen, wie sie zusammenarbeiten können. Sie lernen, wie man Systeme entwirft und aufbaut, wie man Systeme in der Produktion überwacht und Rückmeldungen dazu erhält und wie man diese Informationen nutzt, um die Systeme zu verbessern. Noch wichtiger ist jedoch, dass sie lernen, die Erfahrung für ihre Nutzer/innen zu verbessern und einen besseren Wert für das Unternehmen zu schaffen, das sie finanziert.

Der massive Umfang der Cloud und die kollaborative, codezentrierte Natur der DevOps-Bewegung haben den Betrieb zu einem Softwareproblem gemacht. Gleichzeitig haben sie aber auch Software zu einem betrieblichen Problem gemacht. All das wirft diese Fragen auf:

• Wie kannst du Software in großen, heterogenen Netzwerken mit unterschiedlichen Serverarchitekturen und Betriebssystemen einsetzen und aktualisieren?

• Wie kann man verteilte Umgebungen zuverlässig und reproduzierbar mit weitgehend standardisierten Komponenten bereitstellen?

Jetzt kommt die dritte Revolution: der Container.

Die Ankunft der Container

Um eine Software zu installieren, brauchst du nicht nur die Software selbst, sondern auch ihre Abhängigkeiten. Das bedeutet Bibliotheken, Interpreter, Unterpakete, Compiler, Erweiterungen und so weiter.

Du brauchst auch die Konfiguration: Einstellungen, standortspezifische Details, Lizenzschlüssel, Datenbankpasswörter - alles, was die Rohsoftware in einen nutzbaren Dienst verwandelt.

Der Stand der Technik

Zu den früheren Versuchen, dieses Problem zu lösen, gehörte die Verwendung von Konfigurationsmanagementsystemen wie Puppet oder Ansible, die aus Code zur Installation, Ausführung, Konfiguration und Aktualisierung der Software bestehen.

Eine andere Lösung ist das Omnibus-Paket, das, wie der Name schon sagt, versucht, alles, was die Anwendung braucht, in eine einzige Datei zu packen. Ein Omnibus-Paket enthält die Software, ihre Konfiguration, ihre abhängigen Softwarekomponenten, ihre Konfiguration, ihre Abhängigkeiten und so weiter. (Ein Java-Omnibuspaket würde zum Beispiel die Java-Laufzeitumgebung sowie alle Java-Archivdateien [JAR] für die Anwendung enthalten).

Einige Anbieter sind sogar noch einen Schritt weiter gegangen und haben das gesamte Computersystem, das für den Betrieb benötigt wird, als virtuelles Maschinen-Image (VM-Image) integriert, aber diese sind groß und unhandlich, zeitaufwändig in der Erstellung und Wartung, anfällig im Betrieb, langsam im Herunterladen und in der Bereitstellung und äußerst ineffizient in Bezug auf Leistung und Ressourcenbedarf.

Aus betrieblicher Sicht musst du nicht nur diese verschiedenen Arten von Paketen verwalten, sondern auch eine Flotte von Servern, auf denen sie laufen.

Server müssen bereitgestellt, vernetzt, eingesetzt, konfiguriert, mit Sicherheitspatches auf dem neuesten Stand gehalten, überwacht und verwaltet werden und so weiter.

All das erfordert eine Menge Zeit, Können und Mühe, nur um eine Plattform für Software bereitzustellen. Gibt es da nicht einen besseren Weg?

Innerhalb der Box denken

Um diese Probleme zu lösen, hat sich die Tech-Industrie eine Idee aus der Schifffahrtsbranche abgeschaut: den Container. In den 1950er Jahren schlug ein Lkw-Fahrer namens Malcolm McLean vor, die Waren nicht mehr mühsam einzeln von den Lkw-Anhängern, die sie in die Häfen brachten, abzuladen und auf Schiffe zu verladen, sondern die Lkw selbst - oder besser gesagt, die Lkw-Aufbauten - auf das Schiff zu laden.

Ein Lkw-Anhänger ist im Wesentlichen eine große Metallbox auf Rädern. Wenn du die Kiste - den Container - von den Rädern und dem Fahrgestell trennen kannst, mit denen er transportiert wird, hast du etwas, das sehr leicht zu heben, zu beladen, zu stapeln und zu entladen ist und direkt auf ein Schiff oder einen anderen Lkw am anderen Ende der Reise verladen werden kann. Container haben außerdem Standardmaße, so dass die gesamte Schifffahrtsbranche, einschließlich Schiffe, Züge und LKW, weiß, was sie zu erwarten hat, wenn es darum geht, sie von einem Ort zum anderen zu transportieren(Abbildung 1-2).

McLeans Containerschifffahrtsunternehmen Sea-Land wurde sehr erfolgreich, indem es dieses System nutzte, um Waren viel billiger zu verschiffen, und Container setzten sich schnell durch. Heute werden jedes Jahr Hunderte Millionen von Containern verschifft und Waren im Wert von Billionen Dollar transportiert.

Abbildung 1-2. Standardisierte Container senken die Kosten für den Versand von Massengütern drastisch (Foto von Lucarelli, lizenziert unter Creative Commons)

Software in Containern unterbringen

Der Software-Container ist genau die gleiche Idee: ein standardisiertes Verpackungs- und Verteilungsformat, das generisch und weit verbreitet ist und eine deutlich höhere Tragfähigkeit, niedrigere Kosten, Skaleneffekte und eine einfachere Handhabung ermöglicht. Das Container-Format enthält alles, was die Anwendung zum Laufen braucht, in einer Image-Datei, die von einer Container-Laufzeitumgebung ausgeführt werden kann.

Was ist der Unterschied zu einem Image einer virtuellen Maschine? Auch dieses enthält alles, was die Anwendung braucht, um zu laufen - aber noch viel mehr. Ein typisches VM-Image ist etwa 1 GiB groß.¹ Ein gut durchdachtes Container-Image kann dagegen hundertmal kleiner sein.

Da die virtuelle Maschine viele nicht zusammenhängende Programme, Bibliotheken und Dinge enthält, die die Anwendung nie nutzen wird, wird der meiste Platz verschwendet. Die Übertragung von VM-Images über das Netzwerk ist viel langsamer als bei optimierten Containern.

Noch schlimmer ist, dass virtuelle Maschinen virtuell sind: Die zugrunde liegende physische CPU stellt eine emulierte CPU dar, auf der die virtuelle Maschine läuft. Die Virtualisierungsschicht hat einen dramatischen, negativen Effekt auf die Leistung: In Tests laufen virtualisierte Workloads etwa 30 % langsamer als die entsprechenden Container.

Im Vergleich dazu laufen Container direkt auf der realen CPU, ohne Virtualisierungs-Overhead, genau wie gewöhnliche Binärdateien.

Und weil Container nur die Dateien enthalten, die sie benötigen, sind sie viel kleiner als VM-Images. Außerdem verwenden sie eine clevere Technik mit adressierbaren Dateisystemschichten, die zwischen Containern geteilt und wiederverwendet werden können.

Wenn du zum Beispiel zwei Container hast, die beide vom gleichen Debian Linux Basisbild abgeleitet sind, muss das Basisbild nur einmal heruntergeladen werden und jeder Container kann es einfach referenzieren.

Die Container-Laufzeitumgebung stellt alle erforderlichen Schichten zusammen und lädt eine Schicht nur herunter, wenn sie nicht bereits lokal zwischengespeichert ist. Dadurch werden Speicherplatz und Netzwerkbandbreite sehr effizient genutzt.

Plug and Play Anwendungen

Der Container ist nicht nur die Einheit für die Bereitstellung und Verpackung, sondern auch die Einheit für die Wiederverwendung (ein und dasselbe Container-Image kann als Bestandteil vieler verschiedener Dienste verwendet werden), die Einheit für die Skalierung und die Einheit für die Ressourcenzuweisung (ein Container kann überall dort laufen, wo genügend Ressourcen für seine eigenen spezifischen Bedürfnisse zur Verfügung stehen).

Die Entwickler müssen sich nicht mehr darum kümmern, verschiedene Versionen der Software zu pflegen, damit sie auf verschiedenen Linux-Distributionen, mit unterschiedlichen Bibliotheks- und Sprachversionen usw. laufen. Das Einzige, wovon der Container abhängt, ist der Kernel des Betriebssystems (z. B. Linux).

Du musst deine Anwendung nur in einem Container-Image bereitstellen und schon läuft sie auf jeder Plattform, die das Standard-Container-Format unterstützt und einen kompatiblen Kernel hat.

Die Kubernetes-Entwickler Brendan Burns und David Oppenheimer haben es in ihrem Papier "Design Patterns for Container-Based Distributed Systems" so formuliert :

Da sie hermetisch verschlossen sind, ihre Abhängigkeiten mit sich führen und ein atomares Bereitstellungssignal ("erfolgreich"/"fehlgeschlagen") liefern, verbessern [Container] den bisherigen Stand der Technik bei der Bereitstellung von Software im Rechenzentrum oder in der Cloud dramatisch. Aber Container haben das Potenzial, viel mehr zu sein als nur ein besseres Bereitstellungsvehikel - wir glauben, dass sie dazu bestimmt sind, analog zu Objekten in objektorientierten Softwaresystemen zu werden und als solche die Entwicklung von Designmustern für verteilte Systeme ermöglichen werden.

Das Dirigieren des Container-Orchesters

Auch für die Betriebsteams wird ihre Arbeit durch Container erheblich vereinfacht. Anstatt eine Vielzahl von Rechnern unterschiedlicher Art, Architekturen und Betriebssysteme zu unterhalten, müssen sie nur noch einen Container-Orchestrator einsetzen: eine Software, die viele verschiedene Rechner zu einem Cluster zusammenfasst. Ein Container-Orchestrator ist eine Art einheitliches Compute-Substrat, das für den Nutzer wie ein einziger, sehr leistungsstarker Computer aussieht, auf dem Container laufen können.

Die Begriffe Orchestrierung und Zeitplanung werden oft synonym verwendet. Streng genommen bedeutet Orchestrierung in diesem Zusammenhang jedoch, dass verschiedene Aktivitäten koordiniert und in eine Reihenfolge gebracht werden, um ein gemeinsames Ziel zu erreichen (wie die Musiker in einem Orchester). Zeitplanung bedeutet, die verfügbaren Ressourcen zu verwalten und die Arbeitslasten dort zuzuweisen, wo sie am effizientesten ausgeführt werden können. (Nicht zu verwechseln mit Scheduling im Sinne von geplanten Aufträgen, die zu bestimmten Zeiten ausgeführt werden).

Eine dritte wichtige Aktivität ist das Clustermanagement: der Zusammenschluss mehrerer physischer oder virtueller Server zu einer einheitlichen, zuverlässigen, fehlertoleranten und scheinbar nahtlosen Gruppe.

Der Begriff Container-Orchestrator bezieht sich in der Regel auf einen einzelnen Dienst, der sich um die Planung, die Orchestrierung und das Cluster-Management kümmert.

Die Containerisierung (die Verwendung von Containern als Standardmethode für die Bereitstellung und den Betrieb von Software) bot offensichtliche Vorteile, und ein de facto standardisiertes Containerformat hat alle Arten von Skaleneffekten möglich gemacht. Doch ein Problem stand der breiten Einführung von Containern noch im Weg: das Fehlen eines standardisierten Container-Orchestrierungssystems.

Solange mehrere verschiedene Tools für die Planung und Orchestrierung von Containern auf dem Markt konkurrierten, zögerten die Unternehmen, teure Wetten darauf abzuschließen, welche Technologie sie einsetzen sollten. Doch das sollte sich nun ändern.

Kubernetes

Google hat schon lange vor allen anderen Unternehmen Container in großem Maßstab für Produktionsprozesse eingesetzt. Nahezu alle Google-Dienste laufen in Containern: Google Mail, Google-Suche, Google Maps, Google App Engine und so weiter. Da es damals noch kein geeignetes Container-Orchestrierungssystem gab, war Google gezwungen, eines zu entwickeln.

Von Borg zu Kubernetes

Um das Problem zu lösen, eine große Anzahl von Diensten in globalem Maßstab auf Millionen von Servern zu betreiben, entwickelte Google ein privates, internes Container-Orchestrierungssystem namens Borg.

Borg ist im Wesentlichen ein zentrales Managementsystem, das Container für die Ausführung auf einem Pool von Servern zuweist und einplant. Obwohl Borg sehr leistungsfähig ist, ist es eng an Googles interne und proprietäre Technologien gekoppelt, schwer zu erweitern und nicht für die Öffentlichkeit zugänglich.

2014 gründete Google ein Open-Source-Projekt namens Kubernetes (vom griechischen Wort κυβερνήτης, was so viel wie "Steuermann, Lotse" bedeutet), das einen Container-Orchestrator entwickeln sollte, den jeder nutzen kann und der auf den Erkenntnissen von Borg und seinem Nachfolger Omega basiert.

Der Aufstieg von Kubernetes war kometenhaft. Zwar gab es schon vor Kubernetes andere Container-Orchestrierungssysteme, aber keines davon hat eine so große Verbreitung gefunden wie Kubernetes. Mit dem Aufkommen eines wirklich kostenlosen und quelloffenen Container-Orchestrators wuchs die Akzeptanz von Containern und Kubernetes in rasantem Tempo.

Kubernetes erfreut sich immer größerer Beliebtheit und wird zur Norm für den Betrieb von containerisierten Anwendungen. Das geht aus einem Bericht von Datadog hervor:

Kubernetes hat sich zum De-facto-Standard für die Container-Orchestrierung entwickelt. Heute nutzt die Hälfte der Unternehmen, die Container einsetzen, Kubernetes, sei es in selbstverwalteten Clustern oder über einen Cloud-Provider-Service... Die Verbreitung von Kubernetes hat sich seit 2017 mehr als verdoppelt und wächst stetig weiter, ohne Anzeichen einer Verlangsamung.

So wie Container die Art und Weise standardisiert haben, wie Software verpackt und bereitgestellt wird, standardisiert Kubernetes die Plattform, auf der diese Container laufen.

Warum Kubernetes?

Kelsey Hightower, Mitarbeiterin bei Google, Co-Autorin von Kubernetes Up & Running (O'Reilly) und eine Legende in der Kubernetes-Community, hat es so formuliert:

Kubernetes tut das, was auch der beste Systemadministrator tun würde: Automatisierung, Ausfallsicherung, zentrale Protokollierung, Überwachung. Kubernetes nimmt das, was wir in der DevOps-Community gelernt haben, und macht es zum Standard, direkt nach dem Auspacken.

Kelsey Hightower

Viele der traditionellen Sysadmin-Aufgaben wie das Upgraden von Servern, das Installieren von Sicherheitspatches, das Konfigurieren von Netzwerken und das Ausführen von Backups sind in der Cloud-Native-Welt weniger wichtig. Kubernetes kann diese Dinge für dich automatisieren, sodass sich dein Team auf seine Kernaufgaben konzentrieren kann.

Einige dieser Funktionen, wie Lastverteilung und Autoskalierung, sind in den Kubernetes-Kern integriert, andere werden von Add-ons, Erweiterungen und Drittanbieter-Tools bereitgestellt, die die Kubernetes-API nutzen. Das Kubernetes-Ökosystem ist groß und wächst ständig weiter.

Kubernetes macht die Bereitstellung einfach

Betriebsmitarbeiter lieben Kubernetes aus diesen Gründen, aber auch für Entwickler gibt es einige wichtige Vorteile. Kubernetes reduziert den Zeit- und Arbeitsaufwand für die Bereitstellung erheblich. Zero-Downtime-Deployments sind üblich, da Kubernetes standardmäßig rollierende Updates durchführt (Container mit der neuen Version starten, warten, bis sie in Ordnung sind, und dann die alten Container abschalten).

Kubernetes bietet auch Funktionen, die dir helfen, kontinuierliche Bereitstellungspraktiken zu implementieren, wie z. B. Canary Deployments: schrittweises Ausrollen von Updates auf einen Server, um Probleme frühzeitig zu erkennen (siehe "Canary Deployments"). Eine weitere gängige Praxis sind Blue-Green Deployments: Dabei wird eine neue Version des Systems parallel hochgefahren und der Datenverkehr auf sie umgestellt, sobald sie voll funktionsfähig ist (siehe "Blue/Green Deployments").

Nachfragespitzen werden deinen Dienst nicht mehr zum Erliegen bringen, denn Kubernetes unterstützt die automatische Skalierung. Wenn zum Beispiel die CPU-Auslastung eines Containers einen bestimmten Wert erreicht, kann Kubernetes so lange neue Replikate des Containers hinzufügen, bis die Auslastung unter den Schwellenwert fällt. Wenn die Nachfrage sinkt, skaliert Kubernetes die Replikate wieder herunter und setzt so Cluster-Kapazität für andere Arbeitslasten frei.

Da Kubernetes über Redundanz und Failover verfügt, ist deine Anwendung zuverlässiger und widerstandsfähiger. Einige Managed Services können sogar den Kubernetes-Cluster selbst bedarfsgerecht skalieren, sodass du nie für einen größeren Cluster bezahlst, als du gerade brauchst (siehe "Autoskalierung"). Das bedeutet zwar, dass deine Anwendungen so konzipiert sein müssen, dass sie in einer dynamischen Umgebung laufen, aber Kubernetes bietet dir Standardmöglichkeiten, um diese Art von Infrastruktur zu nutzen.

Auch die Unternehmen werden Kubernetes lieben, denn es senkt die Infrastrukturkosten und nutzt die vorhandenen Ressourcen viel besser. Herkömmliche Server, selbst Cloud-Server, sind die meiste Zeit ungenutzt. Die überschüssige Kapazität, die du brauchst, um Nachfragespitzen zu bewältigen, wird unter normalen Bedingungen praktisch vergeudet.

Kubernetes nutzt diese ungenutzte Kapazität für die Ausführung von Workloads. So kannst du eine viel höhere Auslastung deiner Maschinen erreichen - und du bekommst Skalierung, Lastausgleich und Failover gratis dazu.

Einige dieser Funktionen, wie z. B. die automatische Skalierung, gab es zwar schon vor Kubernetes, aber sie waren immer an einen bestimmten Cloud-Provider oder Service gebunden. Kubernetes ist anbieterunabhängig: Sobald du die verwendeten Ressourcen definiert hast, kannst du sie auf jedem Kubernetes-Cluster betreiben, unabhängig vom zugrunde liegenden Cloud-Provider.

Das bedeutet nicht, dass Kubernetes dich auf den kleinsten gemeinsamen Nenner beschränkt. Kubernetes ordnet deine Ressourcen den entsprechenden anbieterspezifischen Funktionen zu: Ein Kubernetes-Dienst mit Lastverteilung in der Google Cloud erzeugt beispielsweise einen Google Cloud Load Balancer, während er bei Amazon einen Amazon Web Services (AWS) Load Balancer erzeugt. Kubernetes abstrahiert die Cloud-spezifischen Details, damit du dich auf die Definition des Verhaltens deiner Anwendung konzentrieren kannst.

Genauso wie Container eine portable Art sind, Software zu definieren, bieten Kubernetes-Ressourcen eine portable Definition, wie diese Software laufen soll.

Wird Kubernetes verschwinden?

Seltsamerweise werden wir trotz der aktuellen Aufregung um Kubernetes in den nächsten Jahren vielleicht nicht mehr viel darüber reden. Viele Dinge, die einst neu und revolutionär waren, sind heute so sehr Teil der Computerwelt, dass wir gar nicht mehr darüber nachdenken: Mikroprozessoren, die Maus, das Internet.

Auch Kubernetes wird wahrscheinlich in den Hintergrund rücken und Teil der Sanitärinstallation werden. Es ist langweilig, auf eine gute Art! Wenn du einmal gelernt hast, was du wissen musst, um deine Anwendung in Kubernetes einzusetzen, kannst du dich darauf konzentrieren, deiner Anwendung neue Funktionen hinzuzufügen.

Managed-Service-Angebote für Kubernetes werden wahrscheinlich mehr und mehr die schwere Arbeit übernehmen, die hinter dem Betrieb von Kubernetes selbst steckt. Im Jahr 2021 veröffentlichte Google Cloud Platform (GCP) ein neues Angebot für seinen bestehenden Kubernetes-Dienst namens Autopilot, das Cluster-Upgrades, Vernetzung und die Skalierung der VMs je nach Bedarf übernimmt. Auch andere Cloud-Provider gehen in diese Richtung und bieten Kubernetes-basierte Plattformen an, auf denen sich Entwickler/innen nur um den Betrieb ihrer Anwendung kümmern müssen und nicht um die zugrunde liegende Infrastruktur.

Kubernetes ist kein Allheilmittel

Wird die gesamte Software-Infrastruktur der Zukunft vollständig auf Kubernetes basieren? Wahrscheinlich nicht. Ist es unglaublich einfach und unkompliziert, alle Arten von Workloads auszuführen? Nicht ganz.

Der Betrieb von Datenbanken auf verteilten Systemen erfordert zum Beispiel sorgfältige Überlegungen, was bei Neustarts passiert und wie sichergestellt werden kann, dass die Daten konsistent bleiben.

Bei der Orchestrierung von Software in Containern geht es darum, neue austauschbare Instanzen zu erstellen, ohne dass sie untereinander koordiniert werden müssen. Datenbankreplikate sind jedoch nicht austauschbar; sie haben jeweils einen eigenen Status, und die Bereitstellung eines Datenbankreplikats erfordert eine Koordination mit anderen Knoten, um sicherzustellen, dass Dinge wie Schemaänderungen überall zur gleichen Zeit stattfinden.

Sean Loiselle, Cockroach Labs

Es ist zwar durchaus möglich, zustandsabhängige Workloads wie Datenbanken in Kubernetes mit unternehmensgerechter Zuverlässigkeit zu betreiben, aber das erfordert eine große Investition an Zeit und Technik, die sich für dein Unternehmen vielleicht nicht lohnt (siehe "Weniger Software betreiben"). In der Regel ist es kostengünstiger, stattdessen einen verwalteten Datenbankdienst zu nutzen.

Zweitens brauchen manche Dinge vielleicht gar nicht Kubernetes, sondern können auf sogenannten serverlosen Plattformen laufen, besser bekannt als Functions as a Service (FaaS).

Cloud-Funktionen

AWS Lambda ist zum Beispiel eine FaaS-Plattform, mit der du in Go, Python, Java, Node.js, C# und anderen Sprachen geschriebenen Code ausführen kannst, ohne dass du deine Anwendung überhaupt kompilieren oder bereitstellen musst. Amazon macht das alles für dich. Google Cloud hat mit Cloud Run und Functions ähnliche Angebote, und auch Microsoft bietet Azure Functions an.

Da die Ausführungszeit in Millisekundenschritten abgerechnet wird, eignet sich das FaaS-Modell perfekt für Berechnungen, die nur dann ausgeführt werden, wenn du sie brauchst, anstatt für einen Cloud-Server zu bezahlen, der die ganze Zeit läuft, egal ob du ihn nutzt oder nicht.

Diese Cloud-Funktionen sind in mancher Hinsicht bequemer als Container (obwohl einige FaaS-Plattformen auch Container ausführen können). Sie eignen sich jedoch am besten für kurze, eigenständige Aufträge (AWS Lambda begrenzt die Laufzeit der Funktionen beispielsweise auf 15 Minuten), insbesondere für solche, die mit bestehenden Cloud Computing Services wie Azure Cognitive Services oder der Google Cloud Vision API integriert werden.

Diese Arten von ereignisgesteuerten Plattformen werden oft als "serverlose" Modelle bezeichnet. Technisch gesehen ist immer noch ein Server im Spiel: Es ist nur der Server eines anderen Anbieters. Der Punkt ist, dass du diesen Server nicht bereitstellen und warten musst; der Cloud-Provider übernimmt das für dich.

Bei weitem nicht jeder Workload ist für den Betrieb auf FaaS-Plattformen geeignet, aber es ist wahrscheinlich, dass es in Zukunft eine Schlüsseltechnologie für Cloud Native Applications sein wird.

Auch sind Cloud-Funktionen nicht auf öffentliche FaaS-Plattformen wie Lambda Functions oder Azure Functions beschränkt: Wenn du bereits einen Kubernetes-Cluster hast und FaaS-Anwendungen darauf laufen lassen willst, machen Open-Source-Projekte wie OpenFaaS und Knative dies möglich.

Einige dieser serverlosen Kubernetes-Plattformen umfassen sowohl langlaufende Container als auch ereignisgesteuerte kurzlebige Funktionen, was bedeuten kann, dass in Zukunft die Unterscheidung zwischen diesen beiden Arten von Compute verwischt oder ganz verschwindet.

Cloud Native

Der Begriff "Cloud Native" ist zu einer immer beliebteren Kurzform für moderne Anwendungen und Dienste geworden, die die Vorteile der Cloud, von Containern und Orchestrierung nutzen und oft auf Open-Source-Software basieren.

Die Cloud Native Computing Foundation (CNCF) wurde 2015 gegründet, um, wie sie es ausdrückt, "eine Community rund um eine Konstellation von qualitativ hochwertigen Projekten zu fördern, die Container als Teil einer Microservices-Architektur orchestrieren".

Die CNCF ist Teil der Linux Foundation und bringt Entwickler, Endnutzer und Anbieter zusammen, darunter auch die großen Public Cloud-Provider. Das bekannteste Projekt unter dem Dach der CNCF ist Kubernetes selbst, aber die Stiftung fördert auch andere wichtige Komponenten des Cloud-Native-Ökosystems: Prometheus, Envoy, Helm, Fluentd, gRPC und viele mehr.

Was genau verstehen wir also unter Cloud Native? Wie bei den meisten Dingen bedeutet es für jeden etwas anderes, aber vielleicht gibt es eine gemeinsame Basis.

Erstens ist mit Cloud nicht unbedingt ein öffentlicher Cloud-Provider wie AWS oder Azure gemeint. Viele Unternehmen betreiben ihre eigenen internen "Cloud"-Plattformen und nutzen oft gleichzeitig einen oder mehrere öffentliche Cloud-Provider für verschiedene Arbeitslasten. Der Begriff "Cloud" bezeichnet im weitesten Sinne die Serverplattform, auf der die Software-Infrastruktur läuft, und die kann viele Formen annehmen.

Was macht eine Anwendung also Cloud-nativ? Eine bestehende Anwendung auf einer Cloud-Computing-Instanz laufen zu lassen, macht sie noch nicht Cloud-nativ. Es geht auch nicht nur darum, die Anwendung in einem Container laufen zu lassen oder Cloud-Dienste wie Azure's Cosmos DB oder Google's Pub/Sub zu nutzen, obwohl dies durchaus wichtige Aspekte einer Cloud-nativen Anwendung sein können .

Schauen wir uns also ein paar der Merkmale von Cloud Native Systemen an, auf die sich die meisten Menschen einigen können:

Automatisierbar

Wenn Anwendungen nicht mehr von Menschen, sondern von Maschinen bereitgestellt und verwaltet werden sollen, müssen sie gemeinsame Standards, Formate und Schnittstellen einhalten. Kubernetes bietet diese Standardschnittstellen auf eine Art und Weise, dass sich die Anwendungsentwickler/innen nicht einmal darum kümmern müssen.

Allgegenwärtig und flexibel

Da sie von physischen Ressourcen wie Festplatten oder spezifischen Kenntnissen über den Rechenknoten, auf dem sie laufen, entkoppelt sind, können containerisierte Microservices leicht von einem Knoten zum anderen oder sogar von einem Cluster zum anderen verschoben werden.

Widerstandsfähig und skalierbar

Herkömmliche Anwendungen neigen dazu, nur an einer Stelle auszufallen: Die Anwendung funktioniert nicht mehr, wenn ihr Hauptprozess abstürzt, wenn der zugrunde liegende Rechner einen Hardwarefehler hat oder wenn eine Netzwerkressource überlastet wird. Da Cloud-native Anwendungen von Natur aus verteilt sind, können sie durch Redundanz und Graceful Degradation hochverfügbar gemacht werden.

Dynamisch

Ein Container-Orchestrator wie Kubernetes kann Container so planen, dass die verfügbaren Ressourcen optimal genutzt werden. Er kann viele Kopien von Containern laufen lassen, um eine hohe Verfügbarkeit zu erreichen, und rollende Updates durchführen, um Dienste reibungslos zu aktualisieren, ohne dass der Datenverkehr unterbrochen wird.

Erkennbar

Cloud-native Anwendungen sind von Natur aus schwieriger zu überprüfen und zu debuggen. Eine wichtige Anforderung an verteilte Systeme ist daher die Beobachtbarkeit: Monitoring, Logging, Tracing und Metriken helfen Ingenieuren zu verstehen, was ihre Systeme tun (und was sie falsch machen).

Verteilt

Cloud Native ist ein Ansatz für die Entwicklung und den Betrieb von Anwendungen, der die Vorteile der verteilten und dezentralen Natur der Cloud nutzt. Es geht darum, wie deine Anwendung funktioniert, nicht wo sie läuft. Anstatt deinen Code als eine einzige Einheit (bekannt als Monolith) zu implementieren, bestehen Cloud Native-Anwendungen in der Regel aus mehreren kooperierenden, verteilten Microservices. Ein Microservice ist einfach ein in sich geschlossener Dienst, der eine bestimmte Aufgabe erfüllt. Wenn du genügend Microservices zusammenfügst, erhältst du eine Anwendung.

Es geht nicht nur um Microservices

Aber auch Microservices sind kein Allheilmittel. Monolithen sind leichter zu verstehen, weil sich alles an einem Ort befindet und du die Interaktionen der verschiedenen Teile nachvollziehen kannst. Aber es ist schwer, einen Monolithen zu skalieren, sowohl was den Code selbst als auch die Entwicklerteams angeht, die ihn pflegen. Wenn der Code wächst, nehmen die Wechselwirkungen zwischen den verschiedenen Teilen exponentiell zu und das System als Ganzes wächst über die Fähigkeit eines einzelnen Gehirns hinaus, alles zu verstehen.

Eine gut konzipierte Cloud Native-Anwendung besteht aus Microservices, aber die Entscheidung, was diese Microservices sein sollen, wo die Grenzen liegen und wie die verschiedenen Services zusammenwirken sollen, ist kein einfaches Problem. Ein gutes Cloud Native Service Design besteht darin, kluge Entscheidungen darüber zu treffen, wie du die verschiedenen Teile deiner Architektur trennst. Aber auch eine gut konzipierte Cloud Native Anwendung ist immer noch ein verteiltes System, das von Natur aus komplex, schwer zu beobachten und zu verstehen ist und auf überraschende Weise ausfallen kann.

Auch wenn Cloud-native Systeme in der Regel verteilt sind, ist es immer noch möglich, monolithische Anwendungen mit Containern in der Cloud zu betreiben und daraus einen erheblichen geschäftlichen Nutzen zu ziehen. Dies kann ein Schritt auf dem Weg zur schrittweisen Migration von Teilen des Monolithen zu modernen Microservices sein oder eine Überbrückungsmaßnahme, bis das System vollständig cloud-nativ umgestaltet ist.

Die Zukunft der Operationen

Betrieb, Infrastruktur-Engineering und Systemadministration sind hochqualifizierte Berufe. Sind sie in einer cloudbasierten Zukunft gefährdet? Wir denken nicht.

Stattdessen werden diese Fähigkeiten nur noch wichtiger werden. Verteilte Systeme zu entwerfen und über sie nachzudenken ist schwierig. Netzwerke und Container-Orchestratoren sind kompliziert. Jedes Team, das Cloud-native Anwendungen entwickelt, braucht operative Fähigkeiten und Kenntnisse. Die Automatisierung entlastet die Mitarbeiter/innen von langweiligen, sich wiederholenden, manuellen Arbeiten, damit sie sich mit komplexeren, interessanteren und lustigeren Problemen beschäftigen können, die Computer noch nicht selbst lösen können.

Das heißt aber nicht, dass alle laufenden Aufträge garantiert sind. Früher konnten Sysadmins ohne Programmierkenntnisse auskommen, außer vielleicht das eine oder andere einfache Shell-Skript zu erstellen. In der Cloud Native Welt wird das nicht mehr ausreichen, um erfolgreich zu sein.

In einer softwaredefinierten Welt wird die Fähigkeit, Software zu schreiben, zu verstehen und zu warten, entscheidend. Wenn du nicht bereit bist, neue Fähigkeiten zu erlernen, wird die Branche dich im Stich lassen - und das war schon immer so.

Verteilte DevOps

Anstatt in einem einzigen Betriebsteam konzentriert zu sein, das andere Teams betreut, wird das Fachwissen im Betrieb auf viele Teams verteilt.

Jedes Entwicklungsteam braucht mindestens einen Ops-Spezialisten, der für den Zustand der Systeme oder Dienste verantwortlich ist, die das Team bereitstellt. Er wird auch ein Entwickler sein, aber er ist auch der Experte für Netzwerke, Kubernetes, Leistung, Ausfallsicherheit und die Tools und Systeme, die es den anderen Entwicklern ermöglichen, ihren Code in der Cloud bereitzustellen.

Dank der DevOps-Revolution gibt es in den meisten Unternehmen keinen Platz mehr für Entwickler, die keine Ops sind, oder für Ops, die keine Entwickler sind. Die Unterscheidung zwischen diesen beiden Disziplinen ist obsolet und wird bald ganz aufgehoben. Das Entwickeln und Betreiben von Software sind lediglich zwei Aspekte derselben Sache.

Einige Dinge werden zentralisiert bleiben

Gibt es Grenzen für DevOps? Oder wird das traditionelle zentrale IT- und Betriebsteam ganz verschwinden und sich in eine Gruppe umherziehender interner Berater auflösen, die coachen, lehren und Probleme im Betrieb beheben?

Wir denken nicht, oder zumindest nicht ganz. Manche Dinge sind immer noch von Vorteil, wenn sie zentralisiert werden. Es ist zum Beispiel nicht sinnvoll, dass jedes Anwendungs- oder Serviceteam seine eigene Methode hat, um Störungen in der Produktion zu erkennen und darüber zu kommunizieren, oder dass es sein eigenes Ticketingsystem oder seine eigenen Verteilungswerkzeuge hat. Es macht keinen Sinn, dass jeder sein eigenes Rad neu erfindet.

Entwicklerproduktivität Technik

Der Punkt ist, dass Self-Service seine Grenzen hat und das Ziel von DevOps ist es, die Entwicklungsteams zu beschleunigen und sie nicht mit unnötiger und überflüssiger Arbeit zu verlangsamen.

Ja, ein großer Teil des traditionellen Betriebs kann und sollte an andere Teams übertragen werden, vor allem an die Teams, die Code bereitstellen und auf codebezogene Vorfälle reagieren. Um dies zu ermöglichen, muss es jedoch ein starkes zentrales Team geben, das das DevOps-Ökosystem aufbaut und unterstützt, in dem alle anderen Teams arbeiten.

Anstatt dieses Team Operations zu nennen, gefällt uns der Name Developer Productivity Engineering. Manche Unternehmen nennen diese Rolle Platform Engineer oder vielleicht sogar DevOps Engineer. Der Punkt ist, dass diese Teams alles tun, was nötig ist, um anderen Softwareentwicklungsteams dabei zu helfen, ihre Arbeit besser und schneller zu erledigen: Infrastruktur betreiben, Tools entwickeln, Probleme beseitigen.

Und während die Entwicklung der Entwicklerproduktivität eine Spezialität bleibt, können die Ingenieure selbst in die Organisation hinausgehen, um ihr Fachwissen dorthin zu bringen, wo es gebraucht wird.

Der Lyft-Ingenieur Matt Klein hat darauf hingewiesen, dass ein reines DevOps-Modell zwar für Start-ups und kleine Unternehmen sinnvoll ist, aber wenn ein Unternehmen wächst, gibt es eine natürliche Tendenz, dass sich Infrastruktur- und Zuverlässigkeitsexperten auf ein zentrales Team konzentrieren. Aber er sagt, dass dieses Team nicht unbegrenzt skaliert werden kann:

Wenn eine Entwicklungsorganisation eine Größe von etwa 75 Mitarbeitern erreicht hat, gibt es mit ziemlicher Sicherheit ein zentrales Infrastrukturteam, das damit beginnt, gemeinsame Substratfunktionen zu entwickeln, die von den Produktteams für Microservices benötigt werden. Doch irgendwann kommt der Punkt, an dem das zentrale Infrastrukturteam nicht mehr in der Lage ist, die für den Geschäftserfolg wichtige Infrastruktur aufzubauen und zu betreiben und gleichzeitig die Produktteams bei ihren operativen Aufgaben zu unterstützen.

Matt Klein

An diesem Punkt kann nicht jeder Entwickler ein Infrastrukturexperte sein, genauso wenig wie ein einziges Team von Infrastrukturexperten eine ständig wachsende Zahl von Entwicklern betreuen kann. In größeren Unternehmen wird zwar immer noch ein zentrales Infrastrukturteam benötigt, aber es gibt auch Gründe dafür, Site Reliability Engineers (SREs) in jedes Entwicklungs- oder Produktteam einzubinden. Sie bringen ihr Fachwissen als Berater in jedes Team ein und bilden außerdem eine Brücke zwischen Produktentwicklung und Infrastrukturbetrieb.

Du bist die Zukunft

Wenn du dieses Buch liest, bist du ein Teil dieser neuen cloudbasierten Zukunft. In den verbleibenden Kapiteln behandeln wir alle Kenntnisse und Fähigkeiten, die du als Entwickler oder Betriebsingenieur brauchst, der mit Cloud-Infrastruktur, Containern und Kubernetes arbeitet.

Einige dieser Dinge werden dir bekannt vorkommen, andere sind neu, aber wir hoffen, dass du am Ende des Buches mehr Vertrauen in deine eigene Fähigkeit hast, Cloud Native-Fähigkeiten zu erwerben und zu beherrschen. Ja, es gibt viel zu lernen, aber es ist nichts, was du nicht bewältigen kannst. Du schaffst das!

Lies jetzt weiter.

Zusammenfassung

Wir haben dir notwendigerweise einen kurzen Überblick über die Landschaft gegeben, einschließlich der Geschichte von DevOps, Cloud Computing und dem aufkommenden Standard der Verwendung von Containern und Kubernetes für den Betrieb von Cloud Native Applications. Wir hoffen, dass wir dich damit auf den neuesten Stand gebracht haben, was die Herausforderungen in diesem Bereich angeht und wie sie die IT-Branche verändern werden.

Eine kurze Zusammenfassung der wichtigsten Punkte, bevor wir im nächsten Kapitel Kubernetes persönlich kennenlernen:

• Cloud Computing befreit dich von den Kosten und dem Aufwand für die Verwaltung deiner eigenen Hardware und ermöglicht es dir, robuste, flexible und skalierbare verteilte Systeme aufzubauen.

• DevOps ist die Erkenntnis, dass moderne Softwareentwicklung nicht bei der Auslieferung von Code aufhört: Es geht darum, die Feedbackschleife zwischen denen, die den Code schreiben, und denen, die ihn nutzen, zu schließen.

• DevOps bringt einen codezentrierten Ansatz und gute Praktiken der Softwareentwicklung auch in die Welt der Infrastruktur und des Betriebs.

• Mit Containern kannst du Software in kleinen, standardisierten, in sich abgeschlossenen Einheiten einsetzen und ausführen. Das macht es einfacher und billiger, große, vielfältige, verteilte Systeme zu bauen, indem man containerisierte Microservices miteinander verbindet.

• Orchestrierungssysteme kümmern sich um die Bereitstellung deiner Container, das Zeitplannungsprogramm, die Skalierung, die Vernetzung und all die Dinge, die ein guter Systemadministrator tun würde, aber auf eine automatisierte, programmierbare Weise.

• Kubernetes ist der De-facto-Standard für die Container-Orchestrierung, und du kannst es schon heute in der Produktion einsetzen. Das Projekt entwickelt sich schnell weiter, und alle großen Cloud-Provider bieten immer mehr Managed Services an, um die zugrunde liegenden Kubernetes-Kernkomponenten automatisch zu verwalten.

• Das "serverlose" ereignisgesteuerte Computing wird auch für Cloud-native Anwendungen immer beliebter, wobei häufig Container als Laufzeitumgebung verwendet werden. Es gibt Tools, um diese Art von Funktionen auf Kubernetes-Clustern auszuführen.

• Cloud Native ist eine nützliche Abkürzung, um über cloudbasierte, containerisierte, verteilte Systeme zu sprechen, die aus kooperierenden Microservices bestehen, die dynamisch durch automatisierte Infrastruktur als Code verwaltet werden.

• Betriebs- und Infrastrukturkenntnisse werden durch die Cloud-Revolution keineswegs überflüssig, sondern sind wichtiger denn je.

• Was verschwinden wird, ist die scharfe Unterscheidung zwischen Softwareentwicklern und Betriebsingenieuren. Es geht nur noch um Software, und wir sind alle Ingenieure.

¹ Das Gibibyte (GiB) ist die Dateneinheit der Internationalen Elektrotechnischen Kommission (IEC) und entspricht 1.024 Mebibyte (MiB), das Kibibyte (KiB) entspricht 1.024 Byte. Wir verwenden in diesem Buch die IEC-Einheiten (GiB, MiB, KiB), um Unklarheiten zu vermeiden.