Bem-vindos a mais um episódio de Pílulas de Conhecimento Microsoft aqui na M305FM. Eu sou o Zezé Fiderão Mirko Pit. Você tem implantado recursos do Azure clicando pelo portal, funciona bem até que deixe de funcionar. Então você precisa fazer de novo, mas não consegue lembrar exatamente o que escolheu. E aí precisa passar a tarefa para um colega e ele não consegue seguir seus passos. Por diversão, não há nada para enviar. Esse é o problema que vamos resolver hoje. Ao final deste episódio, você entenderá o que é infraestrutura como código, por que o Bicep existe e como ele torna as implantações no Azure mais simples e confiáveis. Começaremos com o problema e depois a solução. Em seguida, é um exemplo prático que você pode seguir. Pegue seu café e vamos começar. Problema do portal. A armadilha do clicar para implantar aparece rápido. Você faz login, preenche o formulário, clica em criar e pronto.

Mas o que acontece quando você precisa fazer de novo com as mesmas configurações, região e convenção de nomenclatura? Você tem que lembrar de cada detalhe que escolheu, e aí que tudo desmorona. Implantação manual significa resultados inconsistentes, erro humano e nenhum rastro de auditoria. Aqui está um exemplo do mundo real. Alguém na sua equipe cria um recurso com configurações ligeiramente diferentes. Agora você tem dois ambientes que não correspondem. Um funciona, o outro não. E boa sorte tentando descobrir o porquê. E tem um problema da documentação. Infraestrutura como um documento Word ou pior. Um vídeo do YouTube gravado há seis meses quando o portal parecia completamente diferente. Recursos mudam, menus são alterados, novas opções aparecem. Eu conversei com o gerente de produto da equipe do portal do Azure, e ele disse que lança novos recursos duas vezes ao dia. Duas vezes ao dia.

Seu documento Word fica obsoleto antes mesmo de você terminar de escrever. O ponto é o seguinte. Clicar pelo portal funciona para render. Falha para produção. Então qual é a alternativa? Você escreve um arquivo que descreve o que deseja. Então diz o Azure para construir. A infraestrutura como código. Infraestrutura como código significa gerenciar sua configuração de nuvem com código em vez de clicar em um portal. Aqui está a ideia central. Você escreve um arquivo que descreve sua infraestrutura. Esse arquivo vive no seu repositório. E você pode controlar a versão dele, revisá-lo em um pull request e executá-lo novamente amanhã para obter o mesmo resultado. Há um termo-chave aqui, declarativo. Isso significa que você descreve o que quer, não como construir. Ainda não diz ao Azure, primeiro crie um grupo de recursos, depois adicione uma conta de armazenamento e depois configure a rede. Em vez disso você diz, eu quero um grupo de recursos com uma conta de armazenamento e rede configurados desta maneira.

E o Azure define a ordem. O resultado é algo chamado idempotência. Execute uma vez, execute cem vezes. Você terá o mesmo resultado. Esse é o poder. Pense nisso como um projeto estrutural versus construir uma mãe. Um projeto é repetível, compartilhável e revisável. Entregue a outra pessoa e elas construíram exatamente a mesma coisa. Agora, várias ferramentas sozinhas. Modelos ARM, Bicep, Terraform, Pullume. Todas elas implementam o mesmo conceito de maneiras diferentes. Essa é uma distinção importante. Infraestrutura como código é o conceito. Bicep é apenas uma ferramenta que o implementa. Mas a questão. O Azure tem uma linguagem de ASEAN chamada modelos ARM. E há uma razão para a Microsoft ter criado uma nova. Problema dos modelos ARM. Os modelos ARM são o formato original de S2. Eles são arquivos JSON e têm muitas vantagens. Cobertura total de todos os recursos do Azure. E o mesmo mecanismo de implantação usado internamente.

Se você pode criá-lo no portal, pode defini-lo em um modelo ARM. Então qual é o problema? JSON é ótimo para máquinas, mas terrível para humano. Deixa eu te mostrar o que quero dizer. Uma conta de armazenamento em um modelo ARM leva cerca de 20 linhas de código. A mesma conta de armazenamento no Bicep cerca de 10 linhas. A versão em JSON é praticamente o dobro. E isso é apenas um recurso simples. Imagina uma implantação completa com rede, computação, bancos de dados e regras de segurança. O modelo ARM se torna uma parede de texto. Os pontos problemáticos comuns são previsíveis. Vírgulas faltando, colchetes incompatíveis, alinhamento prolixo que dificulta saber onde um recurso termina e outro começa. Você gasta mais tempo lutando com a sintaxe JSON do que definindo sua infraestrutura. E ainda tem as dependências. No ARM você precisa declarar manualmente ou depends on. Se o recurso A precisa que o recurso B exista primeiro, você deve escrever isso explicitamente.

