Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Two hundred reasons to not use Azure

mastodon.social

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Two hundred reasons to not use Azure

#41

Post by quesera »

mingus88 wrote: post #10
RajT88 wrote: post #3

There is a lot to complain about on Azure. But a lot of his posts are wrong (he just could not figure it out - a documentation problem likely) or complaining not about Azure, but Terraform.

I can concur. At an old job we had a slack channel filled with terraform issues like these. We were an AWS shop. Terraform tends to be one of those things that can quickly become a nightmare if you take up it’s offer to manage everything in your infrastructure.

I've been feeling this lately. A new guy came in and Terraformed the crap out of a very consistent and reliable AWS infrastructure.

I don't know whether to blame the tool or the implementation, but the injection of unpredictability is extremely unwelcome! We're only using it on the non-production account so far, fortunately.

I prefer boring systems. The more boring, the better.

Re: Two hundred reasons to not use Azure

#42

Post by ElephantAndARat »

RajT88 wrote: post #37
empuxr wrote: post #7

Earlier quoted context omitted.

If you tell me which ones are wrong I'd be happy to look into them again. :) We can't guarantee that all of the posts are 100% correct, although we try to confirm all of them before posting. Most of these are things we encountered during our daily work, and yes, many of them are possibly just documentation errors. But when you can't figure out how to do something in a reasonable amount of time... that's not great eit…

To use an example: The AppGW TLS cert/KeyVault issue. If it works manually, but not via Terraform, it's the fault of Terraform (or possibly the underlying Go SDK, small disclaimer). The ARM API is used by the Azure portal, as well as all the SDK's. Of course it's totally possible it doesn't work manually. It did last time I checked, and it's a pretty foundational functionality - so I'd be surprised if it didn't.

> If it works manually, but not via Terraform, it's the fault of Terraform (or possibly the underlying Go SDK, small disclaimer). The ARM API is used by the Azure portal, as well as all the SDK's.

that's not true. sure the portal uses the same APIs, mostly. it also uses its own hidden APIs for some functionality. so it is entirely possible for it to work via the portal, but not work via any API mechanism.

