Benvenuti a un altro episodio delle Microsoft Knowledge Nuggets qui su M365FM. Sono il vostro host Mirko Peters. Avete distribuito risorse Azure cliccando qua e là nel portale. Funziona bene finché non smette di farlo. Poi dovete rifarlo, ma non ricordate esattamente cosa avete scelto. Dovete passare a un collega e lui non riesce a seguire i vostri passaggi. Controllo di versione. Non ce ne lo da sottoporre. E questo è il problema che risolveremo oggi. Alla fine di questo episodio capirete cos'è l'infrastruttura come codice, perché esiste BCHAP e come rende le distribuzioni Azure più semplici e affidabili. Inizieremo dal problema, poi la soluzione. e infine un esempio pratico che potete seguire. Prendete il vostro caffè e iniziamo. Problema del portale. La trappola del clic che distribuisci sembra vedo. Accedete e compilate un modulo, premete Crea, avete finito. Ma cosa succede quando dovete rifarlo con le stesse impostazioni, regione e convenzioni di denominazione?

Dovete ricordare ogni singola cosa che avete scelto ed è lì che le cose vanno a rotoli. La distribuzione manuale significa risultati incoerenti, errore umano e nessuna traccia di audit. Ecco un esempio reale. Qualcuno nel vostro team crea una risorsa con impostazioni leggermente diverse. Ora avete due ambienti che non corrispondono. Uno funziona, l'altro no. E buona fortuna capire il perché. Poi c'è il problema della documentazione. Infrastruttura come documento Word, o peggio, un video YouTube registrato sei mesi fa quando il portale era completamente diverso. Le funzionalità si spostano, i menu cambiano, appaiono nuove opzioni. Mi sono seduto con un product manager del team del portale Azure e ha detto che rilasciano nuove funzionalità due volte al giorno. Due volte al giorno. Il vostro documento Word è obsoleto prima ancora che avete finito di scrivere. Punto è questo. Cliccare qua la va bene per imparare.

Non va bene per adozione. Quindi, qual è l'alternativa? Escrivete un file che descrive ciò che volete, poi dite da azzurro di costruirlo. Cos'è l'infrastruttura come codice? Infrastruttura come codice significa gestire la configurazione cloud con il codice invece di cliccare su un portale web. Ecco l'idea centrale. Escrivete un file che descrive la vostra infrastruttura. Quel file vive nel vostro repository. Potete controllarne la versione, revisionarlo in una pull request e eseguirlo domani per ottenere lo stesso risultato. C'è un termine chiave qui, dichiarativo. Significa che descrivete ciò che volete, non come costruirlo. Non dite ad Azure di creare prima un gruppo di risorse, poi aggiungere un account di archiviazione e poi configurare la rete. Invece tu dici voglio un gruppo di risorse con un account di archiviazione e una rete configurata in questo modo. E Azure stabilisce l'ordine.

Risultato è qualcosa chiamato idempotenza. Eseguilo una volta, eseguilo cento volte e otterrai lo stesso risultato. Questa è la potenza. Pensalo come un progetto rispetto a costruire a mano. Un progetto è ripetibile, condivisibile e revisionabile. Passalo a qualcun altro e costruiranno esattamente la stessa cosa. Diversi strumenti fanno questo. Modelli ARM, Bicep, Terraform, Plumi. Implementano tutti lo stesso concetto in modi diversi. Questa è una distinzione importante. L'infrastruttura come codice è il concetto. Bicep è solo uno strumento che lo implementa. Ma ecco il punto. Azure ha avuto un linguaggio di hash per anni chiamato modelli ARM. E c'è un motivo per cui Microsoft ne ha costruito un nuovo problema dei modelli ARM. I modelli ARM sono il formato IHC original di Azure. Sono file JSON. E hanno molti pregi. Copertura completa di ogni risorsa Azure. E lo stesso motore di distribuzione usato internamente.

Se puoi crearlo nel portale puoi definirlo in un modello ARM. Il quale è il problema? Il JSON è ottimo per le macchine ma terribile per gli esseri umani. Lascio che ti mostri cosa in te. Un account di archiviazione in un modello ARM richiede circa 20 righe di codice. Lo stesso account in Bicep circa 10 righe. La versione JSON è circa il doppio. Queste sono le resource 7. Immagina una distribuzione completa con rete, elaborazione, database e regole di sicurezza. Il modello ARM diventa un muro di testo. I punti critici comuni sono prevedibili. Virgole mancanti, parentesi non corrispondenti, annidamenti prolissi che rendono difficile capire dove finisce una risorsa e ne inizia un'altra. Passi più tempo a combattere con la sintasi JSON che a definire effettivamente la tua infrastruttura. E poi ci sono le dipendenze. In ARM devi dichiarare manualmente depends on. Se la risorsa A ha bisogno che la risorsa B esista prima, devi scriverlo esplicitamente.

