Welkom bij een nieuwe aflevering van Microsoft Knowledge Nuggets hier op M365FM. Ik ben uw host, Mirko Peters. U implementeert Azure Resources door in de portal te klikken. Het werkt prima, totdat het misgaat. Dan moet u het opnieuw doen, maar u weet niet meer precies wat u hebt gekozen. U moet het overdragen aan een teamlid en die kan uw stappen niet volgen. Versiebeheer, er is niets om te committen. Dat is het probleem dat we vandaag gaan oplossen. Aan het einde van deze aflevering begrijpt u wat infrastructure als code is, waarom Bicep bestaat en hoe het Azure implementaties eenvoudiger en betrouwbaarder maakt. We beginnen met het probleem, dan de oplossing en vervolgens een praktisch voorbeeld dat u kunt volgen. Pak een kop koffie en laten we beginnen. Het portalprobleem. De klik om te implementeren. Valkuil voelt snel. U logt in, vult een formulier in, klikt op, maken en klaar. Maar wat gebeurt er als u het opnieuw moet doen met dezelfde instellingen, regio en NAAM-evingsconventie?

Je moet alles wat je hebt gekozen onthouden en dat is waar het misgaat. Want matige implementatie betekent inconsistente resultaten, menselijke fouten en geen addedspoor. Hier is een praktijkvoorbeeld. Iemand in je team maakt een resource aan met iets andere instellingen. Nu heb je twee omgevingen die niet overeenkomen. De ene werkt, de andere niet en veel succes met uitzoeken waarom. Dan is er nog het documentatieprobleem. Infrastructuur als een woorddocument of erger nog, een YouTube-video die zes maanden geleden is opgenomen toen de portal er compleet anders uitzag. Functies worden verplaatst, menu's veranderen, nieuwe opties verschijnen. Ik sprak met een productmanager van het Azure Portal team en hij vertelde dat ze twee keer per dag nieuwe functies uitbrengen. Twee keer per dag. Je woorddocument is verouderd voordat je het hebt afgeschreven. Het punt is, rondklikken werkt prima om te leren, maar niet in een productieomgeving.

Dus wat is het alternatief? Je schrijft een bestand waarin je beschrijft wat je wilt en vervolgens geef je Azure de opdracht om het te bouwen. Wat is infrastructuur als code? Infrastructuur als code betekent dat je je cloudomgeving beheert met code in plaats van door een webportal te klikken. Dit is het kernidee. Je schrijft een bestand dat je infrastructuur beschrijft. Dat bestand staat in je repository en je kunt het versiebeheer toepassen. Het controleren via een pull request en het morgen opnieuw uitvoeren om hetzelfde resultaat te krijgen. Een belangrijk begrip hier is declaratief. Dat betekent dat je beschrijft wat je wilt, niet hoe je het moet bouwen. Je vertelt Azure niet om eerst een resourcegroep aan te maken, dan een opslagaccount toe te voegen en vervolgens de netwerkinstellingen te configureren. In plaats daarvan zeg je ik wil een resourcegroep met een opslagaccount en netwerkinstellingen die op deze manier zijn geconfigureerd.

En Azure bepaalt de volgorde. Het resultaat is iets dat idempotentie wordt genoemd. Voer het één keer uit, voer het honderd keer uit en je krijgt hetzelfde resultaat. Dat is de kracht. Zie het als een blauwdruk versus handmatig bouwen. Een blauwdruk is herhaalbaar, deelbaar en controleerbaar. Geef het aan iemand anders en die bouwt precies hetzelfde. Verschillende tools doen dit. ARM Templates, Bicep, Terraform, Pulumi. Ze implementeren allemaal hetzelfde concept op verschillende manieren. Dat is een belangrijk onderscheid. Infrastructuur als code is het concept. Bicep is slecht één tool die het implementeert. Maar hier komt het. Azure heeft al jaren een IAC-taal genaamd, ARM Schablone. En er is een reden waarom Microsoft een nieuwe heeft ontwikkeld. Het probleem met ARM Schablone. ARM Schablone zijn het oorspronkelijke Azure IAC-formaat. Het zijn JSON-bestanden en ze hebben veel voordelen.

