Infrastructure as Code: Programmieren geht über konfigurieren (tschüss YAML!)

Infrastructure as actual Code

Ich bin Entwickler. Als ich «Infrastructure as Code» (IaC) zum ersten Mal gehört habe, vermutete ich folgende Bedeutung hinter dem Begriff: Ich provisioniere Infrastruktur mit der gleichen Programmiersprache, wie ich meine Applikationen programmiere – macht Sinn!

Schnell habe ich realisiert, dass IaC etwas anderes bedeutet: Ich provisioniere Infrastruktur mit Konfigurationstemplates, die neu für mich sind. Ich muss mich mit ihrem Format und ihrer Funktionsweise auseinandersetzen. Diese Templates liegen normalerweise nicht im Repository meiner Applikation, sondern in monolithischen Repositories zur Provisionierung der unternehmensweiten Infrastruktur. Der erste Kontakt mit solchen Repositories, typischerweise bestehend aus tausenden von Zeilen YAML (oder JSON oder HCL), wirkt überwältigend – im negativen Sinn.

Nun stellt sich heraus, dass Entwicklungs-Frameworks existieren, die meine initiale Interpretation von IaC wahr werden lassen! Dazu gehören die beiden Open Source-Projekte AWS Cloud Development Kit (CDK) und Pulumi. Am Beispiel einer einfachen Webapplikation zeigt dieser Artikel Vorteile auf, die solche Entwicklungs-Frameworks mit sich bringen.

Ein vermeintlich einfaches IaC-Beispiel

Das nachfolgend erläuterte Beispiel wurde von Robert Hoffmann am WeAreDevelopers Weltkongress präsentiert. Robert ist Senior Solutions Architect bei AWS mit selbstdiagnostizierter YAML-Phobie. Das Beispiel beinhaltet eine hochverfügbare Webapplikation, die auf AWS bereitgestellt wird. Pulumi und die verschiedenen Flavors von CDK können Infrastruktur jedoch auch bei anderen Cloud-Anbietern und On-Prem provisionieren.

Das folgende Diagramm zeigt die Architektur der Webapplikation. Ein Application Load Balancer nimmt Requests aus dem Internet für die Applikation entgegen und eine EC2 Auto Scaling Group (eine Gruppe virtueller Maschinen) verarbeitet die Requests.

Zur Provisionierung dieser vermeintlich einfachen Infrastruktur benötigt CloudFormation, der IaC-Service von AWS, über 300 Zeilen YAML. Mit AWS CDK sind es hingegen weniger als 30 Zeilen Code. Wie kommt es zu dieser Differenz? Hinter den Komponenten steckt mehr Komplexität, als das obige Diagramm vermuten lässt. Was alles konfiguriert und provisioniert werden muss, um die Applikation zum Laufen zu bringen, zeigt das folgende Diagramm im Detail auf.

AWS CDK abstrahiert einen Grossteil dieser Komplexität. Sowohl bei AWS CDK als auch bei Pulumi instanziieren Entwicklerinnen und Entwickler Klassen, die ihre Infrastruktur repräsentieren. Diese Klassen machen sichere Default-Konfigurationen gemäss Best Practices im Hintergrund, damit man sich nicht selbst darum kümmern muss. So reicht eine Zeile Code aus, um eine Virtual Private Cloud (VPC) zu provisionieren: const vpc = new ec2.Vpc(this, 'MyVPC'). Den gesamten Code für das Beispiel findest du auf GitHuB.

Vorteile von IaC mittels Programmiersprache

Die Abstraktionen und Defaults von AWS CDK und Pulumi beschleunigen den Entwicklungsprozess. Sie erlauben, Proof of Concepts (POC) und Minimum Viable Products (MVP) schnell zu implementieren. Beim Ausbau dieser Applikationen können Entwicklerinnen und Entwickler dann kontinuierlich Konfigurationen hinzufügen bzw. Default-Konfigurationen überschreiben, wo nötig. Hierfür müssen sie lediglich die entsprechenden Attribute auf den Infrastruktur-Objekten setzen.

