5 ms·

> Anecdotally - working with Azure has been hell on earth for me. Insanely unintuitive and buggy interface. Many cryptic errors preventing me from doing anythin

> Anecdotally - working with Azure has been hell on earth for me. Insanely unintuitive and buggy interface. Many cryptic errors preventing me from doing anything. What pisses me off the most about Azure is now they designed it as the 90's view of what a cloud provider is. With Azure you don't just provision a VM or God forbid a web service. No no no. You need to provision an app service plan first, where you have to provision what computational resources you allocate to it, and then assign services and even gasp function-as-a-service apps. And even with FaaS stuff you don't just provision a handler. No, that would make too much sense. First you need to provision a function app running on your service plan, and you provision whatever azure functions you need as part of the function app. How much accidental complexity is that? Can't I just deploy an app or God forbid a function? The same think applies to storage, but it's even worse. You get your storage account, and you need to providion a storage account to be able to provision one or more blob storage containers, azure tables, even simple queues. But wait, you need a storage account to store data in a nosql services, but if you opt for the other nosql service then that's an entirely different thing. For that you can simply go ahead and create an account. You can use the same SDK for both? That's nice. Wait, why do they have two nosql services? Azure, man. It exists to make every single alternative look good.

p_ing 1y ago
You can provision an Azure Web Service (PaaS web server running IIS or whatever the Linux version runs) which provisions the computational resource, Azure App Service, as part of the deployment steps. You certainly can do it in the way you've specified but I only see that as useful if you're provisioning multiple Web Services to point to a single App Service. But to answer your question, yes you can "just" provision a Function or Web Service, the wizard walks you through it. The App Service behind the scenes is just details and not something you must interact with post-Function creation.
- motorest 1y ago
  > 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 1y ago
    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 1y ago
      > 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.
koakuma-chan 1y ago
Yeah that, and in Azure OpenAI you have to create a separate deployment for each model you want to use.
tstrimple 1y ago
> What pisses me off the most about Azure is now they designed it as the 90's view of what a cloud provider is. With Azure you don't just provision a VM or God forbid a web service. No no no. You need to provision an app service plan first What's funny is you're completely backwards here. Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2. Azure started as PaaS first and AWS started as IaaS first and that fingerprint is still all over their products. Building everything in a VM is the most expensive and naive way to adopt the cloud. It's the main reason why complexity and costs blow up. You're building in the cloud wrong and somehow seemed to have missed that a consumption based Function app is the default option and doesn't require an App Service Plan.
- everfrustrated 1y ago
  >Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2 You must be joking! I was looking a various Container Registry products and looked up Azure's recently. It has the following limits (On the premium SKU!): 50Mbps upload, 100Mbps down What sort of a cloud product has limits like this! What a clown show.
  - p_ing 1y ago
    The footnote points out that those are minimum limits. https://learn.microsoft.com/en-us/azure/container-registry/container-registry-skus#service-tier-features-and-limits https://learn.microsoft.com/en-us/azure/container-registry/c...
  - tstrimple 1y ago
    As noted, those are minimum limits. If there's a clown show, it's you who is hosting it.
    - motorest 1y ago
      > As noted, those are minimum limits. If there's a clown show, it's you who is hosting it. Do they specify ay SLA other than the minimums? If not, I'm sorry to tell you, but they only offer the minimum and anything over that is a pleasant surprise.
mawax 1y ago
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.
- snupples 1y ago
  Which is exactly the opposite of how to effectively manage applications, code, and change at any scale beyond a home project.
  - jiggawatts 1y ago
    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 1y ago
    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.
    - motorest 1y ago
      > 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.
