Kolumne: Stropek as a Service

Warum Cloud-Profis auf Infrastructure as Code setzen
Keine Kommentare

Das Azure-Portal bietet eine riesige Menge an Funktionalitäten und selbst erfahrene Entwickler entdecken immer wieder für sie neue Features. Doch Cloud-Profis setzen in der Regel stattdessen auf Infrastructure as Code: Ein Plädoyer für den sparsameren Umgang mit dem Azure-Portal.

Wenn man sich bewusst macht, wie umfangreich die Funktionalität ist, für die das heute bestehende Azure Portal eine brauchbare Benutzerschnittstelle bieten muss, sieht man über die eine oder andere Unzulänglichkeit hinweg und wertschätzt die beeindruckende Leistung des Azure-Portal-Teams etwas mehr. Obwohl ich das Azure Portal bereits seit seinen Anfängen kenne, entdecke ich immer noch jede Woche neue Funktionen und Tricks.

Trotzdem soll diese Ausgabe meiner Kolumne ein Plädoyer für den sparsameren Umgang mit dem Azure Portal sein. Azure-Profis verbringen wenig Zeit im GUI und lernen stattdessen, effizient mit Infrastructure as Code (IaC) umzugehen. IaC bedeutet, dass IT-Infrastruktur in Form von Code (z. B. Skripte oder Konfigurationsdateien) definiert wird. Führt man diesen Code aus, werden die entsprechenden IaaS-, PaaS-, SaaS- und Serverless-Komponenten automatisiert angelegt oder verändert.

Schwieriger Entzug

Wenn ich mit Teams arbeite, die neu in den Cloud-Bereich einsteigen, schlägt mir oft Ablehnung beim Thema IaC entgegen. Man ist es seit langer Zeit gewohnt, bei Bedarf interaktiv auf alle Umgebungen inklusive Produktion zugreifen zu können. Man hat Routine im regelmäßigen Einspielen von Patches. Neue Programmversionen werden „liebevoll“ per Hand auf Server kopiert und konfiguriert. Man schätzt die Unterstützung von GUI-Tools. Warum soll man in der Cloud plötzlich anders arbeiten, auf das hübsche Portal verzichten und sich stattdessen durch Skriptcode plagen? Hier meine wichtigsten Argumente:

  • Skripte sind wiederholbar: Man kann eine Infrastrukturänderung in einer Umgebung entwickeln, sie anschließend in einer anderen Umgebung testen und die für gut befundene Variante schließlich in Produktion ausrollen. Würde man die Änderungen manuell im Portal machen, müsste man drei Mal alles exakt gleich zusammenklicken. Die Chance, dabei Fehler zu machen, ist hoch.

  • Skripte kann man teilen und wiederverwenden: Oft ähnelt eine Anwendung der anderen. Skripte, die man für eine Lösung geschrieben hat, kann man bei einem anderen Projekt anpassen und wiederverwenden. Wissen und Erfahrung sind dadurch leichter weiterzugeben und in Summe wird man als Team produktiver.

  • Skripte sind nachvollziehbar: Sofern man die Skripte in einer Quellcodeverwaltung ablegt (was man unbedingt tun sollte!), werden Infrastrukturerweiterungen und -änderungen nachvollziehbar. Ein Blick auf die Git-Historie und man weiß, wer wann was geändert hat. Durch das Verwenden von Skripten lassen sich in der Softwareentwicklung etablierte Prinzipien wie beispielsweise Codereviews, der Git/GitHub Flow und automatisiertes Testen auf den Infrastrukturbereich anwenden.

  • Skripte sind automatisierbar: Automatisiert man die Ausführung von IaC-Skripten, fallen lästige Routinetätigkeiten weg. Wenn für eine Cloud-Lösung die Infrastruktur angepasst werden muss, ändert man das entsprechende Skript, und beim nächsten Deployment werden nicht nur der Anwendungscode, sondern auch die Infrastrukturänderungen ausgerollt. Man kann so weit gehen, jede Nacht mit Hilfe der IaC-Skripte eine Testumgebung von Grund auf hochzufahren, gewisse Integrationstests ablaufen zu lassen und das Ganze zum Minimieren der Cloud-Kosten anschließend sofort wieder zu löschen.

