[mawax]

You can just deploy a function.

You open vscode, install the Azure Functions extensions, walk through the wizard to pick your programming language and write the code. Then create and deploy it from vscode without ever leaving your IDE.

[motorest]

> You open vscode, install the Azure Functions extensions, walk through the wizard to pick your programming language and write the code. Then create and deploy it from vscode without ever leaving your IDE.

You are talking about something entirely different. Provisioning a function app is not the same as deploying the function app. How easy it is to upload a zip is immaterial to the discussion.

[mawax]

The vscode extension can both provisions the resource as well as deploy it.

Edit: And yes, it will create every resource it needs if you want to, except for the subscription.

[snupples]

Which is exactly the opposite of how to effectively manage applications, code, and change at any scale beyond a home project.

[jiggawatts]

One thing I noticed about all of the public clouds is an insistence by small-scale users to avoid the user-friendly interface and go straight to the high scale templating or provisioning APIs because of a perception that that’s “more proper”.

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.

[mawax]

That was not the point. Parent was complaining how complicated provisioning and deploying through the Azure portal was.

At scale you'd IaC such as Bicep.