Programmieren und Skripte erstellen statt implementieren und konfigurieren. Das ist, vereinfacht gesagt, der Unterschied zwischen Infrastructure as Code (IaC) und der bislang üblichen Vorgehensweise beim Konfigurieren von IT-Systemen. «IaC bietet die Möglichkeit, Server, Storage und Netzwerke automatisch und damit auch qualitätsgesichert bereitzustellen», präzisiert Georg Ember, Certified IT Archi­tect - Hybrid Cloud Solutions bei IBM. Eine Schlüsselrolle spielen dabei Ansätze wie Software-defined Data Center (SDDC) oder Software-defined Networking (SDN).

«Software-defined bedeutet, dass wir virtualisierte Hardware-Komponenten als Code definieren können. Und nichts anderes machen wir bei Infrastructure as Code», erklärt Lukas Höfer, Cloud Solutions Architect beim Münchner Be­ratungshaus Consol Software. «Ohne IaC wäre die Cloud, wie wir sie kennen, gar nicht möglich. Denn auch dort läuft im Hintergrund nahezu alles virtualisiert und das Deployment erfolgt mittels wiederholbarer Skripte, um Skalierbarkeit und Stabilität zu erreichen.»

In der Praxis bedeutet dies, dass ein Software-Entwickler oder ein Fachmann aus dem Bereich Operations die IT-Infrastruktur, die eine Anwendung benötigt, in Form von Software definiert. Die Hardware-Anforderungen werden dabei in maschinenlesbarem Code abgebildet. In einem Skript oder Template ist aufgeführt, welche Server, Betriebssysteme, Storage-Ressourcen und Netzwerkverbindungen für eine Applikation bereitgestellt werden müssen. Über Programmierschnittstellen (APIs) spricht der Code diese Ressourcen an und reserviert sie quasi für die Applikationsumgebung. Ein Administrator muss somit nicht von Hand Server, Netzwerk-Switches und Speichersysteme inklusive der dazugehörigen Middleware konfigurieren.

Es gibt drei Stufen von Infrastructure as Code, erläutert Gerald Pfeifer, Chief Technology Officer (CTO) des Software-Unternehmens SUSE:

imperativ (prozedural): eine klassische Schritt-für-Schritt-Beschreibung wie ein Kochrezept

deklarativ: eine Beschreibung des erwünschten Zustands, unabhängig von den erforderlichen Schritten dorthin

intelligent: eine abstrakte Beschreibung von Zielen und Hintergründen.

«Die Entwicklung konzentriert sich derzeit auf die Optimierung deklarativer Methoden und geht verstärkt in Richtung intelligenter Systeme», so Pfeifer.

Um IaC-Vorlagen zu erstellen, können IT-Fachleute auf diverse Werkzeuge, Cloud-Services und Frameworks zurückgreifen. Bei deklarativen Tools und Plattformen wie Terraform, Salt und Puppet legt der User fest, welche IT-Infrastruktur erstellt werden soll. Das Framework ermittelt selbstständig, wie es diese Vorgaben umsetzen kann.

Zu den klassischen imperativen Werkzeugen zählen, neben Lösungen wie Chef und Ansible, Kommandozeilen-Tools, die jedem Administrator und Software-Entwickler vertraut sind. Microsoft bietet beispielsweise für das Konfigurieren von Infrastrukturkomponenten in seiner Azure-Cloud Lösungen an wie Azure CLI (Command Line Interface) und Azure Powershell. Der Fachmann erstellt damit Skripte, die in der vorgegebenen Reihenfolge abgearbeitet werden.

Im Vergleich zu deklarativen Tools kann bei imperativen Werkzeugen der Aufwand steigen, wenn eine IT-Infrastruktur erweitert oder angepasst werden muss, Stichwort Skalierbarkeit. Bei der deklarativen Variante erfolgt das automatisch. Daher gilt es im Vorfeld sorgfältig abzuwägen, welche Anforderungen die Nutzer an eine IT-Infrastruktur stellen und wie oft diese angepasst werden muss. Zudem sollte geprüft werden, ob Skripte weiterverwendet werden sollen, die aus der Zeit vor der Einführung von IaC stammen.

Eine weitere Grundsatzentscheidung betrifft die Art der IaC-Infrastruktur, sprich ob sie variabel (mutable) oder unveränderlich (immutable) sein soll. Der Vorteil des variablen Ansatzes: Eine Entwicklungsabteilung kann beispielsweise die Parameter der IaC-Umgebung an geänderte Anforderungen anpassen, etwa indem sie einen Server mit mehr Rechenleistung oder ein Storage-System mit einer grösseren Speicherkapazität konfiguriert. Doch dies kann dazu führen, dass inkonsistente Versionen einer IT-Infrastruktur entstehen und der Aufwand für die Versionskontrolle steigt.