Esqueça 1 e sua implantação falhará. Boa sorte tentando descobrir qual você esqueceu. Se você já tentou escrever um arquivo JSON de 200 linhas manualmente, não é divertido. Nem um pouco. Curva de aprendizado é íngreme. Novos membros da equipe lutam para entender os modelos ARM. A barreira de entrada é alta. E o que acontece na prata? Muitas equipes acabam com uma pessoa que conhece o modelo ARM. Essa pessoa se torna um ponto único de falha. Eles são os únicos que podem modificar a implantação e os únicos que podem depurá-la quando algo quebra. Isso não é sustentável. A Microsoft ouviu o feedback e criou o Bicep para resolver exatamente esses problemas. O Bicep. Então o que exatamente é o Bicep? É uma linguagem projetada para implantar recursos no Azure e em sua essência é um transpiler. Você escreve em Bicep e ele compila para JSON do ARM. O motor é o mesmo, mas a forma de escrever é muito mais limpa.

E o nome Bicep é na verdade a ARM escrito traz para frente Bicep. Uma pequena piada interna da Microsoft. Mas quando você vem em ação faz todo sentido. O Bicep fica acima do ARM em vez de substituí-lo? Ou você obtém o mesmo poder com uma sintaxe mais simples? O Bicep não substitui o ARM, ele é construído sobre ele. Tudo o que você pode fazer com ARM você pode fazer com o Bicep. Cada tipo de recurso, cada versão de API, cada opção de configuração está lá. A única diferença é como você escreve. A sintaxe é muito mais limpa. Sem aspas nos nomes das propriedades, sem vírgulas entre propriedades, sem colchetes para acompanhar. É simplesmente mais simples. Compara as duas versões lado a lado. A versão em JSON do ARM de uma conta de armazenamento é cheia de ruim. Aspas, vírgulas, colchetes, alinhamento. A versão em Bicep tem a mesma informação, mas é legível. Você pode olhar e entender imediatamente o que está fazendo, sem precisar passar por camadas de sintaxe JSON.

Uma grande melhoria é a inferência automática de dependências. No ARM você precisa declarar manualmente o DependZone. Mas no Bicep, se o recurso A referencia o recurso B, o sistema descobre a dependência automaticamente. Você não precisa escrever isso. Simples funciona. E só isso já economiza horas de depuração. Os modos são outra grande parte. Você pode dividir sua infraestrutura em peças menores e reutilizáveis e compartilhá-las entre projetos. Uma equipe cria um módulo de rede e outra equipe o utiliza. Não há necessidade de reinventar a roda toda vez. Parâmetros e variáveis permitem definir suas entradas uma vez e reutilizá-las em todos os lugares. Chega de procurar e substituir valores fixos. E a interpolação de string significa que você pode escrever o prefixo do armazenamento em vez de funções complexas de concatenação. As ferramentas são outra razão pela qual o Bicep é tão bom de trabalho.

A extensão do VS Code oferece intelicense, destaque de sintaxe e verificação de erros em tempo real. Honestamente, é uma das melhores extensões de linguagem no VS Code. Você começa a digitar e ele sugere o que vem a seguir. Se cometer um erro, ele avisa imediatamente. Chega de esperar uma implantação falhar para descobrir que você esqueceu uma vírgula. Então como isso realmente funciona na prática? Vamos ver como o Bicep difere do arm. Bicep versus arm, o que é realmente diferente? Vamos falar sobre o que realmente muda quando você escreve em Bicep em vez de arm e JSON. O tamanho do arquivo é uma diferença óbvia. Arquivos Bicep tem aproximadamente metade do tamanho de templates ARM equivalentes. Isso não é um exagero. Você remove todas as aspas, vírgulas, colchetes e clichês, e o que resta é apenas a definição da infraestrutura. Metade do código mesmo, tá? A legibilidade vem naturalmente.