Volledige dekking van elke Azure resource en dezelfde implementatie-engine als die je intern gebruikt. Als je het in de portal kunt maken, kun je het ook in een ARM Schablone definiëren. Dus, wat is het probleem? JSON is geweldig voor machines, maar verschrikkelijk voor mensen. Laat me je laten zien wat ik bedoel. Een opslagaccount in een ARM Schablone vereist ongeveer 20 regels code. Hetzelfde opslagaccount in Bicep, ongeveer 10 regels. De JSON-versie is ongeveer twee keer zo groot. En dat is slechts een simpele resource. Stel je een volledige implementatie voor met netwerken, rekenkracht, databases en beveiligingsregels. De ARM Schablone wordt een muur van tekst. De veel voorkomende pijnpunten zijn voorspelbaar. Ontbrekende komma's, verkeerd geplaatste haakjes. Een ontslachtige structuur waardoor het moeilijk is om te zien waar de ene resource eindigt en de andere begint. Je bent meer tijd kwijt aan het worstelen met de JSON-syntaxis dan aan het daadwerkelijk definiëren van je infrastructuur.

En dan zijn er nog de afhankelijkheden. In ARM moet je afhankelijkheden handmatig declareren. Als resource A resource B nodig heeft, moet je dat expliciet vermelden. Mis je er één, dan mislukt je implementatie. Succes met het uitzoeken welke je bent vergeten. Als je ooit hebt geprobeerd om handmatig een JSON-bestand van 200 regels te schrijven, weet je dat het geen pretje is? Helemaal niet. De leerkurve is stijl. Nieuwe teamleden hebben moeite om ARM templates te begrijpen. De drempel om te beginnen is hoog. En wat gebeurt er in de praktijk? Veel teams hebben uiteindelijk maar één persoon die de ARM template kent. Die persoon wordt een single point of failure. Hij of zij is de enige die de implementatie kan aanpassen en de enige die kan debuggen als er iets misgaat. Dat is niet houdbaar. Microsoft heeft de feedback gehoord en daarom Bicep ontwikkeld om precies deze problemen op te lossen.

Wat is Bicep? Wat is Bicep nu precies? Het is een taal die is ontworpen voor het implementeren van Azure resources en in de kern is het een transpilair. Je schrijft in Bicep en het compileert naar ARM JSON. Dezelfde engine eronder, maar een veel schonere manier van schrijven. En de naam Bicep is eigenlijk ARM achterstevoren gespeld. Bicep. ARM. Een klein grapje van Microsoft. Maar als je het in actie ziet, begrijp je het. Bicep bouwt voort op ARM in plaats van het te vervangen. Je krijgt dezelfde mogelijkheden met een eenvoudigere syntaxis. Bicep vervangt ARM niet, maar bouwt erop voort. Alles wat je met ARM kunt doen, kun je ook met Bicep doen. Elk resource type, elke API versie, elke configuratie optie is er. Het enige verschil is hoe je het schrijft. De syntaxis is veel overzichtelijker. Geen aanhalingstekens rond eigenschapsnamen, geen comma's tussen eigenschappen, geen haakjes om bij te houden.

Het is gewoon eenvoudiger. Vergelijk de twee versies eens naast elkaar. De ARM JSON versie van een opslagaccount zit vol met overbodige informatie. Aanhalingstekens, comma's, haakjes, geneste structuren. De Bicep versie bevat dezelfde informatie, maar is leesbaar. Je kunt ernaar kijken en direct begrijpen wat het doet, zonder door lage JSON syntaxis te hoeven navigeren. Een grote verbetering is de automatische afhankelijkheidsinferentie. In ARM moet je afhankelijkheden handmatig declareren. Maar in Bicep, als resource A verwijst naar resource B, berekent het systeem de afhankelijkheid automatisch. Je hoeft het niet uit te schrijven. Het werkt gewoon. En dat alleen al bespaart uren debuggen. Modules zijn een ander belangrijk onderdeel. Je kunt je infrastructuur opsplitsen in kleinere, herbruikbare onderdelen en deze delen tussen projecten. Het ene team bouwt een netwerkmodule en een ander team gebruikt deze.

