Wer ist schon mal im Datacenter gestanden (oder hat in der Cloud Console rumgeklickt) und hat sich gefragt: „Wer zur Hölle hat das denn jetzt schon wieder geändert?“
Keine Sorge, Sie sind nicht allein. Wir alle kennen das Gefühl, wenn die liebevoll aufgebaute Systemlandschaft plötzlich anfängt, sich wie ein bockiges Maultier zu benehmen, nur weil irgendjemand „mal eben“ was angepasst hat.
Und genau hier liegt der Hund begraben: In der IT, speziell im Bereich der Infrastruktur, herrschen oft Zustände, die man in anderen Ingenieursdisziplinen mit Kopfschütteln quittieren würde. Stellen Sie sich mal vor, ein Bauingenieur würde einfach so „mal eben“ an der Statik einer Brücke rumfuhrwerken, ohne Plan, ohne Kontrolle, ohne irgendwas. Horrorszenario, oder? In der IT ist das aber oft traurige Realität und genau da müssen wir umdenken!
Unser Credo muss lauten: Alles, was keine Daten sind, ist als versioniertes Artefakt zu behandeln. Ob das nun die Konfigurationsdateien für den Webserver sind, die Templates für die Datenbanken oder die Orchestrierungs-Skripte für die Container – alles muss in die Versionskontrolle! (Am besten in Git, denn Git ist quasi der Goldstandard, wenn es um Versionsmanagement geht.)
Daten sind heilig – und werden separat behandelt
Eine Sache ist dabei aber ganz wichtig: Daten sind Daten und Artefakte sind Artefakte. Daten, also die wertvollen Informationen, die die Applikation ausmachen, gehören separat gesichert. Am besten in einem Managed Service, weil man sich dann nicht auch noch um Backup, Replikation und all den anderen Kram kümmern muss. Und natürlich ist dieser Managed Service idealerweise auch Infrastructure-as-Code (IaC) basiert. So schließt sich der Kreis.
Staging ist keine Raketenwissenschaft – aber auch keine Option
Nächster Punkt auf der Agenda: Staging! Wer immer noch in einer Welt lebt, in der es nur „Production“ gibt, der möge bitte einmal kurz aufwachen. Jede ernstzunehmende Workload braucht mindestens zwei Stages: Dev und Prod. Dev zum Spielen, Testen und Ausprobieren, Prod für den Ernstfall, wenn die Kohle verdient wird. Je nach Komplexität der Anwendung können das natürlich auch gerne mehr Stages sein. Hauptsache, es gibt eine klare Trennung zwischen Entwicklung und Produktion. Das ist wie in der Gastronomie: Erst wird in der Testküche rumexperimentiert, bevor das neue Gericht auf die Speisekarte kommt.
Konfiguration als Code – und zwar als Template!
Und wie bekommt man nun die Konfiguration in den Griff? Ganz einfach: Konfigurationsdateien werden zu Templates! Ob nun Container, Instanzen oder klassische Server konfiguriert werden – man definiert Templates in IaC, ScM (Software Configuration Management) oder Orchestrierung. Diese Templates sind natürlich versioniert (Git, hatten wir ja schon). Und der Clou: Die eigentlichen Daten in diesen Templates (Passwörter, Datenbank-URLs, etc.) werden pro Stage externalisiert. Das heißt, für jede Stage (Dev, Prod, usw) gibt es separate Variablen-Dateien (oder ein eigenes Vault, oder was auch immer uns gefällt). Die Möglichkeiten sind da wirklich groß.
Eine IaC Codebase für alle Stages – Weniger ist mehr!
Klar, Struktur ist wichtig, aber wir wollen es ja auch nicht übertreiben mit der Ordnungsliebe. Deshalb: Für jede Workload existiert eine IaC/ScM/Orchestration Codebase! Diese Codebase ist der heilige Gral, der alle Stages bedient. Die Unterschiede zwischen Dev, Prod und Co. werden elegant über variable Overrides gelöst, z.B. mit Terraform und seine tfvars-Dateien.
In dieser einen Codebase werden dann die variablen Konfigurationsbestandteile je Stage per extra File(s) zugeführt. Das hält die Sache schlank, übersichtlich und maximal wartbar. Für jede Stage ein eigenes Repository pflegen – das wäre ja Wahnsinn hoch drei! So aber ist alles schön zentral und trotzdem flexibel. Weniger ist hier definitiv mehr!
Änderungen beginnen unten – immer!
Und jetzt kommt der wichtigste Punkt überhaupt: Änderungen beginnen unten – immer, auch wenn es „eilig ist“. Ja, „eilig“ ist das Lieblingswort von Managern weltweit. Aber es wird noch eiliger, wenn Änderungen direkt in Produktion eingespielt werden und alles in die Hose geht. Deshalb: Änderungen werden getestet und von unten nach oben durch die Stages „promoted“.
Breaking Changes? Kein Problem – mit Plan!
Und was ist mit Breaking Changes an IaC/ScM/Orchestrierung? Auch die sind kein Problem, wenn man sie richtig angeht. Breaking Changes können natürlich Anpassungen der Var-Files nach sich ziehen. Aber das ist alles handhabbar mit Release-Notes und einer Checkliste/Howto. Kommunikation ist hier das A und O.
Fazit: Wer nicht hören will, muss fühlen – und zwar richtig!
Wer sich nicht an diese goldenen Regeln hält, dem droht das Desaster. Und zwar sowohl On-Prem klassisch als auch Cloud-Nativ. Denn glauben Sie mir, das Chaos kennt keine Cloud-Grenzen. Deshalb: Befreien Sie Ihre IT-Infrastruktur vom Chaos und führen Sie die Versionskontrolle als Standard ein. Ihre Nerven (und die Ihrer Kollegen) werden es Ihnen danken!
Deutsch 
English