Menos linhas e estrutura mais limpa e mais fácil de entender rapidamente. Ao abrir um arquivo Bicep, você pode analisá-lo e entender o que está sendo implantado. Com o ARM JSON, você precisa passar por camadas de alinhamento antes de encontrar a configuração real do recurso. Dependências são uma enorme economia de tempo. No ARM, você declara manualmente o DependZone. Se esquecer uma implantação falha. No Bicep, se o recurso A referencia o recurso B, o sistema cuida disso automaticamente. Ele adiciona dependência quando compila para ARM de ISO. Você não precisa pensar nisso, simplesmente funciona. E só isso economiza horas de depuração. Modo de diferença é importante. O ARM tinha templates alinhados, mas era trabalhoso trabalhar com ele. Arquivos separados, links complexos de oficina. O Bicep possui módulos que são mais limpos, versionáveis e reutilizáveis. Você define um módulo uma vez. Publica em um registro e referencia de qualquer lugar.

O mesmo módulo, a mesma configuração sempre. O processo de implantação em si é idêntico. O Bicep compila para ARM JSON e então o Azure Resource Manager faz a implantação. O mesmo mecanismo, o mesmo pipeline. Você não precisa mudar seu processo de implantação. Apenas muda como escreve os templates. What If é um recurso que o ARM tecnicamente possui, mas o Bicep o torna muito mais acessível. Você pode visualizar as alterações antes de implantar e ver exatamente o que será criado, modificado ou excluído. Sem surpresas, sem exclusões acidentais. Executa o What If e revisa o resultado. E se é tudo certo, você implanta. O Word de aprendizado é uma área onde o Bicep se destaca. O ARM de JSON assume que você sabe o que está fazendo. Ele foi projetado para máquinas, não para humanos. O Bicep foi projetado para iniciantes. Sintaxe intuitiva, ferramenta a você. Você pode aprender uma tarde e ser produtivo até o final da semana.

A Microsoft tornou o Bicep a experiência de criação recomendada. Todos os novos recursos e melhorias priorizam o Bicep. Templates ARM ainda funcionam e não vão desaparecer, mas você provavelmente não deveria criar novos. Se você está começando um novo projeto hoje, o Bicep é o caminho a seguir. Três linhas de Bicep para implantar um grupo de recurso. Apenas três linhas. O ARM JSON equivalente tem cerca de 15 linhas. Mesmo resultado, mesma implantação, mas um é legível e o outro é ruído. Agora você pode estar se perguntando, e o Terraform? Devo aprender Bicep ou Terraform? Bicep versus Terraform, qual você deve usar? Bem-vindo de volta ao Microsoft Nottingham. Eu sou Mirko Peters e hoje abordaremos uma dúvida recorrente. Bicep ou Terraform? Vamos analisar. O Terraform funciona em várias nuvens. Você pode usá-lo para Azure, AWS, GCP ou até nas três ao mesmo tempo. O Bicep, por outro lado, foi criado para o Azure e nada mais.

Essa diferença fundamental afeta todo o resto. Se você trabalha com várias nuvens, o Terraform é o caminho. Você aprende uma linguagem, uma ferramenta, um fluxo e funciona em toda parte. Mas, se você é focado em Azure, o Bicep traz vantagens reais. Aqui está a primeira. Sem arquivo de estado para gerenciar. Terraform mantém um arquivo de estado que rastreia o que é implantado, e ele é crítico. Se ele for corrompido ou perder a sincronia, você terá um problema sério. Você precisa armazená-lo com segurança, fazer backup e gerenciar o acesso. O Bicep fala diretamente com o Azure Resource Manager, verificando o que já existe e as diferenças. Sem arquivo de estado significa sem problemas de sincronia e risco de corrupção. Segunda vantagem, suporte imediato. Quando a Microsoft lança um novo recurso no Azure, o Bicep o suporta no mesmo dia. Terraform precisa esperar a atualização do provedor, que às vezes demora semanas.

Se você precisa usar um novo recurso imediatamente, o Bicep é a única opção. Esse seria ele criado pela equipe do Azure. As ferramentas, o IntelliSense, as mensagens de erro, tudo desenhado para o Azure. Ao escrever em Bicep, você usa uma linguagem que entende recursos Azure inativamente. Ele sabe quais propriedades são obrigatórias, quais valores são válidos e quais dependências. Essa integração profunda é difícil de replicar com ferramentas de terceiro. Você também pode usar ambos. Muitas empresas usam o Bicep para plataformas e zonas de destino e Terraform para cargas multi-cloud. Eles não são mutuamente exclusivos. Você pode escolher a ferramenta certa para cada tarefa. A resposta honesta é esta. Para aprender a Azure especificamente, o Bicep tem menos partes móveis. Um caminho mais simples para quem está começando. Você não precisa aprender sobre arquivos de estado, provedores ou configuração de backend.

