In­fra­struc­tu­re as Code (IaC)

Geht es um IT-In­fra­struk­tur, führt mitt­ler­wei­le kaum ein Weg an vir­tua­li­sier­ter, per Software steu­er­ba­rer Hardware vorbei. Punkt­ge­nau lassen sich Speicher-, Server- und Netzwerk-Res­sour­cen oder gar komplette Re­chen­zen­tren zu­sam­men­stel­len und jederzeit skalieren, ohne dass hierfür ein manueller Zugriff auf die je­wei­li­gen Geräte er­for­der­lich ist. Dank In­fra­struc­tu­re-as-a-Service-Providern kann die zu­grun­de­lie­gen­de, soft­ware­de­fi­nier­te Hardware sogar kos­ten­güns­tig gemietet werden, was Inhouse-In­fra­struk­tur gänzlich ent­behr­lich macht.

An­spruchs­voll bleibt das Ma­nage­ment der ver­schie­de­nen Res­sour­cen dennoch – ins­be­son­de­re aufgrund der stetig stei­gen­den Ansprüche an IT-In­fra­struk­tur und der Tatsache, dass häufig gleich­zei­tig auf die Dienste mehrerer un­ter­schied­li­cher IaaS-Anbieter zu­rück­ge­grif­fen wird. Einen immer höheren Stel­len­wert nimmt daher das Prinzip „In­fra­struc­tu­re as Code“ ein, das auch unter der Be­zeich­nung „pro­gram­mier­ba­re In­fra­struk­tur“ bekannt ist.

Bei In­fra­struc­tu­re as Code, oder kurz IaC, handelt es sich um ein IT-Paradigma, demgemäß nicht nur Software, sondern auch die zur Aus­füh­rung benötigte In­fra­struk­tur wie Spei­cher­platz (Storage), Re­chen­power oder Netz­werk­res­sour­cen in Com­pu­ter­spra­che be­schrie­ben wird. Es geht prin­zi­pi­ell also darum, auch Hardware-Struk­tu­ren als aus­führ­ba­ren Code zu pro­gram­mie­ren, der sich jederzeit pro­blem­los anpassen, du­pli­zie­ren, löschen und ver­sio­nie­ren lässt. Dabei baut das In­fra­struc­tu­re-as-Code-Konzept auf modernen Cloud-Tech­no­lo­gien wie Vir­tua­li­sie­rung und soft­ware­de­fi­nier­tem Res­sour­cen-Handling auf, die ein solches Hardware-Ma­nage­ment ohne manuellen Zugriff auf die zu­grun­de­lie­gen­den Geräte erst möglich machen.

Die Ansprüche an Software-Produkte sind in den ver­gan­ge­nen Jahren rapide gestiegen. Daraus re­sul­tie­ren­de Kon­se­quen­zen sind z. B. immer kürzer werdende Ent­wick­lungs­zy­klen und ein Streben nach maximaler Ver­füg­bar­keit und Fle­xi­bi­li­tät. Neben einer op­ti­mier­ten Code-Ent­wick­lung zählt daher auch die ständige Ver­bes­se­rung und intensive Pflege der zu­grun­de­lie­gen­den Hardware-In­fra­struk­tur zu den Eck­pfei­lern für ein er­folg­rei­ches, stabiles und vor allem kon­kur­renz­fä­hi­ges Ge­samt­kon­strukt. An dieser Stelle kommt In­fra­struc­tu­re as Code ins Spiel, denn das Konzept „pro­gram­mier­ba­re In­fra­struk­tur“ ist speziell dafür ent­wi­ckelt worden, die Qualität und Effizienz von In­fra­struk­tu­ren zu erhöhen. Zu den ele­men­ta­ren Zielen und Aufgaben von IaC zählen dabei u. a.:

• manuelle Prozesse so weit wie möglich zu au­to­ma­ti­sie­ren
• die Grenzen zwischen An­wen­dun­gen und den Um­ge­bun­gen, in denen sie aus­ge­führt werden, auf­zu­he­ben
• einen flexiblen Workflow zu schaffen, der die un­ter­neh­mens­wei­te Zu­sam­men­ar­beit für alle, die am Ent­wick­lungs­pro­zess beteiligt sind, ver­ein­facht
• Be­we­gun­gen von Inhalten und Än­de­run­gen jederzeit trans­pa­rent und de­tail­liert nach­voll­zieh­bar zu machen
• Hardware-Set-ups in gleichem Maße „testbar“ wie Software zu machen

Im klas­si­schen, nicht­vir­tua­li­sier­ten Umfeld sind sämtliche Res­sour­cen immer direkt an physische Hardware gebunden, was nicht nur eine wenig flexible In­fra­struk­tur zur Folge hat, sondern auch mit einer Menge Hand­ar­beit bei jeglichen Än­de­run­gen am Set-up verbunden ist.

Mit der Vir­tua­li­sie­rung von Server-Hardware, Speicher und Netz­werk­struk­tu­ren hat sich diese Aus­gangs­la­ge erheblich geändert: Dank der Tech­no­lo­gie haben Provider die Mög­lich­keit, Kunden zentral re­gu­lier­ba­re Res­sour­cen an­zu­bie­ten, ohne hierfür de­di­zier­te Hardware zuweisen zu müssen. Das sorgt zum einen für eine deutlich höhere Aus­fall­si­cher­heit, da etwa defekte Hardware umgehend ersetzt werden kann. Zum anderen ist auch das Hin­zu­bu­chen neuer Res­sour­cen bzw. das Zu­rück­fah­ren bereits ge­mie­te­ter Res­sour­cen für beide Seiten deutlich einfacher.

Einen Schritt weiter als ge­wöhn­li­che vir­tua­li­sier­te In­fra­struk­tu­ren gehen soft­ware­de­fi­nier­te (Software Defined) Um­ge­bun­gen. Diese zeichnen sich dadurch aus, dass die Steu­er­lo­gik komplett aus den einzelnen Hardware-Kom­po­nen­ten abs­tra­hiert und in eine zentrale Steu­er­soft­ware im­ple­men­tiert wird. Provider und Kunden können diese Steu­er­ein­heit dank ent­spre­chen­der Schnitt­stel­len und Tools pro­blem­los ansteuern und IT-Struk­tu­ren ganz in­di­vi­du­ell zu­sam­men­stel­len sowie punkt­ge­nau skalieren. Zudem pro­fi­tie­ren beide Seiten von einer erhöhten Leis­tungs­fä­hig­keit der Hardware, da diese nicht für die Da­ten­ver­ar­bei­tung zuständig ist.

In­fra­struc­tu­re as Code bedient sich der zuvor genannten Techniken, indem es das soft­ware­ge­steu­er­te Ma­nage­ment der je­wei­li­gen vir­tua­li­sier­ten Res­sour­cen au­to­ma­ti­siert, um das Potential der Cloud optimal aus­zu­schöp­fen. Damit ist IaC nicht als Al­ter­na­ti­ve, sondern als Ergänzung bzw. Op­ti­mie­rung soft­ware­de­fi­nier­ter In­fra­struk­tur zu verstehen.

In­fra­struc­tu­re as Code trägt ent­schei­dend dazu bei, die An­for­de­run­gen agiler Software-Ent­wick­lung zu erfüllen. Er­for­der­li­che Än­de­run­gen an der In­fra­struk­tur sind dank fertig kon­fi­gu­rier­ter Skripte in einem Tempo vollzogen, das Sie bei manueller Ad­mi­nis­tra­ti­on schlicht­weg nicht erreichen können. Dabei spielt es keinerlei Rolle, ob die An­pas­sun­gen mitten in der Nacht, am Wo­chen­en­de oder an einem Feiertag zu rea­li­sie­ren sind. Darüber hinaus sinkt das Feh­ler­po­ten­zi­al – ins­be­son­de­re bei Ad­mi­nis­tra­ti­ons­schrit­ten, die es häufig zu wie­der­ho­len gilt –, da Eingabe- und Tipp­feh­ler aus­ge­schlos­sen sind. Zu­sätz­lich zur hohen Ge­schwin­dig­keit und der geringen Feh­ler­an­fäl­lig­keit punktet In­fra­struc­tu­re as Code gegenüber manueller Ad­mi­nis­tra­ti­on durch folgende Vorteile:

• Hohe Effizienz: IaC bietet die Mög­lich­keit, den Großteil des Res­sour­cen­ma­nage­ments zu au­to­ma­ti­sie­ren und trägt damit ent­schei­dend zur Op­ti­mie­rung des Software De­ve­lo­p­ment Life Cycles (SDLC), also des gesamten Ent­wick­lungs­pro­zes­ses, bei.
• Wie­der­ver­wend­bar­keit: Sobald der Code für eine In­fra­struk­tur ge­schrie­ben ist, lässt er sich jederzeit und so oft wie gewünscht ausführen, um diese In­fra­struk­tur um­zu­set­zen. Gleiches gilt z. B. auch für Sandbox-Um­ge­bun­gen während der Ent­wick­lungs­pha­se(n).
• Ver­si­ons­ver­wal­tung: Wo Code ist, ist auch Ver­si­ons­ver­wal­tung möglich – und so erlaubt In­fra­struc­tu­re as Code die Do­ku­men­ta­ti­on und Ver­fol­gung jeglicher Än­de­run­gen, die an einer In­fra­struk­tur vor­ge­nom­men werden. Das hat u. a. den Vorteil, dass sich ein vor­an­ge­gan­ge­nes Set-up ohne Probleme wie­der­her­stel­len lässt.
• Mi­ni­mie­rung von Kosten/Aufwand: Die Au­to­ma­ti­sie­rung der In­fra­struk­tur­ver­wal­tung spart eine Menge Aufwand und Kosten, die wiederum in andere Bereiche in­ves­tiert werden können.

Der zuletzt genannte Vorteil, Kosten und Zeit ein­zu­spa­ren, ist al­ler­dings nicht ohne Ein­schrän­kun­gen zu nennen. Auf eine gut pro­gram­mier­te In­fra­struc­tu­re-as-Code-Umgebung trifft diese Tatsache zwar zu – al­ler­dings darf der Aufwand, der mit ihrer Kon­zep­ti­on und Umsetzung verbunden ist, nicht außer Acht gelassen werden: So bedeutet das IaC-Modell für viele ver­ant­wort­li­che Ad­mi­nis­tra­to­ren große Um­stel­lun­gen, denn ohne ein um­fas­sen­des Ver­ständ­nis von Cloud-Ar­chi­tek­tur-Konzepten sowie ohne Know-how in Pro­gram­mier­spra­chen wie Java, Node.js, Python usw. und im Umgang mit APIs ist der Umstieg auf eine au­to­ma­ti­sier­te In­fra­struk­tur bzw. deren Rea­li­sie­rung kaum möglich. Gerade zu Beginn ist daher mit ver­gleichs­wei­se hohen Kosten und einem hohen Ein­ar­bei­tungs­auf­wand zu rechnen.

Bereits eingangs ist the­ma­ti­siert worden, dass Un­ter­neh­men in den meisten Fällen auf die Dienste mehrerer ver­schie­de­ner IaaS-Provider setzen. Das hat zur Folge, dass Ad­mi­nis­tra­to­ren sich mit den Ei­gen­hei­ten und vor allem mit den un­ter­schied­li­chen Schnitt­stel­len der je­wei­li­gen Platt­for­men aus­ein­an­der­set­zen müssen. Al­ter­na­tiv bieten spezielle IaC-Tools bzw. -Frame­works eigene Kon­fi­gu­ra­ti­ons­spra­chen, die ein an­bie­ter­über­grei­fen­des Ma­nage­ment der Res­sour­cen er­mög­li­chen und genaue Kennt­nis­se über die an­ge­spro­che­nen APIs über­flüs­sig machen. Einige der be­lieb­tes­ten Lösungen sind:

• Terraform: Grund­sätz­lich Open Source lässt sich das von HashiCrop ent­wi­ckel­te Terraform in seiner Ba­sis­ver­si­on kos­ten­frei her­un­ter­la­den und nutzen. Zwei kos­ten­pflich­ti­ge Editionen bieten Features für Ein­rich­tun­gen und Or­ga­ni­sa­ti­on sowie für die Arbeit im Team.
• AWS Cloud­For­ma­ti­on: Cloud­For­ma­ti­on ist das haus­ei­ge­ne IaC-Tool der Amazon Web Services (AWS) und als solches quasi un­ver­zicht­bar für alle, die mit AWS-Produkten wie ELB, S3 oder EFS arbeiten. Für die Nutzung fallen keine zu­sätz­li­chen Gebühren an, sodass Nutzer lediglich die gebuchten Res­sour­cen zahlen.
• Google Cloud De­ploy­ment Manager: Was Cloud­For­ma­ti­on für AWS ist, ist der De­ploy­ment Manager für die Google-Cloud-Plattform. Wer seine IaaS-Res­sour­cen also aus dem Hause Google bezieht, kann diese mit dem kos­ten­lo­sen Tool bequem über zentrale Kon­fi­gu­ra­ti­ons-Dateien in der Aus­zeich­nungs­spra­che YAML verwalten.
• Chef Infra: Chef Infra ist die IaC-Lösung des US-ame­ri­ka­ni­schen Un­ter­neh­mens Chef. Seit April 2019 unter der freien Apache-2.0-Lizenz stehend, wird Chef Infra u. a. von Facebook genutzt. Zu den un­ter­stütz­ten Platt­for­men zählen Google Cloud, Microsoft Azure, Amazon EC2 und OpenStack.
• Red Hat Ansible Tower: Das In­fra­struc­tu­re-as-Code-Werkzeug Ansible gehört seit 2015 zum Portfolio der Software-Schmiede Red Hat. Es bietet ein visuelles Dashboard, eine eigene Kom­man­do­zei­le und eine leis­tungs­star­ke REST-API. Die beiden ver­füg­ba­ren Pakete „Standard“ und „Premium“ sind al­ler­dings kos­ten­pflich­tig.

Der In­fra­struc­tu­re-as-Code-Ansatz ist für alle Un­ter­neh­men in­ter­es­sant, die komplexe An­wen­dun­gen ent­wi­ckeln und betreiben und aus diesem Grund auf ebenso um­fas­sen­de und leis­tungs­star­ke In­fra­struk­tur an­ge­wie­sen sind. Ent­schei­den­de Gründe, auf die Pro­gram­mie­rung von In­fra­struk­tur zu­rück­zu­grei­fen, sind:

• die Nutzung einer großen Menge an IaaS-Res­sour­cen
• In­fra­struk­tur ist bei vielen ver­schie­de­nen Providern bzw. Platt­for­men gemietet
• In­fra­struk­tur bedarf re­gel­mä­ßi­ger An­pas­sun­gen
• eine gute Do­ku­men­ta­ti­on der In­fra­struk­tur-Än­de­run­gen ist gefragt
• eine optimale Zu­sam­men­ar­beit von Ad­mi­nis­tra­to­ren und Ent­wick­lern ist gewünscht

Auch wenn Un­ter­neh­men grund­sätz­lich eigene IaC-Kon­fi­gu­ra­ti­ons­da­tei­en pro­gram­mie­ren könnten und dies si­cher­lich zum Teil auch tun, gehört der Einsatz der oben genannten Tools bzw. Frame­works wohl bei allen Ad­mi­nis­tra­to­ren, die mit IaC arbeiten, zum Alltag. Anstelle von konkreten In­fra­struc­tu­re-as-Code-Bei­spie­len zeigen daher folgende Clips zum Abschluss, wie sich In­fra­struk­tur-Code mit den prak­ti­schen IaC-Werk­zeu­gen (hier: AWS Cloud­For­ma­ti­on und Terraform) pro­gram­mie­ren lässt.