DevOps & InfrastructureCloud Migration & DeploymentMid-Sized Business

Infrastructure as Code für Teams, die nicht Google sind

Der Grund, Infrastruktur als Code zu beschreiben, ist nicht Skalierung. Es ist, dass sich niemand erinnert, was damals geklickt wurde — und dieses Problem ist im eigenen Serverraum dasselbe wie beim Hyperscaler.

Foto: Google Gemini · AI-generated

Das meiste, was über Infrastructure as Code geschrieben wird, richtet sich an Unternehmen mit tausenden Diensten. Wer vier betreibt, schließt daraus leicht, dass ihn das Thema nicht betrifft.

Dieser Schluss ist falsch — aber aus einem Grund, den die üblichen Argumente übergehen. Im Mittelstand spricht nicht die Skalierung für IaC. Es ist das Gedächtnis.

Die Frage, die IaC wirklich beantwortet

Irgendwo in Ihrer Produktivumgebung steckt eine Einstellung, die jemand vor zwei Jahren um 23 Uhr geändert hat, um ein dringendes Problem zu lösen. Es hat funktioniert. Aufgeschrieben wurde es nie. Diese Person arbeitet womöglich längst woanders.

Rechnen Sie das über ein paar Jahre hoch, und Sie haben eine Umgebung, die niemand mehr vollständig beschreiben kann. Das ist unproblematisch — bis zu dem Tag, an dem Sie sie nachbauen müssen. Eine neue Testumgebung, eine Migration, ein ausgefallener Server, ein Prüfer, der wissen will, was eigentlich läuft.

IaC macht aus der Antwort auf “was läuft in Produktion” eine Datei, die man lesen kann, statt einer Rekonstruktion aus Erinnerung und Screenshots. Dieser Wert hängt nicht an der Anzahl der Dienste. Eine einzige Umgebung, die niemand nachbauen kann, ist bereits das Problem.

Kein Thema nur für Hyperscaler

Meist wird angenommen, das sei ein Cloud-Thema, und zwar eines der großen Anbieter. Ist es nicht.

Das Einkaufsportal, das wir für einen Maschinenbauer gebaut haben, läuft on premises — mit definierter und automatisierter Infrastruktur und Auslieferung statt handkonfigurierter Server. Das Nachunternehmerportal für einen Bauunternehmer läuft aus Gründen der Datenhaltung in einer privaten deutschen Cloud, mit derselben Disziplin.

Beides sind keine Hyperscaler-Installationen. Beide profitieren von genau demselben: Die Umgebung ist woanders beschrieben als im Kopf eines Kollegen. Außerhalb der großen Clouds wiegt das Argument eher schwerer, denn dort gibt es keine verwaltete Konsole, die sich Ihre Konfiguration stillschweigend für Sie merkt.

Der Cargo-Kult

Schiefgehen kann das für kleinere Teams vor allem so: Man kopiert das Werkzeug von Unternehmen, die ein Plattformteam haben — ohne eines zu haben.

Kubernetes, weil ein Konferenzvortrag es nahelegte. Ein Service Mesh für sechs Dienste. Eine Modulstruktur, entworfen für fünfzig Entwickler, gepflegt von dreien. Das Ergebnis ist eine Infrastruktur, die nun komplex und fremd ist. Sie haben ein zweites System zu verstehen dazugewonnen, und das ursprüngliche Problem besteht weiter.

Der ehrliche Test ist nicht, ob Ihr Aufbau dem eines Tech-Konzerns ähnelt. Er lautet: Könnte eine fähige Person, die letzten Monat angefangen hat, aus dem Repository eine funktionierende Umgebung hochziehen, ohne jemanden zu fragen? Wenn ja, haben Sie genug. Wenn nein, hilft auch kein modisches Werkzeug.

Genug, ungefähr in dieser Reihenfolge

Für ein mittelständisches Unternehmen ist der sinnvolle Weg unspektakulär und kurz.

Beginnen Sie mit der Umgebungsdefinition — Server, Netze und Dienste in der Versionsverwaltung beschrieben. Dann die Auslieferung, damit ein Release ein Pipelinelauf ist und keine Person, die eine Checkliste abarbeitet. Dann die Konfiguration, damit der Unterschied zwischen Umgebungen in einer Datei steht und nicht in mündlicher Überlieferung. Dann die Überwachung, denn eine Umgebung, die man nachbauen, aber nicht beobachten kann, ist nur halb gelöst.

Sie dürfen aufhören, sobald es wiederholbar ist. Fürs Weitermachen gibt es keinen Preis.

Was es an einem schlechten Tag einbringt

Der Nutzen zeigt sich nicht an guten Tagen. Deshalb ist er schwer zu budgetieren.

Bei CarLicence — einer Echtzeit-API für Zulassungsverlängerungen, die Partner in eigene Websites, Apps und Geldautomaten einbinden — deckt das Team Entwicklung, Cloud-Infrastruktur und DevOps gemeinsam ab: CI/CD, Umgebungsverwaltung, Produktionsüberwachung. Es kommen laufend neue Integrationspartner dazu. Keiner davon ist ein Ereignis, weil das Aufsetzen und Ändern von Umgebungen Routine ist und kein Vorgang, an dessen Ablauf sich jemand erinnern muss.

Mehr ist der Ertrag nicht. Keine Eleganz, keine Ähnlichkeit mit einem Hyperscaler. Nur weniger Tage, an denen auf “können wir das nachbauen” ein langes Schweigen folgt.

Wenn Ihre Produktivumgebung nur im Kopf einer Person existiert, sprechen wir darüber.