ULTIMATE SHOWDOWN: Azure Bicep vs. Terraform
Вставка
- Опубліковано 3 чер 2023
- We'll do a deep dive comparison between Azure Bicep code against equivalent Terraform code that provisions an Azure Open AI service account. We'll compare our ARM template against both equivalent "azurerm" and "azapi" terraform provider implementations.
Follow me on Twitter for quick code snippets and thoughts on Cloud, Automation and other things!
/ marktinderholt
Keep the knowledge flowing!
www.buymeacoffee.com/azterraf... - Наука та технологія
9:15 i'd prefer terraform, it's too verbose in bicep
Based.
7:56 random_string is a resource (and not a function) in Terraform because functions are evaluated every time Terraform plan/apply is run so a random() function would 'taint' whatever resource was using it because each run would evaluate a different random number. See the uuid() function in the docs for a brief mention/warning about this sort of thing. Ideally, you will want your random string to be stateful for the lifecycle of whatever resource consumes it. Because of that, it needs to be a a resource itself.
Right on! I love the random provider!
Thank you sir for sharing this!! I also like to be like you becoming a Azure Terraformer!! :D
This is the way 😊👍
When deploying with an ADO pipeline I tend to lean on Bicep, the default build containers don't come with terraform. On AWS the argument is more tricky because CF is more annoying even after working with it for a few years now. Terraform started with AWS first and Azure feels like a second class provider in many respects because of it.
In terms of scoping, you're right. Since Bicep doesn't cover AAD (another TODO problem of Bicep) I use the az cli to define my LZ's and RG's, scope the IAM and then have complete bicep deploys for the resource groups. It stops the need to modularize every resource and you get that flat hierarchy you're looking for.
Finally, getting a client who is hesitant on cloud to pick up both Azure AND Terraform is often too big an ask, sticking with Bicep lets them hire a cloud admin so the position requirements are kept low.
Terraform is clean, and even with state surgery issues I enjoy what it does for me, but unless I _need_ multiple providers its always going to be second fiddle to cloud-provided IaC solutions.
It may seem like learning azure and terraform is two things to learn. But I would argue it’s also learning two things with azure and bicep. 😁 bicep may have official support but it requires you to learn new mental models and concepts just like terraform does.
@@azure-terraformer except bicep is covered in az-104, so you learn them both if you go through their stated learning paths without having to cover Terraform topics. I use more Terraform than bicep from client requests so there's no hate here, just a separate set of pro/cons.
Tbh I am waiting for someone to come up with a stateless Terraform that leans on deployment practices so we can keep projects immutable, but hopes and dreams I suppose
@@arimill1045 ^_^ No worries, I understand where you are coming from.
I think the problem is that Terraform can't assume the underlying platform maintains its own state. Not all infrastructure maintain its own state like Azure and AWS do. I think the little bit of friction we get from state management is made up for by the planning process. This is essentially non-existent in the ARM/Bicep world. Its pretty much YOLO ^_^
@@azure-terraformer 100%, providers are the weakness but a necessary one for what Terraform wants to do.end of the day we gotta know them all that's the job
How does bicep handle drift when there are click ops changes?
Unpredictably. Sometimes it will revert, sometimes it will crash. It depends on the type of change. If a resource has to be replaced, it really doesn't like to do that. I have found so many resources ignored though (even ones that I know I have changed) I can't tolerate the lack of a comprehensive plan!
@@azure-terraformer I’m currently working on getting Sentinel stood up via terraform and I’m noticing that when updating content hub solutions to newer versions terraform isn’t catching the newer version and is telling me that there are no new changes 🤔
Great topic, and for sure I think if you go over Terraform state management and terraform cli workspaces for this comparison, terraform would be the winner, please correct me if I'm wrong, Thanks
I think terraform was the winner. I’m not a huge fan of the scoping mechanism within bicep. I think it makes things overly cumbersome.
scoping mechanisms aren't nearly as bad as handling a remote back end, deformed state, or dependency issues forcing 2+ runs per deploy in edge cases.
I'm more interested in Terraform's AzureAD provider handling cases that Bicep can't (AAD/Entra), and the benefits of state management allow for much better planning, and iterative development. (Bicep feels like its perfect if you have _the solution_ in one file ready to be deployed, but as soon as you need to iterate its almost better to treat deployments as immutable with the --complete option)
Agree, state can be painful but that’s why it’s important to keep things small and iterate. I agree with you about ARM and bicep being great when you have exactly what you want done, it’s not as great of a developer experience but once you’re done it’s a good cloud shotgun. AAD is very powerful and will get more powerful with Microsoft Graph API.