[über]
[lösungen]
[log]
Nichts Passendes dabei? Stellen Sie ein, welche Inhalte Sie auf aleri.de sehen möchten:
Wo steht Infrastructure as Code in 2022?
Bei immer mehr Projektsituationen werden wir beauftragt, Applikationen entweder in eine Cloud-Umgebung zu migrieren oder gleich für eine – meist Public – Cloud zu entwerfen. Der Trend weg vom klassischen Hosting oder sogar der On-Premise-Betrieb in den eigenen vier Wänden hin zu Cloud-Computing ist aus unserer Sicht ungebrochen.
Was ist Infrastructure as Code?
Cloud-Infrastruktur kann „von Hand“ aufgebaut werden. Die Webportale der verschiedenen Dienstleister erlauben es, IT-Infrastruktur dynamisch anzulegen und händisch zu verändern. Als Best Practice ist es allerdings üblich, Cloud-Infrastruktur durch wiederholbare Prozesse automatisiert aufsetzen zu lassen. Die Beschreibung dieser Aufbau-Prozesse ist wiederum: Code – der Vorgang nennt sich „Infrastructure as Code“ (kurz: IaC) [1] und fasst alle Sprachen, Datenformate und Werkzeuge zusammen, um Dinge wie virtuelle Maschinen, Netze, Datenbanken oder sonstige Services dynamisch, vollautomatisch und verifizierbar zu erstellen.
IaC hat eine Reihe von Vorteilen. Auch wenn es initial ggf. länger dauert - durch die Automatisierung sind bei wiederholter Anwendung die Aufwände geringer. Häufig muss man ein und dasselbe Konstrukt mehrfach anwenden (Entwicklungsumgebung, Testumgebung, Pre-Production, Produktionsumgebung), und dann wird es günstiger.
Ähnliches gilt für die Geschwindigkeit. Die vollautomatisierte Ausführung ist in der Regel um ein Vielfaches schneller als das, was Menschen in einer Webschnittstelle händisch zusammensetzen können.
Und im Falle eines Verlusts oder einer Störung kann eine identische Umgebung automatisch wieder hergestellt werden.
Nun gibt es verschiedene Vorgehensweisen, wie man sich dem Thema IaC näher kann. Zum einen hat jeder der großen öffentlichen Cloud-Provider eine deklarative Auszeichnungssprache, um Cloud-Infrastruktur zu beschreiben. Amazon Web Services bietet (u. a.) ihr Produkt CloudFormation [2], bei Microsoft Azure kommen die Templates des Azure Resource Managers (ARM) [3] zum Einsatz. Hier wird in Formaten wie JSON oder YAML Infrastruktur beschrieben, und die Werkzeuge des Cloud Providers erlauben das Deployment.
Wie fängt man damit an?
Der Vorteil dieser „nativen“ Lösungen der jeweiligen Cloud-Provider liegt darin, dass sehr viele Konstrukte der Cloud automatisiert werden können, mit Support durch den Provider selber. Natürlich ist den Providern daran gelegen, dass ihre Deployment-Werkzeuge funktionieren und gut dokumentiert sind.
Ein Nachteil für Nutzer liegt darin, dass die Konstrukte nicht portabel sind – ein ARM-Template von Azure lässt sich nicht bei AWS deployen. Vielfach wird auch die Menge an Infrastruktur-Code zum Hindernis für eine effiziente Zusammenarbeit im (Ops-)Team.
Das Unternehmen HashiCorp hat im Jahr 2014 das Produkt „Terraform“ [4] herausgebracht, was mittlerweile eine sehr weite Verbreitung gefunden hat. Terraform ist ein reines IaC-Werkzeug und erlaubt die deklarative Gestaltung von Cloud- bzw. IT-Infrastruktur. Es hat eine offene Schnittstelle für Provider, sodass man in einem Werkzeug und in einer Beschreibungssprache bleiben kann, aber dennoch für verschiedene Cloud-Anbieter die Infrastruktur beschreibt. Das Werkzeug bringt auch gleichzeitig den Deployment-Vorgang mit.
Wer sich heute ernsthaft mit modernen Cloud-Native-Ansätzen beschäftigt, hat mit hoher Wahrscheinlichkeit auch Terraform im Werkzeugkoffer.
Ein relativ neuer Vertreter im Bereich IaC ist „Pulumi“ [5]. Die Anfänge lassen sich im Github-Repository bis 2017 zurückverfolgen, ca. 2020 ist das Werkzeug vermehrt in Erscheinung getreten.
Pulumi geht einen anderen Ansatz als die bisher erwähnten Werkzeuge. Während Cloudformation, Terraform & Co deklarativ arbeiten (d.h. ein Zielzustand wird statisch im Formaten wie JSON, YAML, HCL beschrieben) lässt sich Pulumi programmieren – und zwar in Sprachen wie Typescript, Go, Python, also Konstrukten, die näher an Softwareentwicklern dran sind. Dabei hat Pulumi natürlich auch entsprechende Komplextität, aber auch unter anderem den Vorteil, dass man als Entwickler die Ausführung des eigenen Codes in der Hand hat.
D.h. für Unternehmen, die ihren Kunden dynamisch Cloud-Ressourcen bereitstellen ist Pulumi durchaus eine Alternative.
Wie geht es weiter?
Und damit nicht genug, das Feld „IaC“ bleibt auch 2022 in Bewegung. Die erwähnten Werkzeuge werden alle verbessert, aber die „Developer Experience“ ändert sich nicht grundlegend. Ein häufiger Kritikpunkt ist, dass größere Vorhaben eine entsprechend große Codebasis an IaC-Code erzeugen und ab einer gewissen Größe nicht mehr gut skalieren.
Und bei der Beliebtheit von Kubernetes und dem dahinterstehenden Ökosystem aus Werkzeugen wundert es nicht, dass auch aus dieser Ecke Innovationen kommen: Zum Beispiel auf Basis von „CrossPlane“ [6], einer Möglichkeit Cloud-Infrastruktur in Rahmen eines Kubernetes-Clusters aufzubauen.
Was ist die Zukunft von Infrastructure as Code?
Für uns steht fest, dass Cloud ohne professionellen Einsatz von IaC nicht sinnvoll ist. Unsere Kunden und auch wir selber müssen bewerten, wieviel Marktinnovation wir bereit sind aufzunehmen, um neue Vorteile zu realisieren: Kostenersparnis, Zeitvorteile, Risikominimierung.
In diesem Sinne wollen wir uns im nächsten Teil dieser Serie mit neuartigen Werkzeugen wie Pulumi und Crossplane befassen.
Ihr Ansprechpartner zum Thema
Sie haben noch Fragen zum Thema? Kontaktieren Sie uns gerne!