Live data from Hacker News

Two hundred reasons to not use Azure

mastodon.social

51–58 of 58 posts

Re: Two hundred reasons to not use Azure

#51
post #50

Earlier quoted context omitted.

> 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.

I'm not quite sure what you mean by "not used for deployment" when they are for some cases, like the example I gave. trying to "deploy" an automation runbook that needs authentication. it'd be part of a greater solution, sure, but it'll still be part of the deployment

Re: Two hundred reasons to not use Azure

#52
post #41

Earlier quoted context omitted.

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.

What do you use instead, CF?

Re: Two hundred reasons to not use Azure

#54
post #50

Earlier quoted context omitted.

The hidden API's are a corner case. They are not generally used for deployment. My point is valid.

I'm not quite sure what you mean by "not used for deployment" when they are for some cases, like the example I gave. trying to "deploy" an automation runbook that needs authentication. it'd be part of a greater solution, sure, but it'll still be part of the deployment

You're wrong about that anyways.

It appears to be a documentation miss in the REST API doc.

https://learn.microsoft.com/en-us/powershell/module/az.autom...

The AZ module is using the REST API QED - it supports the password.

In this case probably what you need to do to sniff out how it is working with the REST API is to run it in powershell with -verbose -debug and see what it is doing (or configure powershell for the fiddler proxy).

My point - just to remind you (I can almost hear you typing) - is that it's more likely to be the fault of Terraform. Undocumented Portal API's from what I have personally seen are all "read" not "write".

Yes, the docs suck.

Re: Two hundred reasons to not use Azure

#55
post #43

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 SUC…

“2 min or 45”

IME any vm operation via portal takes at least 15 minutes. Stop/start/restart/redeploy. It’s so consistent it feels like they just slept for 14 minutes then do the thing.

Re: Two hundred reasons to not use Azure

#56
post #37
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.

It might be possible to do through the API, but there is no documentation available on what you need to do. There are only PowerShell examples, which you could look into and try to replicate on your own using the API.

The shit part about this: - Can't do it through the Azure Portal - Can't do it through Terraform - Docs only give you PowerShell examples - Docs don't explain you WHY you need to do this, they just expect you to suck it up - Why is Application Gateway only supporting user-managed identities and not system-assigned identities for this feature?

Sorry, I don't really care about which part of the Azure ecosystem is at fault here. It's a shitty experience.

Re: Two hundred reasons to not use Azure

#57
post #54

Earlier quoted context omitted.

I'm not quite sure what you mean by "not used for deployment" when they are for some cases, like the example I gave. trying to "deploy" an automation runbook that needs authentication. it'd be part of a greater solution, sure, but it'll still be part of the deployment

You're wrong about that anyways. It appears to be a documentation miss in the REST API doc. https://learn.microsoft.com/en-us/powershell/module/az.autom... The AZ module is using the REST API QED - it supports the password. In this case probably what you need to do to sniff out how it is working with the REST API is to run it in powershell with -verbose -debug and see what it is doing (or configure powershell for the…

I think you misunderstand. the problem isn't to do with the password necessarily. I want to not have a password, which is fine. however the cert I generate and upload does not work (rather, started to stop working). if the same cert is given a password (as the portal requires it), then, uploaded via the portal, the portal changes the certificate via a hidden API (I can see it via dev tools). that cert then works fine.

that's the issue.

I believe I also tried uploading the cert I generated via PowerShell (both with and without a password), and the same problem was there. It was narrowed down to 1. certs generated by PowerShell are fine. 2. The portal uses that hidden API to transform the cert before uploading it. which neither PowerShell or the REST API do.

Re: Two hundred reasons to not use Azure

#58
post #39

Bicep might be a better option to do IAC on azure.

Bicep is just a set of macros for the JSON templating. I get why it was invented, I tried to use it about a dozen times, have always fallen back to either Terraform or raw Azure templates (which I actually prefer since they’re so, so easy to handle programmatically and work essentially like serialized API call data).

I find it easier than terraform since when using bicep you don't need to track state.
Post reply on HN