Você instala o Azure CLA e abre o VS Code e começa a escrever. Chega de teoria. Vamos falar sobre o que você realmente precisa para começar. Começando. O que você realmente precisa. Você precisa de duas coisas para começar. Azure CLA e a extensão Bicep para o VS Code. É só isso. Não há Bicep CLI separado para instalar nem ferramentas extras para configurar. O Azure CLA já vem com o Bicep integrado. Instalar o Azure CLA é bem simples. Dá para a documentação da Microsoft. Encontre a página de instalação para o seu sistema operacional. Se você usa Mac, é apenas um comando. No Windows há um instalador MSI. Baixe Execute e pronto. Também funciona no Linux através do seu gerenciador de pacote. Uma vez instalado, execute a Zversion para confirmar se tudo está funcionando. Você deve ver a versão do Azure CLA e a do Bicep listadas. Agora, abra o VS Code e vá para o painel de extensões à esquerda e pesquise por Bicep.

Instale a da Microsoft. Não é de terceiro, só oficial. Você realmente precisa dessa extensão. Ela oferece a IntelliSense que sugere propriedade de recursos enquanto você digita, destaca a sintaxe para identificar erros rapidamente e verifica falhas em tempo real. Você verá linhas onduladas vermelhas sobre qualquer erro antes mesmo de tentar implantar. Honestamente, é uma das melhores extensões de linguagem no VS Code e uma grande razão pela qual o Bicep é tão agradável de usar. Agora, crie um novo arquivo no meio como main.bicep. Essa extensão Bicep diz ao VS Code para ativar o suporte de linguagem. Sem ela, você estaria apenas escrevendo o texto sim. Com ela, você obtém a experiência completa da ferramenta. Questão, exemplo rápido. Uma implantação de grupo de recursos em três linhas de cor. Primeiro, defina o escopo de destino com uma assinatura. Depois, defina o recurso, um grupo de recursos com nome e localização.

É isso, três linhas. Compare isso ao equivalente em ARM JSON, que tem cerca de 15 linhas de colchetes e aspas. Para implantar, você usa o Azure CLI. Como você está implantando no escopo de assinatura, o comando é az-deployment-subcreate e apassa uma localização para os metadados da implantação e aponta para o seu arquivo Bicep. Esse é o método via linha de comando, mas também existe uma experiência guiada. No VS Code, clique com o botão direito no arquivo Bicep e selecione Deploy Bicep File. Ela te guia por todo o processo. Pede um nome para a implantação. Solicita que selecione sua assinatura, que crie ou selecione um grupo de recursos e pergunta se você tem um arquivo de parâmetros. Você diz não, ele faz a implantação. O resultado aparece no seu portal do usuário. É o mesmo que clicar no portal, mas agora você tem um arquivo que pode reutilizar. Você pode fazer o commit no seu repositório, compartilhar com sua equipe e executar novamente amanhã.

E aqui está a parte mágica. Execute a mesma implantação novamente. Observe o que acontece. Poder da impotência. Que está o ponto sobre executar implantações? Você quer ser capaz de executá-las repetidamente sem quebrar nada? É exatamente isso que ele proporciona. Na primeira vez que você executa o arquivo Bicep, ele cria o grupo de recursos, mas na segunda vez, nada acontece. Sem erro, sem duplicata, nada. O Bicep verifica o que já existe no Azure, compara com o que você solicitou e diz que não há nada a mudar. Ele não tentou criar um novo grupo de recursos e não gerou erro dizendo que um já existe. Ele apenas confirmou que o estado atual corresponde ao estado desejado. Pense nisso como executar o git status em um repositório limpo. Não há nada a ser feito. O doge está exatamente como deveria estar. Este é o poder da infraestrutura como código. Você pode executar sua implantação repetidamente e obter o mesmo resultado sempre.

