Willkommen zu einer weiteren Folge von Microsoft Knowledge Nuggets hier auf M365FM. Bin der Moderator Mirko Peters? Sie haben Azure-Ressourcen bereitgestellt, indem Sie im Portal herumgeklickt haben. Funktioniert der einwandfrei, bis es nicht mehr funktioniert? Dann müssen Sie es erneut tun, können sich aber nicht mehr genau erinnern, was Sie ausgewählt haben. Sie müssen es an einen Teamkollegen übergeben und dieser kann Ihre Schritte nicht nachvollziehen. Versionskontrolle? Es gibt nichts, das Committed wird. Das ist das Problem, das wir heute lösen werden. Am Ende dieser Folge werden Sie verstehen, was Infrastructure as Code ist, warum BICEP existiert und wie es Azure-Bereitstellungen einfacher und zuverlässiger macht. Wir beginnen mit dem Problem, dann mit der Lösung und anschließend mit einem praktischen Beispiel, an dem Sie sich orientieren. Schnappen Sie sich Ihren Kaffee und legen wir los.

Das Portalproblem. Die Click-to-Deploy-Falle fühlt sich schnell an. Sie melden sich an, füllen ein Formular aus, klicken auf Erstellen und sind fertig. Aber was passiert, wenn Sie es mit denselben Einstellungen der selben Region und Namenskonvention erneut tun müssen? Sie müssen sich an jede einzelne Auswahl erinnern und genau da bricht alles zusammen. Eine manuelle Bereitstellung führt zu inkonsistenten Ergebnissen, menschlichem Versagen und keinem Prüfpfad. Hier ist ein Beispiel aus der Praxis. Jemand in Ihrem Team erstellt eine Ressource mit leicht unterschiedlichen Einstellungen. Jetzt haben Sie zwei Umgebungen, die nicht übereinstimmen. Eine funktioniert, die andere nicht. Viel liegt beim Herausfinden, woran das liegt. Dann ist da noch das Problem mit der Dokumentation. Infrastruktur als Word-Dokument oder, schlimmer noch, ein YouTube-Video, das vor sechs Monaten aufgenommen wurde, als das Portal noch ganz anders aussah.

Features werden verschoben, Menüs ändern sich, neue Optionen werden eingeschrieben. Ich habe mich mit einem Produktmanager des Azure-Portal-Teams zusammengesetzt und er sagte mir, dass Sie zweimal täglich neue Features veröffentlichen. Zweimal täglich. Ihr Word-Dokument ist veraltet, bevor Sie es fertig geschrieben haben. Hier ist das Problem. Herumklicken funktioniert zum Lernen. In der Produktion ist das Problem. Was ist also die Alternative? Sie schreiben eine Datei, die beschreibt, was Sie möchten und weisen Azure an, sie zu erstellen. Was ist Infrastruktur als Code? Infrastruktur als Code bedeutet, dass Sie Ihr Cloud-Setup mit Code verwalten, anstatt sich durch ein Webportal zu klicken. Hier ist die Kernidee. Sie schreiben eine Datei, die Ihre Infrastruktur beschreibt. Diese Datei befindet sich in Ihrem Repository. Sie können sie versionieren, in einem Pull-Request überprüfen und morgen erneut ausführen, um dasselbe Ergebnis zu erhalten.

Hier gibt es einen Schlüsselbegriff, Deklarativ. Das bedeutet, Sie beschreiben, was Sie möchten und nicht, wie es erstellt werden soll. Sie weisen Azure nicht an, zuerst eine Ressourcengruppe zu erstellen, dann ein Speicherkonto hinzuzufügen und dann das Netzwerk zu konfigurieren. Stattdessen sagen Sie, ich möchte eine Ressourcengruppe mit einem Speicherkonto und einem Netzwerk, das auf diese Weise konfiguriert ist. Und Azure ermittelt die Reihenfolge. Das Ergebnis wird als Idempotenz bezeichnet. Führen Sie es einmal aus, führen Sie es hundertmal aus und Sie erhalten dasselbe Ergebnis. Darin liegt die Stärke. Stellen Sie es sich wie eine Blaupause im Gegensatz zur manuellen Erstellung. Eine Blaupause ist wiederholbar, gemeinsam nutzbar und überprüfbar. Geben Sie sie an jemand anderen weiter und er wird genau dasselbe erstellen. Mittlerweile gibt es dafür verschiedene Tools. Armvorlagen, Bizep, Terraform, Pulumi.