Daher greifen Anwender vorzugsweise zu einer immu­table IaC-Infrastruktur. Das heisst aber nicht, dass diese inflexibel ist. Denn Infrastructure as Code heisst, dass Nutzer bei Bedarf mit geringem Aufwand eine neue, angepasste Umgebung erstellen können. Bedingung ist, dass das Unternehmen Zugang zu Cloud-Technologien und Ansätzen wie Software-
defined Data Center hat: «IaC setzt die Cloud-Technologie voraus», betont Andreas Jaekel, Head of PaaS Development bei IONOS & Strato. «Wo eine Cloud zum Einsatz kommt, werden mit ziemlicher Sicherheit auch Virtualisierung und Software-defined Networking verwendet.»

Infrastructure as Code ist jedoch nicht einer Public oder Private Cloud vorbehalten. «Ich selbst verwende IaC in einer abgemilderten Form auf meinem Notebook», berichtet beispielsweise Gerald Pfeifer von SUSE. «Es gibt keinen Grund, IaC auf eine Public Cloud zu beschränken.» Jede Infrastruktur im IT-Umfeld kommt seiner Einschätzung nach für diese Technologie infrage. Allerdings gibt es dabei einige Dinge zu beachten, betont Georg Ember von IBM: «Alles, was für Cloud-Computing entwickelt wurde, und dazu gehört IaC, lässt sich auch ‚On-prem‘, also in einem Firmen­rechenzentrum einsetzen. Das hängt aber von der verwendeten Hardware ab.» So kommen in Unternehmens-Data-Centern oft andere Systeme zum Einsatz als in einem Cloud-Rechenzentrum. 

Beispiele sind grosse virtuelle Server, virtualisierte Speichercontroller (SVC) und Tape-Technologien. «Will ein Unternehmen selbst entwickelte IaC-Konzepte durchgängig verwenden, also parallel im eigenen Data-Center und in einer Pu­blic Cloud, ist es ratsam, eine Software-definierte Ebene (SDE) zu verwenden. Diese kann von VMware stammen oder Red Hat kann sie mit OpenShift beisteuern.»

Die SDE sollte sich in beiden Umgebungen ähnlich verhalten und sich möglichst auf dieselbe Weise installieren und warten lassen.

Doch warum sollten sich Unternehmen überhaupt mit IaC beschäftigen? Handelt es sich tatsächlich um einen Ansatz, der Vorteile bringt? Eine klare Antwort darauf hat Kalki Rose, Cloud Architect bei der Digitalisierungsagentur Futurice. Er sieht in der Konzentration auf das Was statt das Wie durch Infrastructure as Code einen Vorteil. «Traditionell unterliegt die IT-Infrastruktur der Verantwortung spezialisierter Operations-Abteilungen, mit Experten für Netzwerke, Hardware, Software-Lizenzierung und -Verteilung sowie Sicherheit und Zugangsmanagement», so der Cloud-Spezialist. In Cloud-Umgebungen und der damit verknüpften Verwendung vorgefertigter Ser­vices sinke jedoch die Notwendigkeit, eine derart breite Expertise im eigenen Haus vorzuhalten. IaC gehe noch einen Schritt weiter: «Die Details verschwinden gewissermassen hinter wiederverwendbaren Bausteinen. Zusätzlich profitiert der Nutzer von Validierungs- und Dokumentationsmechanismen, der Nachvollziehbarkeit durch eine Versionskontrolle und vor allem von einem hohen Automatisierungs­potenzial.»

Weitere Punkte führt Gerald Pfeifer von SUSE an: «Mit IaC erreichen wir Konsistenz und Reproduzierbarkeit, Skalierbarkeit und Agilität. Zusätzlich erleichtert die Technologie das Erstellen von Vorlagen und Richtlinien sowie deren gemeinsame Nutzung und Wiederverwendung.» Nutzer können zudem auf öffentlich zugängliche Anleitungen und Playbooks zugreifen, die sich an jeden Hypervisor oder die Infrastruktur von Cloud-Service-Providern anpassen lassen. Eine Quelle solcher Vorlagen ist beispielsweise Github. Auch innerhalb eines Unternehmens lassen sich solche «Kochrezepte» teilen und wiederverwenden.