Je hoeft het wiel niet elke keer opnieuw uit te vinden. Met parameters en variabelen kun je je invoer één keer definiëren en overal hergebruiken. Geen gedoe meer met het zoeken en vervangen van hardgecodeerde waarden. En string interpolatie betekent dat je prefixopslag kunt schrijven in plaats van complexe concatenatiefuncties. De tooling is nog een reden waarom Bicep zo prettig is om mee te werken. De VS Code extensie biedt Intel iSense, syntax, markering en real-time foutcontrole. Eerlijk gezegd is het een van de beste taal extensies in VS Code. Je begint te typen en het suggereert wat er daarna komt. Maak je een fout, dan krijg je het meteen te horen. Je hoeft niet meer te wachten tot een implementatie mislukt voordat je erachter komt dat je een comma bent vergeten. Maar hoe ziet dit er in de praktijk uit? Laten we eens kijken hoe Bicep verschilt van ARM. Bicep versus ARM, wat is het verschil?

Laten we het hebben over de verschillen wanneer je Bicep gebruikt in plaats van ARM JSON. De bestandsgrootte is een duidelijk verschil. Bicep bestanden zijn ongeveer half zo groot als vergelijkbare ARM templates. Dat is geen overdrijving. Je verwijdert alle aanhalingstekens, comma's, haakjes en boilerplate code en wat overblijft is alleen de infrastructuurdefinitie. De helft van de code, hetzelfde resultaat. Leesbaarheid volgt vanzelf. Minder regels, een schonere structuur en gemakkelijker in één oogopslag te begrijpen. Wanneer je een Bicep bestand opent, kun je het scannen en begrijpen wat er wordt geïmplementeerd. Met ARM JSON moet je door verschillende lagen van geneste structuren heen voordat je de daadwerkelijke resource configuratie vindt. Afhankelijkheden besparen enorm veel tijd. In ARM declareer je handmatig afhankelijkheden. Als je er een mist, mislukt je implementatie. In Bicep, als resource A verwijst naar resource B, handelt het systeem dit automatisch af.

Het voegt de afhankelijkheid toe tijdens het compileren naar ARM JSON. Je hoeft er niet over na te denken, het werkt gewoon. En dat alleen al bespaart uren debuggen. Modules zijn een ander groot verschil. ARM had geneste templates, maar die waren lastig om mee te werken. Aparte bestanden, complexe koppelingen, moeilijk te versioneren. Bicep heeft modules, die overzichtelijker, versioneerbaar en herbruikbaar zijn. Je definieert een module één keer, publiceert deze naar een register en verwijst er overal naar. Dezelfde module, dezelfde configuratie elke keer. Het implementatieproces zelf is identiek. Bicep compileert naar ARM JSON en vervolgens implementeert Azure Resource Manager het. Dezelfde engine, dezelfde pipeline. Je hoeft je implementatieproces niet te veranderen. Je hoeft alleen de manier waarop je de schablonen schrijft aan te passen. De WhatEF-functie is technisch gezien beschikbaar in ARM, maar Bicep maakt deze veel toegankelijker.

Je kunt wijzigingen bekijken voordat je ze implementeert en precies zien wat er wordt aangemaakt. Gewijzigd of verwijderd. Geen verrassingen, geen onbedoelde verwijderingen. Je voert de WhatEF-test uit, bekijkt de uitvoer en als alles er goed uitziet, implementeer je. De leerkurve is een van de sterke punten van Bicep. ARM JSON gaat ervan uit dat je weet wat je doet. Het is ontworpen voor machines, niet voor mensen. Bicep is ontworpen voor beginners. Intuitieve syntaxes, tools die je begeleiden. Je kunt het in een middag leren en aan het einde van de week al productief zijn. Microsoft heeft Bicep aangewezen als de aanbevolen ontwikkelomgeving. Alle nieuwe functies en verbeteringen zijn eerst gericht op Bicep. ARM-schablonen werken nog steeds en zullen niet verdwijnen, maar je zou waarschijnlijk geen nieuwe moeten schrijven. Als je vandaag een nieuw project start, is Bicep de beste keuze.

