Anecdotally - working with Azure has been hell on earth for me. Insanely unintuitive and buggy interface. Many cryptic errors preventing me from doing anything.
Microsoft doesn’t really respect their users because most of the users don’t decide by themselves to use Azure. Someone else make the decision for them. And it’s probably like that for many of their other products.
Yes it sucks and the documentation sucks even more. I think azure and whatever you call the google cloud configuration site are both so complicated because they're best for giant corporations with thousands of employees and many many roles in the organization with different privileges. However if you're just a single developer setting up something simple it's hellish.
It would be nice if they provided a simple setup configuration option for simple setups.
Quite honestly a single person working at a micro scale is not the target market for the hyperscalers. You're better served not going for managed services (and buying unmanaged services on the big clouds also doesn't make sense without needing the entire ecosystem around it).
Coming from a Windows enterprise background, the UI for the most part makes sense and not something I find difficult to navigate (the original UI was awful). I know your sentiment is not uncommon, but I'm unable to share it.
I will agree, and this is a general Microsoft problem spanning back to the 90s, some error messages aren't useful what so ever. Others are clear and concise. I figure this is due to the different PGs following their own set of rules.
> 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.
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.
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…
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.
> 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.
lifty|8 months ago
p_ing|8 months ago
comrade1234|8 months ago
It would be nice if they provided a simple setup configuration option for simple setups.
Anon1096|8 months ago
patmorgan23|8 months ago
p_ing|8 months ago
I will agree, and this is a general Microsoft problem spanning back to the 90s, some error messages aren't useful what so ever. Others are clear and concise. I figure this is due to the different PGs following their own set of rules.
motorest|8 months 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, 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|8 months ago
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.
SvenL|8 months ago
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…
koakuma-chan|8 months ago
mawax|8 months ago
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.
tstrimple|8 months ago
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.