Wo das Portal Sinn ergibt

Ich möchte an dieser Stelle betonen, dass absolut nichts gegen die Verwendung des Azure Portals spricht, wenn man sich lesend die Cloud-Infrastruktur ansehen möchte. In der Praxis ist das häufig notwendig, um sich zu vergewissern, dass alles planmäßig funktioniert. Im Problemfall ist das Azure Portal zur Analyse unverzichtbar. Bei schwerwiegenden Fehlern, die sofort zu beheben sind und bei denen keine Zeit für das Schreiben eines Skripts bleibt, ist das Azure Portal oft das rettende Tool.

Neueinsteiger*innen in Azure, die in der Lernphase sind, schätzen die grafische Oberfläche des Portals ebenfalls. Sie sollten in dieser Phase auch nicht drauf verzichten, solange der Fokus nicht auf der Entwicklung von produktiven Lösungen, sondern auf explorativer oder prototypischer Entwicklung liegt.

Notwendiger Wissensaufbau

Teams, denen IaC neu ist, müssen sich darauf einstellen, dass ihre Mitglieder neue Grundfertigkeiten lernen und üben müssen. Dazu gehören meiner Erfahrung nach insbesondere die folgenden:

  • Erlernen einer Skriptsprache wie PowerShell oder Bash

  • Umgang mit einer zur gewählten Sprache passenden Entwicklungsumgebung; Visual Studio Code ist in Verbindung mit entsprechenden Erweiterungen in diesem Punkt ein verbreitetes und mächtiges Werkzeug

  • Umgang mit modernen Datenformaten wie JSON oder YAML

  • Quellcodeverwaltung mit Git

Das Lernen dieser Dinge geht im interdisziplinären DevOps-Team leichter, da Softwareentwickler*innen mit den oben genannten Punkten in der Regel gut vertraut sind. Wer aber meint, dass die Wissensvermittlung nur in eine Richtung (von Dev zu Ops) geht, liegt falsch. Entwickler*innen können von Expert*innen für IT- und Cloud-Infrastruktur eine Menge über den stabilen und sicheren Betrieb von Anwendungen lernen.

IaC in Azure

In Azure hat man – ohne Drittanbieterwerkzeuge in Betracht zu ziehen – im Wesentlichen fünf Möglichkeiten, IaC zu betreiben:

  1. Man kann PowerShell-Skripte in Verbindung mit den Azure PowerShell Cmdlets schreiben. Während man früher mit PowerShell an Windows gefesselt war, ist diese Technologie heute auf allen gängigen Plattformen verfügbar.

  2. Fans von Bash-Skripten greifen auf das Azure Command Line Interface (CLI) zurück. Das Azure CLI bietet eine Menge Tricks in Verbindung mit JSON, wodurch Azure-Automatisierung erleichtert wird.

  3. Azure-Resource-Manager-(ARM-)Templates sind eine deklarative, JSON-basierte Sprache, mit der Azure-Umgebungen beschrieben werden können. Wenige Zeilen lange PowerShell- oder CLI-Skripte genügen, um ein ARM-Template auf eine Azure-Umgebung anzuwenden.

  4. Als vierte Variante stellt Microsoft für viele Sprachen fertige Management SDKs zur Verfügung.

  5. Wenn man das Pech hat, dass für die eigene Programmiersprache kein Management SDK angeboten wird, kann man auf ein entsprechendes RESTful Web-API von Azure zurückgreifen, das von jeder Plattform aus aufrufbar ist.

Qual der Wahl