Drie regels Bicep om een resource groep te implementeren. Slechts drie regels. De equivalente ARM JSON is ongeveer 15 regels. Hetzelfde resultaat, dezelfde implementatie, maar de ene is leesbaar en de andere is rommel. Nu vraag je je misschien af, een Terraform dan? Moet ik Bicep of Terraform leren? Aanhalingsteken. Bicep versus Terraform. Welke moet je gebruiken? Welkom terug bij Microsoft Knowledge Nuggets. Ik ben Mirko Peters en vandaag behandelen we een vraag die steeds terugkomt. Bicep of Terraform. Laten we het eens nader bekijken. Terraform werkt in meerdere clouds. Je kunt het gebruiken voor Azure, AWS, GCP of zelfs alle drie tegelijk. Bicep daarentegen is gebouwd voor Azure en niets anders. Dat fundamentele verschil heeft invloed op alles. Als je in meerdere clouds werkt, is Terraform de beste keuze. Je leert één taal, één tool, één workflow en het werkt overal. Maar als je voornamelijk met Azure werkt, heeft Bicep een aantal echte voordelen.

Hier is de eerste, geen statusbestand om te beheren. Terraform houdt een statusbestand bij dat bijhoud wat er wordt geïmplementeerd en dat bestand is cruciaal. Als het beschadigd raakt of niet meer gesynchroniseerd is, heb je een serieus probleem. Je moet het veilig opslaan, er een backup van maken en de toegang beheren. Bicep communiceert rechtstreeks met Azure Resource Manager, controleert wat er al aanwezig is en achterhaalt de verschillen. Geen statusbestand betekent geen synchronisatieproblemen en geen risico op beschadiging. Een tweede voordeel is ondersteuning vanaf dag één. Wanneer Microsoft een nieuwe Azure functie uitbrengt, ondersteunt Bicep deze direct dezelfde dag nog. Terraform moet wachten op een provider update, wat soms snel gaat, maar soms ook weken duurt. Als je een nieuwe functie direct nodig hebt, is Bicep de enige optie. Ten derde is het ontwikkeld door het Azure team. De tools, de IntelliSense, de foutmeldingen, alles is ontworpen op basis van hoe Azure daadwerkelijk werkt.

Wanneer je Bicep schrijft, gebruik je een taal die Azure Resources Native begrijpt. Het weet welke eigenschappen vereist zijn, welke waarden geldig zijn en welke afhankelijkheden er bestaan. Die diepe integratie is moeilijk te repliceren met een tool van derde. Je kunt ze ook allebei gebruiken. Veel organisaties gebruiken Bicep voor platform en landingzones en Terraform voor multicloud workloads. Ze sluiten elkaar niet uit. Je kunt voor elke taak de juiste tool kiezen. Het eerlijke antwoord is dit. Specifiek voor het leren van Azure heeft Bicep minder complexe onderdelen. Het is een eenvoudigere aanpak voor beginners. Je hoeft niets te leren over statusbestanden, providers of back-end configuratie. Je installeert Azure CLI, opent VS-code en begint met schrijven. Genoeg theorie. Laten we het hebben over wat je daadwerkelijk nodig hebt om te beginnen. Aan de slag. Wat je echt nodig hebt. Je hebt twee dingen nodig om te beginnen. Azure CLI en de Bicep-extensie voor VS-code.

Dat is alles. Geen aparte Bicep CLI om te installeren. Geen extra tools om te configureren. Azure CLI wordt geleverd met Bicep ingebouwd. Het installeren van Azure CLI is vrij eenvoudig. Ga naar Microsoft Docs. Zoek de installatiepagina voor je besturingssysteem. Op een Mac is het één commando, accentgraven, brew install, Azure CLI accentgraven. Op Windows is er een MSI-installatieprogramma. Download het, voer het uit, klaar. Het werkt ook op Linux via je pakketbeheerder. Nadat het is geïnstalleerd, voer je AZ-version uit om te controleren of alles werkt. Je zou zowel de Azure CLI-versie als de Bicep-versie moeten zien staan. Open nu VS-code. Ga naar het extensiepaneel aan de linkerkant en zoek naar Bicep. Installeer de versie van Microsoft, niet die van een derde partij, maar de officiële. Je hebt deze extensie echt nodig. Het biedt Intel iSense die suggesties geeft voor resource-eigenschappen terwijl je typt, markeert syntax zodat je fouten in één oogopslag kunt zien en controleert in realtime op fouten.