Sie alle implementieren dasselbe Konzept auf unterschiedliche Weise. Das ist ein wichtiger Unterschied. Infrastruktur als Konzept. Reisep ist nur ein Tool, das dies implementiert. Aber hier ist der Clou. Azure verfügt seit Jahren über eine IAC-Sprache namens Armvorlagen. Und es gibt einen Grund, warum Microsoft er neu entwickelt hat. Das Problem mit Armvorlagen. Armvorlagen sind das ursprüngliche IAC-Format von Azure. Es handelt sich um JSON-Dateien, die viele Vorteile bieten. Sie decken alle Azure-Ressourcen vollständig ab und verwenden dieselbe Bereitstellungs-Engine, mit der Sie sie intern verwenden. Wenn Sie sie im Portal erstellen können, können Sie sie auch in einer Armvorlage definieren. Liegt also das Problem. JSON eignet sich hervorragend für Maschinen, aber für Menschen ist es schreckend. Zeige Ihnen, was ich meine. Ein Speicherkonto in einer Armvorlage benötigt etwa 20 Codezeilen.

Das gleiche Speicherkonto in Bizep umfasst etwa 10 Zeilen. Die JSON-Version ist ungefähr doppelt so groß. Das sind nur einfache Ressourcen. Stellen Sie sich eine vollständige Bereitstellung mit Netzwerk, Compute, Datenbank und Sicherheitsregeln vor. Die Armvorlage wird zu einer Textwand. Die häufigsten Schwachstellen sind vorhersehbar. Fehlende Kommas, nicht übereinstimmende Klammern, ausführliche Verschachtelungen, die es schwer machen zu erkennen, wo eine Ressource endet und eine andere beginnt. Sie verbringen mehr Zeit mit dem Ring, mit der JSON-Syntax, als mit der eigentlichen Definition Ihrer Infrastruktur. Und dann sind da noch die Abhängigkeiten. In A müssen Sie Abhängigkeiten manuell deklarieren. Wenn Ressource A die Existenz von Ressource B benötigt, müssen Sie das explizit angeben. Wenn Sie eine vergessen schlägt, Ihre Bereitstellung fehlt. Viel liegt beim herausfinden, welche Sie vergessen haben.

Wenn Sie jemals versucht haben, eine 200-zeilige JSON-Datei von Hand zu schreiben, wissen Sie, dass das keinen Spaß macht. Nicht einmal ein bisschen. Die Lernkurve ist steil. Neue Teammitglieder haben Schwierigkeiten, Armvorlagen zu verstehen. Die Einstiegshürden sind hoch. Und was passiert in der Praxis? Viele Teams haben am Ende nur noch eine Person, die die Armvorlage kennt. Diese Person wird zum Single Point of Failure. Sie ist die Einzige, die die Bereitstellung ändern und debuggen kann, wenn etwas nicht funktioniert. Es ist nicht tragbar. Microsoft hat das Feedback gehört und Bicep entwickelt, um genau diese Probleme zu beheben. Was ist Bicep? Was genau ist Bicep? Es handelt sich um eine Sprache, die für die Bereitstellung von Azure-Ressourcen entwickelt wurde und im Kern ein Transpiler ist. Sie schreiben Bicep und es wird in Arm-JSON kompiliert. Im Grunde ist es dieselbe Engine, aber die Schreibweise ist viel übersichtlich.

Der Name Bicep setzt sich eigentlich aus Arm zusammen, das rückwärts geschrieben wird. Arm. Ein kleiner Insider-Witz von Microsoft. Aber wenn Sie es in Aktion sehen, ergibt es Sinn. Bicep setzt auf Arm auf, anstatt es zu ersetzen. Sie erhalten die gleiche Leistung mit einer einfachen Syntag. Bicep ersetzt Arm nicht, sondern baut darauf auf. Alles, was Sie mit Arm tun können, können Sie auch mit Bicep tun. Jeder Ressourcentyp, jede API-Version und jede Konfigurationsoption ist vorhanden. Der einzige Unterschied besteht in der Schreibweise. Die Syntagse ist viel übersichtlicher. Keine Anführungszeichen, um Eigenschaftsnamen, keine Kommas zwischen Eigenschaften und keine Klammern, die man beachten muss. Es ist einfach einfacher. Vergleichen Sie die beiden Versionen nebeneinander. Die Arm-JSON-Version eines Speicherkontos ist voller Informationen. Anführungszeichen, Kommas, Klammern, Verschachtelungen.