Im Zeitalter der Digitalisierung, die wechselnde Anforderungen an IT-Ressourcen mit sich bringt, spielen ausserdem die Bereitstellungszeiten eine wichtige Rolle. Sie lassen sich laut IBM-IT-Architect Georg Ember verkürzen, wenn Systemtopologien bereits in Form von Vorlagen oder Code vorliegen. «Noch wichtiger ist, dass sich mit IaC alle Komponenten fehlerfrei, in der richtigen Reihenfolge, in der richtigen Version und für den richtigen Einsatzzweck bereitstellen lassen.» So können IT-Spezialisten etwa Virtual Machines für In-Memory-Datenbanken mit grossem Arbeitsspeicher ausstatten, VMs für Datenanalysen dagegen mit redundanten (Multipath) oder skalierbaren (Multi-Port) I/O-Adaptern.

Von den kürzeren Bereitstellungszeiten profitieren nicht zuletzt Software-Entwickler und -Tester: «Sie können mit Hilfe von Infrastructure as Code produktionsnahe Testumgebungen problemlos erstellen; die Implementierung solcher Umgebungen ohne Ausfall eines Services wird zur Norm», betont Kalki Rose von Futurice. Zudem werde das Risiko minimiert, dass ein System ohne entsprechende Dokumenta­tion modifiziert wird und damit nicht wiederhergestellt werden könne (Snowflake-Effekt). Dieser höhere Freiheitsgrad kann Rose zufolge dazu beitragen, die Agilität eines Unternehmens zu erhöhen: «Durch die hohe Flexibilität lässt sich eine Kultur des Experimentierens schaffen.»

In einigen Online-Foren wird als Nachteil von IaC der hohe Aufwand genannt, der mit der Verwaltung der Code-Versionen verbunden ist. Das Gegenteil sei der Fall, so Rose. Der Aufwand für Code-Management und Fehleranalyse sei bei IaC deutlich geringer als bei herkömmlichen IT-Systemen. «Manuelle Änderungen, die sich über Jahre ansammeln, können selten verlässlich reproduziert werden, es herrscht beinahe eine Art Angst, solche Systeme anzufassen.» Dagegen ermöglicht es Infrastructure as Code, eine lückenlose Aufstellung aller Anpassungen zu erstellen. Tritt ein Fehler auf, lässt sich bei IaC ein Service isolieren und untersuchen. «Innerhalb von Minuten kann der Nutzer auf eine funktionierende Version zurückspringen», betont Rose.

Doch Agilität hin, Digitalisierung her: Letztlich steht bei IaC der geschäftliche Nutzen im Vordergrund, findet Sohini Roy, Produktmanagerin bei Canonical, dem Unternehmen, das hinter der Linux-Distribution Ubuntu steht. «IaC hat sicherlich ein grosses Potenzial in vielen Bereichen. Doch der wahre Nutzen besteht darin, dass Unternehmen damit Geld und Zeit sparen können.» Dies setze aber voraus, dass sich das Konfigurationsmanagement von Infrastrukturkomponenten und Anwendungen von speziellen Hosting-Umgebungen entkoppeln lasse, etwa Private, Public und Hybrid Clouds, aber auch Unternehmensrechenzentren und Bare-Metal-Server-Systemen.

Bewerkstelligen kann man das Roy zufolge mit IaC-Tools wie Juju von Canonical. Solche DevOps-Lösungen, die einfach zu handhaben und zudem sicher sind, unterstützen Nutzer dabei, Anwendungen in jeder IT- und Cloud-Umgebung zu implementieren und zu verwalten. «Nach unserer Erfahrung muss der Einsatz von Infrastructure as Code für Anwender deswegen keinesfalls eine Herausforderung darstellen oder gar abschreckend sein», bekräftigt Sohini Roy.

Doch wie bei jeder Technologie sind auch bei IaC einige Herausforderungen zu bewältigen. «Die grössten Gefahren bei diesem Ansatz lauern, wie so oft, beim Anwender selbst», erläutert Andreas Jaekel von IONOS. „Denn wenn man eine Infrastruktur automatisiert, dann kann man sie auch ‚automatisch‘ zerstören. Somit ist das Katastrophenpotenzial höher. Das gilt allerdings auch für das Reparaturpotenzial.»

Für einen sorgfältigen Umgang mit IaC plädiert auch Gerald Pfeifer von SUSE: «Natürlich erlaubt es IaC auch, sich mit gnadenloser Effizienz und Skalierbarkeit ‚ins eigene Knie zu schiessen‘. Im schlimmsten Fall verbreiten sich Konfigurationsfehler in Windeseile und zerschiessen möglicherweise die eigene Infrastruktur. Doch das kann auch durch Tippfehler von Administratoren passieren.» Sein Rat: Die Nutzer sollten Änderungen von IaC-Vorlagen testen und schrittweise ausrollen.

