Handbuch Infrastructure as Code E-Book

Kief Morris

• Herausgeber: O'Reilly
• Kategorie: Wissenschaft und neue Technologien
• Serie: Animals
• Sprache: Deutsch

Seitenzahl: 583

Veröffentlichungsjahr: 2021

Beschreibung

Cloud-Infrastrukturen erfolgreich automatisieren: Strategien für die Praxis

• Mithilfe von Patterns und Antipatterns Automatisierung verstehen und erfolgreich umsetzen
• Pseudocode-Beispiele veranschaulichen die konkrete Umsetzung
• Diese Auflage beschreibt neben dem Managen von Servern jetzt auch komplexe Container-Plattformen

Kief Morris von ThoughtWorks zeigt in diesem Praxisbuch, wie Sie die von DevOps-Teams entwickelte Prinzipien, Praktiken und Patterns effektiv verwenden, um in der Cloud sicher und flexibel Infrastruktur zu managen. Es vermittelt, wie nicht nur Server, sondern auch komplexe Container-Plattformen (Stacks) aufgesetzt werden. Sie erfahren, wie sie mithilfe von Cloud- und Automatisierungstechnologien Änderungen einfach, sicher und schnell vornehmen. Sie lernen, wie Sie nahezu alles als Code definieren und setzen Praktiken aus dem Softwaredesign ein, um ein System aus kleinen, lose gekoppelten Elementen aufzubauen.

Zielgruppen sind Mitarbeiterinnen und Mitarbeiter in der Systemadministration, Infrastruktur-Entwicklung, Softwareentwicklung und Architektur.

Leseprobe

Zu diesem Buch – sowie zu vielen weiteren O’Reilly-Büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei oreilly.plus+:

www.oreilly.plus

Handbuch Infrastructure as Code

Prinzipien, Praktiken und Patternsfür eine cloudbasierte IT-Infrastruktur

Kief Morris

Deutsche Übersetzung vonThomas Demmig

Kief Morris

Lektorat: Ariane Hesse

Übersetzung: Thomas Demmig

Fachliche Unterstützung: Pascal Euhus

Korrektorat: Claudia Lötschert, www.richtiger-text.de

Satz: mediaService, Gerhard Alfes, Siegen, www.mediaservice.tv

Herstellung: Stefanie Weidner

Umschlaggestaltung: Michael Oréal, www.oreal.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print   978-3-96009-170-7

PDF    978-3-96010-624-1

ePub   978-3-96010-625-8

mobi   978-3-96010-626-5

1. Auflage 2022

Translation Copyright für die deutschsprachige Ausgabe © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Authorized German translation of the English edition Infrastructure as Code: Dynamic Systems for the Cloud Age, 2nd Edition, ISBN 9781098114671 © 2021 Kief Morris.

This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Dieses Buch erscheint in Kooperation mit O’Reilly Media, Inc. unter dem Imprint »O’REILLY«.

O’REILLY ist ein Markenzeichen und eine eingetragene Marke von O’Reilly Media, Inc. und wird mit Einwilligung des Eigentümers verwendet.

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag noch Übersetzer können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhalt

Vorwort

Warum ich dieses Buch geschrieben habe

Was in dieser Auflage neu und anders ist

Was kommt als Nächstes?

Was dieses Buch ist und was es nicht ist

Etwas Geschichte zu Infrastructure as Code

Für wen dieses Buch gedacht ist

Prinzipien, Praktiken und Patterns

Die ShopSpinner-Beispiele

In diesem Buch verwendete Konventionen

Danksagung

Teil IGrundlagen

1Was ist Infrastructure as Code?

Aus der Eisenzeit in das Cloud-Zeitalter

Infrastructure as Code

Vorteile von Infrastructure as Code

Infrastructure as Code nutzen, um für Änderungen zu optimieren

Einwand »Wir haben gar nicht so häufig Änderungen, sodass sich Automation nicht lohnt«

Einwand »Wir sollten erst bauen und danach automatisieren«

Einwand »Wir müssen zwischen Geschwindigkeit und Qualität entscheiden«

Die Four Key Metrics

Drei zentrale Praktiken für Infrastructure as Code

Zentrale Praktik: Definieren Sie alles als Code

Zentrale Praktik: Kontinuierliches Testen und die gesamte aktuelle Arbeit ausliefern

Zentrale Praktik: Kleine einfache Elemente bauen, die Sie unabhängig voneinander ändern können

Zusammenfassung

2Prinzipien der Infrastruktur im Cloud-Zeitalter

Prinzip: Gehen Sie davon aus, dass Systeme unzuverlässig sind

Prinzip: Alles reproduzierbar machen

Fallstrick: Snowflake-Systeme

Prinzip: Erstellen Sie wegwerfbare Elemente

Prinzip: Variationen minimieren

Konfigurationsdrift

Prinzip: Stellen Sie sicher, dass Sie jeden Prozess wiederholen können

Zusammenfassung

3Infrastruktur-Plattformen

Die Elemente eines Infrastruktur-Systems

Dynamische Infrastruktur-Plattform

Infrastruktur-Ressourcen

Computing-Ressourcen

Storage-Ressourcen

Networking-Ressourcen

Zusammenfassung

4Zentrale Praktik: Definieren Sie alles als Code

Warum Sie Ihre Infrastruktur als Code definieren sollten

Was Sie als Code definieren können

Wählen Sie Werkzeuge mit externalisierter Konfiguration aus

Managen Sie Ihren Code in einer Versionsverwaltung

Programmiersprachen für Infrastruktur

Infrastruktur-Scripting

Deklarative Infrastruktur-Sprachen

Programmierbare, imperative Infrastruktur-Sprachen

Deklarative und imperative Sprachen für Infrastruktur

Domänenspezifische Infrastruktur-Sprachen

Allgemein nutzbare Sprachen und DSLs für die Infrastruktur

Implementierungs-Prinzipien beim Definieren von Infrastructure as Code

Halten Sie deklarativen und imperativen Code voneinander getrennt

Behandeln Sie Infrastruktur-Code wie echten Code

Zusammenfassung

Teil IIArbeiten mit Infrastruktur-Stacks

5Infrastruktur-Stacks als Code bauen

Was ist ein Infrastruktur-Stack?

Stack-Code

Stack-Instanzen

Server in einem Stack konfigurieren

Low-Level-Infrastruktur-Sprachen

High-Level-Infrastruktur-Sprachen

Patterns und Antipatterns für das Strukturieren von Stacks

Antipattern: Monolithic Stack

Pattern: Application Group Stack

Pattern: Service Stack

Pattern: Micro Stack

Zusammenfassung

6Umgebungen mit Stacks bauen

Worum es bei Umgebungen geht

Auslieferungsumgebungen

Mehrere Produktivumgebungen

Umgebungen, Konsistenz und Konfiguration

Patterns zum Bauen von Umgebungen

Antipattern: Multiple-Enviroment Stack

Antipattern: Copy-Paste Environments

Pattern: Reusable Stack

Umgebungen mit mehreren Stacks erstellen

Zusammenfassung

7Stack-Instanzen konfigurieren

Eindeutige Kennungen durch Stack-Parameter erstellen

Beispiel-Stack-Parameter

Patterns zum Konfigurieren von Stacks

Antipattern: Manual Stack Parameters

Pattern: Stack Environment Variables

Pattern: Scripted Parameters

Pattern: Stack Configuration Files

Pattern: Wrapper-Stack

Pattern: Pipeline Stack Parameters

Pattern: Stack Parameter Registry

Konfigurations-Registry

Eine Konfigurations-Registry implementieren

Eine oder mehrere Konfigurations-Registries

Secrets als Parameter nutzen

Secrets verschlüsseln

Secretlose Autorisierung

Secrets zur Laufzeit injizieren

Wegwerf-Secrets

Zusammenfassung

8Zentrale Praktik: Kontinuierlich testen und ausliefern

Warum Infrastruktur-Code kontinuierlich testen?

Was kontinuierliches Testen bedeutet

Was sollten wir bei der Infrastruktur testen?

Herausforderungen beim Testen von Infrastruktur-Code

Herausforderung: Tests für deklarativen Code haben häufig nur einen geringen Wert

Herausforderung: Das Testen von Infrastruktur-Code ist langsam

Herausforderung: Abhängigkeiten verkomplizieren die Test-Infrastruktur

Progressives Testen

Testpyramide

Schweizer-Käse-Testmodell

Infrastruktur-Delivery-Pipelines

Pipeline-Stages

Scope von Komponenten, die in einer Stage getestet werden

Scope von Abhängigkeiten für eine Stage

Plattformelemente, die für eine Stage erforderlich sind

Software und Services für die Delivery-Pipeline

Testen in der Produktivumgebung

Was Sie außerhalb der Produktivumgebung nicht nachbauen können

Die Risiken beim Testen in der Produktivumgebung managen

Zusammenfassung

9Infrastruktur-Stacks testen

Beispiel-Infrastruktur

Der Beispiel-Stack

Pipeline für den Beispiel-Stack

Offline-Test-Stages für Stacks

Syntax-Checks

Statische Offline-Code-Analyse

Statische Code-Analyse per API

Testen mit einer Mock-API

Online-Test-Stages für Stacks

Preview: Prüfen, welche Änderungen vorgenommen werden

Verifikation: Aussagen über Infrastruktur-Ressourcen treffen

Ergebnisse: Prüfen, dass die Infrastruktur korrekt arbeitet

Test-Fixtures für den Umgang mit Abhängigkeiten verwenden

Test-Doubles für Upstream-Abhängigkeiten

Test-Fixtures für Downstream-Abhängigkeiten

Komponenten refaktorieren, um sie isolieren zu können

Lebenszyklus-Patterns für Testinstanzen von Stacks

Pattern: Persistent Test Stack

Pattern: Ephemeral Test Stack

Antipattern: Dual Persistent and Ephemeral Stack Stages

Pattern: Periodic Stack Rebuild

Pattern: Continuous Stack Reset

Test-Orchestrierung

Unterstützen Sie lokales Testen

Vermeiden Sie eine enge Kopplung mit Pipeline-Tools

Tools zur Test-Orchestrierung

Zusammenfassung

Teil IIIMit Servern und anderen Anwendungs-Laufzeitplattformen arbeiten

10Anwendungs-Laufzeitumgebungen

Cloud-native und anwendungsgesteuerte Infrastruktur

Ziele für eine Anwendungs-Laufzeitumgebung

Deploybare Teile einer Anwendung

Deployment-Pakete

Anwendungen auf Server deployen

Anwendungen als Container verpacken

Anwendungen auf Server-Cluster deployen

Anwendungen auf Anwendungs-Cluster deployen

Pakete zum Deployen von Anwendungen auf Cluster

FaaS-Serverless-Anwendungen deployen