Die Bicep-Version enthält dieselben Informationen, ist aber lesbar. Sie können sie betrachten und sofort verstehen, was sie tut, ohne dass die Schichten von JSON-Syntags durchlaufen müssen. Eine große Verbesserung ist die automatische Abhängigkeitsableitung. In Arm müssen Sie Depends-On manuell deklarieren. Wenn in Bicep jedoch Ressource A auf Ressource B verweist, ermittelt das System die Abhängigkeit automatisch. Sie müssen sie nicht aufschreiben. Es funktioniert einfach. Und das allein spart stundenlanges Debuggen. Module sind ein weiterer wichtiger Bestandteil. Sie können Ihre Infrastruktur in kleinere, wiederverwendbare Teile aufteilen und diese projekteübergreifend nutzen. Ein Team erstellt ein Netzwerkmodul und ein anderes Team verwendet es. Sie müssen nicht jedes Mal das Rad neu erfinden. Mit Parametern und Variablen können Sie Ihre Eingaben einmal definieren und überall wieder verwenden.

Das Suchen und Ersetzen von festcodierten Werten gehört der Vergangenenheit. Und die Zeichenketteninterpolation bedeutet, dass Sie Präfixspeicheranstelle komplexer Verkettungsfunktionen schreiben können. Die Tools sind ein weiterer Grund, warum sich Bicep so angenehm verwenden. Die VS Code-Erweiterung bietet IntelliSense, Syntax-Hervorhebung und Echtzeitfehlerprüfung. Ehrlich gesagt ist sie eine der besten Spracherweiterungen in VS Code. Sie beginnen mit der Eingabe und sie schlägt vor, was als nächstes kommt. Machen Sie einen Fehler und Sie werden sofort darüber informiert. Sie müssen nicht mehr warten, bis eine Bereitstellung fehlschlägt, bevor Sie feststellen, dass Sie ein Komma vergessen. Wie sieht das nun in der Praxis aus? Sehen wir uns an, wie sich Bicep von Arm unterscheidet? Bicep im Vergleich zu Arm, was ist der Unterschied? Brechen wir darüber, was der Unterschied ist, wenn Sie Bicep anstelle von Arm.json schreiben.

Die Dateigröße ist ein offensichtlicher Unterschied. Bicep-Dateien sind etwa halb so groß wie entsprechende Arm-Vorlagen. Das ist nicht übertrieben. Sie entfernen alle Anführungszeichen, Kommas, Klammern und Boilerplate-Codes und übrig bleibt nur die Infrastrukturdefinition. Die Hälfte des Codes desselbe ergibt. Die Lesbarkeit ergibt sich von selbst. Weniger Zeilen, übersichtlichere Struktur und auf einen Blick leichter Verständnis. Wenn Sie eine Bicep-Datei öffnen, können Sie sie scannen und nachvollziehen, was bereitgestellt wird. Bei Arm.json müssen Sie mehrere Verschachtelungsebenen durchlaufen, bevor Sie die eigentliche Ressourcenkonfiguration finden. Abhängigkeiten sparen enorm viel Zeit. In Arm deklarieren Sie Abhängigkeiten manuell. Wenn Sie eine vergessen, schlägt Ihre Bereitschlung fehl. Wenn in Bicep-Ressource A auf Ressource B verweist, wird dies vom System automatisch verarbeitet.

