ARM is a complete joke, and Bicep compiles down to ARM.
(More details: ARM is simply a dumb script that says "do this, do that", it doesn't interact with your cloud resources in any smart way. As one example: You can download a template for an Azure SQL instance from the Azure portal. That template will then randomly fail to execute, because it contains two "configuration" child resources of Azure SQL, which ARM will try to deploy in paralell, but oh, they touch the same parent sources, so they crash with an error...
Then try to add depends_on in order to have it, perhaps, not fail.
Or how about the Azure SQL feature where, if you block Azure SQL to only AD logins, you'd have to declare an administrator password on first ARM run (resource creation), then remove it on subsequent ARM runs (resource update) because having it is then prevented...
These aren't minor issue or glitches; it's symptomatic of a system that's just built in the wrong way from ground up. ARM isn't a stateless description of your resources, it's an awkward scripting language (although since the APIs it interacts with are idempotent the difference isn't obvious at first).
How Microsoft could decide to have Bicep compile to ARM is beyond me -- Azure has some good features (refer to resources by name rather than allocated ID) that could greatly simplify the approach that Terraform/Pulumi takes if they only targeted Azure -- why didn't Microsoft do that instead, give us Terraform/Pulumi for Azure without having to keep a statefile (especially a statefile with secrets in it).
This is only partly accurate, because it conflates ARM the CRUD API with ARM Templates. ARM’s CRUD API is used by Terraform’s AzureRM provider (I bootstrapped that provider in 2016).
I’m not sure exactly what you’re looking for with regards to referencing by name rather than ID - names must be qualified with a resource group and so forth, and to actually unambiguously identify things, you’d need all components of the ID.
Bicep looks like a solution in search of a problem to me, though fortunately I haven’t had to spent more than about 5 minutes looking at it.
Hmm, not sure how I am conflating things, I meant to just wrote about ARM templates full stop? The API I refer to is the Azure Management API (we ended up using that directly from Python instead of using ARM ourselves)...
I said that referencing by name is one of the few things that are good about Azure. It means one does not have to persist a lot of resource IDs when deploying infra, one can just query the cloud state.
What I am looking for -- or what I would love if someone built for me -- is utilizing that feature to deliver Terraform or Pulumi without the need for a statefile. The statefile should not be needed on Azure due to the resource naming scheme -- just query the management APIs to get currrent state.
When we looked at Terraform and Pulumi we saw that the tools by default sucked down evey secret in the resources into the statefile. This is behaviour I very much disagree with, we do not want secrets stored anywhere or pass through anywhere, we want to rely on service identity everywhere.
PS I am speculating here about why the statefile is needed...I have been assuming something about Amazon made it needed, but I may be wrong.
Sounds like you're just angry I don't like the same technologies as you. I don't need terraform because I only work with Azure. What are you going to do to stop me?
I think he's more angry at ARM templates than anything else.
I'm learning terraform to work with Azure. Primarily because one day I might need to work with any other cloud provider and I don't want to learn 3 different DSLs when I might be able to get away with learning 1.
But even that sounds like wishful thinking as I write it out.
