[motorest]

> You can provision an Azure Web Service (...) which provisions the computational resource, Azure App Service, as part of the deployment steps.

That's not a solution because deployment steps aren't a problem. The brain-dead aspect of Azure is how it forces users to handle the complexity of having to deal with provisioning and budgeting what computational resources used to run a set of web apps. This doesn't even buy isolation. If I'm paying for cloud services, why on earth should I concern myself with how much RAM I need to share across N apps? It's absolutely brain dead.

[p_ing]

You don't have to share anything across apps.

When I ran public sites each received it's own App Service, though they were provisioned via ARM template because that's what you do (or Terraform, etc) rather than get into the UI or manual CLI in an enterprise. All of these complaints you're bringing forth are a non-issue in a practical deployment.

[motorest]

> You don't have to share anything across apps.

You don't. You also do not have to share the same service plan with any other app service or function app. That's besides the point. The point is that Azure requires anyone who wants to run a god damned web service or even a single event handler to provision a bunch of infrastructure resources, just to be in a position to even consider deploying the thing.

I mean, you need to have both an Azure Service Plan and an Azure Storage Account to even consider deploying something serverless. Let that absurdity sink in.

In contrast, with AWS you just deploy the damned Lambda. That's it.

> (...) though they were provisioned via ARM template (...)

That is completely besides the point. It's irrelevant how any IaC offering turns any provisioning into a one-click affair. What's relevant is accidental complexity created by Azure for no reason at all. Go look at your ARM templates and count the number of resources you need to have there just to be able to run a single no-op event handler. It's stupid.