Die Abhängigkeit wird beim Kompilieren in Arm.json zugefügt. Sie müssen nicht darüber nachdenken, es funktioniert einfach. Und das allein spart stundenlanges Debuggen. Module sind ein weiterer wichtiger Unterschied. Arm verfügt über verschachtelte Vorlagen, deren Arbeit jedoch mühsam. Separate Dateien, komplexe Verknüpfungen, schwer zu versionen. Bicep verfügt über Module, die übersichtlicher, versionierbar und wiederverwendbar sind. Sie definieren ein Modul einmal, veröffentlichen es in einer Registrierung und referenzieren von überall darauf. Gleiches Modul, jedes Mal dieselbe Konfiguration. Der Bereitstellungsprozess selbst ist identisch. Bicep wird in Arm.json kompiliert und dann von Azure Resource Manager bereitgestellt. Gleiche Engine, gleiche Pipeline. Sie müssen Ihren Bereitstellungsprozess nicht ändern, sondern nur die Art und Weise, wie Sie die Vorlagen schraben. Was wäre, wenn das eine Funktion, die Arm technisch gesehen bereits bietet, die aber durch Bicep wesentlich zugänglich ist?

Sie können Änderungen vor der Bereitstellung in der Vorschau anzeigen und genau sehen, was erstellt, geändert oder gelöscht wird. Keine Überraschungen, keine versehentlichen Löschungen. Sie führen Was-wäre-wenn-aus, überprüfen die Ausgabe und stellen sie bereit, wenn Sie richtig haben. Die Lernkurve ist ein Bereich, in dem Bicep hervorsteht. Arm.json setzt voraus, dass Sie wissen, was Sie tun. Es wurde für Maschinen entwickelt, nicht für Menschen. Bicep wurde für Anfänger entwickelt. Intuitive Syntax-Tools, die Sie anleiten. Sie können es dann am Nachmittag lernen und am Ende der Woche produktiv sein. Microsoft hat Bicep zur empfohlenen Erstellungsumgebung gemacht. Alle neuen Funktionen und Verbesserungen zielen in erster Linie auf Bicep. Arm-Vorlagen funktionieren immer noch und werden nicht verschwinden, aber Sie sollten wahrscheinlich keine neuen schreiben. Wenn Sie heute ein neues Projekt starten, ist Bicep die richtige Wahl.

Drei Zeilen Bicep, um eine Ressourcengruppe bereitzustellen. Nur drei Zeilen. Das entsprechende Arm.json umfasst etwa 15 Zeilen. Gleiches Ergebnis, gleiche Bereitstellung. Aber eine ist lesbar und die andere ist unleserlich. Jetzt fragen Sie sich vielleicht, was ist mit Terraform? Sollte ich Bicep oder Terraform lernen? Bicep oder Terraform, was sollten Sie verwenden? Willkommen zurück bei den Microsoft Knowledge Nuggets. Ich bin Mirko Peters und heute befassen wir uns mit einer Frage, die immer wieder auftaucht. Bicep oder Terraform? Lassen Sie es uns aufschlüsseln. Terraform funktioniert cloudübergreifend. Sie können es für Azure, AWS, GCP oder sogar für alle drei gleichzeitig verwenden. Bicep hingegen wurde speziell für Azure entwickelt. Dieser grundlegende Unterschied wirkt sich auf alles andere. Wenn Sie also cloudübergreifend arbeiten, ist Terraform die richtige Wahl. Sie lernen eine Sprache, ein Tool und ein Workflow und es funktioniert überall.

Wenn Sie jedoch hauptsächlich mit Azure arbeiten, bietet Bicep einige echte Vorteile. Das ist der erste Vorteil. Keine Statusdateien, die verwaltet werden. Terraform speichert eine Statusdateien, der nachverfolgt wird, was bereitgestellt wird. Diese Datei teilt Deutung. Wenn sie beschädigt wird oder nicht mehr synchron ist, liegt ein ernstes Problem vor. Sie müssen die Datei sicher speichern, sichern und den Zugriff verwalten. Bicep kommuniziert direkt mit Azure Resource Manager, überprüft, was bereits vorhanden ist und ermittelt die Unterschiede. Keine Statusdatei bedeutet keine Synchronisierungsprobleme und keine Gefahr der Beschädigung. Zweiter Vorteil, DayZero Support. Wenn Microsoft ein neues Azure Feature veröffentlicht, unterstützt Bicep es sofort noch am selben Tag. Terraform muss auf ein Anbieter-Update warten, das manchmal schnell geht, manchmal aber Wochen dauert. Wenn Sie ein neues Feature sofort verwenden müssen, ist Bicep die einzige Option.

