Which is exactly the opposite of how to effectively manage applications, code, and change at any scale beyond a home project.
You won’t get any benefits until you have dozens of instances of the same(ish) thing, and maybe not even then!
Especially in the dev stage it is perfectly fine to use the wizards in VS or VS Code.
The newer tooling around Aspire.NET and “azd up” makes this into true IaC with little effort.
Don’t overthink things!
PS: As a case in point I saw an entire team get bogged down for months trying to provision something through raw API calls that had ready-to-run script snippets in the docs and a Portal wizard that would have taken that team all of five minutes to click through… If they’re very slow with a mouse.
At scale you'd IaC such as Bicep.
No, I wasn't. I was pointing out the fact that Azure follows an absurd, brain-dead model of what the cloud is, which needlessly and arbutrarily imposes layers of complexity without any reason.
Case in point: the concept of a service plan. It's straight up stupid to have a so-called cloud provider force customers to manage how many instances packing X RAM and Y vCPUs you need to have to run a function-as-a-service app, and then have to manage how that is shared with app services and other function apps.
Think about the backlash that AWS would experience if they somehow decided to force users to allocate EC2 instances to run lambda functions, and on top of that create another type of resource to group together lambdas to run on each EC2 instance.
To let the absurdity of that sink in, it's far easier, simpler, and much cheaper to just provision virtual private servers on a small cloud provider, stitch them together with a container orchestration service, and just deploy apps in there.
You're not forced to, you can use a consumption plan.
https://azure.microsoft.com/en-us/pricing/details/functions/...
Pray tell, what do you think is relevant in citing how many plans you can pick and choose from to just run a simple function? I mean, are you trying to argue that instead of one type of plan, you have to choose another type of plan?
But it disproves your point that you're "forced" to have an app service plan.
At this point you're simply arguing to argue after having been shown to be incorrect multiple times. Good luck.