e.g. uploading PKCS12 certs to (IIRC) automation accounts. the UI requires a password, and also sends the cert to some back end middleware to change the cert itself. while via the REST API you can upload the cert without a password, and it remains unmodified. (without the modification process some valid PKCS12 certs will not show up on the runners, and therefore can't be used for auth.)

Note: Azure support was not helpful in resolving this matter, since if it worked via PowerShell (the cert generation and upload), then it was considered an issue with our code (ignoring the fact that our code (and libraries used) remained unchanged throughout). though changing API behavior even when specifying an API version in the request is typical for Azure.

Re: Two hundred reasons to not use Azure

#43

Post by nunez »

If you're reading this and thinking "it can't be that bad:"

no, it really is.

On paper, Azure has everything you need and more.

In reality, using Azure is death by one hundred thousand cuts that's smoothed over by an army of support engineers, TAMs, and PMs (seriously!) providing the best support I have ever seen. Seriously, they are everywhere. They're probably reading this comment!

Enumerating them like this is SUCH A GREAT IDEA.

Here are some of the ones I experienced when I spent a year working seriously with Azure:

- I hope you like HTTP 409 CONFLICT

- Azure AD goes down ALL OF THE TIME. Everything in Azure and Office 365 relies on Azure AD. Somehow this is fine.

- One minute, your VM will take two minutes to create. Another minute, it will take 45. You have no way of knowing beforehand.

- Literally EVERYTHING about Azure ARM. You will not get nested templates right. Just give in.

- Try using Azure DevOps via CLI. You will love Jira more quickly than you thought possible.

Re: Two hundred reasons to not use Azure

#44

Post by agentrnge »

sofixa wrote: post #12
politelemon wrote: post #4

Wouldn't you be able to do a similar list for any given provider, given sufficient motivation and rage? Or do you think Azure is distinct

You would, but as someone who has interacted with all three big cloud providers at some level, and has seen demos using all three, and has colleagues that have had to do work and/or demos with all three... Azure is by far the worst. Their security is the worst - they have had more than 10 critical security vulnerabilities, most of them cross-tenant, some of them trivial to exploit and should have never gotten into pr…

> The main reason to go to Azure is because your bosses' boss was convinced to buy it at a golf course.

I have said this so many times about all this horrible garbage our mgmt picks.

Re: Two hundred reasons to not use Azure

#45

Post by flumpcakes »

$DAYJOB is spending a lot of money very quickly in a modernisation project of our core product. It's being split into a micro-service architecture using Azure.

We've basically shipped 5% of the features but already to the point where compute and logging is costing "too much". I'm not sure who made the decision to jump to Azure without doing even back-of-the-envelope estimates on this type of thing.

My real annoyances is that the support in Azure is some of the worst bottom of the barrel crap I've experienced.

- You have to open a support ticket to raise your limits on your subscriptions - and prepare to wait weeks with zero communication from microsoft if your region is contended.

- I've had people from the third party support companies directly contact me on teams chasing for me to close their tickets... HIGHLY unprofessional in my opinion. Tickets they have not been able to complete because it's "impossible":

- You cannot delete 'views' of previous commits that may be leaking secrets in Azure DevOps. GitHub has an entire support category for this. Not for ADO, apparently it's impossible according to support. Oh well, leaked secrets in the GUI for our repository forever, despite the commits no longer existing.

- Even their architect experts are useless; we want to separate our SaaS from our company's Entra ID and even though it's one of the "legitimate" reasons listed in their docs (ISV), all of their so-called experts don't think this is wise, or at least is too bothersome for them to work out how entitlements work. Yes, let's pollute our corporate tenant with service principles etc. of our hosted software.

Overall it has been a garbage experience, meanwhile $DAYJOB is hurtling down this path for strategic reasons (boils down to the CEO being told by customer CEOs that you need to be in the cloud to be considered a real company, despite buying our services for decades).

Azure could be pretty good to be honest - it just has bad support and even worse technical sales/architect people.

Re: Two hundred reasons to not use Azure

#47

Post by nunez »

sofixa wrote: post #12
politelemon wrote: post #4

Wouldn't you be able to do a similar list for any given provider, given sufficient motivation and rage? Or do you think Azure is distinct

You would, but as someone who has interacted with all three big cloud providers at some level, and has seen demos using all three, and has colleagues that have had to do work and/or demos with all three... Azure is by far the worst. Their security is the worst - they have had more than 10 critical security vulnerabilities, most of them cross-tenant, some of them trivial to exploit and should have never gotten into pr…

Less "golf course" and more "discounts on discounts on discounts"

Re: Two hundred reasons to not use Azure

#48

Post by nunez »

RajT88 wrote: post #3

There is a lot to complain about on Azure. But a lot of his posts are wrong (he just could not figure it out - a documentation problem likely) or complaining not about Azure, but Terraform.

After having used Azure for a year, I believe every single post on this thread.

Re: Two hundred reasons to not use Azure

#49

Post by Al-Khwarizmi »

rcarmo wrote: post #40
evook wrote: post #21

Earlier quoted context omitted.

The reason for this I heard by Microsoft was to stop having to explain to non technical people that Azure AD doesn't have feature parity with a real Active Directory.

As a Portuguese native Microsoft FTE, I found the name change jarring. “Entra” means “Enter”, with a subtext of permissiveness that seems overly positive for an authentication mechanism. But then again, Continental Portuguese is seldom considered as a semantic idiom, and Brazilian Portuguese (or even Spanish) tend to have a lot more influence in branding everywhere on the planet.

"Entra" means "Enter" in Spanish as well.

Re: Two hundred reasons to not use Azure

#50

Post by RajT88 »

ElephantAndARat wrote: post #42
RajT88 wrote: post #37

Earlier quoted context omitted.

To use an example: The AppGW TLS cert/KeyVault issue. If it works manually, but not via Terraform, it's the fault of Terraform (or possibly the underlying Go SDK, small disclaimer). The ARM API is used by the Azure portal, as well as all the SDK's. Of course it's totally possible it doesn't work manually. It did last time I checked, and it's a pretty foundational functionality - so I'd be surprised if it didn't.

> If it works manually, but not via Terraform, it's the fault of Terraform (or possibly the underlying Go SDK, small disclaimer). The ARM API is used by the Azure portal, as well as all the SDK's. that's not true. sure the portal uses the same APIs, mostly. it also uses its own hidden APIs for some functionality. so it is entirely possible for it to work via the portal, but not work via any API mechanism. e.g. upload…

The hidden API's are a corner case.

They are not generally used for deployment. My point is valid.

Post reply on HN