Evaluation: Infrastructure-as-Code-Frameworks für Microsoft Azure

Moderne IT-Infrastrukturumgebungen werden immer größer und komplexer. Die einfache und schnelle Bereitstellung von Infrastruktur in der Cloud per Knopfdruck sowie die flexiblen Skalierungsmöglichkeiten sollten Entwicklern dabei helfen, den Zeitaufwand für die Verwaltung zu reduzieren. In der Realität jedoch sorgt die Flexibilität von Cloud-Infrastruktur dafür, dass noch größere Umgebungen konzipiert werden.

An diesem Punkt setzt Infrastructure as Code (IaC) an. IaC ist eine Praxis aus dem Bereich DevOps, die Techniken aus der Softwareentwicklung mit bewährten Praktiken zur Automatisierung kombiniert. Die Infrastruktur wird dabei lediglich über Quellcode verwaltet. Änderungen am Code werden durch Techniken wie Continuous Integration (CI) und Continuous Delivery (CD) automatisiert auf die Infrastruktur angewandt, sodass konsistente, wiederholbare und schnelle Bereitstellungen ganzer Umgebungen entstehen.

In vielen Projekten werden daher unterschiedliche IaC-Frameworks für die Bereitstellung der Infrastruktur genutzt. Doch welches Framework sollte in einer bestimmten Situation genutzt werden? Diese Frage soll mithilfe einer Evaluation von Frameworks, welche die Bereitstellung von Infrastruktur in der Microsoft Azure Cloud unterstützen, beantwortet werden.

Bereitstellung von Cloud-Infrastruktur mit Infrastructure-as-Code-Frameworks

Grundsätzlich erfolgt die Bereitstellung von Cloud-Infrastruktur mithilfe eines Infrastructure-as-Code-Frameworks nach folgendem Schema:

1. Entwickler schreiben Code für das Framework und laden ihn in ihr Repository hoch (z.B. Azure DevOps).
2. Das Framework greift auf den Code zu und verarbeitet ihn zu API-Aufrufen.
3. Das Framework sendet die API-Anfragen an den API-Endpunkt der Cloud (z.B. ARM bei Azure), sodass die gewünschten Änderungen an der Infrastruktur durchgeführt werden.

Für die Verarbeitung des Codes zu API-Anfragen existieren zwei Ansätze:

Beim imperativen Ansatz beinhaltet der Code die einzelnen Schritte, die durchgeführt werden müssen, um von Ausgangszustand A zum gewünschten Zustand B zu gelangen. Entwickler haben hierbei die volle Kontrolle und bestimmen genau, welche Schritte durchgeführt werden sollen. Der Schwerpunkt dieses Ansatzes liegt also auf dem Wie der Umsetzung.

Der deklarative Ansatz dagegen konzentriert sich auf das Was. Das bedeutet, Entwickler beschreiben im Code lediglich den gewünschten Zustand B und das Framework erarbeitet selbstständig durch einen Vergleich mit dem Ausgangszustand die durchzuführenden Schritte. Der Vorteil dieses Ansatzes liegt vor allem in der Übersichtlichkeit und Wiederverwendbarkeit, da der Code unabhängig vom Ausgangszustand genutzt werden kann und Entwickler sich keine Gedanken über die einzelnen Schritte machen müssen.

Haben Sie Fragen zur Bereitstellung von Cloud-Infrastruktur mit IaC-Frameworks? Wir unterstützen bei der Integration.

Bewertungskriterien der IaC-Frameworks

Die Evaluation erfolgte anhand verschiedener Bewertungskriterien. Die folgenden vier Kriterien wiesen dabei die signifikantesten Unterschiede auf:

• Übersichtlichkeit
• Initialer Aufwand
• Wiederverwendbarkeit
• State Management

Übersichtlichkeit

IaC ist aus dem Bedürfnis entstanden, immer komplexere Infrastruktursysteme möglichst fehlerfrei und effizient bereitstellen zu können. Um dies zu bewerkstelligen, sollen nach den DevOps-Prinzipien Redundanzen vermieden und klare Strukturen angestrebt werden. Dazu müssen IaC-Frameworks gute Strukturierungsmöglichkeiten für den Code bieten. Außerdem spielt die Lesbarkeit des Codes für Menschen eine wichtige Rolle.

Initialer Aufwand

Die Einführung von IaC in einem Projekt bringt mehrere Aufgaben mit sich. Zum einen müssen Entwickler den Umgang mit den Tools und der verwendeten Sprache erlernen. Zum anderen werden ggf. Konzepte für die Erstellung von Modulen und für das State Management benötigt.

Wiederverwendbarkeit

