Vorwort
Bei meiner letzten Aufgabe habe ich in Azure eine Infrastruktur innerhalb einer Ressourcengruppe öfters angelegt, wieder gelöscht und auch zwischendrin immer wieder verändert. Und das alles manuell!
Das hat mich sehr viel Zeit und Nerven gekostet. Mir wurde dann vorgeschlagen Infrastructure-as-Code (IaC) zu benutzen, damit ich meine Infrastrukturdeployments lediglich einmal deklarieren muss und später einfach per Klick verwalten kann. Da ich das Thema mit der Zeit immer interessanter fand und es aktuell auch in beinahe allen unseren Kundenprojekten relevant wird, möchte ich in einer kleinen Blog-Serie näher darauf eingehen, wieso IaC auch für BI Entwickler kaum mehr wegzudenken ist.
Für diese Serie beschränke ich mich auf Azure, jedoch können (fast) alle vorgestellten Tools mit allen großen Cloudprovidern genutzt werden. Die folgenden 4 Tools werde ich vorstellen:
- ARM,
- Bicep,
- Terraform,
- Pulumi.
Ich werde Vor- und Nachteile aufzeigen sowie am Schluss ein Fazit ziehen, welches Tool für BI Umgebungen am Besten erscheint.
Als Testobjekt werden wir in Azure ein Modern Data Warehouse einrichten. Es besteht aus einem logischen SQL-Server, einer SQL-Datenbank, einer Data Factory und einem Storage Account, allesamt fully managed >Platform-as-a-Service Komponenten. Dieses DWH ist geeignet für typische Unternehmensanalysen sowie für die Analyse historischer Daten.
Was ist Infrastructure as Code?
IaC ist also eine Methode, mit der die Bereitstellung von Infrastruktur wie CPU, Speicher und Netzwerk mithilfe von Code ermöglicht wird.
In meinem Beispiel erzeuge ich Ressourcen in Azure und verwalte die Ressourcen durch ein Tool.
Wie ist es entstanden?
Infrastructure as Code ist ein Ansatz von DevOps. DevOps ist eine Wortkombination aus dem Entwickler (Dev) und IT Operations (Ops), und beschreibt einen Ansatz der Prozessoptimierung durch eine Verbindung der Bereiche Softwareentwicklung und Systemadministration.
Als Cloud-Computing-Angebote (Azure, AWS etc..) immer beliebter wurden, wurden die Bereitstellungen bzw. Konfigurationen manuell angepasst. Dadurch war es auch fehleranfälliger, da oft mehr als eine Person involviert war. Um die Bereitstellungen effizienter zu machen, wurde Infrastructure as Code eingeführt.
Infrastructure as Code ist ein wichtiges Puzzleteil, mit dem man Infrastrukturen automatisieren kann.
Wofür wird es gebraucht?
Infrastructure as Code wird benutzt, um schnellstmöglich, programmgesteuert und ohne mögliche Fehler, die manuell gemacht werden könnten, eine Infrastruktur zu erzeugen, zu konfigurieren und kontinuierlich anzupassen. Die größten Vorteile dabei sind, dass Änderungen schneller durchgeführt werden können und die Verwaltung von Versionen sowie Rollbacks per Knopfdruck machbar sind. Auch die Skalierung auf mehrere Geräte ist wesentlich komfortabler und günstiger.
Wie funktioniert es?
- Der Entwickler beschreibt die Infrastruktur in einer Tool-spezifischen Sprache.
- Die daraus entstehenden Dateien werden zur Versionierung mit einem Code repository synchronisiert.
- Außerdem werden die Dateien an einen Master Server oder eine API über Push/Pull Methoden gesendet.
- Die Plattform übernimmt dann alle notwendigen Schritte zum Erstellen und Konfigurieren der Ressourcen.
Was sind Push/Pull Methoden?
Bei der Push-Methode werden die Daten vom Entwickler per Knopfdruck übertragen.
Bei der Pull Methode holt sich der Server die Daten, regelmäßig oder wenn er sie benötigt, dazu muss sich ein Setup z.B. auf einer Cloud-Computing-Plattform befinden.
In unserem Beispiel benutzen wir nur Tools die, die Push-Methode benutzen. Tools, welche die Pull Methode nutzen, sind immer dann relevant, wenn es darum geht, z.B. Lösungen regelmäßig ohne manuellen Eingriff intensiv zu testen. Ein Beispiel dafür sind nightly builds.
Was ist der Unterschied zwischen dem imperativen und deklarativen Ansatz?
Die heute auf dem Markt erhältlichen IaC Tools ticken allesamt recht unterschiedlich. Größtes Unterscheidungsmerkmal neben Push/Pull ist jedoch die Frage, ob das Tool die Infrastruktur nach dem klassischen imperativen Ansatz oder nach dem modernen deklarativen Ansatz bereitstellt.
Der deklarative Ansatz beschreibt zentral lediglich das Ergebnis, welches erstellt werden soll. In unserem Fall sind das die Ressourcen in der Azure Cloud. Der Optimierer erkennt dann selbstständig, wie der vermeintlich beste Weg zum Ziel ist. Ein bekannter Vertreter der deklarativen Programmierung ist übrigens SQL.
Der imperative Ansatz beschreibt im Detail den Weg, wie man zum Ziel kommt. Das heißt jeder Teilschritt zum Ergebnis ist explizit vom Entwickler vorgegeben. Es geht darum, der Maschine einen genauen Ablauf zu vermitteln, mit dem ein gewünschtes Ergebnis erreicht werden soll. Ein Beispiel zur imperativen Programmierung ist demnach Powershell.
Lassen Sie uns diese abstrakte Definition etwas anschaulicher machen anhand eines Kochrezeptes. Wenn ich mit einem deklarativen IaC Tool Nudeln mit Tomatensauce kochen will, dann gibt es nur einen einzigen Prozessschritt, nämlich die Deklaration des Ergebnisses. Diese ist “Nudeln mit Tomatensauce” bekommen. Dies hat in der Entwicklung entscheidende Vorteile: Da ich mich nicht um das genaue Kochrezept kümmern muss, kann mir mein Essen nicht anbrennen, d.h. manuelle Fehler sind ausgeschlossen. Andererseits kann ich aber evtl. wichtige Parameter, wie den Salzgehalt oder die Konsistenz der Sauce nicht kontrollieren, insofern ich sie nicht als Teil des Ergebnisses angeben kann (Nudeln mit salziger Tomatensauce). Wir sind bei diesem Ansatz also auf die von den Cloudprovidern vorgegebenen API Parameter beschränkt.
In der imperativen Programmierung wird jeder einzelne Teilschritt beschrieben wie zum Beispiel, Wasser erhitzen, salzen, Nudeln dazugeben usw. Es wird also klar, dass der Implementierungsaufwand deutlich größer ist als im deklarativen Ansatz. Ebenso kann man durch Fehler im Prozess auch das Endergebnis zunichtemachen (die Nudeln verkochen lassen).
In unserem Vergleich nutzen wir lediglich deklarative Tools, da in der modernen agilen Entwicklung die schnelle Bereitstellung von Ressourcen einen nicht zu unterschätzenden Vorteil in der sog. Time-To-Market von Produkten bringt.