Wichtig ist zudem, die Mitarbeiter frühzeitig in ein IaC-Projekt einzubeziehen, unterstreicht Kalki Rose. «Der Zeitersparnis bei der Implementierung neuer Services steht ein umfassender Paradigmenwechsel gegenüber. Dieser erfordert Trainings und eine Sensibilisierung der Beschäftigten.»

Allein der wachsende Druck, IT-Ressourcen immer schneller nach Bedarf und weitgehend automatisch bereitzustellen, spielt Infrastructure as Code in die Hände. Hinzu kommt, dass Unternehmen in immer stärkerem Mass auf agile Entwicklungsmethoden und Cloud-Computing zurückgreifen. Beide Ansätze lassen sich bestens mit IaC kombinieren. Diese Faktoren tragen dazu bei, dass IaC in den kommenden Jahren an Boden gewinnen wird, und dies nicht nur bei Grossunternehmen und im gehobenen Mittelstand.

Gerade Start-ups und kleinere Firmen können dank Infrastructure as Code den Aufwand reduzieren, der mit dem Aufsetzen und dem Management von Cloud- und herkömmlichen IT-Infrastrukturen verbunden ist. Erste Gehversuche können Anwender mit Hilfe von Open-Source-Lösungen wie Terraform starten.

Problematisch ist jedoch, dass es bislang keine universellen IaC-Tools und -Plattformen gibt. Dies tangiert vor allem Nutzer von Multi-Cloud- und Hybrid-Cloud-Umgebungen. Denn die IaC-Lösungen der grossen Cloud-Service-Provider wie AWS, Microsoft und Google sind auf deren Cloud-Umgebungen zugeschnitten. Auch bei Infrastructure as Code sollten Anwender daher im Vorfeld prüfen, ob das Risiko besteht, sich von einem Anbieter abhängig zu machen. Denn dies würde zulasten der Flexibilität gehen, die Nutzer durch IaC gewinnen.

Die höhere Skalierbarkeit, Stabilität und Agilität sprechen für Infrastructure as Code, wenn ein Unternehmen neue Produktionsumgebungen entwickeln und implementieren möchte, erläutert Lukas Höfer, Cloud Solutions Architect beim Software- und Beratungshaus Consol Software.

Lukas Höfer: Software-defined bedeutet, dass wir virtualisierte Hardware-Komponenten als Code definieren können. Und nichts anderes machen wir bei Infrastructure as Code. Ohne IaC wäre also die Cloud, wie wir sie kennen, gar nicht möglich. Denn auch dort läuft im Hintergrund nahezu alles virtualisiert und das Deployment erfolgt mittels wiederholbarer Skripte, um Skalierbarkeit und Stabilität zu erreichen.

Höfer: Bei unseren Kunden ist IaC ein grosses Thema. Ein Grund: Teilweise kann es schon helfen, sich vorgefertigter Templates zu bedienen, um schnell einen Prototyp auszurollen. Vor allem beim Aufbau einer Produktionsumgebung sind klar definierte Infrastruktur-Templates nicht zu ersetzen. Wenn alles exakt definiert ist und jede Komponente automatisiert bereitgestellt wird, lässt sich garantieren, dass jede Umgebung, von der Entwicklung bis zur Produktion, einheitlich ist; so werden stabile Produktionssysteme geschaffen. Und genau dies ist das Ziel unserer Kunden.

Höfer: Der Mehrwert zeigt sich deutlich, wenn man quasi per Copy and Paste innerhalb kurzer Zeit neue Systeme aufbaut. Im Vergleich dazu kann es aber sehr zeitraubend sein, Konfigurationen in Codes einzupflegen, die man mit wenigen Klicks im User Interface umsetzen könnte. Wir arbeiten allerdings häufig mit erfahrenen Kunden zusammen, die den Wert von Automation zu schätzen wissen. IaC bietet zudem vor allem Wiederholbarkeit: Wenn eine Task häufig identisch oder ähnlich ablaufen soll, lässt sich dies mit Code abbilden. Die Nutzung von Code bringt zudem mehr Stabilität im Vergleich zu einer manuellen Konfiguration. Und das führt letztlich dazu, dass man ein höheres Vertrauen in seine Infrastruktur und die darauf ausgeführten Deployments hat.