Wiederverwendbarkeit ist eines der Kernthemen von IaC. Durch die Wiederverwendung von Code werden konsistente Strukturen geschaffen, sodass die erzeugten Umgebungen jedes Mal dasselbe Verhalten aufweisen. Außerdem wird somit eine effiziente Arbeitsweise gefördert, da weniger Code neu entwickelt werden muss und Änderungen an zentraler Stelle durchgeführt werden können. Idempotenz ist hierbei eine wichtige Eigenschaft. Code ist idempotent, wenn er mehrmals hintereinander ausgeführt werden kann und immer dasselbe Ergebnis liefert.

State Management

Im IaC-Kontext bezeichnet der Zustand eines Systems (State) die Ressourcen, deren Konfiguration und Abhängigkeiten zueinander. Einige deklarative Frameworks speichern eine Cache-Version des States nach der Bereitstellung. Dieser State enthält alle Ressourcen, die durch das Framework bereitgestellt wurden. Er wird dazu verwendet, eine Verbindung zwischen den real bereitgestellten Ressourcen und den im Code beschriebenen zu schaffen und dient als Grundlage für die Planung der durchzuführenden Schritte bei späteren Bereitstellungen. Bei der Bewertung der Frameworks wurde betrachtet, welche Möglichkeiten für die Speicherung des States geboten werden, ob eine Überprüfung der geplanten Schritte möglich ist und wie aufwendig der Import bestehender Infrastruktur ist.

Ergebnisse der Evaluation der IaC-Frameworks von Microsoft

Für die Evaluation wurden drei der vier Frameworks betrachtet, die Microsoft für die Bereitstellung von Ressourcen in Azure empfiehlt :

• Azure CLI
• Bicep
• Terraform

ARM-Templates wurden nicht weiter evaluiert, da Bicep eine Weiterentwicklung dazu darstellt und alle Funktionen von ARM-Templates unterstützt.

Azure CLI

Azure CLI ist ein Kommandozeilenprogramm, das genutzt werden kann, um einzelne Befehle in Azure auszuführen. Ein Befehl entspricht dabei einem Aufruf von Azure CLI mit bestimmten Parametern. Für die Automatisierung der Befehle muss auf die Skriptsprache einer Shell wie bspw. PowerShell zurückgegriffen werden. Es handelt sich daher um ein imperatives Framework.

• Übersichtlichkeit
  Aufgrund der Umsetzung von Befehlen in Aufrufen des Programms mit Parametern entstehen Skripte mit sehr langen Einzeilern, was zu einer schlechten Lesbarkeit führt.
• Initialer Aufwand
  Der initiale Aufwand bei Azure CLI ist relativ gering, da eine beliebige Skriptsprache verwendet werden kann und Entwickler dadurch in den meisten Fällen keine spezielle Syntax erlernen müssen. Azure CLI speichert keinen State und der Code kann beliebig in verschiedene Skripte ausgelagert werden, sodass keine Konzepte hierfür benötigt werden.
• Wiederverwendbarkeit
  Als imperatives Framework ist Azure CLI immer vom aktuellen Zustand abhängig. Außerdem sind einige Befehle (bspw. Erstellen eines Key Vaults) zum aktuellen Zeitpunkt nicht idempotent, sodass die Skripte nur in der jeweiligen Situation ohne Anpassungen ausgeführt werden können.
• State Management
  Azure CLI benötigt keinen State, da Entwickler dafür verantwortlich sind, die durchzuführenden Schritte im Code zu hinterlegen. Eine Überprüfung der geplanten Änderungen ist daher jederzeit möglich, indem der Code betrachtet wird. Operationen wie die gezielte Deprovisionierung von bereitgestellten Ressourcen sind ebenfalls möglich, da das Framework den Zustand nicht überprüft. Da keine Informationen darüber gespeichert werden, welche Ressourcen durch das jeweilige Skript bereitgestellt werden, kann es allerdings dazu kommen, dass verschiedene Skripte ihre Änderungen gegenseitig überschreiben.

Bicep

Bicep setzt im Gegensatz zu ARM-Templates nicht auf JSON, sondern verwendet eine eigene domänenspezifische Sprache. Es handelt sich jedoch trotzdem um eine reine Übersetzung von ARM-Templates. Bicep-Code wird vor der Bereitstellung automatisiert in ein ARM-Template transpiliert. Eine Dekompilierung von ARM-Templates zu Bicep-Code ist ebenfalls möglich.

• Übersichtlichkeit
  Die simple und kompakte Syntax der domänenspezifischen Sprache sowie der deklarative Ansatz sorgen für eine gute Lesbarkeit des Codes. Des Weiteren kann der Code in Modulen gekapselt werden, wobei eine Datei einem Modul entspricht.