Drittens wurde es vom Azure Team entwickelt. Die Tools, IntelliSense und Fehlermeldungen wurden alle auf die Funktionsweise von Azure ausgelegt. Wenn Sie Bicep schreiben, verwenden Sie eine Sprache, die Azure Ressourcen nativ versteht. Sie weiß, welche Eigenschaften erforderlich sind, welche Werte gültig sind und welche Abhängigkeiten bestehen. Diese tiefe Integration ist mit einem Drittanbieter-Tool nur schwer nachzubilden. Sie können auch beides verwenden. Viele Organisationen verwenden Bicep für Plattformen und Zielzonen und Terraform für Multicloud-Workloads. Diese beiden Konzepte schließen sich gegenseitig. Sie können für jede Aufgabe das richtige Tool auswählen. Die ehrliche Antwort lautet, wenn Sie sich speziell mit Azure vertraut machen möchten, verfügt Bicep überwiegliche Teile. Es ist ein einfacherer Weg, wenn Sie gerade das anfangen. Sie müssen sich nicht mit Statusdateien, Anbietern oder Backend-Konfigurationen vertraut machen.

Sie installieren die Azure CLI, öffnen VSCode und beginnen mit dem Schreiben. Genug der Theorie. Lassen Sie uns darüber sprechen, was Sie tatsächlich für den Einstieg benötigen. Erste Schritte. Was Sie tatsächlich benötigen. Sie benötigen zwei Dinge, um loszulegen. Die Azure CLI und die Bicep-Erweiterung für VSCode. Das ist alles. Sie müssen keine separate Bicep-CLA installieren und keine zusätzlichen Tools konfigurieren. Bicep ist in der Azure CLI integriert. Die Installation der Azure CLI ist ziemlich einfach. Rufen Sie die Microsoft-Docs auf. Suchen Sie die Installationsseite für Ihr Betriebssystem. Währenden ist es nur ein Befehl. Blue install Azure CLI. Unter Windows gibt es ein MSI-Installationsprogramm. Laden Sie es herunter, füllen Sie es aus, fertig. Sie funktioniert auch unter Linux über Ihren Paketmanager. Füllen Sie nach der Installation AZ-Version aus, um zu überprüfen, ob alles funktioniert.

Sowohl die Azure CLI-Version als auch die Bicep-Version sollten aufgeführt sein. Öffnen Sie nun VSCode, wechseln Sie zum Erweiterungsbereich auf der linken Seite und suchen Sie nach Bicep. Installieren Sie die Version von Microsoft. Keine Drittanbieter-Version, sondern die offizielle Version. Sie benötigen diese Erweiterung glücklich. Sie erhalten IntelliSense, das während der Eingabe Ressourceneigenschaften vorschlägt, die Syntax hervorhebt, sodass Sie Fehler auf einen Blick erkennen können und in Echtzeit nach Fehlern suchen. Sie sehen rote Wellenlinien unter allem, was falsch ist, noch bevor Sie überhaupt versuchen, es bereitzustellen. Ehrlich gesagt ist dies eine der besten Spracherweiterungen im VSCode und ein wichtiger Grund dafür, warum die Arbeit mit Bicep so angenehm ist. Erstellen Sie nun eine neue Datei und nennen Sie sie Main.bit. Diese Bicep-Erweiterung weist VSCode an, die Erweiterung zu aktivieren.

Ohne sie schreiben Sie einfach nur Klartext. Mit ihr erhalten Sie die volle Tooling-Erfahrung. Das ist ein kurzes Beispiel. Eine Ressourcengruppenbereitstellung, drei Kurzzeilen. Zuerst legen Sie den Zielbereich auf Abonnement fest, dann definieren Sie die Ressource, eine Ressourcengruppe mit einem Namen und einem Speicherort. Das sind alles drei Zeilen. Vergleichen Sie dies mit dem ARM JSON-Äquivalent, das aus etwa 15 Zeilen mit Klammern und Anführungszeichen besteht. Verwenden Sie zum Bereitstellen die Azure CLI. Da Sie die Bereitstellung im Abonnementbereich durchführen, lautet der Befehl azDeploymentSubCreate. Sie übergeben einen Speicherort für die Bereitstellungsmetadaten und verweisen auf Ihre Bicep-Datei. Dies ist die Befehlszahlmethode, es gibt aber auch eine geführte Benutzeroberfläche. Klicken Sie in VS Code mit der rechten Maustaste auf die Bicep-Datei Bereitstellen aus. Sie werden durch den gesamten Prozess geführt.

