Hey before we get into the blog, I'm thinking about starting a mailing list I would use the mailing list to go into further depth on these blogs, augmented with videos on how to actually configure solutions. Let me know if you're interested here! [REGISTER YOUR INTEREST FOR A MAILING LIST HERE](https://mcsec.ck.page/ecc5642a3a) --- So Bicep is pretty cool, It's documented well and integrates neatly with Bicep Build and Bicep decompile, which effectively translates ARM Templates. Bicep is stateless in that it requires no additional configuration to just work. The language is simple and readable and I would say that it is suitable up to mid sized businesses... One of the key issues with bicep is how, similar to ARM templates, it runs into a 4 MB File limitation. That is to say that your Bicep file can be smaller Or larger than 4mb, but if after it's compiled to an ARM template it doesn't work. This leads to juggling configurations between multiple files, to try and get it to deploy in a manner that had each requisite resource available prior to it being required. As it's file and resource group focused it becomes challenging to define bigger deployments. Now with the caveat of needing to deploy quickly, I didn't have time to work through creating a file / folder structure that used modules, which may have been a good use case here... in saying that I wonder if it would have still run into the same 4MB limitation. As they say - If I had more time, I would have written a shorter letter. A healthy alternative to Bicep which has similar language is Terraform, or for a good open source alternative Open Tofu. While these contain a state file, which must be stored and managed especially in a team environment, It's a great option which appears to have no issue with the 4mb limitation. In addition it has providers for many platforms, Azure, Aws, GCP. TerraForm/Tofu process a whole folder worth of files, and present the changes in a "Plan" which demonstrate what's going to change as part of the deployment. Neatly illustrating what code has changed, and making it easier to tell if it was going to destory, delete or otherwise change infrastructure before actually firing it. For readability this makes good sense, being not only able to set up modules in different folders, but also create outputs that make different resources wait for the deployment of others, all which can be set up in different files. In this way a lot of the confusion that can become apparent in larger files can be mitigated. Terraform/Tofu can also specify multiple resource groups/subscriptions in it's file structure, which also allows greater control in deploying in a clean/clear fashion - better enabling resources with the same life cycle to be grouped together.