SvenL 1y ago
They have a Azure Function Serverless Offering called consumption plan: https://learn.microsoft.com/en-gb/azure/azure-functions/functions-scale https://learn.microsoft.com/en-gb/azure/azure-functions/func... Quote: „Default hosting plan that provides true serverless hosting“ This one doesn’t require an app service plan. Actually I like that offering, depending on your requirements you have several options to host your functions. That’s pretty great. If they would offer just one kind of function app or one kind of storage solution people would complain that their very important edge case is not supported. For those simple requirements you can use cloudflare, vercel etc…
- motorest 1y ago
  > This one doesn’t require an app service plan. It requires a plan. You need to know what a plan is and what plan your azure functions are running on. Is it a consumption plan? Or is it a flex consumption plan? I mean, you can run multiple function apps on the same plan. As a developer, you are required to know which plan a particular function app is running on, and be aware of the implications. You see how brain dead it is?

p_ing 1y ago

You can provision an Azure Web Service (PaaS web server running IIS or whatever the Linux version runs) which provisions the computational resource, Azure App Service, as part of the deployment steps. You certainly can do it in the way you've specified but I only see that as useful if you're provisioning multiple Web Services to point to a single App Service. But to answer your question, yes you can "just" provision a Function or Web Service, the wizard walks you through it. The App Service behind the scenes is just details and not something you must interact with post-Function creation.

motorest 1y ago
> 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 1y ago
  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 1y ago
    > 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.

koakuma-chan 1y ago

Yeah that, and in Azure OpenAI you have to create a separate deployment for each model you want to use.

tstrimple 1y ago

> What pisses me off the most about Azure is now they designed it as the 90's view of what a cloud provider is. With Azure you don't just provision a VM or God forbid a web service. No no no. You need to provision an app service plan first What's funny is you're completely backwards here. Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2. Azure started as PaaS first and AWS started as IaaS first and that fingerprint is still all over their products. Building everything in a VM is the most expensive and naive way to adopt the cloud. It's the main reason why complexity and costs blow up. You're building in the cloud wrong and somehow seemed to have missed that a consumption based Function app is the default option and doesn't require an App Service Plan.

everfrustrated 1y ago
>Microsoft has a much more modern view of the cloud than AWS where everything is a thin veneer over EC2 You must be joking! I was looking a various Container Registry products and looked up Azure's recently. It has the following limits (On the premium SKU!): 50Mbps upload, 100Mbps down What sort of a cloud product has limits like this! What a clown show.
- p_ing 1y ago
  The footnote points out that those are minimum limits. https://learn.microsoft.com/en-us/azure/container-registry/container-registry-skus#service-tier-features-and-limits https://learn.microsoft.com/en-us/azure/container-registry/c...
- tstrimple 1y ago
  As noted, those are minimum limits. If there's a clown show, it's you who is hosting it.
  - motorest 1y ago
    > As noted, those are minimum limits. If there's a clown show, it's you who is hosting it. Do they specify ay SLA other than the minimums? If not, I'm sorry to tell you, but they only offer the minimum and anything over that is a pleasant surprise.

mawax 1y ago

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.

snupples 1y ago
Which is exactly the opposite of how to effectively manage applications, code, and change at any scale beyond a home project.
- jiggawatts 1y ago
  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 1y ago
  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.
  - motorest 1y ago
    > 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.

SvenL 1y ago

They have a Azure Function Serverless Offering called consumption plan: https://learn.microsoft.com/en-gb/azure/azure-functions/functions-scale https://learn.microsoft.com/en-gb/azure/azure-functions/func... Quote: „Default hosting plan that provides true serverless hosting“ This one doesn’t require an app service plan. Actually I like that offering, depending on your requirements you have several options to host your functions. That’s pretty great. If they would offer just one kind of function app or one kind of storage solution people would complain that their very important edge case is not supported. For those simple requirements you can use cloudflare, vercel etc…

motorest 1y ago
> This one doesn’t require an app service plan. It requires a plan. You need to know what a plan is and what plan your azure functions are running on. Is it a consumption plan? Or is it a flex consumption plan? I mean, you can run multiple function apps on the same plan. As a developer, you are required to know which plan a particular function app is running on, and be aware of the implications. You see how brain dead it is?