Je ziet rode golvende lijnen onder alles wat fout is, nog voordat je probeert te implementeren. Eerlijk gezegd is het een van de beste taal extensies in VS-code en een belangrijke reden waarom Bicep zo prettig is om mee te werken. Maak nu een nieuw bestand aan en noem het main, Bicep. Die Bicep-extensie vertelt VS-code dat de extensie geactiveerd moet worden. Zonder deze extensie schrijf je gewoon platte tekst. Met de extensie krijg je de volledige tooling ervaring. Hier is een kort voorbeeld, een implementatie van een resource-groep in slechts drie regels-code. Eerst stelt u het doelbereik in op abonnement, vervolgens definieert u de resource, een resource-groep met een naam en een locatie. Dat is alles, drie regels. Vergelijk dat eens met het ARM JSON-equivalent, dat bestaat uit ongeveer 15 regels met haakjes en aanhalingstekens. Om dit te implementeren, gebruikt u de Azure CLI. Omdat u implementeert op abonnementsniveau, is de opdracht accentgraven az-deployment-sub-create accentgraven.

U geeft een locatie op voor de implementatie-metadata en verwijst naar uw BICEP-bestand. Dat is de manier via de opdrachtregel, maar er is ook een begeleide methode. Klik in VS-code met de rechter muisknop op het BICEP-bestand en selecteer BICEP-bestand implementeren. U wordt door het hele proces geleid. Er wordt gevraagd om een implementatie-naam, uw abonnement, of u een resource-groep wilt maken of selecteren, en of u een parameter-bestand hebt. U zegt nee en de implementatie wordt uitgevoerd. Het resultaat verschijnt in uw Azure-portal. Net zoals wanneer u in de portal rondklikt, maar nu hebt u een bestand dat u kunt hergebruiken. Je kunt het vastleggen in je repository, delen met je team en het morgen opnieuw uitvoeren. En hier komt het magische gedeelte. Voer dezelfde implementatie opnieuw uit en kijk wat er gebeurt. De kracht van idempotentie. Het punt met het uitvoeren van implementaties is dat je ze steeds opnieuw wilt kunnen uitvoeren zonder dat er iets kapot gaat.

Dat is precies wat idempotentie je biedt. De eerste keer dat je het BICEP-bestand uitvoert, maakt het de resource-groep aan, maar de tweede keer dat je het uitvoert, gebeurt er niets. Geen foutmelding, geen duplicaat, niets. BICEP controleert wat er al in Azure staat, vergelijkt het met wat je hebt aangevraagd en zegt dat er niets hoeft te worden gewijzigd. Het heeft niet geprobeerd een nieuwe resource-groep aan te maken en het heeft geen foutmelding gegeven dat er al een bestaat. Het heeft alleen bevestigd dat de huidige status overeenkomt met de gewenste status. Zie het als het uitvoeren van accentgraven gidsstatus accentgraven op een schone repository. Er is niets te doen. Alles is al precies zoals het hoort. Dit is de kracht van infrastructuur als code. Je kunt je implementatie keer op keer uitvoeren en elke keer hetzelfde resultaat krijgen. Geen verrassingen, geen afwijkingen. Je weet precies wat er is geïmplementeerd, omdat het bestand dat aangeeft.

Het bestand wordt je enige bron van waarheid. Je hoeft je nooit af te vragen of je een instelling wel hebt onthouden... ...of te worstelen met het probleem dat het op jouw machine wel werkt... ...of door de Azure portal te zoeken om te controleren of iemand iets heeft gewijzigd. Het bestand vertelt je wat er is. Als je iets wilt wijzigen, wijzig je het bestand en voer je de implementatie opnieuw uit. Als je wilt controleren, voer je de implementatie opnieuw uit en bevestig deze dat alles overeenkomt. Zo bouw je vertrouwen op in je infrastructuur. Het bestand is de bron van waarheid. Niet je geheugen, niet een woorddocument, niet een YouTube-video van zes maanden geleden, maar het bestand. Dus, waar past Bicep in het grotere geheel van Azure? Het grotere geheel waar Bicep in past. Bicep maakt deel uit van het Azure Resource Manager ecosysteem. Het is geen aparte tool. Veel mensen denken van wel, maar het is eigenlijk gewoon een betere manier om ARM schablonen te schrijven.