Se ne dimentichi una la distribuzione fallisce. Buona fortuna a capire quale hai dimenticato. Se hai mai provato a scrivere un file JSON da 200 righe a mano, non è divertente. Nemmeno un po'. La curva di apprendimento è ripida. I nuovi membri del team faticano a capire i modelli ARM. La barriera all'ingresso è alta. Cosa succede nella pratica? Molti team finiscono con una sola persona che conosce il modello ARM. Quella persona diventa un singolo punto di guasto. È l'unico che può modificare la distribuzione e l'unico che può eseguire il debug quando qualcosa si rompe. Microsoft ha ascoltato il feedback e ha creato ByteShap proprio per risolvere questi problemi. Cos'è Bichap? Quindi cos'è esattamente Bichap? È un linguaggio progettato per distribuire risorse Azure e nel suo cuore è un transpiler. Scrive in Bichap e viene compilato in JSON ARM. Lo stesso motore sottostante ma molto più pulito per scrivere.

E il nome Bichap è in realtà ARM scritto al contrario. Bichap. Un piccolo scherzo interno di Microsoft. Ma una volta che lo vedi in azione ha senso. Bichap si trova sopra ARM invece di sostituirlo. Ottieni la stessa potenza con una sintesi più semplice. Bichap non sostituisce ARM e ci costruisce sopra. Tu ciò che puoi fare con ARM puoi farlo con Bichap. Ogni tipo di risorso, ogni versione API, ogni opzione di configurazione è lì. L'unica differenza è il modo in cui lo scrivo. La sintesi è molto più pulita. Niente virgolette intorno ai nomi delle proprietà, niente virgolette delle proprietà, niente parentesi da gestire. È semplicemente più facile. Confronta le due versioni fianco a fianco. La versione JSON ARM è di un account di archiviazione pieno di rumore. Virgolette virgole, parentesi, annidamento. La versione Bichap ha le stesse informazioni, ma è leggibile. Puoi guardarla e capire immediatamente cosa sta facendo senza dover passare attraverso strati di sintassi JSON.

Un grande miglioramento è l'inferenza automatica delle dipendenze. In ARM devi dichiarare manualmente DependZone. Ma in Bichap, se la risorsa A fa riferimento alla risorsa B, il sistema rileva la dipendenza automaticamente. Non hai bisogno di scriverla. Funzione e basta. E questo da solo fa risparmiare ore di debug. I moduli sono un'altra tasa importante. Puoi dividere la tua infrastruttura in pezzi più piccoli e riutilizzabili e condividerli tra i progetti. Un team crea un modulo di rete e un altro team lo utilizza. Non c'è bisogno di reinventare la ruota ogni volta. Parametri e variabili ti permettono di definire i tuoi input una volta e riutilizzarli ovunque. Niente più ricerche e sostituzioni di valori codificati. E l'interpolazione delle stringhe significa che puoi scrivere prefisso archiviazione invece di complesse funzioni di concatenazione. Gli strumenti sono un altro motivo per cui è piacevole lavorare con Bichap.

L'estensione di VS Code ti offre IntelliSense, evidenziazione della sintassi e controllo degli errori in tempo reale. Onestamente è una delle migliori estensioni di linguaggio in VS Code. Inizia a scrivere e ti suggerisce cosa avviene dopo. Se fai un errore te lo dici immediatamente. Niente più attese per il fallimento di un deployment prima di scoprire che ti sei dimenticato una via. Quindi come appare effettivamente tutto questo alla pratica? Vediamo come Bichap differisce da ARM. Bichap contro ARM cosa cambia realmente? Parliamo di ciò che cambia concretamente quando si scrive in Bichap invece che in ARM.json. La dimensione del file è una differenza evidente. I file Bichap sono circa la metà rispetto ai modelli ARM equivalenti. Non è un'esagerazione. Rimuovi virgolette virgolette parentesi e boilerplate. Resta solo la definizione dell'infrastruttura. Metà del codice stessa il tante. La leggibilità ne guadagna naturalmente.