Anwendungsdaten

Datenschemata und -strukturen

Cloud-native Storage-Infrastruktur für Anwendungen

Anwendungs-Connectivity

Service Discovery

Zusammenfassung

11Server als Code bauen

Was gibt es auf einem Server

Woher Dinge kommen

Server-Konfigurationscode

Code-Module für die Serverkonfiguration

Code-Module für die Serverkonfiguration designen

Server-Code versionieren und weitergeben

Serverrollen

Server-Code testen

Server-Code progressiv testen

Was Sie bei Server-Code testen

Wie Sie Server-Code testen

Eine neue Server-Instanz erstellen

Eine neue Server-Instanz per Hand erstellen

Einen Server mit einem Skript erstellen

Einen Server mit einem Stack-Management-Tool erstellen

Die Plattform für das automatische Erstellen von Servern konfigurieren

Einen Server mit einem Network-Provisioning-Tool erstellen

Server vorbereiten

Hot-Cloning eines Servers

Einen Server-Snapshot verwenden

Ein sauberes Server-Image erstellen

Eine neue Server-Instanz konfigurieren

Eine Server-Instanz ausbacken

Server-Images backen

Backen und Ausbacken kombinieren

Serverkonfiguration beim Erstellen eines Servers anwenden

Zusammenfassung

12Änderungen an Servern managen

Patterns zum Changemanagement: Wann Änderungen angewendet werden

Antipattern: Apply on Change

Pattern: Continuous Configuration Synchronization

Pattern: Immutable Server

Wie Sie Serverkonfigurationscode anwenden

Pattern: Push Server Configuration

Pattern: Pull Server Configuration

Andere Ereignisse im Lebenszyklus eines Servers

Eine Server-Instanz stoppen und erneut starten

Eine Server-Instanz ersetzen

Einen ausgefallenen Server wiederherstellen

Zusammenfassung

13Server-Images als Code

Ein Server-Image bauen

Warum ein Server-Image bauen?

Wie Sie ein Server-Image bauen

Tools zum Bauen von Server-Images

Online Image Building

Offline Image Building

Ursprungsinhalte für ein Server-Image

Aus einem Stock-Server-Image bauen

Ein Server-Image von Grund auf bauen

Herkunft eines Server-Image und seiner Inhalte

Ein Server-Image ändern

Ein frisches Image aufwärmen oder backen

Ein Server-Image versionieren

Server-Instanzen aktualisieren, wenn sich ein Image ändert

Ein Server-Image in mehreren Teams verwenden

Umgang mit größeren Änderungen an einem Image

Eine Pipeline zum Testen und Ausliefern eines Server-Image verwenden

Build-Stage für ein Server-Image

Test-Stage für ein Server-Image

Delivery-Stages für ein Server-Image

Mehrere Server-Images verwenden

Server-Images für unterschiedliche Infrastruktur-Plattformen

Server-Images für unterschiedliche Betriebssysteme

Server-Images für unterschiedliche Hardware-Architekturen

Server-Images für unterschiedliche Rollen

Server-Images in Schichten erstellen

Code für mehrere Server-Images verwenden

Zusammenfassung

14Cluster als Code bauen

Lösungen für Anwendungs-Cluster

Cluster as a Service

Packaged Cluster Distribution

Stack-Topologien für Anwendungs-Cluster

Monolithischer Stack, der Cluster as a Service nutzt

Monolithischer Stack für eine Packaged-Cluster-Lösung

Pipeline für einen monolithischen Anwendungs-Cluster-Stack

Beispiel für mehrere Stacks in einem Cluster

Strategien zur gemeinsamen Verwendung von Anwendungs-Clustern

Ein großes Cluster für alles

Getrennte Cluster für Auslieferungs-Stages

Cluster für die Governance

Cluster für Teams

Service Mesh

Infrastruktur für FaaS Serverless

Zusammenfassung

Teil IVInfrastruktur designen

15Zentrale Praktik: Kleine, einfache Elemente

Für Modularität designen

Eigenschaften gut designter Komponenten

Regeln für das Designen von Komponenten

Design-Entscheidungen durch Testen

Infrastruktur modularisieren

Stack-Komponenten versus Stacks als Komponenten

Einen Server in einem Stack verwenden

Grenzen zwischen Komponenten ziehen

Grenzen mit natürlichen Änderungsmustern abstimmen

Grenzen mit Komponenten-Lebenszyklen abstimmen

Grenzen mit Organisationsstrukturen abstimmen

Grenzen schaffen, die Resilienz fördern

Grenzen schaffen, die Skalierbarkeit ermöglichen

Grenzen auf Sicherheits- und Governance-Aspekte abstimmen

Zusammenfassung

16Stacks aus Komponenten bauen

Infrastruktur-Sprachen für Stack-Komponenten

Deklarativen Code mit Modulen wiederverwenden

Stack-Elemente dynamisch mit Bibliotheken erstellen

Patterns für Stack-Komponenten

Pattern: Facade Module

Antipattern: Obfuscation Module

Antipattern: Unshared Module

Pattern: Bundle Module

Antipattern: Spaghetti Module

Pattern: Infrastructure Domain Entity

Eine Abstraktionsschicht bauen

Zusammenfassung

17Stacks als Komponenten einsetzen

Abhängigkeiten zwischen Stacks erkennen

Pattern: Resource Matching

Pattern: Stack Data Lookup

Pattern: Integration Registry Lookup

Dependency Injection

Zusammenfassung

Teil VInfrastruktur bereitstellen

18Infrastruktur-Code organisieren

Projekte und Repositories organisieren

Ein Repository oder viele?

Ein Repository für alles

Ein eigenes Repository für jedes Projekt (Microrepo)

Mehrere Repositories mit mehreren Projekten

Unterschiedliche Arten von Code organisieren

Projektsupport-Dateien

Projektübergreifende Tests

Dedizierte Projekte für Integrationstests

Code anhand des Domänenkonzepts organisieren

Dateien mit Konfigurationswerten organisieren

Infrastruktur- und Anwendungscode managen

Infrastruktur und Anwendungen ausliefern

Anwendungen mit Infrastruktur testen

Infrastruktur vor der Integration testen

Infrastruktur-Code zum Deployen von Anwendungen nutzen

Zusammenfassung

19Infrastruktur-Code ausliefern

Auslieferungsprozess von Infrastruktur-Code

Ein Infrastruktur-Projekt bauen

Infrastruktur-Code als Artefakt verpacken

Infrastruktur-Code mit einem Repository ausliefern

Projekte integrieren

Pattern: Build-Time Project Integration

Pattern: Delivery-Time Project Integration

Pattern: Apply-Time Project Integration

Infrastruktur-Tools durch Skripte verpacken

Konfigurationswerte zusammenführen

Wrapper-Skripte vereinfachen

Zusammenfassung

20Team-Workflows

Die Menschen

Wer schreibt Infrastruktur-Code?

Code auf Infrastruktur anwenden

Code von Ihrem lokalen Rechner aus anwenden

Code von einem zentralisierten Service anwenden lassen

Private Infrastruktur-Instanzen

Quellcode-Branches in Workflows

Konfigurationsdrift verhindern

Automatisierungs-Verzögerung minimieren

Ad-hoc-Anwendung vermeiden

Code kontinuierlich anwenden

Immutable Infrastruktur

Governance in einem Pipeline-basierten Workflow

Zuständigkeiten neu ordnen

Shift Left

Ein Beispielprozess für Infrastructure as Code mit Governance

Zusammenfassung

21Infrastruktur sicher ändern

Reduzieren Sie den Umfang von Änderungen

Kleine Änderungen

Refaktorieren – ein Beispiel

Unvollständige Änderungen in die Produktivumgebung übernehmen

Parallele Instanzen

Abwärtskompatible Transformationen

Feature Toggles

Live-Infrastruktur ändern

Infrastruktur-Chirurgie

Expand and Contract

Zero-Downtime-Änderungen

Kontinuität

Kontinuität durch das Verhindern von Fehlern

Kontinuität durch schnelles Wiederherstellen

Kontinuierliches Disaster Recovery

Chaos Engineering

Für Ausfälle planen

Datenkontinuität in einem sich ändernden System

Sperren

Aufteilen

Replizieren

Neu laden

Ansätze zur Datenkontinuität mischen

Zusammenfassung

Index

Über dieses Buch

Die Praktiken im Bereich von Infrastructure as Code entwickelten sich vom Managen von Servern weiter zum Managen ganzer Stacks, aber diese neuen Möglichkeiten bringen auch zusätzliche Komplexität mit sich. Dieses Buch hilft Ihnen dabei, über die reinen Befehle hinaus ein Verständnis zu entwickeln und die Design-Patterns kennenzulernen, die hinter guter Praxis stehen. Zudem lernen Sie, wie Sie die nächste Stufe der Automatisierung meistern können.

– Patrick Debois, Begründer der DevOpsDays

Infrastructure as Code befindet sich an der Schnittstelle mehrerer Domänen des Software-Engineering. Dieses Buch ordnet die wichtigsten Best Practices aus jeder Domäne neu und führt sie auf ihre zentralen Aspekte zurück, sodass man beim Lesen einen Überblick über die Infrastruktur-Automatisierung erhält.

– Carlos Condé, VP of Engineering bei Sweetgreen

Ein unkomplizierter Ratgeber für die Orientierung in der Landschaft der Cloud-Infrastruktur mit Prinzipien, Praktiken und Patterns.

– Effy Elden, Technologist bei ThoughtWorks

Vorwort

Vor zehn Jahren schlug ich einem CIO bei einer weltweit agierenden Bank vor, sich mit Private-Cloud-Technologien und Werkzeugen zur Infrastruktur-Automation zu befassen, und er antwortete nur höhnisch: »Das mag ja für Start-ups ganz nett sein, aber wir sind zu groß und unsere Anforderungen sind zu komplex.« Und auch ein paar Jahre später wollten viele Unternehmen den Einsatz von Public Clouds noch nicht in Betracht ziehen.

Heutzutage ist Cloud-Technologie allgegenwärtig. Selbst die größten und unbeweglichsten Organisationen wechseln sehr zügig zu einer »Cloud First«-Technologie. Organisationen, die Public Clouds nicht einsetzen können, greifen auf dynamisch provisionierte Infrastruktur-Plattformen in ihren Data Centern zurück.1 Die Möglichkeiten, die diese Plattformen bieten, werden so schnell so viel umfassender und besser, dass es schwer ist, sie zu ignorieren, ohne Gefahr zu laufen, stark ins Hintertreffen zu geraten.