Onder de motorkap is het nog steeds ARM, dezelfde implementatie-engine, dezelfde API, alles is hetzelfde. Het enige verschil is hoe je het schrijft. En omdat Bicep compileert naar ARM, werkt alles wat met ARM werkt ook met Bicep. Azure Policy zorgt voor naleving van de regels voor je implementaties. RBAC bepaalt wie wat mag implementeren. Kostenbeheer houdt de uitgaven voor je resources bij. Azure DevOps en GitHub Actions implementeren je Bicep bestanden via pipelines. Dit werkt allemaal perfect omdat Bicep standaard ARM JSON produceert. Je verliest niets door over te stappen. Sterker nog, je wint aan duidelijkheid. Microsoft heeft een compleet ecosysteem rond Bicep gebouwd. Azure Verified Modules, AVM, is een samengestelde bibliotheek met Bicep en Terraform modules die de best practices volgen. Je hoeft niet alles helemaal zelf te schrijven. Je kunt vooraf gebouwde modules gebruiken voor veelvoorkomende patronen zoals virtuele netwerken, opslagaccounts en app services.

Ze zijn getest, onderhouden en afgestemd op het Well-Architected Framework. Het Cloud Adoption Framework bevat referentie-implementaties van Bicep voor gestandardiseerde bedrijfsarchitecturen. Als je een landingzone bouwt, is er een Bicep-schabloon voor. Implementatiestacks bieden je levenscyclus beheer voor groepen resources. Je kunt een stack implementeren en als je een resource uit je Bicep-bestand verwijderd, kan de stack deze voor je opruimen. Of beschermen tegen onbedoelde verwijdering. Jij beslist. Het ecosysteem blijft groeien met meer modules, betere tools en een diepere integratie met AI en GitHub Copilot. Je kunt in eenvoudige taal beschrijven wat je wilt en Copilot genereert de Bicep-code voor je. Microsoft blijft investeren in Bicep als de belangrijkste auteurservaring voor Azure. Nieuwe functies zijn daarom eerst gericht op Bicep. Arm-schablonen werken nog steeds, maar de innovatie vindt plaats in Bicep.

Kortom, als je in Azure werkt, is Bicep de logische volgende stap na het openen van de portal. Je hoeft Terraform niet te leren of Arm-JSON te beheersen. Je installeert twee dingen, schrijft een paar regelscode en je implementeert infrastructuur die herhaalbaar, versiebeheerd en betrouwbaar is. Laat ik je afsluiten met iets praktisch dat je vandaag nog kunt doen. Je weet nu wat infrastructuur als code is, waarom Bicep bestaat en hoe het Azure implementaties vereenvoudigt. Hier komt het belangrijkste punt, Bicep is geen ander implementatiesysteem. Het is een betere manier om dezelfde Arm-schablonen te schrijven die je sowieso al zou schrijven, met dezelfde Engine en Azure Resource Manager, maar dan in een taal die mensen daadwerkelijk kunnen lezen en schrijven. Hier is een uitdaging voor je. Maak een Main-Bicep bestand aan, implementeer een resource groep en voer de implementatie twee keer uit.

Kijk hoe het beide keren werkt. De eerste keer wordt de resource aangemaakt en de tweede keer wordt bevestigd dat er niets is veranderd. Dat is het moment waarop je het snapt, waarop je beseft dat je nooit meer in de portal hoeft te klikken. Dit is de basis. Vanuit hier kun je opslagaccounts, virtuele netwerken en app-services toevoegen volgens hetzelfde patroon. Schrijf een bestand, implementeer het en voer het opnieuw uit. Dat bestand wordt je bron van waarheid en alles wat je verder doet, vloeit daaruit voort. Vond je dit nuttig? Deel het dan met iemand die nog steeds aan het rondklikken is in het portaal. Diegene zal je dankbaar zijn. Abonneer je op je favoriete podcast platform en in de volgende aflevering gaan we met Bicep een stap verder door echte middelen in te zetten bij echte projecten. Dankjewel.