Die Frage, die sich stellt, lautet, für welche Variante man sich in welchem Fall entscheiden sollte. Für die Entwicklung produktiver Lösungen empfehle ich in der Regel ARM-Templates. Sie haben einige Vorteile gegenüber skript- oder programmbasierenden Ansätzen:

  • ARM-Templates sind idempotent. Man kann sie als Ganzes immer wieder ausführen, ohne nachteilige Auswirkungen fürchten zu müssen. Azure erkennt automatisch, was man ergänzt oder geändert hat, und führt die notwendigen Anpassungen durch. Als Entwickler*in muss man keinen Code schreiben, der zwischen dem Neuanlegen und Ändern von Komponenten unterscheidet.

  • ARM-Templates sind schnell. Der Azure Resource Manager analysiert die Abhängigkeiten der im Template definierten Ressourcen und führt voneinander unabhängige Operationen (zum Beispiel das Anlegen einer Datenbank und eines Webserverclusters, die nichts miteinander zu tun haben) automatisch parallel durch. In Skripten oder Programmen hingegen muss man sich um die Parallelisierung selbst kümmern.

  • ARM-Templates sind deklarativ. Bei deklarativen ARM-Sprachen spezifiziert man nur das gewünschte Ergebnis, nicht den Algorithmus, wie man dorthin kommt. ARM-Templates haben in dieser Hinsicht Ähnlichkeit mit SQL.

  • ARM-Templates können über das Azure Portal generiert werden. Man kann sich im Azure Portal in einer Entwicklungsumgebung Komponenten zusammenklicken und anschließend das dazu passende ARM-Template generieren. Der generierte Code braucht zwar in der Praxis Anpassungen, ist aber trotzdem eine gute Basis zum Starten.

Diesen Vorteilen stehen aber auch Nachteile gegenüber:

  • ARM-Templates lassen sich schlecht debuggen. Das liegt bis zu einem gewissen Grad an der deklarativen Natur der Sprache. Einsteiger*innen müssen sich daher anfänglich auf manchmal frustrierende Stunden des Fehlersuchens einstellen.

  • Das JSON-Format von ARM-Templates ist nur bedingt benutzerfreundlich. Die ARM-Template-Erweiterungen von Visual Studio Code helfen über diesen Nachteil ein wenig hinweg.

PowerShell- oder CLI-Skripte sind besonders attraktiv für Personen, die schon Erfahrung mit Skriptsprachen haben. Das erleichtert den Einstieg in IaC natürlich sehr, und man sollte den Know-how-Vorsprung auch auszunutzen. Langfristig empfehle ich aber, zumindest einen Blick in ARM-Templates zu werfen. Durch Kombination von Skripten und ARM-Templates kann man das Beste aus beiden Welten kombinieren und schneller ans Ziel kommen. Zwischen PowerShell und Bash mit Azure CLI besteht kein großer Unterschied. In der Regel wird man mit beiden Ansätzen erfolgreich sein. Für PowerShell spricht die mittlerweile gute Integration in Serverless Azure Functions. Dadurch lassen sich Infrastrukturarbeiten elegant und kostengünstig automatisieren.

Auf die Management-APIs oder das RESTful Web-API von ARM würde ich nur zurückgreifen, wenn gewisse Infrastrukturarbeiten in größere Programme nahtlos integriert werden sollen. Ein Beispiel wäre eine Webseite, die bei Registrierung eines neuen Kunden automatisch gewisse Komponenten in Azure anlegen oder Konfigurationen verändern muss. Dafür könnte man das Management-API für die Programmiersprache nutzen, in der das Backend der Webseite entwickelt wurde. In der Praxis würde ich heutzutage aber eher den IaC-Teil in PowerShell-basierende Azure Functions oder Azure Automation Runbooks ausgliedern und diese vom Programmcode aufrufen.

Fazit

Das grafische Azure Portal hat seine Daseinsberechtigung beim Ansehen von Umgebungen und während der Entwicklungs- und Lernphase. Finger weg vom Azure Portal, wenn es um Änderungen an produktiven Cloud-Umgebungen geht! Profis setzen dafür auf Skripte und Templates. shell.azure.com oder Visual Studio Code sind Ihr neues Azure Portal.

 

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
X
- Gib Deinen Standort ein -
- or -