Fußnoten

Vorwort

1So ist es beispielsweise vielen Regierungsorganisationen und Finanzunternehmen in Ländern ohne vorhandene Cloud gesetzlich untersagt, Daten oder Transaktionen im Ausland zu hosten.

2Die von DORA im State of DevOps Report (https://oreil.ly/ysk9n) veröffentlichten Forschungsergebnisse zeigen, dass schwergewichtige Änderungsmanagement-Prozesse mit einer schlechten Performance bei Änderungsfehlerraten und anderen Messwerten mit Bezug zur Effektivität von Software Delivery korrelieren.

1Es gibt auch im Sommer 2020 immer noch den ursprünglichen Inhalt auf dieser Site, allerdings hat sich seit 2007 nichts mehr darauf getan.

Kapitel 1: Was ist Infrastructure as Code?

1Das steht im Gegensatz zu dem, was die gleichen Personen ein paar Jahre zuvor gesagt haben, nämlich dass Software »nicht Teil unseres Kerngeschäfts ist«. Nachdem sie diesem Ratschlag gefolgt sind und ihre IT outgesourced haben, stellten die Organisationen fest, dass diejenigen an ihnen vorbeizogen, die bessere Software als Wettbewerbsvorteil und nicht als Kostenersparnis ansahen.

2Laut (englischsprachiger) Wikipedia (https://oreil.ly/IkDu_) kann es einen Reifenbrand in zwei Ausprägungen geben: »Schnell brennende Ereignisse, die fast sofort dazu führen, dass das Feuer außer Kontrolle gerät, und langsam brennende Pyrolyse, die sich mehr als ein Jahrzehnt hinziehen kann.«

1Mit »Cowboy-IT« meine ich Leute, die IT-Systeme ohne eine Vorgehensweise oder Überlegung hinsichtlich der Konsequenzen in der Zukunft bauen. Meist wählen Personen, die noch nie Produktivsysteme betreut haben, den einfachsten Weg, um etwas zum Laufen zu bekommen, ohne auf Sicherheit, Wartbarkeit, Performance und andere Operability-Aspekte zu achten.

1Gene Kim, George Spafford und Kevin Behr schreiben in The Visible Ops Handbook (IT Process Institute), dass Änderungen für 80 Prozent der ungeplanten Ausfälle verantwortlich sind.

2Die Berichte aus der Accelerate-Forschung finden sich im jährlich erscheinenden State of DevOps Report (https://oreil.ly/0Q3FE) und im Buch Accelerate von Dr. Nicole Forsgren, Jez Humble und Gene Kim (IT Revolution Press).

1Ja, ich arbeite als Berater, warum fragen Sie?

1Das ist ein Beispiel für die »Normalisierung der Abweichung« – die Menschen gewöhnen sich an eine Arbeitsweise, die das Risiko ansteigen lässt. Diane Vaughan hat diesen Begriff in The Challenger Launch Decision (University of Chicago Press) definiert.

2Es ist ironisch (und beängstigend), dass so viele Mitarbeiterinnen und Mitarbeiter in Branchen wie dem Finanzwesen, in Regierungen und in der Gesundheitsversorgung fragile IT-Systeme – und Prozesse, die deren Verbesserung behindern – als normal, ja sogar als wünschenswert ansehen.

3DORA, jetzt Teil von Google, ist das Team hinter dem Accelerate State of DevOps Report (https://oreil.ly/ysk9n).

Kapitel 2: Prinzipien der Infrastruktur im Cloud-Zeitalter

1Ich habe die Idee aus Sam Johnsons Artikel »Simplifying Cloud: Reliability« (https://oreil.ly/S3VRT) übernommen.

2Das Prinzip, davon auszugehen, dass Systeme unzuverlässig sind, ist eine Grundlage für das Chaos Engineering (https://oreil.ly/7fvio), bei dem Fehlfunktionen unter kontrollierten Bedingungen injiziert werden, um die Zuverlässigkeit Ihrer Services zu testen und zu verbessern. Ich gehe darauf in »Chaos Engineering« auf Seite 427 ein.

1Siehe »Cloud-native und anwendungsgesteuerte Infrastruktur« auf Seite 190.

2Ich habe das erstmals in Gavin McCances Präsentation »CERN Data Centre Evolution« (https://oreil.ly/cDt47) gehört. Randy Bias bezieht sich auf Bill Bakers Präsentation »Architectures for Open and Scalable Clouds« (https://oreil.ly/_SG96). Beide Präsentationen sind ausgezeichnete Einführungen in diese Prinzipien.

1ShopSpinner ist eine fiktive Firma, die es Unternehmen erlaubt, Online-Stores aufzusetzen und zu betreiben. Ich werde sie im Buch nutzen, um Konzepte und Praktiken zu illustrieren.

1Water Works schickt Ihnen jeden Monat Flaschen mit Craft-Wasser von einem anderen Anbieter.

2Servermaker ist ein fiktives Tool zur Serverkonfiguration, das wie Ansible, Chef oder Puppet einsetzbar ist.

3Palace Pens verkauft die weltweit schönsten Luxus-Schreibutensilien.

1Mein Kollege Florian Sellmayr sagt: »Wenn es wert ist, dokumentiert zu werden, ist es auch wert, automatisiert zu werden.«

Kapitel 3: Infrastruktur-Plattformen

1Das US National Institute of Standards and Technology (NIST) hat unter https://oreil.ly/U8qkE eine ausgezeichnete Definition von Cloud Computing bereitgestellt.

2So definiert das NIST IaaS: »Dem Konsumierenden wird die Möglichkeit geboten, Processing, Storage, Netzwerke und andere grundlegende Rechenressourcen zu provisionieren, auf dem der Konsumierende beliebige Software deployen und ausführen kann – wozu auch Betriebssysteme und Anwendungen gehören können. Der Konsumierende verwaltet oder steuert nicht die zugrunde liegende Cloud-Infrastruktur, hat aber Kontrolle über Betriebssysteme, Storage und deployte Anwendungen – und möglicherweise eine begrenzte Kontrolle über ausgewählte Netzwerkkomponenten (zum Beispiel Host-Firewalls).«

1Es gibt schon seit den 1960ern Virtualisierungs-Technologien, aber in der Mainstream-Welt der x86er-Server kamen sie erst in den 2000ern an.

2Ich kann Azure DevOps nicht erwähnen, ohne darauf hinzuweisen, wie furchtbar dieser Name für einen Service ist. Bei DevOps geht es vor allem um die Kultur, nicht um Tools und Technologie. Lesen Sie dazu Matt Skeltons Review (https://oreil.ly/YZQ4j) von John Willis Vortrag über DevOps-Kultur (https://oreil.ly/BFQDd).

1Ein Anwendungshosting-Cluster sollte nicht mit einer PaaS verwechselt werden. Diese Art von Cluster kümmert sich um das Provisionieren von Computing-Ressourcen für Anwendungen, was eine der Kernfunktionen einer PaaS ist. Aber eine vollständige PaaS bietet noch eine ganze Reihe zusätzlicher Services, die über reine Rechenleistung hinausgehen.

1Network File System (https://oreil.ly/OLv7D), Andrew File System (https://oreil.ly/c8nh3) und Server Message Block (https://oreil.ly/DEXyZ).

1Google dokumentiert seinen Ansatz bezüglich Zero-Trust (auch als Perimeterless bekannt) mit dem BeyondCorp-Sicherheitsmodell (https://oreil.ly/0Zonv).

Kapitel 4: Zentrale Praktik: Definieren Sie alles als Code

1Damit der Kontext sinnvoll nutzbar ist, müssen die Entwicklerinnen und Entwickler auch hilfreiche Commit-Messages schreiben.

1»Seit Kurzem« bezieht sich auf Mitte 2020.

2Manchmal beziehe ich mich auf imperativen Code oder imperative Sprachen als programmierbar, auch wenn das nicht der exakteste Begriff ist, aber er ist intuitiver als »imperativ«.

1Ich verwende diese Pseudocode-Sprache, um die Konzepte zu illustrieren, die ich erläutern möchte, ohne sie an ein bestimmtes Tool zu binden.

1Martin Fowler und Rebecca Parsons definieren in ihrem Buch Domain-Specific Languages (Addison-Wesley Professional, https://oreil.ly/hlyHx) eine DSL als »kleine Sprache, die sich auf einen bestimmten Aspekt eines Softwaresystems konzentriert«.

1Sie können in Ihre Chef-Recipes imperativen Ruby-Code einbauen, aber das wird schnell unübersichtlich. Chef interpretiert Recipes in zwei Phasen – erst wird der Ruby-Code kompiliert, dann wird er ausgeführt, um Änderungen am Server vorzunehmen. Prozeduraler Code wird normalerweise in der Kompilierungsphase ausgeführt. Damit wird Chef-Code, in dem prozeduraler und imperativer Code vermischt werden, schwer verständlich. Imperativer Code ist andererseits nützlich, wenn man Chef-Provider schreibt, bei denen es sich um eine Art Bibliothek handelt. Damit wird die Idee unterstützt, dass eine imperative Sprache gut für Bibliothekscode einsetzbar ist, während eine deklarative Sprache zur Definition von Infrastruktur geeignet ist.

2Integrated Development Environment, ein spezialisierter Editor für Programmiersprachen.

1Der Begriff Design Smell leitet sich vom Code Smell ab (https://oreil.ly/meMKB). Ein »Smell« ist eine von Ihnen beobachtete Charakteristik eines Systems, die darauf hindeutet, dass es ein tieferliegendes Problem gibt. Im obigen Beispiel hat der Code, der deklarative und imperative Konstrukte vermischt, einen Smell. Dieser Smell weist darauf hin, dass Ihr Code eventuell versucht, mehrere Dinge auf einmal zu tun. Dann ist es besser, diese Dinge in unterschiedliche Codeteile abzutrennen – vielleicht in unterschiedlichen Sprachen.

Kapitel 5: Infrastruktur-Stacks als Code bauen

1Nein, das ist tatsächlich keine öffentliche IP-Adresse.

1Charity Majors (https://oreil.ly/8KcSk) hat den Begriff Explosionsradius beziehungsweise Blast Radius im Rahmen von Infrastructure as Code bekannt gemacht. Ihr Post »Terraform, VPC, and Why You Want a tfstate File Per env« (https://oreil.ly/pWONA) beschreibt den Wirkungsbereich von potenziellem Schaden, den eine gegebene Änderung in Ihrem System auslösen kann.

1Siehe »Microservices« von James Lewis (https://oreil.ly/NRoab).

2Siehe »The Art of Building Autonomous Teams« von John Ferguson Smart (https://oreil.ly/cKcgK), wo sich auch weitere Referenzen finden.

1Zum Beispiel immutable Server (siehe »Pattern: Immutable Server« auf Seite 234).

Kapitel 6: Umgebungen mit Stacks bauen

1Charity Majors hat ihre schmerzhaften Erfahrungen bei der Arbeit mit einem Multiple-Environment Stack in einem Blog-Post beschrieben (https://oreil.ly/pWONA).

Kapitel 7: Stack-Instanzen konfigurieren

1Beispiele für solche Tools, die von Teams genutzt werden können, um Passwörter sicher gemeinsam zu verwenden, sind GPG (https://gnupg.org), KeePass (https://keepass.info), 1Password (https://1password.com/teams), Keeper (https://keepersecurity.com) und LastPass (https://www.lastpass.com/).

1Consul ist ein Produkt von HashiCorp, die ebenfalls für Terraform verantwortlich sind. Und natürlich arbeiten beide Produkte sehr gut zusammen. Aber Consul wurde als unabhängiges Tool erstellt und wird auch weiterhin so betreut, und Sie brauchen Terraform nicht, um damit zu arbeiten. Darum zähle ich es zu den allgemein nutzbaren Registry-Produkten.

1In »Private Infrastruktur-Instanzen« auf Seite 391 beschreibe ich genauer, wie man lokal an Stack-Code arbeiten kann.

2Deren Einsatz beschreibe ich in »Infrastruktur-Delivery-Pipelines« auf Seite 152.

Kapitel 8: Zentrale Praktik: Kontinuierlich testen und ausliefern

1Siehe »Continuous Integration« von Martin Fowler (https://oreil.ly/Gck3D).

2Das Buch Continuous Delivery von Jez Humble und David Farley (Addison-Wesley) hat die Prinzipien und Praktiken für CD definiert und aus einer obskuren Phrase im Agilen Manifest zu einer weitverbreiteten Praktik unter Software-Delivery-Teams gemacht.

1Siehe »Aus der Eisenzeit in das Cloud-Zeitalter« auf Seite 33.

1Auf der Website von Mountain Goat Software (https://oreil.ly/DEG5M) finden Sie eine Beschreibung von agilen Stories.

2Die Accelerate-Forschung hat im jährlichen State of DevOps Report (https://oreil.ly/ysk9n) Ergebnisse veröffentlicht, dass Teams, bei denen alle ihren Code mindestens täglich mergen, effektiver sind als Teams, die das seltener tun. In den mir bekannten effektiveren Teams übermitteln Entwicklerinnen und Entwickler ihren Code mehrmals am Tag – manchmal sogar stündlich.

1Auf Jez Humbles Website https://continuousdelivery.com finden Sie mehr zu CD-Pattern.

1Meine Kollegin Sarah Taraporewalla hat den Begriff CFR geprägt, um hervorzuheben, dass die funktionsübergreifenden Anforderungen nicht von denen der Entwicklungsarbeit als getrennt zu betrachten sind, sondern dass sie auf die gesamte Arbeit anwendbar sind. Werfen Sie auch einen Blick auf ihre Website (https://oreil.ly/J75na).

1Siehe Perryn Fowlers Post (https://oreil.ly/HIv5b) für eine Erklärung zum Schreiben von Given/When/Then-Tests.

1Martin Fowlers Bliki »Mocks Aren’t Stubs« (https://oreil.ly/SvTx1) ist eine nützliche Referenz für Test-Doubles.

2Beispiele für Cloud-Mocking-Tools und Bibliotheken sind Localstack (https://oreil.ly/8Quwj) und moto (https://oreil.ly/VEWnf). Do Better As Code (https://oreil.ly/LGaYA) enthält eine aktuelle Liste mit solchen Tools.

1»The Practical Test Pyramid« von Ham Vocke (https://oreil.ly/oV266) ist dazu eine umfassende Referenz.

1Siehe die Definition von Unit Tests auf extremeprogramming.org (https://oreil.ly/EoSH6). Martin Fowlers Bliki-Definition von UnitTest (https://oreil.ly/kW14x) behandelt ein paar Wege, über Unit Tests nachzudenken.

1Sam Newman hat das Konzept von Build Pipelines in einer Reihe von Blogposts beschrieben – beginnend 2005, zusammengefasst in einem Blogpost aus dem Jahr 2009 »A Brief and Inclomplete History of Build Pipelines« (https://oreil.ly/hm75g). Das Buch Continuous Delivery von Jez Humble und Dave Farley (siehe weiter oben in diesem Kapitel) hat Pipelines bekannt gemacht. Jez hat das Deployment-Pipeline-Pattern auf seiner Website (https://oreil.ly/lGvIn) dokumentiert.

1Ich möchte aus Gründen der Transparenz darauf hinweisen, dass GoCD von meinem Arbeitgeber ThoughtWorks gebaut wurde. Zunächst war es ein kommerzielles Produkt, aber jetzt ist es vollständig Open Source.

2Trotz seines Namens ist ConcourseCI rund um Pipelines und nicht um CI-Jobs entworfen.

1Diese Gruppen waren: Change Management, Information Security, Risk Management, Service Management, Transistion Management, System Integration Testing, User Acceptance und das Technical Governance Board.

1Auch wenn sie oft gemeinsam mit Monitoring betrachtet wird, geht es bei Observaibility darum, den Leuten die Möglichkeit zu bieten, zu verstehen, was in Ihrem System geschieht. Siehe dazu »Introduction to Observability« von Honeycomb (https://oreil.ly/OVXNF).

Kapitel 9: Infrastruktur-Stacks testen

1Diese Pipeline ist viel einfacher als das, was Sie in der Realität nutzen würden. Vermutlich hätten Sie mindestens eine Stage zum gemeinsamen Testen von Stack und Anwendung (siehe »Infrastruktur und Anwendungen ausliefern« auf Seite 356). Vielleicht würden Sie auch eine Customer-Acceptance-Testing-Stage vor jeder Produktiv-Stage der Kunden benötigen. Zudem fehlen Governance- und Approval-Stages, was in vielen Organisationen erforderlich ist.

1Der Begriff lint (https://oreil.ly/jul6X) entstammt einem klassischen Unix-Tool, das C-Quellcode analysiert.

1Vagrant (https://www.vagrantup.com) ist sehr nützlich für das gemeinsame Verwenden von Konfigurationen für virtuelle Maschinen in einem Team.

Kapitel 10: Anwendungs-Laufzeitumgebungen

1Die Cloud Native Computing Foundation (https://www.cncf.io) hat sich zum Ziel gesetzt, Standards für diesen Bereich zu definieren.

1Docker (https://oreil.ly/bJt9-) ist das dominierende Container-Format. Zu den Alternativen zählen unter anderem CoreOS rkt (https://coreos.com/rkt) und Windows Containers (https://oreil.ly/2uxgp).

1Also vor weniger als zehn Jahren.

2Borg ist Googles internes und proprietäres Cluster-Management-System, das im Artikel »Large-Scale Cluster Management at Google with Borg« (https://oreil.ly/yA8nV) beschrieben ist.

1DBDeploy hat diesen Stil der Datenbank-Schema-Migration zusammen mit Ruby on Rails (https://oreil.ly/AG1no) bekannt gemacht. Aber das Projekt wird zurzeit nicht gewartet.

1Mehr zu entsprechenden Strategien und Techniken finden Sie in »Evolutionary Database Design« von Pramod Sadalage (https://oreil.ly/HCuqr), Refactoring Databases von Scott Ambler und Pramod Sadalage (https://oreil.ly/ta6pb, Addison-Wesley Professional) und Database Reliability Engineering von Laine Campbell und Charity Majors (https://oreil.ly/2wTKaxq, O'Reilly).

1Ein typisches Beispiel für eine »primitive DNS-Implementierung« sind Organisationen, die Teams keinen Zugriff zum Ändern von DNS-Einträgen ermöglichen. Das geschieht meist, wenn die Organisation keine modernen Automations- und Governance-Prozesse besitzt, die einen solchen Zugriff sicher ermöglichen.

1Die Dokumentation für HashiCorp Consul (https://oreil.ly/z4fNG) erläutert, wie ihre Sidecars kommunizieren.

2Meine Kollegen haben Bedenken bezüglich der Tendenz geäußert, Business-Logik in API-Gateways zu zentralisieren. Im Artikel »Overambitious API Gateways« (https://oreil.ly/aqA2q) im ThoughtWorks Technology Radar finden Sie mehr dazu.

Kapitel 11: Server als Code bauen

1Es hätte wirklich zu den Leuten bei Chef gepasst, wenn sie eine Rolle dort als Hat bezeichnet hätten, sodass sie über Server reden könnten, die einen Chef Hat tragen. Zum Glück haben sie das nicht getan.

1Vielleicht erinnern Sie sich an Kapitel 4 und daran, dass es sich bei Servermaker um ein fiktives Tool zur Serverkonfiguration handelt, das Ansible, Chef und Puppet ähnelt.

1Oft muss man eine Funktionstaste beim Starten des Servers drücken, damit er PXE zum Booten eines Netzwerk-Image verwendet. Das kann unbeaufsichtigt zu einem Problem werden. Aber viele Hardware-Anbieter bieten eine »Lights-Out Management«-(LOM-)Funktionalität (https://oreil.ly/N-85U), die diesen Schritt aus der Ferne ermöglicht.

Kapitel 12: Änderungen an Servern managen

1Als Beispiel können Sie sich die Option --splay des Chef-Clients anschauen (https://oreil.ly/MH-54).

1Mein Kollege Peter Gillard-Moss und mein früherer Kollege Ben Butler-Cole haben immutable Server bei ihrer Arbeit an der Mingle-SaaS-Plattform von ThoughtWorks (http://thght.works/1Vw3GY8) verwendet.

2Es gab Proteste, dass der Ansatz immutabler Infrastruktur falsch ist, weil gewisse Aspekte von Servern änderbar sind – unter anderem Logs, Speicher und Prozessraum. Dieses Argument entspricht dem Ablehnen des »Serverless Computing«, weil hinter den Kulissen Server zum Einsatz kommen. Die Terminologie ist eine Metapher. Und trotz der Unvollkommenheit der Metapher ist der dadurch beschriebene Ansatz für viele Entwicklerinnen und Entwickler nützlich.

1Ein »Break Glass«-Prozess kann genutzt werden, um in einem Notfall Zugriff mit umfangreicheren Berechtigungen zu erhalten. Der Prozess ist normalerweise sehr sichtbar, um dafür zu sorgen, dass er nicht regelmäßig zum Einsatz kommt. Beginnt man, sich auf einen »Break Glass«-Prozess zu verlassen, sollte das Team untersuchen, für welche Aufgaben er gebraucht wird, und nach Alternativen Ausschau halten, um diese Aufgaben anders erledigen zu können. In Derek A. Smiths Webinar »Break Glass Theory« (https://oreil.ly/GkcM2) finden Sie mehr dazu.

1Amazon dokumentiert das in seiner Instance Reitirement Policy (https://oreil.ly/vSc0J).

2Eine Ausnahme ist das Chaos Engineering, bei dem Sie absichtlich Ausfälle erzeugen, um die Wiederherstellbarkeit zu zeigen. Siehe »Chaos Engineering« auf Seite 427.

Kapitel 13: Server-Images als Code

1Mehr Informationen zum Security Hardening finden Sie unter »Proactively Hardening Systems Against Intrusion: Configuration Hardening« auf der Tripwire-Website (https://oreil.ly/_ibdW), in »25 Hardening Security Tips for Linux Servers« (https://oreil.ly/XiL0h) und in »20 Linux Server Hardening Tips« (https://oreil.ly/yZUVa).

1Netflix beschreibt seinen Ansatz zum Bauen und Verwenden von AMIs in einem Blog-Posting unter https://oreil.ly/e0_B3.

1FCS ist der fiktive Cloud-Service, der sich an AWS, Azure und anderen in »Dynamische Infrastruktur-Plattform« auf Seite 55 beschriebenen Plattformen orientiert. Ein FSI ist ein Fictional Server Image, ähnlich wie AWS AMI oder Azure Managed Image.

1Siehe Packers chroot-Builder für AWS AMIs (https://oreil.ly/B_FuK) und Azure Server Images (https://oreil.ly/umfU6).

1Zu geskripteten OS-Installern gehören unter anderem Red Hat Kickstart (https://oreil.ly/AsDhQ), Solaris JumpStart (https://oreil.ly/CcETy), Debian Preseed (https://oreil.ly/3_wlN) und das Windows Installation Answer File (https://oreil.ly/UH-5s).

Kapitel 14: Cluster als Code bauen

1Eine Liste zertifizierter Kubernetes-Distributionen finden Sie auf der Kubernetes-Website unter https://oreil.ly/HR9VS.

1In »CF Container Runtime« (https://oreil.ly/Nptwe) finden Sie Details dazu.

1Kubernetes hatte früher Probleme damit, dass die Management-API ohne Authentifizierung genutzt werden konnte. Halten Sie sich an entsprechende Erläuterungen (https://oreil.ly/Uw4Zh), um sicherzustellen, dass Sie Maßnahmen zum Absichern Ihres Clusters ergreifen, und schreiben Sie Tests, um Code- und Konfigurationsänderungen zu stoppen, die unbeabsichtigt Angriffsvektoren öffnen.

1Rob Hirschfeld hat die Vor- und Nachteile von Clustergrößen und der gemeinsamen Verwendung in seinem Artikel »The Optimal Kubernetes Cluster Size? Let’s Look at the Data« (https://oreil.ly/8NUDP) betrachtet.

1Mehr dazu finden Sie in Mike Roberts maßgeblichem Artikel »Serverless Architectures« (https://oreil.ly/wHE-5).

Kapitel 15: Zentrale Praktik: Kleine, einfache Elemente

1Das DRY-Prinzip finden Sie zusammen mit anderen Prinzipien in The Pragmatic Programmer: From Journeyman to Master von Andrew Hunt und David Thomas (Addison-Wesley).

1Die Regel des Zusammenbaus ist eine der grundlegenden Regeln der Unix-Philosophie (https://de.wikipedia.org/wiki/Unix-Philosophie).

2Mein Kollege James Lewis wendet das SRP auf die Frage an, wie groß ein Microservice sein sollte (https://oreil.ly/tPf8f). Er rät, dass eine Komponente konzeptionell in Ihren Kopf passen sollte, was sowohl für Infrastruktur- wie auch für Softwarekomponenten gilt.

1Siehe Kapitel 4 in Building Evolutionary Architectures von Neal Ford, Rebecca Parsons und Patrick Kua (O’Reilly).

1Michael Feathers hat den Begriff Seam in seinem Buch Effektives Arbeiten mit Legacy Code (mitp) eingeführt. Weitere Informationen finden Sie auch online unter https://oreil.ly/Y4EwT.

1Die vollständige Definition lautet: » Organisationen, die Systeme entwerfen, […] sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.«

1Sie sollten ein Zero-Trust-Modell gegenüber rein perimeterbasierten Sicherheitsmodellen vorziehen (siehe »Zero-Trust-Sicherheitsmodell mit SDN« auf Seite 61).

Kapitel 16: Stacks aus Komponenten bauen

1Während ich das in den 2020er-Jahren schreibe, entwickeln die Tool-Anbieter ihre Strategien rund um die verschiedenen Sprachtypen weiter. Ich hoffe, dass sich das Aufteilen von Stacks in den nächsten Jahren zu einer runden Sache entwickeln wird.

1Die Rule of Three wurde in Robert Glass’ Buch Facts and Fallacies of Software Engineering (Addison-Wesley) definiert. Jeff Atwood hat dazu auch etwas in seinem Post »The Delusion of Reuse and the Rule of Three« angemerkt (https://oreil.ly/TBkQC).

1Siehe Domain-Driven Design: Tackling Complexity in the Heart of Software von Eric Evans (Addison-Wesley).

Kapitel 17: Stacks als Komponenten einsetzen

1In »Live-Infrastruktur ändern« auf Seite 415 stelle ich weniger disruptive Wege für solche Änderungen vor.

1Siehe den AWS CDK Developer Guide (https://oreil.ly/jWSJG).

Kapitel 18: Infrastruktur-Code organisieren

1Facebook, Google und Microsoft nutzen alle sehr große Repositories. Alle drei haben entweder eigene Änderungen an ihrer Versionsverwaltungs-Software vorgenommen oder gleich ihre eigene gebaut. In »Scaling version control software« (https://oreil.ly/2KBk8) finden Sie mehr dazu. Und »Scaled trunkbased development« von Paul Hammant (https://oreil.ly/Dc21t) liefert Einblicke in die Geschichte von Googles Vorgehen.

1Die Fragen – und Patterns – rund um den Zeitpunkt des Integrierens von Projekten sind für das Integrieren von Anwendungen und Infrastruktur relevant. Mehr dazu finden Sie in »Projekte integrieren« auf Seite 368.

1Siehe »Using Migration Scripts in Database Deployment« von Red Gate (https://oreil.ly/S_jbC).

1Wir haben das Expand-and-Contract-Pattern genutzt (https://oreil.ly/RUu61), um Änderungen am Datenbankschema ohne eine Downtime vorzunehmen.

Kapitel 19: Infrastruktur-Code ausliefern

1»Bauen Sie Pakete nur einmal.« Siehe die CD-Patterns von Jez Humble unter https://oreil.ly/yXQ9j.

1Das Fan-In Pattern ähnelt dem Aggregate-Artifact-Pipeline-Pattern (oder ist sogar nur ein anderer Name dafür) (https://oreil.ly/uezro).

Kapitel 20: Team-Workflows

1In Googles »SRE Fundamentals« (https://oreil.ly/-0NXt) finden Sie mehr zu SLOs, SLAs und SLIs.

2Soylent Grün ist ein Lebensmittel im dystopischen Science-Fiction-Klassiker »… Jahr 2022 … die überleben wollen«. Spoiler: »Soylent Grün ist Menschenfleisch!« Meine Rechtsberaterinnen und Rechtsberater haben mir allerdinge geraten, darauf hinzuweisen, dass die geheime Zutat für ein zuverlässiges, automatisiertes IT-System lebende Menschen sind.

1Ich habe einmal mit einer Gruppe einer internationalen Bank zusammengearbeitet, die vier verschiedene Release-Testing-Umgebungen besaß – eine für jede Stage im Release-Prozess. Für jede dieser Umgebungen hat ein Team die Infrastruktur konfiguriert, ein weiteres Team die Anwendung deployt und konfiguriert und ein drittes Team das Ganze getestet. Manchen dieser zwölf Teams war gar nicht bewusst, dass es die entsprechenden anderen Teams gab. Daher wurde nur wenig Wissen weitergegeben, und der Release-Prozess war nicht sehr konsistent.

1Das Buch Value Stream Mapping von Karen Martin und Mike Osterling (McGraw-Hill Education) ist eine gute Referenz.

1Insbesondere in den Kapiteln 8 und 9.

1batect (https://batect.dev) und Dojo (https://oreil.ly/v2V7j) sind Beispiele für Tools, die einen wiederholt einsetzbaren, gemeinsam nutzbaren Container für das Entwickeln von Anwendungen und Infrastruktur bauen.

1Siehe den entsprechenden Abschnitt in Fowlers Artikel »Patterns for Managing Source Code Branches« (https://oreil.ly/xxBYF).

2Fowler beschreibt Integrations-Patterns ebenfalls in seinem Artikel (https://oreil.ly/DRZ2U).

3Mehr finden Sie im Abschnitt zur Integrationshäufigkeit in https://oreil.ly/1I8V3.

1Die Automatisierungs-Verzögerung wirkt sich auch auf andere Arten von Automatisierung aus. Führen Sie beispielsweise Ihre automatisierte Anwendungs-Testsuite nur am Ende eines langen Release-Zyklus aus, werden Sie Tage oder Wochen damit verbringen, sie zu aktualisieren, um sie an die Code-Änderungen anzupassen. Führen Sie die Tests jedes Mal beim Einchecken einer Code-Änderung aus, müssen Sie nur ein paar Änderungen vornehmen, um die Suite wieder mit dem Code abzugleichen, sodass die vollständige Testsuite immer ausführungsbereit ist.

1In »ConfigurationSynchronization« (https://oreil.ly/3KZL4) finden Sie eine frühe Beschreibung dieses Konzepts.

2Ein Phönix-Server (https://oreil.ly/ngW7M) wird häufig neu gebaut, um sicherzustellen, dass der Provisionierungs-Prozess wiederholbar ist. Das lässt sich mit anderen Infrastruktur-Konstrukten erreichen, unter anderem auch mit Infrastruktur-Stacks.

1Auf der Website von O’Reilly (https://oreil.ly/G_cYR) finden Sie Artikel zu Compliance as Code.

1Steve Smith definiert das als das Dual Value Streams Antipattern (https://oreil.ly/FI7ng).

Kapitel 21: Infrastruktur sicher ändern

1Donald G. Reinertsen beschreibt das Konzept der verringerten Batchgröße in seinem Buch The Principles of Product Development Flow (Celeritas Publishing).

1Growing Object-Oriented Software, Guided by Tests von Steve Freeman und Nat Pryce (Addison-Wesley) widmet ein ganzes Kapitel den Walking Skeletons.

2Kent Beck beschreibt Vorgehensweisen für große Änderungen, die in kleinen, sicheren Schritten vorgenommen werden, in seinem Artikel »SB Changes« (https://oreil.ly/NWj5T). Dazu gehören mehrere Schritte – manche räumen den Code auf, um eine Verhaltensänderung vorzubereiten, andere sorgen dann für die eigentliche Verhaltensänderung. Entscheidend ist, dass jede Änderung nur eines von beidem macht, aber nicht beides zugleich.

1KubeCan ist ein weiteres fiktives Produkt, das vom fiktiven ShopSpinner-Team favorisiert wird.

2FKS steht für Fictional Kubernetes Service.

1Solche komplexen Migrations-Szenarien mit Anwendungen, die mit zwei Hosting-Clustern integriert sind, entstehen oft, wenn eine große Landschaft serverbasierter Anwendungen, die in einem Data Center gehostet werden, auf eine cloudbasierte Hosting-Plattform umziehen.

1Die Befehle terraform mv (https://oreil.ly/joJZN) und pulumi state (https://oreil.ly/U--o-) sind zwei Beispiele für Tools, die das Bearbeiten von Stack-Datenstrukturen erlauben.

1Keine Sorge, Furcht wird die lokalen Systeme gefügig machen. (https://www.jedipedia.net/wiki/Wilhuff_Tarkin)

1Recheninstanzen sind seit den frühen Tagen des Cloud-Computing zuverlässiger geworden. Ursprünglich konnten Sie eine AWS-EC2-Instanz nicht herunterfahren und später durchstarten – war sie gestoppt, war sie für immer weg. Die vergängliche Natur der Rechensysteme zwang Cloud-Anwenderinnen und -Anwender dazu, neue Praktiken zu übernehmen, um zuverlässige Services auf unzuverlässiger Infrastruktur betreiben zu können. Das war der Ursprung von Infrastructure as Code, Chaos Engineering und anderen Infrastruktur-Praktiken des Cloud-Zeitalters.

2In »5 Lessons We’ve Learned Using AWS« (https://oreil.ly/_JjnV) aus dem Jahr 2010 lesen Sie von frühen Erkenntnissen beim Bauen hochzuverlässiger Services in Public Clouds im großen Maßstab.

3Diese Definition stammt von der Website »Principles of Chaos« (https://principlesofchaos.org).

1Siehe auch »Failure mode and effects analysis« (https://oreil.ly/RfIpS).