Cloud- und Automatisierungs-Technologien reißen Barrieren nieder, die Änderungen an Produktivsystemen im Wege stehen, was allerdings wiederum zu neuen Herausforderungen führt. Während die meisten Organisationen ihre Änderungsgeschwindigkeit erhöhen wollen, können sie es sich nicht leisten, Risiken zu ignorieren oder sich der Gefahr auszusetzen, die Kontrolle über die Prozesse zu verlieren. Klassische Prozesse und Techniken für ein sicheres Ändern der Infrastruktur sind nicht auf häufige Veränderungen ausgelegt. Deren Arbeitsweise tendiert dazu, die Vorteile moderner Technologien des Cloud-Zeitalters auszubremsen und damit der Erledigung von Arbeit im Weg zu stehen und die Stabilität zu gefährden.2

In Kapitel 1 nutze ich die Begriffe »Eisenzeit« und »Cloud-Zeitalter« (siehe »Aus der Eisenzeit in das Cloud-Zeitalter« auf Seite 33), um die unterschiedlichen Philosophien rund um das Managen »realer« Infrastruktur, bei der sich Fehler nur langwierig und teuer korrigieren lassen, und virtueller Infrastruktur, bei der Fehler schnell erkannt und behoben werden können, zu beschreiben.

Werkzeuge für Infrastructure as Code schaffen die Möglichkeit, so zu arbeiten, dass Änderungen häufiger, schneller und zuverlässiger ausgeliefert werden können, wodurch die Gesamtqualität Ihres Systems zunimmt. Aber die Vorteile entstehen nicht aus den Werkzeugen selbst, sondern daraus, wie Sie sie einsetzen. Der Trick ist, die Technologie als Hebel zu verwenden, um damit Qualität, Zuverlässigkeit und Compliance in den Änderungsprozess einzubringen.

Warum ich dieses Buch geschrieben habe

Die erste (englischsprachige) Auflage dieses Buchs schrieb ich, weil ich keine bündige Zusammenfassung für das Managen von Infrastructure as Code gefunden habe. Es gab viele Tipps, verteilt über Blog-Posts, Vorträge auf Konferenzen und Dokumentation von Produkten und Projekten. Aber für den Einsatz musste man alles durchforsten und sich selbst eine Strategie zusammenbasteln, wofür die meisten Leute einfach keine Zeit hatten.

Die Erfahrungen beim Schreiben der ersten Auflage waren überwältigend. Ich hatte die Gelegenheit, herumzureisen und mit Menschen überall auf der Welt über deren Erfahrungen zu sprechen. Diese Unterhaltungen verschafften mir neue Einblicke und stellten mich vor neue Herausforderungen. Ich lernte, dass der Wert des Schreibens eines Buchs, des Haltens von Vorträgen auf Konferenzen und des Beratens mit Kunden darin besteht, den fachlichen Austausch zu fördern. In der Branche sind wir immer noch dabei, unsere Ideen zu Infrastructure as Code zu sammeln, miteinander zu teilen und weiterzuentwickeln.

Was in dieser Auflage neu und anders ist

Seit die erste (englischsprachige) Auflage im Juni 2016 erschienen ist, hat sich ziemlich viel getan. Jene Auflage hatte den Untertitel »Managing Servers in the Cloud«, was die Tatsache widerspiegelte, dass sich damals ein Großteil der Infrastruktur-Automation um das Konfigurieren von Servern drehte. Seitdem sind Container und Cluster viel wichtiger geworden, und die Aktivitäten rund um die Infrastruktur haben sich hin zum Managen von Gruppen von Infrastruktur-Ressourcen bewegt, die auf Cloud-Plattformen provisioniert werden – was ich in diesem Buch als Stacks bezeichne.

Somit kümmert sich diese Auflage mehr um den Aufbau von Stacks, was das Verdienst von Tools wie CloudFormation oder Terraform ist. Ich gehe dabei von der Annahme aus, dass wir Stack-Management-Tools nutzen, um Infrastruktur-Objekte zusammenzufügen, die dann die Anwendungs-Laufzeitumgebungen bereitstellen. Zu diesen Laufzeitumgebungen können Server, Cluster und Serverless-Ausführungsumgebungen gehören.

Ich habe eine Menge geändert, weil ich seit der ersten Auflage viel gelernt habe über neue Herausforderungen und die Anforderungen von Teams beim Aufbau von Infrastruktur. Wie schon erwähnt sehe ich den Hauptvorteil von Infrastructure as Code darin, die Infrastruktur sicher und einfach anpassen zu können. Ich glaube, dass die Menschen deren Wichtigkeit unterschätzen, weil sie davon ausgehen, dass es sich bei Infrastruktur um etwas handelt, das sie einmal aufsetzen und dann vergessen.

Aber zu viele Teams, mit denen ich zu tun hatte, kämpfen damit, die Anforderungen ihrer Organisationen zu erfüllen – sie sind nicht dazu in der Lage, schnell genug zu wachsen und zu skalieren, die Geschwindigkeit der Softwareauslieferungen zu unterstützen oder die erwartete Zuverlässigkeit und Sicherheit zu bieten. Und wenn wir uns die Details ihrer Herausforderungen genauer anschauen, stellen wir fest, dass sie von dem Bedarf an Aktualisierungen, Korrekturen und Verbesserungen ihrer Systeme überrollt werden. Daher habe ich speziell diesen Bereich zum zentralen Thema dieses Buchs gemacht.

Diese Auflage stellt drei zentrale Praktiken für den Einsatz von Infrastructure as Code vor, die Änderungen sicher und einfach machen:

Definieren Sie alles als Code.

Das geht schon aus dem Namen hervor und sorgt für Reproduzierbarkeit und Konsistenz.

Testen Sie und liefern Sie kontinuierlich die aktuelle Arbeit aus.

Jede Änderung verbessert die Sicherheit. Sie ermöglicht es zudem, schneller und mit mehr Vertrauen voranzukommen.

Bauen Sie kleine, einfache Elemente, die Sie unabhängig voneinander ändern können.

Diese lassen sich einfacher und sicherer ändern als große Elemente.

Diese drei Praktiken unterstützen sich gegenseitig. Code lässt sich über die verschiedenen Stadien eines Änderungsmanagement-Prozesses hinweg einfach verfolgen, versionieren und ausliefern. Es ist einfacher, kontinuierlich kleinere Elemente zu testen. Kontinuierliches, eigenständiges Testen eines jeden Elements zwingt Sie dazu, ein lose gekoppeltes Design beizubehalten.

Solche Praktiken und die Details ihrer Anwendung sind uns aus der Welt der Softwareentwicklung vertraut. In der ersten Auflage dieses Buchs bezog ich mich auf Praktiken der agilen Softwareentwicklung und der Auslieferung. In dieser Auflage habe ich zudem auf Regeln und Praktiken effektiven Designs zurückgegriffen.

In den letzten Jahren habe ich gesehen, wie Teams bei größeren und komplizierteren Infrastruktur-Systemen ins Straucheln gerieten, und festgestellt, wie das Anwenden der Erfahrungen mit Software-Design-Patterns und -Prinzipien helfen konnte, daher habe ich eine Reihe von Kapiteln dazu aufgenommen.

Ich habe auch gesehen, dass das Organisieren von Infrastruktur-Code und die Arbeit damit für viele Teams schwierig ist, daher habe ich eine Reihe von kritischen Punkten angesprochen. Ich beschreibe, wie man eine Codebasis gut organisiert hält, wie man Entwicklungs- und Testinstanzen für die Infrastruktur bereitstellt und wie man die Zusammenarbeit mehrerer Personen managt – einschließlich derer, die für Governance verantwortlich sind.

Was kommt als Nächstes?

Ich glaube nicht, dass wir als Branche beim Umgang mit Infrastruktur schon ausgelernt haben. Ich hoffe, dieses Buch gibt einen guten Überblick über all das, was Teams heutzutage als effektiv ansehen. Und motiviert ein bisschen, es noch besser zu machen.

Ich erwarte, dass sich Toolchains und Vorgehensweise in fünf Jahren wieder weiterentwickelt haben. Vielleicht gibt es mehr universell einsetzbare Sprachen zum Bauen von Bibliotheken, und eventuell generieren wir Infrastruktur dynamisch, statt die statischen Umgebungsdetails auf niedriger Ebene zu definieren. Wir müssen mit ziemlicher Sicherheit beim Verwalten von Änderungen an Live-Infrastruktur besser werden. Die meisten mir bekannten Teams haben immer Angst, wenn sie Code auf Live-Infrastruktur anwenden. (Ein Team bezeichnet Terraform als »Terrorform«, aber auch andere Werkzeuge werden ähnlich gesehen.)

Was dieses Buch ist und was es nicht ist

Die These dieses Buchs ist, dass uns das Erforschen verschiedener Wege beim Einsatz von Werkzeugen zum Implementieren von Infrastruktur dabei helfen kann, die Qualität der von uns bereitgestellten Services zu verbessern. Wir wollen durch Geschwindigkeit und Auslieferungsfrequenz die Zuverlässigkeit und Qualität dessen, was wir ausliefern, verbessern.

Daher liegt der Fokus dieses Buchs weniger auf bestimmten Werkzeugen und mehr darauf, wie man sie einsetzt.

Auch wenn ich Beispiele für Tools für bestimmte Funktionen wie das Konfigurieren von Servern und das Provisionieren von Stacks erwähne, werden Sie keine Details zum Einsatz spezifischer Werkzeuge oder Cloud-Plattformen finden. Es gibt Patterns, Praktiken und Techniken, die unabhängig von den von Ihnen eingesetzten Tools und Plattformen relevant sein sollten.