• Initialer Aufwand
  Ähnlich zu Azure CLI wird kein State gespeichert und die simple Modularisierung benötigt wenig Vorüberlegungen durch Entwickler. Allerdings muss die Bicep-Sprache erlernt werden, sodass der initiale Aufwand ein wenig höher ist.
• Wiederverwendbarkeit
  Aufgrund des deklarativen Ansatzes und der Idempotenz des Frameworks ist der Code stets unabhängig vom Ausgangszustand. Bereits erstellte Module können durch andere Module aufgerufen werden und werden bei der Transpilierung zu einem ARM-Template zusammengefügt.
• State Management
  Bicep setzt auf einen inkrementellen Ansatz, bei dem davon ausgegangen wird, dass die Infrastruktur Stück für Stück erweitert wird und speichert daher keinen State. Die Deprovisionierung von Ressourcen wird daher nicht unterstützt. Über die What-If-Funktionalität kann geprüft werden, welche Änderungen das Framework bei einer Bereitstellung durchführt. Leider ist diese Funktion nicht fehlerfrei. Microsoft warnt davor, dass falsch-positive Ergebnisse enthalten sein können und bei der Verwendung mehrerer Module kann es dazu kommen, dass Teile des Codes nicht durch What-If betrachtet werden .
  

Terraform

Terraform ist ein IaC-Framework der Firma HashiCorp, welches ebenfalls eine domänenspezifische Sprache verwendet und den deklarativen Ansatz verfolgt. Die geplanten Schritte zur Überführung in den gewünschten Zustand werden durch sog. Provider in API-Anfragen für die jeweilige Cloud verarbeitet. Dadurch ist Terraform in der Lage, verschiedene Anbieter zu bedienen. Gleichzeitig bedeutet dies, dass API-Updates der Cloud-Anbieter erst unterstützt werden, wenn der zugehörige Provider angepasst wurde.

• Übersichtlichkeit
  Ähnlich zu Bicep weist die domänenspezifische Sprache durch ihre simple Syntax eine gute Lesbarkeit des Codes auf. Im Gegensatz zu Bicep und Azure CLI ist es bei Terraform jedoch möglich, den Code innerhalb eines Moduls auf mehrere Dateien auszulagern. Alle Dateien innerhalb eines Verzeichnisses werden einem Modul zugeordnet, sodass eine übersichtliche Strukturierung erfolgen kann.
• Initialer Aufwand
  Aufgrund der fortgeschritteneren Strukturierungsmöglichkeiten müssen Entwickler im Voraus ein Konzept für eine einheitliche Auslagerung des Codes erarbeiten. Außerdem speichert Terraform den State der Infrastruktur, sodass ein Konzept für die Ablage benötigt wird. Terraform benötigt daher den höchsten initialen Aufwand.
• Wiederverwendbarkeit
  Die Wiederverwendbarkeit des Codes ist auf dem gleichen Niveau wie bei Bicep, da Terraform ebenfalls den deklarativen Ansatz verfolgt und vollständig idempotent ist.
• State Management
  Terraform bietet verschieden Möglichkeiten für die Ablage des States: Storage der Azure, Amazon oder Google Clouds kann verwendet werden. Ebenso ist es möglich, den State per HTTP auf einem eigenen Server zu hinterlegen. Durch die Speicherung des States ist eine zuverlässige Überprüfung der geplanten Änderungen und die gezielte Deprovisionierung möglich. Der erzeugte Plan kann abgespeichert und für eine spätere Bereitstellung verwendet werden, sodass zum Zeitpunkt der Bereitstellung nur die überprüften Schritte ausgeführt werden. Nachteil dieser Vorgehensweise ist, dass nur Ressourcen, die sich im State befinden, verwaltet werden können. Soll bereits bestehende Infrastruktur verwaltet werden, muss diese aufwendig importiert werden.

Fazit zu den IaC-Frameworks von Microsoft Azure

Der Vergleich zeigt, dass Terraform aufgrund der Strukturierungsmöglichkeiten und der Nachvollziehbarkeit besonders in komplexen Projekten mit großer Infrastruktur genutzt werden sollte, sodass der höhere initiale Aufwand ausgeglichen wird. Bicep dagegen bietet durch seine einfache Strukturierung einen schnellen Einstieg für kleinere Projekte. Azure CLI sollte nur genutzt werden, wenn wenige Ressourcen schnell bereitgestellt werden müssen und anschließend nicht mit vielen Änderungen zu rechnen ist, da die Skripte durch den imperativen Ansatz immer an den aktuellen Zustand angepasst werden müssen.

Haben Sie Fragen zur Bereitstellung von Cloud-Infrastruktur mit IaC-Frameworks? Wir unterstützen bei der Integration.