Earlier quoted context omitted.
It is kind of a fundamental risk of IMDS, the guest vms often need some metadata about themselves, the host has it. A hardened, network gapped service running host side is acceptable, possibly the best solution. I think the issue is if your IMDS is fat and vulnerable, which this article kind of alludes to. There’s also the fact that azure’s implementation doesn’t require auth so it’s very vulnerable to SSRF
You could imagine hosting the metadata service somewhere else. After all there is nothing a node knows about a VM that the fabric doesn’t. And things like certificates comes from somewhere anyway, they are not on the node so that service is just cache.
Decisions that eroded trust in Azure – by a former Azure Core engineer
201–210 of 697 posts
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#202Earlier quoted context omitted.
This is well documented: https://learn.microsoft.com/en-us/azure/virtual-machines/ins... Why would an Azure customer need to query this service at all? I was not aware this service even exists- because I never needed anything like it. AFAI can tell, this service tells services running on the VM what SKU the VM is. But how is this useful to the service? Any Azure users could tell how they use IMDS? Thanks!
Mainly for getting managed-identity access tokens for Azure APIs. In AWS you can call it to get temporary credentials for the EC2’s attached IAM role. In both cases - you use IMDS to get tokens/creds for identity/access management. Client libraries usually abstract away the need to call IMDS directly by calling it for you.
Thanks again!
[edited phrasing]
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#203What makes anyone start a new project and think “I know, I’ll use Azure!”? I really don’t get it. Do they have a great sales org? Is it because a phb thinks “well they made Office so it must be good”? I interviewed with a Dutch energy company migrating infra from AWS -to- Azure and I have no idea what would make them do that (aside from inertia, but then why use Azure in the first place?) And for some reason Azure us…
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#204What makes anyone start a new project and think “I know, I’ll use Azure!”? I really don’t get it. Do they have a great sales org? Is it because a phb thinks “well they made Office so it must be good”? I interviewed with a Dutch energy company migrating infra from AWS -to- Azure and I have no idea what would make them do that (aside from inertia, but then why use Azure in the first place?) And for some reason Azure us…
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#205"The team had reached a point where it was too risky to make any code refactoring or engineering improvements. I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something."
Once you reach this stage, the only escape is to first cover everything with tests and then meticulously fix bugs, without shipping any new features. This can take a long time, and cannot happen without the full support from the management who do not fully understand the problem nor are incentivized to understand it.
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#206What makes anyone start a new project and think “I know, I’ll use Azure!”? I really don’t get it. Do they have a great sales org? Is it because a phb thinks “well they made Office so it must be good”? I interviewed with a Dutch energy company migrating infra from AWS -to- Azure and I have no idea what would make them do that (aside from inertia, but then why use Azure in the first place?) And for some reason Azure us…
They give free credit to startups if you fill in a few forms.
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#207Earlier quoted context omitted.
[flagged]
Thanks for the free psychology assessment, I appreciate it, but I believe I’m fine. The series omits lots of details.
There is nothing good that can come out of it,, except getting fired.
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#208Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#209It's a nice read. Thank you for sharing this. > Microsoft, meanwhile, conducted major layoffs—approximately 15,000 roles across waves in May and July 2025 —most likely to compensate for the immediate losses to CoreWeave ahead of the next earnings calls. This is what people should know when seeing massive layoffs due to AI.
I honestly thought this was one of the weaker points of the article. The OpenAI deal almost certainly related purely to GPU capacity, which had little to do with the article. The layoffs would have happened regardless. IMO - churn, and generalization is the root cause. Engineers are thrown on projects for a year with little prior experience, leave others to pickup the pieces, etc. There's no longer a sense of ownersh…
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#210Earlier quoted context omitted.
To what end? I've never seen an SLA which is clear cut enough to be worth pursuing if you want more than a free t-shirt.
> I've never seen an SLA which is clear cut enough to be worth pursuing if you want more than a free t-shirt. I have, regularly. I am not sure what kind of business you are running but parties that rely on service providers for critical (primary business process driving) components routinely agree to SLAs with large penalties and the ability to open up an existing contract in case of non-performance. Obviously you wo…
By the time SLA thresholds are being breached you've been through months (or years) of pain. They're not strong enough or specific enough to save you from a bad provider. ymmv