Höfer: Klassischerweise stammt IaC ja aus dem IT-Betrieb, der die Infrastrukturbereitstellung und -wartung möglichst automatisiert und somit zeitsparend abwickeln möchte - und zwar nicht nur in der Cloud, sondern auch im klassischen Rechenzentrum. Aktuell boomt das Thema vor allem im Bereich DevOps, wodurch auch Entwickler sich immer mehr mit IaC auseinandersetzen müssen. So entstehen zum Beispiel neue IaC-Tools wie AWS SDK oder Pulumi, die es ermöglichen, die Infrastruktur in Sprachen wie Java oder Python abzubilden. Das kommt den Entwicklern sehr entgegen.

Höfer: Manche Tools wie AWS CloudFormation oder AWS CDK oder auch Werkzeuge anderer Anbieter sind Provider-spezifisch. Anwendungen wie Terraform, Ansible oder Packer funktionieren aber mit einer Vielzahl von Virtualisierungs-Providern und werden schon lange On-Premise eingesetzt. Inzwischen gibt es auch die Möglichkeit, im eigenen Rechenzentrum auf Hardware der Cloud-Provider deren Tool-Stack auszuführen. Das lässt sich dann natürlich auch im eigenen Rechenzentrum mit deren IaC-Varianten managen.

Für Entwickler ist die Sicherheit ein zentrales Qualitätskriterium von Programmcode. Bei
In­frastructure as Code gilt das in besonderem Mass, weil fehlerhafte IaC-Vorlagen mit hohen Sicherheitsrisiken verbunden sind, warnt Martin Zeitler, Director Systems Engineering Central Europe beim IT-Security-Spezialisten Palo Alto Networks.

Martin Zeitler: Weil IaC-Templates, die Konfigurationsfehler enthalten, zu signifikanten Sicherheitsrisiken führen können. Das ist etwa der Fall, wenn ein Container-Template falsche Berechtigungen enthält, etwa Root-User anstelle eines Non-Root-Users. Ein weiteres Beispiel: Ein Entwickler erstellt mit Hilfe von Terraform eine Cloud-Umgebung. Darin wird jedoch der Netzwerkfilter, also beispielsweise die Network-Security-Group, nicht granular geöffnet. Das kann dazu führen, dass eine Datenbank für alle User offen im Internet erreichbar ist. Allgemein gesagt können solche Fehler dazu führen, dass IT-Systeme kompromittiert werden und Datenlecks auftreten.

Zeitler: Laut dem Cloud Threat Report vom Frühjahr 2020 sind derzeit mehr als 199.000 unsichere IaC-Templates im Einsatz, mit Schwachstellen von mittlerem und hohem Schweregrad. Eine einzige Fehlkonfiguration reicht aus, um eine ganze Cloud-Umgebung zu kompromittieren. Erschwerend kommt hinzu, dass 43 Prozent der Cloud-Datenbanken nicht verschlüsselt sind und bei 60 Prozent der Cloud-Speicherdienste die Protokollierung deaktiviert ist. Dabei ist die Speicherprotokollierung von entscheidender Bedeutung, um das Ausmass des Schadens bei Cloud-Sicherheitsvorfällen zu bestimmen.

Zeitler: Infrastructure as Code bietet Unternehmen den Vorteil, Sicherheitsstandards systematisch durchzusetzen. IT-Security-Teams haben beispielsweise dadurch die Möglichkeit, Sicherheit frühzeitig in den Software-Entwicklungsprozess einzubringen und in die Bausteine der Cloud-Infrastruktur eines Unternehmens einzubetten. So können Unternehmen im Rahmen eines Shift-Left-Ansatzes Entwicklern ermöglichen, in ihren integrierten Entwicklungsumgebungen (IDEs) IaC-Templates gegen Konfigurationsfehler einzusetzen. Aufgrund der Früherkennung lassen sich auf diese Art und Weise Fehler minimieren und deren Auswirkung deutlich begrenzen.

Zeitler: Shift Left bedeutet, in der Software-Entwicklung frühzeitig den Aspekt Sicherheit mit einzubeziehen. Entwickler stehen diesem Ansatz durchaus nicht skeptisch gegenüber. Das Vorurteil, dass sich Entwickler nicht um Sicherheit kümmern, ist nachweislich falsch. Entwickler denken viel über die Software-Qualität nach. Wenn eine Shift-Left-Security-Strategie allerdings nur mit zusätzlicher Verantwortung einhergeht, wird sie wahrscheinlich nicht die Produktivität und den Workflow der Fachleute verbessern. Um eine Überlastung der Mitarbeiter zu vermeiden, muss nach unserer Meinung die Verschiebung des Sicherheitsansatzes von den «drei T» begleitet werden: Training, Tools und Teamwork.