Infrastructure as Code für Cloud- und DevOps-Teams, von der Werkzeugwahl bis zur Abweichungskontrolle
Die Kluft zwischen Dokumentation und Betrieb
Neue Teammitglieder brauchen bei vielen Teams Wochen, bis ihnen jemand die aktuelle Konfiguration erklären kann. Der Grund: Jede manuelle Änderung an deiner Infrastruktur, über eine Konsole, ein Kommandozeilenwerkzeug oder eine schnelle Lösung unter Zeitdruck, entfernt den tatsächlichen Zustand in der Produktion ein Stück weiter von dem, was irgendwo dokumentiert ist. Bereitstellungen verhalten sich dann in verschiedenen Umgebungen unterschiedlich, und Vorfälle lassen sich kaum reproduzieren.
Auditierbare, wiederholbare Infrastruktur
Sobald jede Ressource als Code in der Versionskontrolle landet und wie Anwendungscode geprüft wird, wird jede Änderung an deiner Infrastruktur nachvollziehbar und reproduzierbar. Änderungen laufen über Pull Requests, und Abweichungen vom festgelegten Zustand – die Drift – werden dabei sichtbar. Ein Rollback wird zum einfachen Zurücksetzen im Code.
Weiterlaufender Betrieb trotz Systemwechsel
Bei roadsurfer, der Vermietungsplattform für Wohnmobile, liefen Alt- und Neusystem während der gesamten Umstellung parallel; das Vermietgeschäft lief währenddessen ungestört weiter. So ein Wechsel zu Infrastructure as Code muss deinen laufenden Betrieb nicht gefährden. Die neue Buchungsplattform ging bereits nach 20 Tagen live.
Komplexität in gewachsenem Infrastruktur-Code
Eine einzige, flache Datei, die mit jeder neuen Ressource unübersichtlicher wird, lässt sich irgendwann kaum leichter warten als der manuelle Ansatz von früher. So sieht die Codebasis bei manchen Teams aus, wenn der Umstieg auf Infrastructure as Code bei dir schon länger zurückliegt.
Terraform, Pulumi oder AWS CloudFormation: Vergleich und Einrichtung
Die Wahl des Werkzeugs richtet sich vor allem nach deinem Cloud-Anbieter und den Sprachpräferenzen deines Teams; was dein Team bereits im Einsatz hat, spielt ebenfalls eine Rolle. Einen von uns bevorzugten Anbieter gibt es dabei nicht. Terraform ist meist der gängigste Ausgangspunkt für Multi-Cloud-Umgebungen oder für Umgebungen, in denen AWS der primäre Anbieter ist.
Pulumi eignet sich für Teams, die ihre Infrastruktur lieber in TypeScript, Python oder Go definieren als in einer eigenen domänenspezifischen Sprache. AWS CloudFormation passt zu AWS-Umgebungen mit tiefer nativer Integration und wenigen externen Abhängigkeiten. Nach der Entscheidung übernehmen wir auch die Einrichtung: Wir richten das gewählte Werkzeug für dein Team ein und binden es in eure bestehenden Arbeitsabläufe ein.
Module für Netzwerk, Rechenleistung, Speicher, Identität und Anwendungsschicht
Wiederverwendbare Bausteine für Netzwerk, Rechenleistung, Speicher, Identität und die Anwendungsschicht halten deine Codebasis erweiterbar und lassen sich über verschiedene Umgebungen hinweg kombinieren. Diese Module sind versioniert und dokumentiert. Jeder Baustein ist einzeln getestet, und dein Team baut ihn bei Bedarf weiter aus.
Zustandsverwaltung mit klaren Leitplanken
Sowohl Terraform als auch Pulumi führen Statusdateien, die den bereitgestellten Zustand der Infrastruktur festhalten. Eine fehlerhafte Verwaltung dieses Zustands zählt zu den häufigsten Ursachen für Infrastruktur-Vorfälle bei der Einführung von Infrastructure as Code. Wir richten dafür Remote-State-Backends mit Sperrfunktionen ein, etwa S3 und DynamoDB bei Terraform, isolieren den Zustand nach Umgebung und Teamgrenzen und legen Workflow-Regeln fest, die überlappende Änderungen verhindern.
Bestehende Infrastruktur nachträglich übernehmen
Der Importprozess läuft schrittweise: Der Zustand wird bei jedem Schritt gegen die tatsächlich laufenden Ressourcen geprüft, während die neue Codebasis parallel zur bestehenden Umgebung entsteht. So wandern bestehende, manuell verwaltete Ressourcen unverändert in deine neue Codebasis, ohne dass dein Betrieb unterbrochen wird. Der Wechsel verläuft als durchgehender, gradueller Übergang, bei dem dein Team jederzeit betriebsbereit bleibt.
Drift-Erkennung, bevor Vorfälle entstehen
Eine kontinuierliche Drift-Erkennung gleicht den im Code deklarierten Zustand fortlaufend mit den tatsächlichen Cloud-Ressourcen ab und meldet jede Abweichung sofort. Diese Abweichung, die Infrastruktur-Drift, entsteht, wenn manuelle Änderungen an der Infrastructure-as-Code-Pipeline vorbeilaufen. Die Berichte fließen direkt in deinen bestehenden Incident-Prozess ein und bleiben damit Teil des Alltagsbetriebs.
Zugangsdaten bleiben außerhalb der Codebasis
Wir binden Secrets Management in deine Infrastructure-as-Code-Pipeline ein – HashiCorp Vault oder, abhängig vom Cloud-Anbieter, den nativen Secret Manager von AWS oder GCP. Dein Infrastruktur-Code selbst enthält damit keine Anmeldeinformationen. Zugangsdaten werden erst zur Anwendungszeit eingespielt, nach Plan rotiert und weder in Statusdateien noch in der Versionskontrolle gespeichert.
Automatisierte Prüfungen vor jedem Produktions-Deploy
Wir binden Infrastrukturänderungen in die bestehenden CI-Werkzeuge deines Teams ein, etwa GitHub Actions, GitLab CI oder Atlantis für Terraform, und richten Schutzmechanismen ein, die ungeprüfte Änderungen von der Produktion fernhalten. Dabei durchläuft jede Infrastrukturänderung denselben Weg wie eine Änderung an deiner Anwendung: Sie wird per Pull Request geplant und beim Zusammenführen angewendet. Automatisierte Richtlinienprüfungen laufen ab, bevor sie deine Produktionsumgebung erreicht.
Kennzahlen aus fünf Kundenprojekten
Diese Ergebnisse stammen aus abgeschlossenen und laufenden Projekten:
DataFlow Group: Bereitstellungen liefen fünfmal schneller, und der manuelle Betriebsaufwand sank um 30 Prozent. Der Automatisierungsgrad der Umgebung erreichte zudem 99 Prozent.
Schuhe.de: Das Backend läuft als serverlose Architektur auf AWS Lambda, SNS, SQS und EventBridge, vollständig in Terraform definiert. Verkehrsspitzen am Black Friday laufen mit voller Leistung durch, und neue Funktionen erscheinen innerhalb weniger Stunden.
Der Banktechnologie-Anbieter der Schweiz: Mehr als 300 Bankanwendungen sind auf Cloud-Kompatibilität geprüft. Eine Multi-Cloud-Grundlage auf Azure und Google Cloud erfüllt dabei die FINMA-Vorgaben zur Datensouveränität, und die tägliche Transaktionsverarbeitung lief während der gesamten Migration ununterbrochen weiter.
roadsurfer: Die neue Buchungsplattform ging nach 20 Tagen live, Buchungen und Umsatz verdoppelten sich innerhalb eines Jahres, die Flotte wuchs um 40 Prozent, und die Seitenladegeschwindigkeit verbesserte sich um 40 Prozent.
commercetools: Die Plattform läuft rund um die Uhr über drei Zeitzonen hinweg, geschützt wird ein annualisiertes Handelsvolumen von mehr als 75 Milliarden US-Dollar.
Deine Umgebung bestimmt die Werkzeugwahl
Es gibt bei uns keinen bevorzugten Anbieter. Terraform, Pulumi oder CloudFormation – wir empfehlen, was zu deiner Umgebung und deinem Team passt.
Bring Struktur und Nachvollziehbarkeit in deine Infrastruktur
Schildere uns deine Cloud-Umgebung, wir finden gemeinsam den Weg zu einer auditierbaren, wiederholbaren Infrastruktur bei laufendem Betrieb.