Entwicklerinnen und Entwickler provisionieren Infrastruktur in ihrer «Muttersprache». Sowohl AWS CDK als auch Pulumi unterstützen JavaScript, TypeScript, Java, Python, Go sowie weitere Programmiersprachen und deren nativen Ökosysteme. Dies bringt verschiedene Vorteile und Möglichkeiten für Entwicklerinnen und Entwickler mit sich:

• Ihre Entwicklungsumgebung ist schon einsatzbereit. Für die gewohnte Programmiersprache sind Plugins installiert, Linters eingerichtet, Libraries bekannt und Code Completion vorhanden.
• Sie verwenden Logik, wie Bedingungen oder Schleifen, für die Definition der Infrastruktur.
• Sie nutzen objektorientierte Ansätze zur Abbildung der Infrastruktur.
• Sie setzen native Test-Frameworks für das Testen der Infrastruktur ein.
• Sie verwalten Infrastruktur und Applikationslogik am gleichen Ort.
• Sie rücken näher an den Betrieb – ganz im Sinn von DevOps.

Was will man mehr angesichts dieser Vorteile? Cloud-Agnostizismus. Ich wünsche mir eine Welt ohne Vendor Lock-in, in der Menschen Infrastruktur einmalig definieren und bei diversen Anbietern provisionieren können. CDK Flavors und Pulumi erlauben zwar, Infrastruktur bei verschiedenen Cloud-Anbietern zu provisionieren, jedoch nicht mit dem gleichen Code. Soll eine Infrastruktur bei zwei Anbietern provisioniert werden, muss sie auch zweimal mit anbieterspezifischen Klassen definiert werden. Dies wird sich in Zukunft ändern. So abstrahiert beispielsweise das Pulumi Cloud Framework (Preview) Eigenheiten verschiedener Anbieter.

Ein Blick unter die Haube

Bei AWS bedeutet das Aufkommen von CDK nicht, dass Konfigurationstemplates verschwinden. Es bedeutet, dass wir diese Templates nicht selbst schreiben müssen. Die Rolle von CDK ist die eines Transpilers, der imperativen Code in deklarative Templates übersetzt. Die generierten Templates sind einsehbar und bilden die Basis für das Deployment der Infrastruktur (wie gehabt). CDK kommt in Flavors, um Infrastruktur in verschiedenen Umgebungen provisionieren zu können: AWS CDK für AWS CloudFormation, CDK8s für Kubernetes und CDKtf für Terraform. Das folgende Diagramm zeigt dieses Zusammenspiel.

Bei Pulumi findet der Zwischenschritt über Templates nicht statt. Pulumi macht sich zwar bestehende Funktionalität von Open Source-Tools wie Terraform zunutze, kommuniziert jedoch direkt mit den REST APIs der Cloud-Anbieter. Zur Verwaltung der Ressourcen pflegt Pulumi ein State File, welches im Gegensatz zu demjenigen von Terraform verschlüsselt ist.

Empfehlung

Die genannten Vorteile von modernen IaC-Frameworks werden nicht jede und jeden überzeugen. Manche Informatikerinnen und Informatiker haben ihre Wurzeln in Operations und sind vertrauter mit der Konfiguration via Templates. Dadurch ist die Anwendung einer Programmiersprache für sie allenfalls weniger intuitiv.

Die gute Nachricht ist, dass nicht alle von dem neuen Ansatz zur Provisionierung von Infrastruktur überzeugt sein müssen. Der eine Ansatz schliesst den anderen nicht aus. Sprich, ein Unternehmen kann Infrastruktur gleichzeitig mit Programmiersprachen und direkt via Templates provisionieren. Daher können und sollen Unternehmen auf Team-Ebene und unter Berücksichtigung der Use Cases entscheiden, wo der Einsatz eines modernen IaC-Frameworks gewinnbringend ist.

Die friedliche Koexistenz der verschiedenen IaC-Ansätze macht es einfach, CDK oder Pulumi auszuprobieren und sich von ihren Vorteilen zu überzeugen. Und genau das ermutige ich Dich zu machen!