Sie werden auch keine Codebeispiele für reale Werkzeuge oder Clouds finden. Tools ändern sich in diesem Bereich zu schnell, sodass Codebeispiele nicht aktuell gehalten werden könnten, aber die Ratschläge in diesem Buch sollten langsamer veralten und für viele Werkzeuge anwendbar sein. Stattdessen schreibe ich Pseudocode-Beispiele für fiktive Tools, um Konzepte deutlich zu machen. Auf der das Buch begleitenden Website (https://infrastructure-as-code.com) finden Sie Beispielprojekte und -code.

Dieses Buch erklärt Ihnen nicht, wie Sie das Betriebssystem Linux einsetzen, Kubernetes-Cluster konfigurieren oder Networking-Routing betreiben. Aber es beschreibt Wege zum Provisionieren von Infrastruktur-Ressourcen, um diese Aufgaben umzusetzen, und wie Sie Code einsetzen, um sie auszuliefern. Ich stelle verschiedene Cluster-Topologie-Patterns und Ansätze zum Definieren und Managen von Clustern als Code vor. Ich beschreibe Patterns zum Provisionieren, Konfigurieren und Ändern von Server-Instanzen mithilfe von Code.

Sie sollten die Praktiken in diesem Buch durch Ressourcen zu den spezifischen Betriebssystemen, Clustering-Technologien und Cloud-Plattformen ergänzen. Auch hier erläutert dieses Buch Vorgehensweisen für den Einsatz dieser Werkzeuge und Technologien, die unabhängig vom spezifischen Tool relevant sind.

Dieses Buch streift Operability-Themen wie Monitoring und Observability, Log-Aggregation, Identity Management und andere Aspekte, die Sie zum Unterstützen von Services in einer Cloud-Umgebung benötigen, nur am Rande. Was Sie hier finden, soll Ihnen dabei helfen, die Infrastruktur als Code zu managen, die für diese Services erforderlich ist – die Details der spezifischen Services sind wiederum nur etwas, das Sie in entsprechenden Quellen finden.

Etwas Geschichte zu Infrastructure as Code

Tools und Praktiken rund um Infrastructure as Code gab es schon lange, bevor dieser Begriff geprägt wurde. Systemadministratorinnen und -administratoren nutzten schon von Anfang an Skripte, um Systeme zu managen. Mark Burgess hat das wegweisende CFEngine-System (https://cfengine.com) im Jahr 1993 geschaffen. Ich habe Praktiken zum Verwenden von Code zum vollständig automatisierten Provisionieren und Updaten von Servern in den frühen 2000ern über die Website http://www.infrastructures.org kennengelernt.1

Infrastructure as Code ist zusammen mit der DevOps-Bewegung gewachsen. Andrew Clay-Shafer und Patrick Debois starteten die DevOps-Bewegung durch einen Talk auf der Agile-2008-Konferenz (https://oreil.ly/ermR3). Die erste Verwendung von »Infrastructure as Code« fand ich in einem Talk mit dem Titel »Agile Infrastructure« von Clay-Shafer auf der Velocity-Konferenz im Jahr 2009 (https://oreil.ly/qnJKX), und John Willis schrieb einen Artikel (https://oreil.ly/2F6y_), der diesen zusammenfasste. Adam Jacob, der Chef mitbegründet hat, und Luke Kanies, Begründer von Puppet, nutzten diese Phrase ebenfalls zu dieser Zeit.

Für wen dieses Buch gedacht ist

Dieses Buch ist für Menschen gedacht, die mit dem Bereitstellen und Einsetzen von Infrastruktur zu tun haben, auf der Software ausgeliefert und ausgeführt wird. Sie haben vielleicht Erfahrung mit Systemen und Infrastruktur oder mit der Softwareentwicklung und -auslieferung. Ihre Rolle kann in der Entwicklung, dem Testen, der Architektur oder dem Management liegen. Ich gehe davon aus, dass Sie schon mit Cloud- oder virtualisierter Infrastruktur und Tools zum Automatisieren von Infrastructure as Code Kontakt hatten.

Leserinnen und Leser, für die Infrastructure as Code neu ist, sollten mit diesem Buch eine gute Einführung zum Thema erhalten, auch wenn Sie mehr daraus ziehen können, wenn Sie schon damit vertraut sind, wie Infrastruktur-Cloud-Plattformen arbeiten, und wenn Sie die Grundlagen zumindest eines Infrastruktur-Coding-Tools kennen.

Wenn Sie mehr Erfahrung im Umgang mit diesen Tools haben, finden Sie hier eine Mischung aus vertrauten und neuen Konzepten und Ansätzen. Der Inhalt sollte eine gemeinsame Sprache schaffen und Herausforderungen und Lösungen so beschreiben, dass erfahrene Praktiker und Teams Nutzen daraus ziehen können.

Prinzipien, Praktiken und Patterns

Ich verwende die Begriffe Prinzipien, Praktiken und Patterns (und Antipatterns), um damit zentrale Konzepte zu beschreiben. So setze ich sie ein:

Prinzip

Ein Prinzip ist eine Regel, die Ihnen dabei hilft, zwischen möglichen Lösungen auszuwählen.

Praktik

Eine Praktik ist eine Vorgehensweise, wie etwas umgesetzt wird. Eine gegebene Praktik ist nicht immer der einzige Weg, um etwas zu erledigen, und eventuell ist sie nicht einmal der beste Weg in einer bestimmten Situation. Sie sollten Prinzipien nutzen, um sich bei der Wahl der passendsten Praktik für eine gegebene Situation leiten zu lassen.

Pattern

Ein Pattern ist eine mögliche Lösung für ein Problem. Es ähnelt einer Praktik darin, dass andere Patterns in anderen Kontexten effektiver sein können. Jedes Pattern ist in einer Form beschrieben, die Ihnen dabei helfen soll, herauszufinden, wie relevant es für Ihr Problem ist.

Antipattern

Ein Antipattern kann zwar eine mögliche Lösung sein, Sie sollten es aber in den meisten Situationen nicht einsetzen, denn oft klingt es nur nach einer guten Idee – oder Sie geraten durch die Verwendung von Antipatterns in Situationen, die schwierig werden können, ohne dass Sie es bemerken.

Warum ich den Begriff »Best Practice« nicht verwende

Die Menschen in unserer Branche lieben es, über »Best Practices« zu sprechen. Problematisch an diesem Begriff ist, dass er uns oft dazu bringt, zu denken, dass es unabhängig von der Situation nur eine Lösung für ein Problem gibt.

Ich ziehe es vor, Praktiken und Patterns zu beschreiben und dabei darauf hinzuweisen, wann sie nützlich sind und welche Grenzen sie haben. Manches davon beschreibe ich als effektiver oder passender, aber ich versuche, offen für Alternativen zu sein. Bei Praktiken, die meiner Ansicht nach weniger effektiv sind, hoffe ich, dass ich meine Einschätzung nachvollziehbar erkläre.

Die ShopSpinner-Beispiele

Ich verwende in diesem Buch eine fiktive Firma namens ShopSpinner, um Konzepte zu illustrieren. Sie erstellt und betreibt Online-Stores für ihre Kunden.

ShopSpinner läuft auf FCS, dem Fictional Cloud Service – einem Public-IaaS-Provider mit verschiedenen Services, zu denen FSI (Fictional Server Images) und FKS (Fictional Kubernetes Service) gehören. Er verwendet das Stackmaker-Tool – ein Analogon zu Terraform, CloudFormation und Pulumi –, um Infrastruktur in seiner Cloud zu definieren und zu verwalten. FCS konfiguriert Server mit dem Servermaker-Tool, was für Tools wie Ansible, Chef oder Puppet steht.

Die Infrastruktur und das Systemdesign von ShopSpinner können je nachdem, was ich zu erklären versuche, unterschiedlich aussehen, wie auch die Code-Syntax oder Befehlszeilenargumente für die fiktiven Tools.

In diesem Buch verwendete Konventionen

Die folgenden typografischen Konventionen werden in diesem Buch genutzt:

Kursiv

Für neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen.

Schreibmaschinenschrift

Für Programmlistings, aber auch für Code-Fragmente in Absätzen, wie zum Beispiel Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter.

###fette Schreibmaschinenschrift###

Für Befehle und anderen Text, der genau so vom Benutzer eingegeben werden sollte.

###kursive Schreibmaschinenschrift###

Für Text, der vom Benutzer durch eigene Werte ersetzt werden sollte.

Tipp

Dieses Symbol steht für einen Tipp oder Vorschlag.

Hinweis

Dieses Symbol steht für eine allgemeine Anmerkung.

Warnung

Dieses Symbol steht für eine Warnung oder Vorsichtsmaßnahme.

Danksagung

Wie schon die erste Auflage ist auch die vorliegende aktuelle 2. Auflage nicht alleine mein Werk – es ist das Ergebnis des möglichst guten Sammelns und Zusammenführens von Informationen, die ich von mehr Menschen gelernt habe, als ich mich erinnern, geschweige denn anständig aufzählen könnte. Eine große Entschuldigung und vielen Dank an all die, die ich hier beim Aufzählen vergessen habe.

Ich liebe es immer, zusammen mit James Lewis Ideen zu jonglieren – unsere Gespräche und seine Texte und Vorträge haben direkt und indirekt viel von dem beeinflusst, was Sie in diesem Buch finden. Er hat freundlicherweise seine umfassende Erfahrung zum Softwaredesign und sein Wissen über viele andere Themen mit mir geteilt, indem er mir seine Gedanken zu einer nahezu finalen Version dieses Buchs zukommen ließ. Seine Vorschläge haben mir dabei geholfen, die Verbindungen zu stärken, die ich zwischen der Softwareentwicklung und Infrastructure as Code ziehen wollte.

Martin Fowler hat meine Arbeit von Anfang an unterstützt. Seine Fähigkeit, aus der Erfahrung anderer zu lernen, sein Wissen und seine Ansichten anzuwenden und all das in klare, hilfreiche Ratschläge zu formulieren, inspiriert mich.

Thierry de Pauw war ein außerordentlich mitdenkender und hilfreicher Gutachter. Er hat mehrere Entwürfe des Buchs gelesen und seine Gedanken dazu mit mir geteilt, mir erzählt, was er neu und nützlich fand, welche Ideen mit seinen Erfahrungen übereinstimmen und welche Teile ihm nicht klar genug waren.

Ich danke Abigail Bangser, Jon Barber, Max Griffiths, Anne Simmons und Claire Walkley für ihre Unterstützung und Inspiration.

Mir haben verschiedene Personen, mit denen ich zusammengearbeitet habe, Gedanken und Ideen mitgeteilt, die dieses Buch besser gemacht haben. James Green hat mir vom Data Engineering und maschinellem Lernen im Kontext von Infrastruktur erzählt. Pat Downey hat seinen Einsatz von Expand and Contract für Infrastruktur erklärt. Vincenzo Fabrizi hat mich auf den Wert der Inversion of Control für Infrastruktur-Abhängigkeiten hingewiesen. Effy Elden besitzt unfassbar viel Wissen über die diversen Infrastruktur-Tools. Moritz Heiber hat direkt und indirekt Einfluss auf dieses Buch genommen, auch wenn ich wohl nicht hoffen kann, dass er allem zu 100 Prozent zustimmt.

Bei ThoughtWorks habe ich die Möglichkeit, mit vielen Kolleginnen und Kollegen sowie Kundinnen und Kunden in Workshops, Projekten und Onlineforen über Infrastructure as Code zu sprechen. Zu ihnen gehören unter anderem Ama Asare, Nilakhya Chatterjee, Audrey Conceicao, Patrick Dale, Dhaval Doshi, Filip Fafara, Adam Fahie, John Feminella, Mario Fernandez, Louise Franklin, Heiko Gerin, Jarrad »Barry« Goodwin, Emily Gorcenski, James Gregory, Col Harris, Prince M Jain, Andrew Jones, Aiko Klostermann, Charles Korn, Vishwas Kumar, Punit Lad, Suya Liu, Tom Clement Oketch, Gerald Schmidt, Boss Supanat Pothivarakorn, Rodrigo Rech, Florian Sellmayr, Vladimir Sneblic, Isha Soni, Widyasari Stella, Paul Valla, Srikanth Venugopalan, Ankit Wal, Paul Yeoh und Jiayu Yi. Vielen Dank auch an Kent Spillner – dieses Mal weiß ich auch, warum.

Viele Personen haben unterschiedliche Entwurfsstände dieser Auflage gelesen und Feedback gegeben, unter anderem Artashes Arabajyan, Albert Attard, Simon Bisson, Phillip Campbell, Mario Cecchi, Carlos Conde, Bamdad Dashtban, Marc Hofer, Willem van Ketwich, Barry O’Reilly, Rob Park, Robert Quinlivan, Wasin Watthanasrisong und Rebecca Wirfs-Brock.

Großer Dank gebührt meiner Lektorin Virginia Wilson, die mich durch den langen und aufreibenden Prozess begleitet hat, durch den dieses Buch entstehen konnte. Mein Kollege John Amalanathan hat meine nur skizzierten Diagramme mit viel Geduld und Sorgfalt in die kleinen Kunstwerke verwandelt, die Sie in diesem Buch finden.

Mein Arbeitgeber ThoughtWorks hat mir ebenfalls sehr viel Unterstützung zukommen lassen. Vor allem, indem er die Umgebung geschaffen hat, in der ich von fantastischen Menschen lernen kann, aber auch durch das Fördern einer Kultur, die die Mitarbeiterinnen und Mitarbeiter darin unterstützt, Ideen mit der ganzen Branche zu teilen. Und schließlich kann ich bei ihm mit anderen ThoughtWorkern sowie Kundinnen und Kunden neue Wege der Arbeit erforschen und ausprobieren. Ashok Subramanian, Ruth Harrison, Renee Hawkins, Ken Mugrage, Rebecca Parsons und Gayathri Rao haben mir (neben vielen anderen) dabei geholfen, aus diesem Buch mehr als ein privates Projekt zu machen.

Und schließlich möchte ich Ozlem und Erel, die wieder einmal meine Obsession für dieses Buch erduldet haben, meiner ewigen Liebe versichern.

TEIL I

Grundlagen

KAPITEL 1

Was ist Infrastructure as Code?

Arbeiten Sie in einem Team, das IT-Infrastruktur erstellt und betreibt, sollten Ihnen Automatisierungstechniken für Cloud und Infrastruktur dabei helfen, in weniger Zeit zuverlässiger mehr Wert bieten zu können. Aber in der Praxis geht es vor allem darum, die stetig zunehmende Größe, Komplexität und Diversität der verschiedenen Elemente im Griff zu behalten.

Diese Technologien sind besonders relevant, wenn Organisationen digital werden. Wenn Business-Menschen »Digital« sagen, meinen sie damit, dass Softwaresysteme für das, was die Organisation tut, von zentraler Bedeutung sind.1 Der Wechsel ins Digitale verstärkt den Druck auf Sie, mehr Aufgaben schneller zu erledigen. Sie müssen zusätzliche Services hinzufügen und betreuen. Mehr Business-Aktivitäten. Mehr Mitarbeiterinnen und Mitarbeiter. Mehr Kundinnen und Kunden, Lieferpartner und andere Stakeholder.

Cloud- und Automatisierungs-Tools helfen dabei, es viel leichter zu machen, Infrastruktur hinzuzufügen und anzupassen. Aber viele Teams haben Probleme damit, ausreichend Zeit dafür zu finden, mit der schon vorhandenen Infrastruktur Schritt zu halten. Da ist es nicht sehr hilfreich, das Erstellen von noch mehr Infrastruktur einfacher zu machen. Einer meiner Kunden sagte mir: »Durch Cloud wurden die Barrieren eingerissen, die unseren Reifenbrand unter Kontrolle behielten.«2

Viele haben auf die Drohung eines ausufernden Chaos durch ein Anziehen ihres Änderungsmanagement-Prozesses reagiert. Sie haben die Hoffnung, dass sich das Chaos durch Begrenzen und Kontrollieren der Änderungen vermeiden lässt. Also legen sie die Cloud in Ketten.

Damit gibt es zwei Probleme. Das eine ist, dass so die Vorteile der Cloud-Technologien verloren gehen, das andere, dass die Benutzerinnen und Benutzer die Vorteile der Cloud-Technologie auch haben wollen. So ist man bemüht, die Personen zu umgehen, die versuchen, das Chaos im Griff zu behalten. Im schlimmsten Fall wird das Risikomanagement vollständig ignoriert, und man entscheidet für sich, dass das in der schönen neuen Cloud-Welt nicht notwendig sei. Sie setzen auf Cowboy-IT, was zu verschiedenen Problemen führt.1

Die Prämisse dieses Buchs ist, dass Sie Cloud- und Automatisierungs-Technologie nutzen können, um Änderungen einfach, sicher, schnell und verantwortungsbewusst durchführen zu können. Diese Vorteile entstehen nicht automatisch durch den Einsatz von Automatisierungs-Werkzeugen oder Cloud-Plattformen. Sie hängen davon ab, wie Sie diese Technologie verwenden.

DevOps und Infrastructure as Code

DevOps ist eine Bewegung, die Hindernisse abbaut und Reibungen zwischen der Silo-Entwicklung, Operations und anderen Stakeholdern reduziert, die am Planen, Bauen und Ausführen von Software beteiligt sind. Auch wenn der Technologie-Anteil der sichtbarste und in mancherlei Hinsicht auch einfachste Aspekt von DevOps ist, haben Kultur, Personen und Prozesse den größten Einfluss auf den Fluss und die Effektivität. Technologie und Entwicklungspraktiken wie Infrastructure as Code sollten zum Einsatz kommen, um die Aktivitäten zu unterstützen, die Gräben überbrücken und die Zusammenarbeit verbessern.

In diesem Kapitel erkläre ich, dass moderne, dynamische Infrastruktur eine Mentalität aus dem »Cloud-Zeitalter« erfordert. Die Mentalität unterscheidet sich grundlegend vom klassischen »Eisenzeit«-Ansatz, den wir bei statischen Prä-Cloud-Systemen genutzt haben. Ich definiere drei zentrale Praktiken für das Implementieren von Infrastructure as Code: Definiere alles als Code, teste und liefere alles fortlaufend während des Entwickelns aus und baue das System aus kleinen, lose gekoppelten Elementen auf.

Ich beschreibe zudem in diesem Kapitel die Gründe für den »Cloud-Zeitalter«-Ansatz zur Infrastruktur. Dieser löst sich von der fälschlich angenommenen Gegensätzlichkeit von Geschwindigkeit und Qualität, die man gegeneinander abwägen müsse. Stattdessen nutzen wir die Geschwindigkeit als eine Möglichkeit, die Qualität zu verbessern, und die Qualität, um mit hoher Geschwindigkeit auszuliefern.

Aus der Eisenzeit in das Cloud-Zeitalter

Technologie des Cloud-Zeitalters ermöglicht ein schnelleres Provisionieren und Ändern von Infrastruktur, als dies mit den klassischen Technologien aus der Eisenzeit möglich wäre (Tabelle 1-1).

Tabelle 1-1: Technologische Änderungen im Cloud-Zeitalter

Eisenzeit

Cloud-Zeitalter

Physische Hardware

Virtualisierte Ressourcen

Provisionieren dauert Wochen

Provisionieren dauert Minuten

Manuelle Prozesse

Automatisierte Prozesse

Aber diese Technologien machen es nicht notwendigerweise einfacher, Ihre Systeme zu managen und wachsen zu lassen. Überführen Sie ein System mit technischen Schulden (https://oreil.ly/3AqHB) in eine schrankenlose Cloud-Infrastruktur, beschleunigen Sie nur das Chaos.

Vielleicht konnten Sie auf bewährte, klassische Governance-Modelle zurückgreifen, um die Geschwindigkeit und das Chaos zu kontrollieren, das neuere Technologien mit sich bringen. Ein umfassendes, vorher ausgearbeitetes Design, rigorose Change Reviews und strikt getrennte Zuständigkeiten werden schon für Ordnung sorgen!

Aber leider sind diese Modelle für die Eisenzeit optimiert, in der Änderungen langsam und teuer sind. Sie sorgen für zusätzlichen Aufwand im Vorhinein mit der Hoffnung, später den Zeitaufwand für die Änderung zu verringern. Das ist durchaus sinnvoll, wenn es später teuer und langsam ist, Änderungen vorzunehmen. Aber durch die Cloud werden Änderungen schnell und günstig. Sie sollten diese Geschwindigkeit zu Ihrem Vorteil nutzen, um kontinuierlich zu lernen und Ihr System zu verbessern. Arbeiten Sie weiter wie in der Eisenzeit, sind Ihr Lernen und Ihre Verbesserungen massiv eingeschränkt.

Statt also langsame Prozesse aus der Eisenzeit auf schnellere Technologie des Cloud-Zeitalters anzuwenden, sollten Sie eine neue Mentalität übernehmen. Nutzen Sie eine schnellere Technologie, um Risiken zu verringern und die Qualität zu verbessern. Das erfordert einen grundlegend anderen Ansatz und neue Wege, über Änderungen und Risiken nachzudenken (Tabelle 1-2).

Tabelle 1-2: Arbeitsweisen im Cloud-Zeitalter

Eisenzeit

Cloud-Zeitalter

Änderungskosten sind hoch

Änderungskosten sind niedrig

Änderungen stehen für Fehler (Änderungen müssen »gemanagt« oder »kontrolliert« werden)

Änderungen stehen für Lernen und Verbesserungen

Gelegenheit zu Fehlern verringern

Geschwindigkeit von Verbesserungen maximieren

In großen Batches ausliefern, am Ende testen

Kleine Änderungen ausliefern, fortlaufend testen

Lange Release-Zyklen

Kurze Release-Zyklen

Monolithische Architektur (wenige und größere Komponenten)

Microservices-Architektur (viele und kleinere Komponenten)

Konfiguration über GUI oder direkt an der Hardware

Konfiguration als Code

Infrastructure as Code

Infrastructure as Code ist ein Ansatz für die Infrastruktur-Automatisierung, der auf Praktiken aus der Softwareentwicklung basiert. Er baut auf konsistenten, wiederholbaren Routinen zum Provisionieren und zur Änderung von Systemen und deren Konfiguration auf. Sie nehmen Änderungen am Code vor und nutzen dann Automation, um diese Änderungen zu testen und auf Ihre Systeme anzuwenden.

In diesem Buch erläutere ich, wie Sie agile Entwicklungspraktiken wie Test-driven Development (TDD), Continuous Integration (CI) und Continuous Delivery (CD) nutzen können, um das Ändern von Infrastruktur schnell und sicher zu gestalten. Ich beschreibe zudem, wie ein modernes Softwaredesign für resiliente, gut gewartete Infrastruktur sorgen kann. Diese Praktiken und Design-Ansätze unterstützen sich gegenseitig. Gut designte Infrastruktur lässt sich leichter testen und bereitstellen. Automatisiertes Testen und Bereitstellen führt zu einfacherem und saubererem Design.

Vorteile von Infrastructure as Code

Zusammengefasst kann man sagen, dass Organisationen, die Infrastructure as Code nutzen, um dynamische Infrastruktur zu verwalten, unter anderem auf Folgendes hoffen:

Mit der IT-Infrastruktur ein schnelles Bereitstellen von Werten ermöglichen.

Aufwand und Risiken von Änderungen an der Infrastruktur reduzieren.

Anwenderinnen und Anwender der Infrastruktur dazu befähigen, die notwendigen Ressourcen dann zu bekommen, wenn sie sie brauchen.

Gemeinsame Werkzeuge für Entwicklung, Operations und andere Stakeholder bereitstellen.

Systeme aufbauen, die zuverlässig, sicher und kostengünstig sind.

Steuerelemente für Governance, Sicherheit und Compliance sichtbar machen.

Die Geschwindigkeit verbessern, mit der Fehler gefunden und gelöst werden.

Infrastructure as Code nutzen, um für Änderungen zu optimieren

Angesichts dessen, dass Änderungen das größte Risiko für ein Produktivsystem sind, sich kontinuierliche Änderungen nicht vermeiden lassen und ein System nur durch Änderungen verbesserbar ist, ist es sinnvoll, Ihre Fähigkeit zu optimieren, Änderungen sowohl schnell als auch zuverlässig zu machen.1 Die Forschungsergebnisse im Accelerated State of DevOps Report unterstützen diese Ansicht. Häufige und zuverlässige Änderungen korrelieren mit dem Erfolg von Organisationen.2

Es gibt eine Reihe von Einwänden, die ich zu hören bekomme, wenn ich einem Team empfehle, zum Optimieren von Änderungen Automation einzuführen. Ich glaube, diese entstehen aus Missverständnissen, wie Sie Automation verwenden können und sollten.

Einwand »Wir haben gar nicht so häufig Änderungen, sodass sich Automation nicht lohnt«

Wir möchten gerne glauben, dass wir ein System bauen, und dann ist es »fertig«. Bei einer solchen Sichtweise nehmen wir nicht viele Änderungen vor, daher ist das Automatisieren von Änderungen nur Zeitverschwendung.

In der Realität gibt es nur an sehr wenigen Systemen keine Veränderungen mehr – zumindest nicht, bevor sie ausgemustert werden. Manche gehen davon aus, dass die aktuelle Menge an Änderungen nur vorübergehend ist. Andere schaffen aufwendige Prozesse zum Änderungsmanagement, um Personen davon abzuhalten, nach Änderungen zu fragen. Aber diejenigen reden es sich schön. Die meisten Teams, die aktiv genutzte Systeme betreuen, haben es mit einem kontinuierlichen Strom von Änderungen zu tun.

Denken Sie nur an die folgenden Beispiele für Änderungen an der Infrastruktur:

Ein wichtiges neues Anwendungsfeature erfordert das Hinzufügen einer neuen Datenbank.

Für ein neues Anwendungsfeature muss der Anwendungsserver aktualisiert werden.

Die App wird häufiger genutzt als erwartet. Sie brauchen mehr Server, neue Cluster und zusätzliche Networking- und Storage-Kapazitäten.

Beim Performance-Profiling zeigt sich, dass die aktuelle Deployment-Architektur für die Anwendung die Performance einschränkt. Sie müssen die Anwendungen auf mehrere andere Anwendungsserver neu deployen. Dazu sind Änderungen am Clustering und an der Netzwerk-Architektur erforderlich.

Es gibt eine neu bekannt gewordene Sicherheitslücke in Systempaketen für Ihr Betriebssystem. Sie müssen dutzende Produktivserver patchen.

Sie müssen Server aktualisieren, auf denen veraltete Versionen des Betriebssystems und zentraler Pakete laufen.

Auf Ihren Webservern gibt es immer wieder Aussetzer. Sie müssen eine Reihe von Konfigurationsänderungen vornehmen, um das Problem untersuchen zu können. Dann müssen Sie ein Modul aktualisieren, um das Problem zu lösen.

Sie finden eine Konfigurationsänderung, die die Performance Ihrer Datenbank verbessert.

Eine zentrale Wahrheit des Cloud-Zeitalters ist: Stabilität entsteht durch Änderungen.

Ungepatchte Systeme sind nicht stabil – sie sind angreifbar. Können Sie Probleme nicht beheben, sobald Sie sie finden, ist Ihr System nicht stabil. Können Sie nach einem Ausfall nicht schnell wieder auf die Füße kommen, ist Ihr System nicht stabil. Wenn für Ihre Änderungen eine deutliche Downtime erforderlich ist, ist Ihr System nicht stabil. Wenn Änderungen immer wieder fehlschlagen, ist Ihr System nicht stabil.

Einwand »Wir sollten erst bauen und danach automatisieren«

Wenn Sie mit Infrastructure as Code beginnen, haben Sie eine steile Lernkurve vor sich. Das Aufsetzen der Tools, Services und Arbeitsweisen zum Automatisieren der Infrastruktur-Bereitstellung erfordert viel Arbeit, insbesondere, wenn Sie sich gleichzeitig auch noch in eine neue Infrastruktur-Plattform einarbeiten. Der Wert dieser Arbeit wird erst dann sichtbar, wenn Sie beginnen, Services damit zu bauen und zu deployen. Und auch dann wird er eventuell denen nicht deutlich werden, die nicht direkt mit der Infrastruktur arbeiten.

Stakeholder drängen Infrastruktur-Teams oft dazu, schnell und mal eben manuell neue in der Cloud gehostete Systeme zu bauen und sich erst später um das Automatisieren zu kümmern.

Es gibt drei Gründe dafür, warum das eine schlechte Idee ist:

Durch die Automation sollte das Bereitstellen schneller gehen, auch für neue Elemente. Implementieren Sie die Automation erst, nachdem ein Großteil der Arbeit erledigt ist, opfern Sie viele der Vorteile.

Automation erleichtert das Schreiben automatisierter Tests für das, was Sie bauen. Und sie macht es einfacher, etwas schnell zu korrigieren und neu zu bauen, wenn Sie Probleme finden. Wenn Sie dies als Teil des Build-Prozesses tun, hilft es Ihnen dabei, eine bessere Infrastruktur zu bauen.

Das Automatisieren eines bestehenden Systems ist sehr schwer. Automation ist Teil des Designs und der Implementierung eines Systems. Um ein System, das ohne Automation aufgebaut wurde, um diese zu ergänzen, müssen Sie das Design und die Implementierung des Systems deutlich anpassen. Das gilt auch für das automatisierte Testen und Deployen.

Cloud-Infrastruktur, die ohne Automation aufgebaut wurde, müssen Sie schneller abschreiben, als Sie denken. Die Kosten für das manuelle Warten und Beheben von Fehlern im System können schnell deutlich wachsen. Ist der Service, der darauf läuft, erfolgreich, werden Sie die Stakeholder dazu drängen, ihn zu erweitern und neue Features hinzuzufügen, statt innezuhalten, um ihn neu zu bauen.

Das Gleiche gilt, wenn Sie ein System als Experiment bauen. Haben Sie einen Proof of Concept zum Laufen gebracht, wird es den Druck geben, sich mit dem nächsten Thema zu beschäftigen, statt zurückzukehren und das System richtig neu zu bauen. Und eigentlich sollte Automation auch Teil des Experiments sein. Wollen Sie Automation zum Managen Ihrer Infrastruktur einsetzen, müssen Sie verstehen, wie das funktionieren wird, daher sollte es auch Teil Ihres Proof of Concept sein.

Die Lösung besteht darin, Ihr System inkrementell aufzubauen und die Automation direkt mit zu berücksichtigen. Stellen Sie sicher, dass Sie Werte bieten, während Sie gleichzeitig für die Möglichkeit sorgen, das kontinuierlich zu tun.

Einwand »Wir müssen zwischen Geschwindigkeit und Qualität entscheiden«

Es ist ganz natürlich, davon auszugehen, dass Sie nur dann schnell vorankommen können, wenn Sie Abstriche bei der Qualität machen, und dass Sie nur dann Qualität erhalten, wenn Sie sich langsam bewegen. Sie sehen das vielleicht als Kontinuum (siehe Abbildung 1-1).

Abbildung 1-1: Die Idee, dass sich Geschwindigkeit und Qualität an entgegengesetzten Enden eines Spektrums befinden, ist eine fälschlich angenommene Gegensätzlichkeit.

Die Accelerate-Forschungsdaten, die ich weiter oben erwähnt habe (siehe »Infrastructure as Code nutzen, um für Änderungen zu optimieren« auf Seite 35), zeigen aber etwas anderes:

Diese Ergebnisse zeigen, dass es keinen Kompromiss zwischen dem Verbessern der Performance und dem Erreichen einer besseren Stabilität und Qualität gibt. Stattdessen sind High-Performer bei all diesen Messwerten besser. Das ist genau das, was die Agile- und Lean-Bewegungen predigen, aber ein Glaubenssatz in unserer Branche basiert immer noch auf der falschen Annahme, dass man ein schnelles Vorankommen gegen andere Performance-Ziele abwägen muss, statt alles zu unterstützen und sich gegenseitig verstärken zu lassen.

– Nicole Forsgren, PhD, Accelerate

Kurz gesagt können Organisationen nicht wählen, ob sie entweder Veränderungen oder Stabilität gut hinbekommen. Sie tendieren dazu, entweder in beidem gut oder in beidem schlecht zu sein.

Ich ziehe es vor, Qualität und Geschwindigkeit als Quadrant statt als Kontinuum zu betrachten,1 wie in Abbildung 1-2 zu sehen ist.

Abbildung 1-2: Geschwindigkeit und Qualität auf Quadranten abgebildet

Dieses Quadrantenmodell zeigt, warum es auf jeden Fall zu Mittelmäßigkeit führen wird, wenn man versucht, zwischen Geschwindigkeit und Qualität zu wählen:

Unterer rechter Quadrant: Geschwindigkeit gegenüber Qualität priorisieren

Das ist die Philosophie »move fast and break things«. Teams, die auf Geschwindigkeit optimieren und dafür die Qualität opfern, schaffen chaotische, fragile Systeme. Sie rutschen in den linken unteren Quadranten, weil sie von ihren schlampigen Systemen ausgebremst werden. Viele Start-ups, die eine Zeitlang so gearbeitet haben, beschweren sich darüber, ihr »Mojo« zu verlieren. Einfache Änderungen, die sie in der guten alten Zeit mal eben rausgehauen hätten, brauchen jetzt Tage oder Wochen, weil das System ein verworrenes Chaos ist.

Oberer linker Quadrant: Qualität gegenüber Geschwindigkeit priorisieren

Auch bekannt als »wir haben es hier mit ernsthaften und wichtigen Dingen zu tun, daher müssen wir es richtig machen«. Der Druck von Deadlines führt dann zu »Workarounds«. Aufwendige Prozesse schaffen Hürden für Verbesserungen, daher wachsen die technischen Schulden zusammen mit der Liste der »bekannten Probleme«. Diese Teams rutschen in den linken unteren Quadranten. Sie landen bei Systemen schlechter Qualität, weil es zu schwer ist, sie zu verbessern. Als Reaktion auf Fehler führen sie noch mehr Prozesse ein. Diese Prozesse machen es noch schwerer, Verbesserungen umzusetzen, und sorgen so für zusätzliche Fragilität und Risiken. Das führt zu mehr Fehlern und mehr Prozessen. Viele Personen, die in so agierenden Organisationen tätig sind, gehen davon aus, dass das normal ist1 – insbesondere, wenn sie in risikosensiblen Branchen unterwegs sind.2

Der obere rechte Quadrant ist das Ziel moderner Ansätze wie Lean, Agile und DevOps. Sich schnell bewegen und ein hohes Qualitätsniveau beibehalten zu können, scheint wie ein Traum zu wirken. Aber die Accelerate-Forschung zeigt, dass viele Teams das erreichen. Daher finden Sie in diesem Quadranten »High Performer«.

Die Four Key Metrics

DORAs Accelerate-Forschungsteam hat vier zentrale Metriken für die Performance der Softwareauslieferung und von Operations identifiziert.3 Dafür wurden diverse Messwerte begutachtet, und es wurde herausgefunden, dass diese vier die stärkste Korrelation dazu haben, wie gut eine Organisation ihre Ziele erreicht:

Auslieferungsdurchlaufzeit

Die Zeit, die erforderlich ist, um Änderungen am Produktivsystem zu implementieren, zu testen und auszuliefern.

Deployment-Häufigkeit

Wie oft Sie Änderungen an Produktivsystemen deployen.

Anteil an Änderungsfehlschlägen

Welcher Prozentsatz an Änderungen entweder einen Service beeinträchtigt hat oder eine sofortige Korrektur erforderte, wie zum Beispiel ein Rollback oder ein Notfall-Fix.

Mean Time to Recovery (MTTR)

Wie lange es dauert, einen Service wiederherzustellen, wenn es einen ungeplanten Ausfall oder eine Beeinträchtigung gibt.

Organisationen, die ihre Ziele gut erreichen – seien es der Umsatz, der Aktienpreis oder andere Kriterien – funktionieren auch gut in Bezug auf diese vier Metriken und umgekehrt. Die Ideen in diesem Buch sollen Ihrem Team und Ihrer Organisation dabei helfen, diese Metriken gut zu erfüllen. Drei zentrale Praktiken für Infrastructure as Code können Sie dabei unterstützen.

Drei zentrale Praktiken für Infrastructure as Code

Das Konzept des Cloud-Zeitalters nutzt die dynamische Natur moderner Infrastruktur- und Anwendungsplattformen aus, um häufig und zuverlässig Änderungen durchführen zu können. Infrastructure as Code ist ein Ansatz, mit dem Sie Infrastruktur bauen, die kontinuierliche Änderungen unterstützt, um eine hohe Zuverlässigkeit und Qualität zu erreichen. Wie kann Ihr Team das schaffen?

Es gibt drei zentrale Praktiken beim Implementieren von Infrastructure as Code:

Definieren Sie alles als Code.

Testen Sie all Ihre aktuelle Arbeit kontinuierlich und liefern Sie sie aus.

Bauen Sie kleine, einfache Einheiten, die Sie unabhängig voneinander austauschen können.

Ich werde jede dieser Thesen nun vorstellen, um den Rahmen für weitere Diskussionen vorzugeben. Im weiteren Verlauf des Buchs werde ich dann jeweils in einem eigenen Kapitel die Prinzipien für das Implementieren dieser drei Praktiken ausführlich erläutern.

Zentrale Praktik: Definieren Sie alles als Code

Es ist eine zentrale Praktik für zügige und zuverlässige Änderungen, alles »als Code« zu definieren. Es gibt dafür ein paar Gründe:

Wiederverwendbarkeit

Definieren Sie etwas als Code, können Sie viele Instanzen davon erzeugen. Sie können Ihre Elemente reparieren und schnell neu bauen, und andere Personen können identische Instanzen des Elements erzeugen.

Konsistenz

Elemente, die aus Code gebaut werden, werden jedes Mal gleich gebaut. Dadurch wird das Verhalten von Systemen vorhersagbar, das Testen zuverlässiger und es werden kontinuierliches Testen und Ausliefern möglich.

Transparenz

Alle können sehen, wie ein Element gebaut wird, indem sie sich den Code anschauen. Die Leute können den Code begutachten und Verbesserungen vorschlagen. Sie können daraus lernen, um Elemente im eigenen Code einzusetzen, Einblicke für das Troubleshooting liefern und zu Compliance-Zwecken Reviews und Audits durchführen.

Ich werde in Kapitel 4 genauer auf die Konzepte und Implementierungs-Prinzipien zum Definieren von Elementen als Code eingehen.

Zentrale Praktik: Kontinuierliches Testen und die gesamte aktuelle Arbeit ausliefern

Effektive Infrastruktur-Teams sind beim Testen rigoros. Sie nutzen Automation, um jede Komponente ihres Systems zu deployen und zu testen, und sie integrieren die gesamte aktuelle Arbeit. Sie testen schon während der Arbeit, statt zu warten, bis sie fertig sind.

Die Idee ist, Qualität einzubauen, statt zu versuchen, die Qualität zu testen.

Dabei wird gerne übersehen, dass dazu das Integrieren und Testen der gesamten aktuellen Arbeit gehört. Bei vielen Teams arbeiten die Entwicklerinnen und Entwickler am Code in eigenen Branches und integrieren erst, wenn sie fertig sind. Laut den Forschungsergebnissen von Accelerate liefern Teams allerdings bessere Ergebnisse, wenn sie ihre Arbeit mindestens täglich integrieren. Zum CI gehört das Mergen und Testen des Codes aller Beteiligten während des Entwickelns. CD geht noch einen Schritt weiter und sorgt dafür, dass der gemergte Code immer bereit für die Produktivumgebung ist.

Details zum kontinuierlichen Testen und Ausliefern von Infrastruktur-Code finden Sie in Kapitel 8.

Zentrale Praktik: Kleine einfache Elemente bauen, die Sie unabhängig voneinander ändern können

Teams bekommen Probleme, wenn ihre Systeme groß und eng gekoppelt sind. Je größer ein System ist, desto schwieriger wird es, es zu ändern, und umso einfacher kann man es zerstören.

Schauen Sie sich die Codebasis eines leistungsfähigen Teams an, sehen Sie den Unterschied. Das System ist aus kleinen, einfachen Elementen aufgebaut. Jedes Element lässt sich leicht verstehen, und es besitzt sauber definierte Schnittstellen. Das Team kann jede Komponente für sich einfach ändern und jede Komponente isoliert deployen und testen.

Genauer gehe ich auf die Implementierungsprinzipien dieser zentralen Praktik in Kapitel 15 ein.

Zusammenfassung

Um etwas aus der Cloud- und Infrastruktur-Automation herauszuholen, benötigen Sie eine Mentalität, die zum Cloud-Zeitalter passt. Sie müssen dafür die Geschwindigkeit ausnutzen, um die Qualität zu verbessern, und Qualität einbauen, um Geschwindigkeit aufzunehmen. Es ist Arbeit, Ihre Infrastruktur zu automatisieren, insbesondere wenn Sie erst lernen, wie Sie das tun können. Aber es hilft Ihnen dabei, Änderungen vorzunehmen – und vor allem, das System überhaupt zu bauen.

Ich habe die Elemente eines typischen Infrastruktur-Systems beschrieben, da diese die Grundlage für die Kapitel legen, in denen erklärt wird, wie Sie Infrastructure as Code implementieren.

Schließlich habe ich drei zentrale Praktiken für Infrastructure as Code beschrieben: Definieren Sie alles als Code, testen und liefern Sie kontinuierlich und bauen Sie kleine Elemente.

KAPITEL 2

Prinzipien der Infrastruktur im Cloud-Zeitalter

In der Eisenzeit der IT waren Rechenressourcen eng mit der physischen Hardware verbunden. Wir haben CPUs, Speicher und Festplatten in einem Gehäuse verbaut, es in einem Rack montiert und mit Switches und Routern verkabelt. Wir haben ein Betriebssystem und Anwendungssoftware installiert und konfiguriert. Wir konnten beschreiben, wo sich ein Anwendungsserver im Datacenter befand: welche Etage, welche Reihe, welches Rack, welcher Slot.

Das Cloud-Zeitalter entkoppelt die Rechenressourcen von der physischen Hardware, auf der sie laufen. Natürlich gibt es die Hardware noch, aber Server, Festplatten und Router verteilen sich darauf. Es gibt keine physikalischen Elemente mehr, denn diese wurden in virtuelle Konstrukte umgewandelt, die wir nach Wunsch erstellen, kopieren, ändern und wieder löschen.

Diese Transformation hat uns dazu gezwungen, unsere Denkweise über Rechenressourcen sowie ihr Design und ihren Einsatz anzupassen. Wir können uns nicht mehr darauf verlassen, dass die physischen Attribute unseres Anwendungsservers konstant sind. Wir müssen Instanzen unserer Systeme ohne großen Aufwand hinzufügen und entfernen können und wir müssen dazu in der Lage sein, die Konsistenz und Qualität unserer Systeme beizubehalten, auch wenn wir sie massiv ausbauen.

Es gibt eine Reihe von Prinzipien zum Designen und Implementieren von Infrastruktur auf Cloud-Plattformen. Diese liefern die Gründe für die drei zentralen Praktiken (definieren Sie alles als Code, testen und liefern Sie kontinuierlich, bauen Sie kleine Einheiten). Ich erwähne auch eine Reihe von Fallstricken, über die Teams mit dynamischer Infrastruktur häufig stolpern.

Diese Prinzipien und Fallstricke bilden die Grundlage für die spezifischen Ratschläge zum Implementieren der Infrastruktur-als-Code-Praktiken in diesem Buch.

Prinzip: Gehen Sie davon aus, dass Systeme unzuverlässig sind

In der Eisenzeit sind wir davon ausgegangen, dass unsere Systeme auf zuverlässiger Hardware laufen. Im Cloud-Zeitalter müssen Sie davon ausgehen, dass Ihre Systeme auf unzuverlässiger Hardware laufen.1

Infrastruktur im Cloud-Maßstab nutzt Hunderttausende Devices, wenn nicht mehr. In dieser Größenordnung kommt es selbst dann zu Ausfällen, wenn Sie zuverlässige Hardware einsetzen – und die meisten Cloud-Anbieter greifen auf günstige, weniger zuverlässige Hardware zurück, überwachen diese und ersetzen sie bei einem Fehler.

Sie werden Teile Ihres Systems aber auch nicht nur offline nehmen müssen, wenn es zu ungeplanten Ausfällen kommt. Sie müssen Patches einspielen und Systeme aktualisieren. Sie werden die Größe anpassen, Last neu verteilen und Probleme analysieren.

Bei statischer Infrastruktur müssen Sie dafür Systeme offline nehmen. Aber in vielen modernen Organisationen heißt das auch, dass damit das Business offline ist.

Sie können also die Infrastruktur, auf der Ihr System läuft, nicht als stabile Grundlage betrachten. Stattdessen müssen Sie so designen, dass ein ununterbrochener Service auch dann möglich ist, wenn sich die zugrunde liegenden Ressourcen ändern.2

Prinzip: Alles reproduzierbar machen

Um ein System wiederherstellbar zu machen, ist eine Möglichkeit, sicherzustellen, dass Sie seine Elemente mühelos und zuverlässig neu bauen können.

Mühelos bedeutet, dass Sie keine Entscheidungen treffen müssen, wie Sie etwas bauen. Sie sollten Elemente wie Konfigurationseinstellungen, Softwareversionen oder Abhängigkeiten als Code definieren. Das erneute Bauen ist dann eine einfache »Ja/Nein«-Entscheidung.

Reproduzierbarkeit erleichtert es nicht nur, ein ausgefallenes System wiederherzustellen, sie hilft Ihnen auch bei Folgendem:

Testumgebungen sind konsistent zur Produktivumgebung.

Systeme lassen sich für eine bessere Verfügbarkeit über Regionen hinweg replizieren.

Instanzen können bei Bedarf hinzugefügt werden, um hohe Lasten abzufedern.

Systeme lassen sich replizieren, um jedem Kunden eine eigene Instanz zu bieten.

Natürlich erzeugt das System Daten, Inhalte und Logs, die Sie nicht im Voraus definieren können. Sie müssen diese identifizieren und Wege finden, sie als Teil Ihrer Replikationsstrategie zu berücksichtigen. Das kann eventuell ganz einfach sein – Daten auf ein Backup kopieren oder streamen und dann beim erneuten Bauen wiederherstellen. Ich beschreibe entsprechende Möglichkeiten in »Datenkontinuität in einem sich ändernden System« auf Seite 430.

Die Möglichkeit, mühelos jeden Teil der Infrastruktur erstmalig oder erneut zu bauen, ist sehr mächtig. Sie nimmt die Risiken und Ängste bei Änderungen, und Sie können Ausfälle zuversichtlich angehen. Neue Services und Umgebungen lassen sich schnell provisionieren.

Fallstrick: Snowflake-Systeme

Eine Snowflake ist eine Instanz eines Systems oder eines Systemteils, die sich nur schwer erneut bauen lässt. Es kann sich auch um eine Umgebung handeln, die anderen Umgebungen möglichst gleichen soll – zum Beispiel eine Staging-Umgebung –, die sich aber auf eine Art und Weise unterscheidet, die vom Team nicht vollständig verstanden wird.

Niemand hat vor, Snowflake-Systeme zu bauen. Sie entstehen einfach ganz natürlich. Wenn Sie mit einem neuen Tool das erste Mal etwas bauen, machen Sie dabei Erfahrungen und auch Fehler. Aber wenn sich die Leute auf das verlassen, was Sie gebaut haben, haben Sie vielleicht nicht die Zeit, einen Schritt zurückzugehen und das Ganze erneut zu bauen und dabei zu verbessern oder die gemachten Erfahrungen einfließen zu lassen. Es ist besonders schwer, schon gebaute Elemente zu verbessern, wenn Sie nicht die Mechanismen und Praktiken verfügen, die Änderungen einfach und sicher machen.

Ein weiterer Grund für Snowflakes besteht darin, dass Entwicklerinnen und Entwickler Änderungen an nur einer Instanz eines Systems machen, die anderen Instanzen aber unverändert bleiben. Vielleicht stehen sie gerade unter dem Druck, ein Problem zu beheben, das nur in einem System auftaucht, oder sie beginnen mit einem großen Upgrade in einer Testumgebung, haben aber nicht mehr die Zeit, es in andere Umgebungen auszurollen.

Sie wissen, dass ein System eine Snowflake ist, wenn Sie nicht davon ausgehen können, es sicher zu ändern oder zu aktualisieren. Schlimmer noch: Wenn das System ausfällt, wird es schwer, es zu reparieren. Daher vermeidet man, solch ein System zu ändern, wodurch es veraltet, keine Patches mehr bekommt und vielleicht sogar teilweise nicht mehr nutzbar ist.

Snowflake-Systeme sorgen für Risiken und verschwenden die Zeit der Teams, die sie betreuen. Es lohnt sich fast immer, sie durch reproduzierbare Systeme zu ersetzen. Lohnt es sich nicht, ein Snowflake-System zu verbessern, ist es es vielleicht auch nicht wert, es überhaupt noch zu behalten.

Am besten ersetzen Sie ein Snowflake-System, indem Sie Code schreiben, der das System replizieren kann, und das neue System parallel laufen lassen, bis es bereit ist. Nutzen Sie automatisierte Tests und Pipelines, um zu zeigen, dass das System korrekt und reproduzierbar ist, dann können Sie es leicht anpassen.

Prinzip: Erstellen Sie wegwerfbare Elemente

Es ist eine Sache, ein System zu bauen, das mit dynamischer Infrastruktur umgehen kann. Es ist aber etwas ganz anderes, ein System zu bauen, das selbst dynamisch ist. Sie sollten die Teile Ihres Systems elegant hinzufügen, entfernen, starten, stoppen, ändern und bewegen können. Das schafft operationelle Flexibilität, Verfügbarkeit und Skalierbarkeit. Zudem vereinfacht es Änderungen und reduziert Risiken.

Es ist die zentrale Idee von Cloud-nativer Software, die Elemente Ihres Systems formbar zu gestalten. Die Cloud abstrahiert Infrastruktur-Ressourcen (Rechenleistung, Networking und Storage) von der physischen Hardware. Cloud-native Software entkoppelt die Anwendungsfunktionalität vollständig von der Infrastruktur, auf der sie läuft.1

Vieh statt Haustiere

»Behandeln Sie Ihre Server wie Vieh und nicht wie Haustiere« ist ein beliebter Spruch.2 Ich vermisse es, jedem von mir neu angelegtem Server einen spaßigen Namen zu geben. Ich vermisse es hingegen nicht, jeden Server in unserem Umfeld per Hand zurechtzuzupfen und zu bepuscheln.

Sind Ihre Systeme dynamisch, müssen die Werkzeuge, mit denen Sie sie managen, das berücksichtigen. So sollte Ihr Monitoring nicht jedes Mal einen Alert ausgeben, wenn Sie Teile Ihres Systems umbauen. Aber es sollte Sie warnen, wenn etwas in einer Endlosschleife immer wieder neu gebaut wird.

Der Fall des verschwundenen Dateiservers

Manche Entwicklerinnen und Entwickler können eine Weile brauchen, um sich an flüchtige Hardware zu gewöhnen. Ein Team, mit dem ich zusammenarbeitete, setzte die Infrastruktur automatisiert mit VMware und Chef auf. Es löschte und ersetzte virtuelle Maschinen nach Bedarf.

Ein neuer Entwickler im Team benötigte einen Webserver, um Dateien zu hosten, die gemeinsam mit Teamkolleginnen und -kollegen genutzt werden sollten. Also installierte er manuell einen HTTP-Server auf einem Entwicklungsserver und schob die Dateien dorthin. Ein paar Tage später habe ich die VM neu gebaut, und sein Webserver verschwand.

Nach einiger Verwirrung verstand der Entwickler, warum das geschehen war. Er ergänzte seinen Webserver im Chef-Code und persistierte seine Dateien auf dem SAN. Das Team besaß nun einen zuverlässigen Service zum gemeinsamen Zugriff auf Dateien.

Prinzip: Variationen minimieren

Wenn ein System wächst, lässt es sich schwerer verstehen, schwerer ändern und schwerer korrigieren. Die Menge an Arbeit wächst mit der Anzahl der Elemente, aber auch mit der Anzahl der verschiedenen Arten von Elementen. Um ein System handhabbar zu halten, ist es daher sinnvoll, nicht zu viele verschiedene Elemente zu haben – um die Variationen gering zu halten. Es ist einfacher, einhundert identische als fünf völlig verschiedene Server zu warten.

Das Prinzip der Reproduzierbarkeit (siehe »Prinzip: Alles reproduzierbar machen« auf Seite 44) ergänzt diese Idee. Definieren Sie eine einfache Komponente und erstellen davon viele identische Instanzen, können Sie sie leicht verstehen, ändern und korrigieren.

Damit das funktioniert, müssen Sie jede Änderung auf alle Instanzen der Komponente anwenden. Denn ansonsten erzeugen Sie Konfigurationsdrift.

Dies sind ein paar Arten von Variationen, die es in Ihren Systemen geben kann:

Mehrere Betriebssysteme, Anwendungs-Runtimes, Datenbanken und andere Technologien. Für jede davon benötigen Sie Personen in Ihrem Team, die sich diesbezüglich auf dem Laufenden halten und Wissen erwerben.

Mehrere

Versionen

einer Software, wie zum Beispiel ein Betriebssystem oder eine Datenbank. Selbst wenn Sie nur ein Betriebssystem nutzen, kann jede Version eine andere Konfiguration und andere Werkzeuge erfordern.

Unterschiedliche Versionen eines Pakets. Haben manche Server eine neuere Version eines Pakets, Tools oder einer Bibliothek als andere, besteht ein Risiko. Vielleicht laufen bestimmte Befehle nicht überall gleich, oder ältere Versionen besitzen Sicherheitslücken oder Bugs.

Organisationen müssen einen Weg finden, es jedem Team zu erlauben, die Technologien und Lösungen zu wählen, die seine Anforderungen erfüllen, gleichzeitig aber die Menge an Variationen in der Organisation auf einem handhabbaren Niveau zu halten.

Lightweight Governance

Moderne, digitale Organisationen lernen den Wert von Lightweight Governance