Meno righe, struttura più pulita e comprensione immediata. Quando apri un file Bichap puoi scansionarlo e capire cosa viene distribuito. Con ARM.json devi attraversare strati di annidamento prima di trovare la configurazione delle risorse. Le dipendenze fanno risparmiare un sacco di tempo. In ARM devi dichiarare manualmente il depend zone. Se ne dimentichi una la distribuzione fa lì. In Bichap, se la risorsa A fa riferimento alla risorsa B il sistema gestisce tutto automaticamente. Aggiunge la dipendenza quando compila in ARM.json. Non devi pensarci, funziona e basta. E questo da solo far risparmiare ore di debugging. I moduli sono un'altra grande differenza. ARM aveva i modelli e i dati, ma erano complessi da gestire. File separati, collegamenti complessi, edifici da versionare. Bichap ha i moduli, che sono più puliti, versionabili e riutilizzabili. Definisci il modulo una volta, lo pubblichi sul registro e lo richiami ovunque.

Stesso modulo, stessa configurazione ogni volta. Il processo di distribuzione in sé è identico. Bichap compila in ARM.json, poi Azure Resource Manager lo distribuisce. Stesso motore, stessa pipeline. Non devi cambiare il tuo processo di distribuzione, solo il modo in cui scrivi i template. Whatif è una funzione che ARM tecnicamente possiede, ma Bichap la rende molto più accessibile. Puoi visualizzare le modifiche prima di distribuire e vedere esattamente cosa verrà creato, modificato o eliminato. Nessuna sorpresa, nessuna cancellazione accidentale. Esegui Whatif, controlli l'output e se è corretto procedi con la distribuzione. La curva di apprendimento è un aspetto in cui Bichap eccelle. ARM.json da per scontato che tu sappia cosa stai facendo. È progettato per le macchine, non per gli esseri umani. Bichap è pensato per i principianti. Si intassi intuitiva ai strumenti che ti guidano. Puoi impararli un pomeriggio ed essere produttivo entro la fine della settimana.

Microsoft ha reso Bichap l'esperienza di scrittura raccomandata. Tre nuove funzionalità e miglioramenti puntano prima su Bichap. I template ARM funzionano ancora e non spariranno, ma probabilmente non dovresti scriverne di nuovi. Se stai iniziando un nuovo progetto oggi, Bichap è la scelta giusta. Tre righe di Bichap per distribuire un gruppo di risorse. Solo tre righe. L'equivalente in ARM.json è di circa 15 righe. Stesso risultato, stesso deployment, ma uno è leggibile e l'altro è solo rumore. Ora potresti chiederti, è Terraform? Dovrei imparare Bichap o Terraform. Bichap contro Terraform, quale dovresti usare? Bentornati su Microsoft Knowledge Nugget. Sono Mirko Peters e oggi affrontiamo una domanda che continua a tornare. Bichap o Terraform? Analizziamolo. Terraform funziona su più cloud. Puoi usarlo per Azure, AWS, GCP o persino tutti e tre insieme. Bichap d'altra parte è creato esclusivamente per Azure.

Questa differenza fondamentale influenza tutto il resto. Ora se lavori su più cloud, Terraform è la scelta giusta. Impari un linguaggio, uno strumento, un flusso di lavoro e funziona ovunque. Ma se usi principalmente Azure, Bichap ha dei veri vantaggi. Ecco il primo. Nessun fa il listato da gestire. Terraform mantiene un file listato che traccia ciò che distribuisce ed è critico. Se si corrompe o non è sincronizzato, hai un serio problema. Devi archiviarlo in sicurezza, farne il backup e gestirne l'accesso. ViceApp comunica direttamente con Azure Resource Manager, verificando cosa c'è già e rilevando le differenze. Nessun file listato significa niente problemi di sincronizzazione e rischi di corruzione. Secondo vantaggio, supporto del giorno C. Quando Microsoft rilascia una nuova funzionalità di Azure, Bichap la supporta immediatamente lo stesso giorno. Terraform deve attendere l'aggiornamento del provider, che a volte è veloce, altre richiede settimane.

Se devi usare subito una nuova funzionalità, Bichap è l'unica opzione. Terzo è creato dal team di Azure. Gli strumenti, gli interi sensi, i messaggi di errore, tutto è progettato su come funziona davvero Azure. Quando scrivi in Bichap, usi un linguaggio che comprende le risorse Azure relativamente. Sa quali proprietà sono richieste, quali valori sono validi e quali dipendenze esistono. Quella profonda integrazione è difficile da replicare con un strumento di terza valore. Puoi anche usarli entrambi. Molte organizzazioni usano Bicep per la piattaforma e la landing zone e Terraform per carichi in multicloud. Non si escludono a vicenda. Puoi scegliere lo strumento giusto per ogni lavoro. La risposta onesta è questa. Per imparare Azure nello specifico, Bicep ha meno componenti da gestire. È un percorso più semplice quando si inizia. Non devi imparare nulla su file di stato, provider o configurazioni di backend.

