Es gibt Unternehmen, die es unter großen Anstrengungen schaffen, einmal im Quartal eine neue Softwareversion produktiv zu setzen. Andere Unternehmen tun dies stattdessen mehrmals am Tag. Wenn man das Innenleben zweier solcher Organisationen vergleicht, wird man viele Unterschiede feststellen. Einer dieser Unterschiede ist das Verständnis von Infrastruktur. Während in der einen Organisation Softwarebetrieb und Entwicklung als organisatorisch und methodisch unabhängige Bereiche angesehen werden, gibt es diese Trennung in der mehrmals am Tag liefernden Organisation nicht.

Auf den Schultern von Giganten

Diese Vereinigung von Systemadministration und Entwicklung hat eine Reihe von technischen und sozialen Auswirkungen. Eine davon ist die veränderte Sicht auf die sogenannte Infrastruktur. Darunter wird gemeinhin alles verstanden, was nicht durch die eigene Entwicklung erzeugt wird, aber trotzdem für die Bereitstellung der Software nötig ist. Dies ist zum einen natürlich Hardware, die dank Virtualisierungstechnologie und Cloud-Computing oft nicht mehr innerhalb der eigenen Organisation zu finden ist. Zum anderen ist es Software, der eine wachsende Bedeutung zukommt. Die Softwareentwicklung ist in den letzten Jahren auch  deshalb wesentlich leistungsfähiger geworden, weil man auf viele bewährte Open Source-Infrastrukturkomponenten zurückgreifen kann. Dazu gehören Applikationsserver, Datenbanken, Caches, Rule Engines, Webserver, verteilte Dateisysteme und viele andere Softwareprodukte, die durch die eigene Applikation genutzt werden können. So stellt man sich auf die Schultern von Giganten.

Allerdings führt dies dazu, dass das Setup der eigenen Anwendung(en) komplizierter wird. Alle Komponenten müssen mit ihren Abhängigkeiten installiert und richtig konfiguriert werden. Und das in jedem Staging mit unterschiedlichen Anforderungen: Während auf der Entwicklungsumgebung alle Komponenten auf einer Maschine installiert und für schnelle Anpassbarkeit  optimiert sind, so besteht eine Produktionsumgebung normalerweise aus einem verteilten System von Maschinen mit der Ausrichtung auf Sicherheit und Performance. Dieser Komplexität Herr zu werden ist eines der Ziele von „Infrastruktur als Code“.

Automatisierung der gesamten Infrastruktur

Was Infrastruktur als Code leisten soll, ist nicht weniger als:

Enable the reconstruction of the business from nothing but a source code repository, an application data backup, and bare metal resources.
(Aus: Web Operations: Keeping the Data On Time, O’Reilly Media, Inc., 2010)

Mit anderen Worten: Die gesamte Infrastruktur wird nicht anders gehandhabt als der eigene Quellcode und der gesamte Prozess automatisiert. Für diese Aufgabe braucht es allerdings Unterstützung, denn mit den traditionellen Mitteln der Systemadministration ist dieses Ziel nicht zu erreichen. Diese Hilfe bieten Configuration Management Frameworks. Die populärsten unter Ihnen sind Chef, Puppet und CFEngine. Sämtliche Änderungen an der Infrastruktur werden nicht mehr direkt auf den jeweiligen Maschinen, sondern über diese Werkzeuge vorgenommen.

Vorteile von Infrastruktur als Code

Dokumentation

„Die Wahrheit steht im (Quell-)Code!“. Man kann sich nicht lange mit Softwareentwicklung beschäftigen, ohne irgendwann einmal diesen Satz zu hören. Er darf natürlich nicht als Entschuldigung dafür gelten, wichtige Informationen, die nicht aus dem Quellcode ersichtlich sind, nicht zu dokumentieren. Aber diese Position hat auch zwei gewichtige Argumente auf ihrer Seite. Zum einen ist der Programmcode nicht mehrdeutig. Eine schriftliche Beschreibung kann diese Genauigkeit nicht erreichen. Zum anderen besteht immer die Gefahr, dass die Dokumentation veraltet ist – entweder, weil der Autor einer Infrastrukturänderung nicht wußte, an welcher Stelle er welche Inhalte dokumentieren muss, oder weil er diese schlichtweg vergessen hat oder wegen Zeitdrucks nicht erstellt hat. Diese Probleme haben zur Folge, dass die Infrastruktur nicht anhand der Dokumentation wiederhergestellt werden kann. Gleichzeitig läßt sich Programmcode wesentlich besser dokumentieren als die Infrastruktur selbst: Man kann die Installation eines Webservermoduls auf der Maschine kaum direkt dort dokumentieren, sehr wohl aber an der entsprechenden Stelle im Code, der das Setup des Webservers beschreibt.

Flexibilität

Dank Virtualisierungstechnologie und Cloudangeboten sind Server nicht nur schnell zu beziehen, sondern auch ebenso schnell wieder loszuwerden. Diese Flexibilität stellt allerdings nur einen Vorteil dar, wenn man neue Maschinen mit minimalen Aufwand schnell und korrekt konfigurieren kann. Genau das leistet Infrastruktur als Code. Von der Installation aller Infrastrukturkomponenten, deren Konfiguration und dem Deployment der Anwendungen ist der gesamte Prozess automatisiert und macht damit diese Flexibilität erst für die Organisation nutzbar, z.B., um auf Lastspitzen schnell mit zusätzlichen Servern zu reagieren oder nach dem Ausfall eines Rechenzentrums die bestehende Infrastruktur bei einem anderen Dienstleister wieder aufzubauen.

Produktivität

Durch Infrastruktur als Code werden viele zeitraubende Arbeiten in der Systemadministration überflüssig gemacht. So kommt man mit weitaus weniger Aufwand zu wesentlich besseren Ergebnissen. Der Unterschied in der Produktivität ist dabei beeindruckend. Während viele Organisationen mit einem Systemadministrator um die zehn Server betreuen, liegt dieses Verhältnis bei Firmen wie Facebook oder Microsoft bei eins zu tausend oder mehr Servern (!).

No silver bullet

Man könnte noch viele weitere Vorteile von Infrastruktur als Code aufzählen. Allerdings wäre falsch, dieses Thema aus seinem Zusammenhang zu reißen und es als Allheilmittel zu präsentieren. Infrastruktur als Code kann nur gelingen, wenn Entwickler sich mit Infrastruktur beschäftigen und Systemadministratoren Techniken verwenden, die sich in der Softwareentwicklung bewährt haben. Mit anderen Worten: Die Grenzen zwischen den beiden Tätigkeiten werden aufgebrochen, sowohl in methodischer als auch sinnvollerweise in organisatorischer Hinsicht. Diese Idee, gemeinhin unter dem Namen DevOps bekannt, ist nicht sinnvoll von Infrastruktur als Code zu trennen. Und eine Entwicklung hin zu dieser Idee bedeutet nicht allein technische, sondern auch soziale und organisatorische Veränderungen. Und diese sind bekanntlich nicht nur schwierig, sondern funktionieren auch nicht von heute auf morgen. Trotzdem sollte sich jede IT-Organisation heute mit dem Thema befassen – sonst gerät sie in Gefahr, in einen strategischen Nachteil gegenüber Konkurrenten zu geraten, die vor diesem Veränderungsprozess nicht zurückschrecken.