← Back to context

Comment by oneplane

3 months ago

Same feeling here. It's like they wanted a way to "play datacenter in the browser", but then asked 30 different teams to do it on their own, and only have them come together after they are all done to put the pieces together.

Then find out it's not good at all and go "oh well, I guess we'll polish it over in the UI" (not knowing that no serious scale works with a UI).

If I can't have AWS I'll make do with GCP. But if someone wants to go full Azure, I'll find work elsewhere. Screw that. Life is too short to work with bad technology.

I don't think that's it. I think Microsoft wanted a way to migrate already Microsoft workloads to something they could more aggressively bill by the GB or second or user or whatever revenue extraction metric you're down with. Basically, O365 extended to the entire M$ ecosystem. And for that it seems...er...ok. We've migrated a couple of dozen major M$ workloads from on-prem reasonably easily, and a bunch of little ones. Lots of skillsets transferred easily...I vividly recall talking a really fine SQLServer admin off the ledge when the "move to cloud" mandate came out who's now like "I had to learn a few new things, but it's pretty much like what I was doing before". Big win.

But then everyone said "a cloud should do X and Y and Z", and they try to bolt X/Y/Z on to the side with various levels of success. And now all the app owners who aren't native M$ have declared Azure not fit for purpose and picked up the torches and pitchforks. So we're going to support AWS, too.

Seriously wondering what you guys experienced with Azure. Never had an issue and prefer it over AWS.

  • Most of it is not an individual experience or 'event', just bad design with bad results. I'll try to describe some global ones:

    One of the most bizarre things is the crazy bad resource hierarchy. There are multiple overlapping and incompatible ones. Resources, networks, storage, IAM, billing and org, none of it in a single universal hierarchy. It seems to mirror the idiosyncrasies of legacy enterprise organisations with their fiefdoms, instead of a cloud.

    The next useless thing is how you just cannot use what you need when you need it in whatever way you want it. Almost all services are hyper-segmented requiring various premium tiers instead of them being universally available.

    I get it, it's a great way to bundle things people don't want and extract as much money out of them, but that only really works if people have no alternative. And those two form the bad architecture/bad technology trifecta with this third one: a lot of services, maybe most of them, seem like some sort of 2005 model where a resource is backed by nothing more than some random managed VM in the backend, with all the problems (failure modes, inconsistent behaviour etc) that come with that model.

    Perhaps the reason for those things is simple: Microsoft wanted a way to extract more money from their customers and lock them in even more. Moving workloads to Azure meant something different for them than it did for the rest of the world: you used to have a lage army of common windows sysadmin jobs where there was a lot of local control and local management loops, but when you move that to a common template in someone else's datacenter (Azure, essentially) you can ditch most of those loops and people. Granted, they created those local controls/loops themselves to get a school-to-work microsoft client pipeline (same as say, Cisco or oracle), but I doubt there is any new markets to cater to in that way. Since people tend to be the most expensive and most risky part of a business, being able to take more of them out of the loop, making more of them optional or making them more expendable/remote is a (short-term) positive thing in the spreadsheets of most MBAs, which is who most large companies cater to after all. This did of course backfire and we now have the same quantity of jobs but instead of sysadmin you get 'azure engineer' which is more of a crossover between operational helpdesk and technical application manager. But everyone wins: during your exodus you can sell it as modernisation, when you remove that on-prem burden you can shift your CAPEX and OPEX around, your quarter looks better when you can reduce headcount, and once your bonus is in, you can put some job postings out for the people you are now missing.

    Technology-wise, the only thing that really changed was the ways in which people could cut corners. Some corners are pre-cut, while others are uncuttable. API-wise, it's a crapshoot, a turd attempted to be polished by a webui that hides the maelstrom of questionable residue below the surface.

    • Re: "There are multiple overlapping and incompatible ones. Resources, networks, storage, IAM, billing and org, none of it in a single universal hierarchy." - hierarchy is based on subscription / resource group. Billing is usually done with tags (you can add a tag like "CostCenter": "Online Marketing CostCenter1234")

      Re: "hyper-segmented requiring various premium tiers instead of them being universally available" - premium tier usually means your service runs on its own Azure VMs; while the other tiers your service shares a VM with other customers. The first choice is more expensive obviously and I prefer to pay for that service only if I need it.

      BTW - Azure supports bare metal Linux and Windows. So if these pesky Azure services get in your way you can always go back to your on-prem version, where instead of running your workload on your own VMs you run it on Azure VMs.

      1 reply →