Sem surpresas, sem desvios. Você sabe exatamente o que está implantado porque o arquivo diz isso. O arquivo se torna a sua única fonte da verdade. Você nunca precisa se perguntar se esqueceu uma configuração. Lidar com o problema de na minha máquina funciona ou procurar no portal do Azure se alguém mudou algo. O arquivo lhe diz que está lá. Se quiser mudar algo, você altera o arquivo e implanta novamente. Se quiser verificar, execute a implantação novamente e ele confirmará que tudo corresponde. É assim que você constrói confiança na sua infraestrutura. O arquivo é a fonte da verdade. Não a sua memória, não um documento do Word, não um vídeo do YouTube de seis meses atrás. O arquivo. Onde o Bicep se encaixa no cenário geral do Azure. Cenário geral. Onde o Bicep se encaixa. O Bicep vive dentro do ecossistema do Azure Resource Management. É uma ferramenta separada. Muitas pessoas pensam que é, mas na verdade é apenas uma forma melhor de escrever modelos ARM.

Por baixo do capô ainda é ARM, mesmo motor de implantação, mesmo API, tudo igual. A única diferença é como você o escreve. E como o Bicep compila para ARM, tudo que funciona com ARM funciona com o Bicep. O Azure Policy impõe conformidade nas suas implantações. O RBI controla quem implanta o quê? Cost Management rastreia os gastos nos seus recursos. O Azure DevOps e o GitHub Actions implantam seus arquivos Bicep via pipelines. Tudo funciona perfeitamente porque o Bicep produz JSON ARM padrão. Você não perde nada ao mudar. Na verdade, você ganha clareza. A Microsoft construiu todo um ecossistema em torno do Bicep. O Azure Verified Modules, ou AVM, é uma biblioteca selecionada de módulos Bicep e Terraform que seguem as melhores práticas. Você não precisa escrever tudo do zero. Você pode usar módulos pré-criados para padrões comuns, como redes virtuais, contas de armazenamento e serviços de aplicativo.

Eles são testados, mantidos e alinhados com o Well-Architected Framework. O Cloud Adoption Framework inclui implementações de referência em Bicep para arquiteturas corporativas padronizadas. Se você está criando uma zona de destino landing zone, existe um modelo Bicep. As pilhas de implantação oferecem gerenciamento de ciclo de vida para grupos de recuo. Você pode implantar uma pilha. E se remover um recurso do seu arquivo Bicep, a pilha pode excluí-lo para você, ou protegê-lo contra a exclusão acidental. Você decide. O ecossistema continua crescendo com mais módulos, melhores ferramentas e integração mais profunda com o IA e o Vithub Copilot. Você pode escrever o que deseja em linguagem simples, e o Copilot gera o código Bicep para você. A Microsoft continua investindo no Bicep como a principal experiência de autoria para o Azure. Portanto, os novos recursos priorizam o Bicep. Os modelos ARM ainda funcionam, mas a inovação está acontecendo no Bicep.

Então, aqui está a conclusão. Se você trabalha com a Azure, o Bicep é o próximo passo natural, além de clicar no portal. Você não precisa aprender a terraforma e o dominal de risco do ARM. Você instala duas coisas, escreve algumas linhas de código e implanta uma infraestrutura que é repetível, controlada por versão e confiável. Deixe-me deixar algo prático que você pode fazer hoje. Então, agora você sabe o que é infraestrutura como código, porque o Bicep existe e como ele torna as implantações no Azure mais simples. Aqui está o ponto principal. O Bicep não é um sistema de implantação diferente. É uma maneira melhor de escrever os mesmos modelos ARM que você escreveria de qualquer forma, usando o mesmo motor do Azure Resource Manager por baixo, apenas em uma linguagem que humanos podem realmente ler e escrever. Aqui está um desafio para você. Crie um arquivo main.bicep, implante um grupo de recursos e execute a implantação duas vezes.

Veja, funciona as vezes. Na primeira vez ele cria o recurso e na segunda ele confirma que nada mudou. Esse é o momento em que a ficha cai, quando você percebe que nunca mais vai querer ficar clicando por aí no portal. Esta é a base. A partir daqui você pode adicionar contas de armazenamento, redes virtuais e serviços e aplicativos usando o mesmo padrão. Escreva um arquivo e implante e execute novamente. Esse arquivo se torna sua fonte de verdade. Tudo o resto segue a partir dele. Se você achou isso útil, compartilhe com alguém que ainda está clicando por aí no portal. Eles vão te agradecer. Inscreva-se na sua plataforma de podcast favorita e no próximo episódio levaremos o Bicep mais longe, implantando recursos reais com propriedades reais.