Sie werden nach einem Bereitstellungsnamen gefragt, müssen Ihr Abonnement auswählen, eine Ressourcengruppe erstellen oder auswählen und gefragt, ob Sie über eine Parameterdatei verfügen. Sie verneinen diese und die Bereitstellung wird durchgeführt. Das Ergebnis wird in Ihrem Azure Portal angezeigt. Dies entspricht dem Klicken im Portal, aber jetzt verfügen Sie über eine Datei, die Sie wiederverwenden. Sie können es in Ihrem Repository-Committen mit Ihrem Team teilen und morgen erneut ausführen. Und jetzt kommt der Clou. Führen Sie dieselbe Bereitstellung erneut aus und beobachten Sie, was passiert. Die Stärke der Idempotenz. Das Besondere an der Ausführung von Bereitstellungen ist, dass Sie diese immer wieder ausführen können, können, möchten, ohne dass Sie etwas kaputt haben. Genau das bietet Ihnen die Idempotenz. Wenn Sie die Bicep-Datei zum ersten Mal ausführen, wird die Ressourcengruppe erstellt.

Beim zweiten Ausführen passiert jedoch nichts mehr. Kein Fehler, keine Duplikate, gar nichts. Bicep überprüft, was sich bereits in Azure befindet, vergleicht es mit Ihren Anforderungen und gibt an, dass es keine Änderungen gibt. Es wurde nicht versucht, eine neue Ressourcengruppe zu erstellen und es ist kein Fehler mit der Meinung aufgetreten, dass bereits eine vorhandene. Es wurde lediglich bestätigt, dass der aktuelle Status mit dem gewünschten Status übereinstimmt. Stellen Sie sich das wie das Ausführen vom Git-Status für ein leeres Repository vor. Sie müssen nichts weiter tun. Alles ist bereits genau so, wie es sein sollte. Das ist die Stärke von Infrastructure as Code. Sie können Ihre Bereitstellung immer wieder ausführen und erhalten jedes Mal dasselbe Ergebnis. Keine Überraschung, keine Abweichung. Sie wissen genau, was bereitgestellt wird, da es in der Datei steht. Die Datei wird zu Ihrer zentralen Informationsquelle.

Sie müssen sich nie wieder fragen, ob Sie sich an eine Einstellung erinnert haben oder sich mit dem Problem, auf meinem Computer herumschlagen oder im Azure-Portal nachsehen, ob jemand etwas geändert hat, hat, hat, hat, hat. Die Datei gibt Ihnen den aktuellen Standpunkt. Wenn Sie etwas ändern möchten, ändern Sie die Datei und stellen Sie erneut bereit. Wenn Sie dies überprüfen möchten, führen Sie die Bereitstellung erneut aus und es wird bestätigt, dass alles übereinstimmt. So schaffen Sie Vertrauen in Ihre Infrastruktur. Die Datei ist die zentrale Informationsquelle. Nicht Ihre Erinnerung, kein Word-Dokument, kein YouTube-Video von vor sechs Monaten, die Datei. Wie fügt sich BICEP also in das Gesamtbild von Azure ein? Das Gesamtbild, in das BICEP passt. BICEP ist Teil des Azure Resource Manager Ökosystems. Es ist kein separates Tool. Viele denken, dass es das ist, aber es ist eigentlich nur eine bessere Möglichkeit, ARM-Vorlagen zu schreiben.