Installi Azure CLI, apri WS Code e inizia a scrivere. Basta teoria. Parliamo di ciò che ti serve davvero per iniziare. Iniziare. Ciò di cui hai veramente bisogno. Ti servono due cose per iniziare. Azure CLI e l'estensione Bicep per WS Code. Tutto qui. Nessuna CLI Bicep separata da installare. Nessun strumento extra da configurare. Azure CLI include Bicep integrato. Installare Azure CLI è piuttosto semplice. Vai su Microsoft Docs. Trova la pagina installazione per il tuo sistema operativo. Se sei su Mac basta un comando. Bru installa Azure CLI. Su Windows c'è un programma di installazione M6. Scarica la B e l'ho fatto. Funziona anche su Linux tramite il tuo gestore pacchetto. Una volta installato, esegui AZ version per confermare che tutto funzioni. Dovresti vedere elencate sia la versione di Azure CLI che quella di Bicep. Ora apri WS Code, vai nel pannello di estensione a sinistra e cerca Bicep.

Installa quella di Microsoft, non è di terze parti, quella ufficiale. Hai davvero bisogno di questa estensione? Ti offre IntelliSense che suggerisce le proprietà delle risorse mentre scrivi, evidenzia la sintassi per individuare errori a colpo d'occhio e controlla gli sbagli in tempo reale. Vedrai linee ondulate rosse sotto tutto ciò che è sbagliato prima ancora di provare a distribuire. Onestamente, è una delle migliori estensioni di linguaggio in WS Code e una parte importante del motivo per cui Bicep è così piacevole da usare. Ora, crea un nuovo file e chiamano main.bicep. Quell'estensione Bicep dice a WS Code di attivare l'estensione. Senza di essa stai solo scrivendo testo semo. Con essa ottieni l'esperienza completa degli strumenti. Ecco un esempio rapido. Una distribuzione di gruppo di risorse in tre righe di code. Prima imposti l'ambito di destinazione su subscription, poi definisci la risorsa, un gruppo di risorse con un nome e una posizione.

Tu qui tre righe. Confrontalo con l'equivalente ARM JSON che conta circa 15 righe di parentesi, virgolette. Per distribuirlo, usi l'interfaccia Azure CLA. Poiché stai distribuendo all'ambito della sottoscrizione, il comando è a Z da Deployment Subcreate. Passi una posizione per i metadati di distribuzione e punti al tuo file Bicep. Questo è il metodo da righe di comando, ma esiste anche un'esperienza guidata. In WS Code, fai clic destro sul file Byicep e seleziona Deploy Byicep File. Ti guida attraverso l'intero processo. Ti chiede un nome per la distribuzione, di selezionare la sottoscrizione, di creare o selezionare un gruppo di risorse e se hai un file di parametri. E il sistema esegue l'esecuzione. Il risultato appare nel tuo portale azzurro. È come cliccare nel portale, ma ora hai un file che puoi riutilizzare. Puoi confermarlo nel tuo repository, condividerlo con il tuo team ed eseguirlo di nuovo.

Ed ecco la parte magica. Esegui di nuovo lo stesso Deployment e guarda cosa succede. Potere delle impotenze. Ecco il punto riguardo ad eseguire i Deployment. Vuoi poterli eseguire più e più volte senza rompere nulla? Questo è esattamente ciò che ti offre le impotenze. La prima volta che esegui il file Bicep crea il gruppo di risorse, ma la seconda volta non succede nulla. Nessun errore, nessun duplicato, niente. Bicep controlla cosa c'è già in Azure, lo confronta con ciò che è richiesto e dice che non c'è nulla da cambiare. Non ha provato a creare un nuovo gruppo di risorse e non ha restituito errori dicendo che ne esiste già uno. Ha semplicemente confermato che lo stato attuale corrisponde allo stato desiderato. Pensalo come eseguire giz status sul repository pulito. Non c'è nulla da fare. Tutto è già esattamente come dovrebbe essere. Questo è il potere dell'infrastruttura come codice. Puoi eseguire il tuo Deployment ripetutamente e ottenere lo stesso risultato ogni singola volta.

