This was a good read! I have similar thoughts especially about IaC vs a bash script. Definitely clear pros and cons to both, but I’m wondering how you handle infrastructure drift with imperative bash scripts?

I mean hopefully no one is logging into Azure to fuck with settings but I’m sure we’ve all worked with that one team that doesn’t give a flying fuck about good practices.

Or say you wish to now scale up a VM, how does your bash script deal with that?

Do you copy past the old script, pass new flags to the Azure CLI, and then run that, then delete the old infrastructure somehow?

I’m curious because I think I’d like to try your approach.

I think you’ve nailed the issues with this approach. I think the best approach to control “cowboy” behaviour is to make everything run through a service connection so that developers don’t actually need access to your azure resources. Though to be fair, I’ve never worked with a non-tech enterprise organisation where developers didn’t have at least some access into Azure directly. I also think the best way to avoid dangers in areas like networking is to make sure the responsibility for these are completely owned by IT-Operations. With VNETs and private DNS zones in places all you really need to allow is for the creation of private end points and integration to the network resources. Similarity I think it’s best practice to have things like key vaults managed by IT operations with limited developer access, but this can depend on your situation.

One of the things I like about the Azure CLI is that it rarely changes. I would like to clarify that I’m mainly talking about Azure App Services and not VMs. Function apps for most things, web apps for things like APIs.

As far as the script goes they are basically templates which are essentially “copy paste”. One of the things I tend to give developers in these organisations is “skeleton” projects that they can git clone. So they’ll typical also have some internal CLI scripts to automate a lot of the code generation and an azure-pipelines-resource-creation.yml plays into this. Each part of your resource creation is its own “if not exist” task. So there is a task to create a resource group. Then a task to create an app service plan and so on.

It won’t scale. But it will scale enough for every organisation I’ve worked with.

To be completely honest it’s something which grew out of my frustration of repeating the same tasks in different ways over the years. I don’t remember exactly but I think quite a few of the AZ CLI commands haven’t change for the past three years. It’s really the one constant across organisations, even the Azure Poetal hasn’t remained the same.