Live data from Hacker News

Decisions that eroded trust in Azure – by a former Azure Core engineer

isolveproblems.substack.com

311–320 of 697 posts

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#311

Earlier quoted context omitted.

This is the root of the issue. For something like Azure, people are nor fungible. You need to retain them for decades, and carefully grow the team, training new members over a long period until they can take on serious responsibilities. But employees are rewarded for showing quick wins and changing jobs rapidly, and employers are rewarded for getting rid of high earners (i.e. senior, long-term employees).

> For something like Azure, people are nor fungible What I've learned from a decade in the industry is that talent is never fungible in low-demand areas. It's surprisingly hard to find people that "get it" and produce something worthwhile together.

I would say "systems design" rather than low-demand.

People who can "reduce" a big system to build on a few simple concepts are few and far between. Most people just add more stuff instead.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#312
post #281

Earlier quoted context omitted.

I was waiting for that comment :) Remember that everybody, eventually, calls into code written in C.

If 90% of the code I run is in safe rust (including the part that's new and written by me, therefore most likely to introduce bugs) and 10% is in C or unsafe rust, are you saying that has no value? Il meglio è l'inimico del bene. Le mieux est l'ennemi du bien. Perfect is the enemy of good.

That is an unexpected interpretation. Use the best tool for the job, also factoring what you (and your org) are comfortable with.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#313
I’ve been working with Azure and Azure Germanyfor the past years and have a strong history with AWS.

I cannot count how many times disks were not attaching during AKS rescheduling. We build polling where we polled Entra Id for minutes until it became “eventually” consistent - not trusting a service principal until it was fetched at least one minute consistently. The slowness of Azure Functions was unbearable. On Azure germany IoT Hubs had to be “rebooted” by support constantly - which was a shocking statement in itself. The docs always lying or leaving out critical parts. The whole Premium vs Standard stuff is like selling windows licenses. The role model and UI is absolutely inconsistent.

The stability, consistency of IAM, and speed of AWS in comparison makes me truly wonder how anyone stays with Azure. One reason might be that the Windows instances are significantly cheaper though..

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#315
Axel's engagement with the issue and refusal to give up is admirable. It also demonstrates that code and architecture remain important even in an era when managers believe these subjects can now be handled by LLMs. Imagine if LLMs were mandated for use in such an environment, further distancing SWEs from the code and overarching architectural choices. I am not saying that it can't work. But friction and maturity through experience really matters.

Also explains perfectly why I never met an engineer who was eager to run workloads on Azure. In orgs I worked, either the use of Azure was mandated by management (probably good $$ incentives) or through Microsoft leaning into the "Multi-Cloud for resilience" selling point, to get Orgs shift workloads from competitors.

Its also huge case for open (cloud) stack(s).

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#316
post #119
post #5

> The direct corollary is that any successful compromise of the host can give an attacker access to the complete memory of every VM running on that node. Keeping the host secure is therefore critical. > In that context, hosting a web service that is directly reachable from any guest VM and running it on the secure host side created a significantly larger attack surface than I expected. That is quite scary

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!

We run a significant amount of stuff on spot-instances (AKS nodes) and use the service detect, monitor and gracefully handle the imminent shutdown on the Kubernetes side.

https://learn.microsoft.com/en-us/azure/virtual-machines/lin...

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#317

Earlier quoted context omitted.

> For something like Azure, people are nor fungible What I've learned from a decade in the industry is that talent is never fungible in low-demand areas. It's surprisingly hard to find people that "get it" and produce something worthwhile together.

What is a low-demand area?

A geographic area where there's not abundant opportunity for software developers. Usually everywhere outside the major metro areas. It was primarily meant to discount experiences from SF or Seattle where I'm sure finding talent is easy enough, assuming you are willing to pay.

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#318
post #47

Earlier quoted context omitted.

I’ve worked with their consultants and they were lovely. They hate Azure too.

I imagine that no one likes Azure.

Azure container apps are a great (idea) and work mostly fine as long as you don’t need to touch them. But they’re just like GCR or what fargate should be - container + resources and off you go.

We ran many internal workloads on ACA, but we had _so may issues_ with everything else around ACA…

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#319

This read was a blast from the past. I'm not going to comment on much from OP and instead give a little of my experience there. Straight out of college in 2017 I joined the Compute Fabric Controller (FC) org as a SWE on an absolutely wonderful team that dealt with mostly container management, VM and Host fault handling & repair policies, and Fabric to Host communication with most of our code in the FC. I drove our te…

The first and most important lesson, that I try to each every young developer starting in the industry: Go home after clocking in your hours negotiated in your contract. Drop your pen. Go home. Sleep well.

And I hope, that every sensible senior developer in here does the same. Lead by example. Maybe it would prevent a few burnouts in this industry.

And if you are a manager, then send your people home after they have clocked in their negotiated hours. For their own well-being. It’s your responsibility. And if it’s not working, then force them to go home.

I hope you are better by now and got through the tough time. All the best for you!

Re: Decisions that eroded trust in Azure – by a former Azure Core engineer

#320

I think this is especially problematic (from Part 4 at https://isolveproblems.substack.com/p/how-microsoft-vaporize... ): "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…

if the service is so shitty, why are people paying so much fucking money for it? is microsoft committing an accounting fraud?

most the upper management of companies who use them have dont have the technical competence to see it. (eg: banks, supermarket chains, manufacturing companies)

once they are in, no one likes to admit they made a mistake.

Post reply on HN