Nessuna sorpresa, nessuna deriva. Sai esattamente cosa hai distribuito perché il file lo dice. Il file diventa la tua unica fonte di verità. Non devi mai chiederti se hai ricordato un'impostazione. Affrontare il problema funziona sul mio PC o cercare nel portale azzurro se qualcuno ha cambiato qualcosa. Il file ti dice cosa c'è lì. Se vuoi cambiare qualcosa, modifichi il file e li distribuisci. Se vuoi verificare, esegui di nuovo il Deployment e confermerà che tutto corrisponde. È così che costruisci fiducia nella tua infrastruttura. Il file è la fonte di verità. Non la tua memoria, non un documento Word, non un video di YouTube di sei mesi fa, il file. Quindi dove si inserisce Bicep nel quadro generale di Azure? Quadro generale dove si inserisce Bicep. Bicep vive all'interno dell'ecosistema di Azure Resource Manager. Non è uno strumento separato. Molti pensano che lo sia, ma in realtà è solo un modo migliore per scrivere modelli ARM.

Sotto il cofano è ancora ARM, lo stesso motore di deployment, la stessa API e tutto quanto. L'unica differenza è come lo scrivi. E poiché Bicep compila in ARM, tutto ciò che funziona con ARM funziona con Bicep. Azure Policy applica la conformità ai tuoi deployment. Airbag controlla chi può distribuire cosa. Cost Management tiene traccia della spesa sulle tue risorse. Azure DevOps e GitHub Actions distribuiscono i tuoi file bicep tramite pipeline. Tutto funziona perfettamente perché Bicep produce JSON ARM Stunner. Non perdi nulla passando a questo. Anzi, guadagni chiarezza. Microsoft ha costruito un intero ecosistema attorno a Bicep. Azure Verified Modules, o AVM, è una libreria curata di moduli Bicep e Terraform che seguono le migliori pratiche. Non devi scrivere tutto da zero. Puoi usare moduli predefiniti per modelli comuni come reti virtuali, account di archiviazione e servizi app. Sono testati, mantenuti e allineati al well-architected framework.

Il Cloud Adoption Framework include implementazioni di riferimento Bicep per architetture aziendali standardizzate. Se stai costruendo una landing zone, esiste un modello Bicep apposta. Gli stack di distribuzione offrono la gestione del ciclo di vita per gruppi di risorse. Puoi distribuire uno stack e se rimuovi una risorsa dal tuo file Bicep lo stack puoi eliminarla per te. Oppure proteggerla da eliminazioni accidente. Decidi tu. L'ecosistema continua a crescere con più moduli, strumenti migliori e una maggiore integrazione con l'EI GitHub Copilot. Puoi descrivere ciò che vuoi in un linguaggio semplice e Copilot genera il codice Bicep per te. Microsoft continua a investire in Bicep come principale esperienza di authoring per Azure. Quindi nuove funzionalità si rivolgono prima a Bicep. I modelli ARM funzionano ancora, ma l'innovazione sta avvenendo in Bicep. Ecco il punto fondamentale. Se lavori in Azure, Bicep è il passo naturale successivo dopo i click nel portale.

Non devi imparare Terraform a padroneggiare il JSON di ARC. Installi due cose, scrivi poche righe di codice e distribuisci un'infrastruttura ripetibile, controllata, tramite versione affidabile. Lascia che ti proponga qualcosa di pratico che puoi fare oggi. Ora sai cos'è l'infrastruttura come codice? Perché esiste Bicep e come semplifica le distribuzioni in Azure? Ecco il concetto principale. Bicep non è un sistema di distribuzione diverso. Da un modo migliore per scrivere gli stessi modelli ARM che scriveresti comunque, usando lo stesso motore e Azure Resource Manager sotto il cofano, ma in un linguaggio che gli umani possono davvero leggere e scrivere. Ecco una sfida per te. Crea un file main.bicep, distribuisci un gruppo di risorse ed esegui la distribuzione due volte. Guarda come funziona entrambe le volte. La prima volta crea la risorsa, la seconda volta conferma che nulla è cambiato.

È il momento in cui scatta la scintilla, quando capisci che non tornerai mai più a cliccare nel portale. Questa è la base. Da qui puoi aggiungere account di archiviazione, reti virtuali, servizi app, usando lo stesso schema. Scrivi un file, distribuisci lo eseguilo di nuovo. Quel file diventa la tua fonte di verità e tutto il resto deriva da esso. Se l'hai trovato utile, condividilo con qualcuno che sta ancora cliccando nel portale. Ti ringrazierà. Iscriviti sulla tua piattaforma podcast preferita. Nel prossimo episodio approfondiremo Bicep distribuendo risorse reali con proprietà reali.