Im Grunde ist es immer noch ARM, dieselbe Bereitstellungsengine, dieselbe API, alles ist gleich. Der einzige Unterschied besteht in der Schreibweise. Da BICEP in ARM kompiliert wird, funktioniert alles, was mit ARM funktioniert, auch mit BICEP. Azure Policy erzwingt die Compliance für Ihre Bereitstellungen. RBAC steuert, wer was bereitstellen kann. Cost Management verfolgt die Ausgaben für Ihre Ressourcen nach. Azure DevOps und GitHub Actions stellen Ihre BICEP-Dateien über Pipelines bereit. All dies funktioniert einwandfrei, da BICEP standardmäßiges ARM-JSON und so. Durch den Wechsel geht nichts verloren. Wir gewinnen sogar in Klarheit. Microsoft hat ein ganzes Ökosystem rund um BICEP aufgebaut. Azure Verified Modules oder AVM ist eine kuratierte Bibliothek von BICEP und Terraform-Modulen, die Best Practices folgen. Sie müssen nicht alles von Grund auf neu schreiben. Sie können vorgefertigte Module für gängige Muster wie virtuelle Netzwerke, Speicherkonten und App-Dienste verwenden.

Sie werden getestet, gewartet und auf das Well-Architekte-Framework abgestimmt. Das Cloud-Adoption-Framework umfasst BICEP-Referenz-Implementierungen für standardisierte Unternehmensarchitekturen. Wenn Sie eine Zielzone erstellen, gibt es dafür eine BICEP-Vorlage. Bereitstellungsstapel ermöglichen Ihnen die Lebenszyklusverwaltung für Ressourcengruppen. Sie können einen Stapel bereitstellen. Und wenn Sie eine Ressource aus Ihrer BICEP-Datei entfernen, kann der Stapel diese für Sie bereinigen. Oder Sie vor versehentlichem Löschen schützen. Sie entscheiden. Das Ökosystem wächst kontinuierlich mit mehr Modulen, besseren Tools und einer tieferen Integration mit KI und GitHub Copilot. Sie können Ihre Anforderungen in einfachem Englisch beschreiben. Und Copilot generiert den BICEP-Code für Sie. Microsoft investiert weiterhin in BICEP als primäre Erstellungsumgebung für Azure. Daher zielen neue Features in erster Linie auf BICEP.

ARM-Vorlagen funktionieren weiterhin, aber die Innovation findet in BICEP statt. Hier also die Quintessenz. Wenn Sie in Azure arbeiten, ist BICEP der natürliche nächste Schritt nach dem Klicken im Portal. Sie müssen weder Terraform lernen noch am JSON-Persche. Sie installieren zwei Dinge, schreiben ein paar Zeilen Code und stellen eine Infrastruktur bereit, die wiederholbar, versionskontrolliert und zuverlässig ist. Ich möchte Ihnen noch etwas Praktisches mit auf den Weg geben, das Sie heute umsetzen können. Sie wissen nun, was Infrastructure as Code ist, warum es BICEP gibt und wie es Azure-Bereitstellungen vereinfacht. Hier ist der springende Punkt. BICEP ist kein separates Bereitstellungssystem. Es ist eine bessere Möglichkeit, dieselben ARM-Vorlagen zu schreiben, die Sie sowieso schreiben würden und dabei dieselbe Engine und denselben Azure-Resource-Manager im Hintergrund zu verwenden und eine Sprache, die Menschen tatsächlich lesen und schreiben können.

Hier ist eine Aufgabe für Sie. Erstellen Sie eine Datei für Main.BICEP, stellen Sie eine Ressourcengruppe bereit und führen Sie die Bereitstellung zu BICEP. Beobachten Sie, wie es beide Male funktioniert. Beim ersten Mal wird die Ressource erstellt und beim zweiten Mal wird bestätigt, dass sich nichts geändert hat. In diesem Moment macht es Klick und Sie werden feststellen, dass Sie nie wieder im Portal herumklicken möchten. Das ist die Grundlage. Von hier aus können Sie Speicherkonten, virtuelle Netzwerke und App-Dienste nach demselben Muster hinzufügen. Schreiben Sie eine Datei, stellen Sie sie bereit und finden Sie sie erneut. Diese Datei wird zu Ihrer Quelle der Wahrheit und alles andere ergibt sich daraus. Wenn Sie dies hilfreich fanden, leiten Sie es an jemanden weiter, der immer noch im Portal herumklickt. Er wird es Ihnen dankbar. Abonniere den Podcast auf deiner bevollzugten Plattform.

In der nächsten Folge bringen wir BICEP noch weiter, indem wir echte Ressourcen mit echten Eigenschaften bereitstellen.