Live data from Hacker News

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

isolveproblems.substack.com

421–430 of 697 posts

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

#421

I've seen Azure OpenAI leak other customer's prompt responses to us under heavy load. https://x.com/DaveManouchehri/status/2037001748489949388 Nobody seems to care.

Did you anomomize those? Did Azure dox them or send the templated version?

Azure sent them to me like that.

I only saw two companies mentioned in the messages I got back. I reached out to both to try to confirm, but never heard back.

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

#422
post #298

Earlier quoted context omitted.

If you're sufficiently stubborn, it's certainly possible to call directly into code written in Verilog, held together with inscrutable Perl incantations. High-level languages like C certainly have their place, but the space seems competitive these days. Who knows where the future will lead.

You didn’t miss the smiley, did you? :)

I didn't miss the smiley =)

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

#423
I knew Microsoft was incredibly dysfunctional (you have to understand this if you're supporting their suite and want to succeed), but damn, I'm floored by the incompetence reported on from juniors to the Board and seemingly every step of leadership in between.

Yet I'm also not surprised, because I keep encountering it in non-Microsoft orgs. The current crop of leadership in general seems to be so myopically focused on GTM and share price bumps that even the mere suggestion of a problem is a career-ending move for whoever reported it (ask me how I know). Making matters worse is that Boards and shareholders have let them get away with this for so long, across every major org, that these folks believe in their heart and soul that they're absolutely, infallibly correct. The higher up someone is in an organization, the higher the likelihood they'll reject any and all feedback from "beneath" them that is contrary to their already-decided-upon agenda.

The kicker is that I'm not sure how to actually deal with this in a way that minimizes pain. In my subjective experience, these sorts of companies simply do not change until and unless there's literally no other option other than failure - and then, they're likely to choose failure for the parachute selection instead of doing the hard work of reform. Maybe what's needed is for Microsoft (or any of the legion of similarly dysfunctional enterprises out there) to genuinely fail in a non-recoverable way so as to shock the wider industry/economy into taking serious action on corporate misgovernance.

Maybe failure is the best option.

I don't know. I just know that this isn't tenable.

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

#424
post #111

Earlier quoted context omitted.

This is insane, when you say azure OpenAI, do you mean like github copilot, microsoft copilot, hitting openai’s api, or some openai llm hosted on azure offering that you hit through azure? This is some real wild west crap!

I have noticied a similar bug on Copilot. I noticed a chat session with questions that I had no recollection of asking. I wonder if it's related. I brushed it off as the question was generic.

I would guess that Copilot uses Azure OpenAI.

In my small sample size of a bit over a 100 accidentally leaked messages, many/most of them are programming related questions.

It's easy to brush it off as just LLM hallucinations. Azure OpenAI actually shows me how many input tokens were billed, and how many input tokens checked by the content filter. For these leaked responses, I was only billed for 8 input tokens, yet the content filter (correctly) checked >40,000 chars of input token (which was my actual prompt's size).

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

#425

Earlier quoted context omitted.

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

I worked at a startup that was using Azure. The reason was simple enough - it had been founded by finance people who were used to Excel, so Windows+Office was the non-negotiable first bit of IT they purchased. That created a sales channel Microsoft used to offer generous startup credits. The free money created a structural lack of discipline around spending. Once the startup credits ran out, the company became faced…

I have had bad experiences across all major vendors.

The main reason I used to push for Azure instead during the last years was the friendliness of their Web UIs, and having the VS Code integration (it started as an Azure product after all).

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

#426

Earlier quoted context omitted.

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

Because the alternatives are also in similar state. AWS or GCP are all pretty crap. You use any of them, any you'll hit just enough rough edges. The whole industry is just grinding out slop, quality is not important anywhere. I work with AWS on a daily basis, and I'm not really impressed. (Also nor did GCP impress me on the short encounter I had with it)

I don't know about AWS or the rest of GCP, but in terms of engineering, my experience of GCE was at least an entire order of magnitude better than what the article alleges about Azure. Security and reliability were taken extremely seriously, and the quality of the engineering was world-class. I hope it has stayed like this since then. It was a worthwhile thing to experience.

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

#428

I knew Microsoft was incredibly dysfunctional (you have to understand this if you're supporting their suite and want to succeed), but damn , I'm floored by the incompetence reported on from juniors to the Board and seemingly every step of leadership in between. Yet I'm also not surprised, because I keep encountering it in non-Microsoft orgs. The current crop of leadership in general seems to be so myopically focused…

> Maybe what's needed is for Microsoft (or any of the legion of similarly dysfunctional enterprises out there) to genuinely fail in a non-recoverable way so as to shock the wider industry/economy into taking serious action on corporate misgovernance.

The naive model of capitalism says that the benefit of market competition is that it's possible for failing companies to get out-competed by non-failing ones. In practice, there's enough of a combination of "natural monopoly", lock-in effects, and anti-competitive practices that the software landscape is covered in companies that are too big to avoid, let alone too big to fail.

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

#429

Earlier quoted context omitted.

I can’t count the number of times the docs have been totally wrong.

And they were actually like that pre-LLM, in 2019, when I was implementing stuff for a car company on azure. They spent _hundreds of thousands_ on cosmosDB, for less performance than a raspberry pi running Postgres.

Every marketing page and just about every second documentation page goes on and on about how fantastic CosmosDB performance and scalability is. Meanwhile, the best performance I have ever managed to squeeze out of it could be generously classified as "glacial".

Whenever I read its docs I feel like I'm being gaslit.

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

#430
post #242

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…

> I submitted several bug fixes and refactoring, notably using smart pointers, but they were rejected for fear of breaking something. And that, my friends, is why you want a memory safe language with as many static guarantees as possible checked automatically by the compiler.

Language choices won't save you here. The problem is organizational paralysis. Someone sees that the platform is unstable. They demand something be done to improve stability. The next management layer above them demands they reduce the number of changes made to improve stability.
Post reply on HN