Azure Portal vs. CLI vs. Bicep: Wer hat hier das Sagen?

Als ich zum ersten Mal im Azure-Portal landete, fühlte es sich an wie der Gang in ein hippes Café mit 300 Sorten Bohnen. Alles sah spannend aus, aber ich hatte keine Ahnung, wo ich anfangen sollte. Dann kamen CLI und Bicep – und plötzlich war ich nicht mehr nur Kaffeetrinker. Ich war Barista, Röster und Maschinentechniker in einem.

Dieser Beitrag ist Teil meiner laufenden Lernreise vom Microsoft-365-Experten zum Azure-Entdecker. Ich zeige dir die drei wichtigsten Wege, mit Azure zu arbeiten, teile die Fehler, die ich als Anfänger gemacht habe, und erkläre, warum Automatisierung kein Nice-to-have ist – sondern essenziell, um deine Cloud-Infrastruktur zu skalieren und zu pflegen.

Drei Wege, mit Azure zu arbeiten – jeder mit eigenem Aroma

1. Azure Portal – die visuelle Oberfläche

Das Azure-Portal (https://portal.azure.com) ist die grafische Weboberfläche, in der du Ressourcen wie virtuelle Maschinen, Speicherkonten und Netzwerke erstellst und verwaltest.

Pro:

• Intuitiv und visuell
• Super für Einsteiger und schnelle Tests
• Kein Code nötig

Contra:

• Nicht reproduzierbar
• Keine Versionskontrolle
• Leicht den Überblick zu verlieren, was du konfiguriert hast

Beispiel: eine VM über das Portal erstellen

• Auf „Virtual Machine” → „Create” klicken
• Eine Ressourcengruppe wählen oder erstellen
• Region, Größe, Image (z. B. Ubuntu), Authentifizierung und Netzwerk auswählen
• Auf „Review + Create” klicken

Der Haken: Du weißt in zwei Wochen nicht mehr, was du geklickt hast – und Azure auch nicht.

2. Azure CLI – Kommandozeile mit Cloud-Power

Die Azure CLI ist ein plattformübergreifendes Kommandozeilen-Werkzeug, das du lokal oder in der Azure Cloud Shell ausführst. Ideal für Skripting und Automatisierung.

Pro:

• Skriptbar und automatisierbar
• Präzise Kontrolle
• Super für DevOps-Workflows

Contra:

• Setzt Syntax-Kenntnisse voraus
• Weniger visuelles Feedback
• Leicht Fehler zu machen, wenn man die Befehle nicht versteht

Beispiel: eine VM über die CLI erstellen

az group create --name RoestGruppe --location westeurope
az vm create \
  --resource-group RoestGruppe \
  --name EspressoVM \
  --image UbuntuLTS \
  --admin-username ferdi \
  --generate-ssh-keys

Mit --output json oder --query ziehst du bestimmte Daten wie öffentliche IPs heraus.

3. Bicep – Azure-native Infrastruktur als Code

Bicep ist eine deklarative Sprache von Microsoft zum Definieren von Azure-Ressourcen. Sie ist sauber, lesbar und integriert sich direkt ins Azure-Ökosystem.

Pro:

• Versionierbar und wiederverwendbar
• Leicht zu lesen und zu pflegen
• Ideal für Teams und CI/CD-Pipelines

Contra:

• Braucht eine anfängliche Lernkurve
• Am besten von Anfang an einsetzen, nicht nachträglich

Beispiel: ein Speicherkonto mit Bicep erstellen

resource storage 'Microsoft.Storage/storageAccounts@2022-09-01' = {
  name: 'roeststorage'
  location: resourceGroup().location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

Deployment:

az deployment group create \
  --resource-group RoestGruppe \
  --template-file storage.bicep

Terraform – was meine Recherche ergeben hat

Ehrlich gesagt: Ich habe Terraform in der Praxis noch nicht genutzt. Aber laut meiner Recherche ist es eine mächtige Alternative zu Bicep – besonders, wenn du über mehrere Cloud-Plattformen hinweg arbeitest.

Terraform ist ein Open-Source-Werkzeug von HashiCorp, das Azure, AWS, Google Cloud, Kubernetes und mehr unterstützt. Es nutzt HCL (HashiCorp Configuration Language) und verwaltet den Infrastruktur-Zustand über eine lokale oder entfernte Datei.

Was mir aufgefallen ist:

• Multi-Cloud-Unterstützung
• Potenziell weniger Codezeilen für manche Ressourcen
• Erfordert sorgfältiges State-Management

Beispiel aus meiner Recherche:

resource "azurerm_storage_account" "roeststorage" {
  name                     = "roeststorage"
  resource_group_name      = "RoestGruppe"
  location                 = "West Europe"
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

Terraform ist kein Ersatz für Bicep – es ist ein anderes Werkzeug mit anderem Fokus. Ich plane, beide zu testen, und schreibe einen Folgebeitrag: „Bicep vs. Terraform – Espresso für Azure oder Multi-Cloud-Mokka?“

Anfängerfehler, die ich mir gern erspart hätte

„Ich klick mich einfach durchs Portal …”

Ich habe Ressourcen manuell angelegt und dachte, ich würde mich erinnern, was ich getan habe. Tat ich nicht. Keine Doku, keine Reproduzierbarkeit. Wie Espresso brühen ohne Rezept – jede Tasse schmeckte anders.

„CLI sieht cool aus – kopieren wir mal ein paar Befehle.”

Ich habe CLI-Befehle aus der Doku kopiert, ohne sie zu verstehen. Am Ende hatte ich Ressourcen in der falschen Region und falsch konfigurierte Netzwerke. Die CLI ist mächtig, aber sie verzeiht keine Unwissenheit.

„Bicep? Klingt nach Fitnessstudio.”

Ich habe Bicep zu spät entdeckt. Ich hatte schon einen Haufen Ressourcen manuell gebaut und musste alles mühsam in Code zurückführen. Schmerzhaft und ineffizient.

„Terraform ist doch wie Bicep, oder?”

Nicht ganz. Terraforms State-Management und Multi-Cloud-Fähigkeiten bringen Komplexität. Ohne zu verstehen, wie die State-Datei funktioniert, riskierst du eine Infrastruktur, die nicht zu deinem Code passt.

Warum Automatisierung essenziell ist

Skalierbarkeit

50 VMs über drei Regionen? Nicht klicken – skripten. Automatisierung lässt dich skalieren, ohne den Verstand zu verlieren.

Wartbarkeit und Sicherheit

Code-basierte Deployments sind versioniert, nachvollziehbar und umkehrbar. Du weißt, wer was wann und warum geändert hat.

Testbarkeit

Baue identische Umgebungen für Test, Staging und Produktion auf. Keine Überraschungen, keine Inkonsistenzen.

Wiederverwendbarkeit

Einmal schreiben, überall nutzen. Deine Bicep-Module werden zu deinem Infrastruktur-Kochbuch.

Mein Espresso-Tipp für dich

Sich durch Azure zu klicken ist fürs Lernen okay. Aber wenn du skalieren, automatisieren und nachts ruhig schlafen willst, fang an, deine Infrastruktur in Code zu gießen. Dein zukünftiges Ich (und dein IT-Team) werden es dir danken.