Handbuch Infrastructure as Code

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...