Thread by @dustinmoris

Because several people have asked me now, here is a list of the things which annoy me about #Azure.

No trolling, simple but honest feedback:

I'll start with Azure Functions. In Azure I cannot just deploy code as a function like I can in AWS or GCP. I have to create an entire application. It's even called Azure Function App. The Function App then can have one or many functions.

This is very obvious because I have to create an actual project in code and I cannot configure things like environment variables per function but only for an entire function app. Even worse, the app mode heavily leaks into my code.

In Azure Functions the runtime dictates what versions of third party packages my function can use. For example, the Newtonsoft.Json .NET library is embedded in the Azure Function runtime in a specific version. If my function code wants to use the latest I get a runtime error.

That is extremely unintuitive. In AWS or GCP I just pull third party pacakges of my liking. I can do it in .NET, in Go, Python or whatever I use. In Azure the runtime limits my choices. That limitation itself means that as a developer I have to be super aware of which packages..

... the Azure Function runtime is already using and therefore doesn't allow me to deviate from. It's kind of the opposite of serverless if I have to know what's running on the server of where my code gets deployed.

It seems like that Azure Functions have been an initial hack ported from Azure Web Apps to become "serverless" and now they cannot easily get changed to actually become serverless without breaking people's code. It's a self dug hole in my opinion.

Also because of the said runtime you never know if the code which you've written 6 months ago will still work when you make a small change and re-deploy it again. In fact, this has caused me many hours of massaging my Function Apps to work again after a runtime upgrade.

Speaking of Azure Web Apps, I have lost count how often they have been renamed. I think at some point they were called Azure Web Sites, and I believe now it's Azure App Services? None of the names are clear in what it means and even less clear when the name keeps changing.

I also remember Worker services and there is a thing called Cloud Services which I'm not entirely sure anymore what it is. Luckily I use mostly AKS - Azure Kubernetes Service which is named well.

AKS is great, but from all three major cloud providers Azure requires the biggest amount of VM (node) resources for the eviction threshold. This means that if you are a hobbyist running a small cluster you are only getting ~ 50% of your VM's power. I've tweeted about that before.

Whilst AKS is mostly great there are many rough edges which show when you use it a lot. For example a common scenario is to reserve a static IP address and use that for your nginx-ingress. This makes things easier when the underlying infrastructure changes...

...and you don't want to update domain records all the time. However in Azure this is more cumbersome, because the static IP address has to defined in number format in an K8s manifest for Azure.

In GCP I can associate an IP via a custom name which makes scripting pre-defined manifests so much easier.

Another thing which is annoying in AKS is that during the creation of a cluster you have to pay attention which scaling set you choose.

If you pick the wrong scaling set (I think the one which is also the default one) then you won't be able to add more node pools to the cluster in the future. This is a really weird architectural decision by Azure. Why should I not be able to add more node pools for any reason?

Depending on which scaling set you pick you have to also pay attention to which load balancer type you choose. The default one costs very little, but you won't be able to select the right scaling set which will allow you to add more node pools later. So...

you also have to select a significantly more expensive load balancer in order to get basic Kubernetes functionality working. When you compare the cost of AKS with GKE then these little details don't show up. You'd think they are more or less the same price, when in fact you'll..

.. end up picking additional costly infrastructure in Azure to achieve the same level of functionality which you get with GCP out of the box. As I said in my previous tweet, that expensive load balancer doesn't work as an Ingress Controller yet. In order to get that working,...

.. you have to settle for even more expensive infrastructure pieces or go with a self hosted alternative as I did.

In my previous tweet I already mentioned a lot of issues about Application Insights...

Just going to AI in the Portal is confusing. It's full of a dozens of menu items which all sound the same. Trying to guess which of these options will bring me to the main log view where I can query logs is like playing roulette.

When I click on the correct link then I get to a screen which does absolutely nothing except make me doubt if I actually clicked on something new which I haven't set up yet or if I made a mistake:

But I know this is just how the Portal works. I need to click on Get started even though I'm not starting because I already used it a million times. This loads another popup which gets in my way of actually seeing logs:

Then I get finally to the screen where I can run some log search queries. It's a bit annoying though that none of the 3-4 screens have shown me any of the most recent 100 logs or so.

And of course, because each service in Azure creates a new Application Insights project by default you're likely having tons of them and you'll need to click through all those screens several times in order to query logs from multiple services.

The Azure Portal is really bad. One of the most common things which any developer or Ops person will have to do many many times is to create service accounts with limited access for various infrastructure pieces. You'd think it would be easy to find that:

The Azure documentation often mentions Service Principals, but searching for that doesn't return anything useful either:

It turns out that "Service Accounts" are called "App Registrations" in Azure. It actually took me an hour or longer to figure that out. I mean how unproductive as a tool can Azure be if even a power user who knows what he wants requires an hour to find something easy as that?

I'm going to sleep now, but I can keep posting lots of feedback like this forever. My main impression is that Azure is designed for demoes to non developers, putting everything developer irrelevant into the forefront and everything what developers actually want are hidden.