> The vscode extension can both provisions the resource as well as deploy it.
On top of having to have an Azure subscription, you need to provision:
- a resource group
- a service plan
- a function app
You do not get to skip those with azure.
And by the way, the only time anyone uses vscode to deploy an app, or even visual studio, is to work on personal projects or sandbox environments. Even so, you use the IDE to pick existing resources to deploy to.
All of this can easily be automated/cloned if it is something you do often. An RG is a collection of (hopefully) related resources. Plans and the App are provisioned together in the web UI wizard if that's the route you take.
I'm trying to educate you on the topic, but you seem to offer resistance.
I mean, I haven't even mentioned the fact that in order to be able to provision an azure function you are also forced to provision a storage account. As if the absurdity of the whole plan concept wasn't enough.
> All of this can easily be automated/cloned if it is something you do often.
Irrelevant. It's completely besides the point how you can automate deploying all those resources.
The whole point is that Azure follows an absurdly convoluted model that leaks forces users to manage many layers of low-level infrastructure details even when using services that supposedly follow serverless computing models. I mean, why on earth would anyone have to provision a storage account to be able to deploy an Azure Function? Absurd.
On top of having to have an Azure subscription, you need to provision:
- a resource group
- a service plan
- a function app
You do not get to skip those with azure.
And by the way, the only time anyone uses vscode to deploy an app, or even visual studio, is to work on personal projects or sandbox environments. Even so, you use the IDE to pick existing resources to deploy to.