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.
> That was not the point. Parent was complaining how complicated provisioning and deploying through the Azure portal was.
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.
jiggawatts|8 months ago
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|8 months ago
At scale you'd IaC such as Bicep.
motorest|8 months ago
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.