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

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

isolveproblems.substack.com

Post reply on HN
Print view View original

481–490 of 697 posts

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

#481

Post by caoilte »

bob1029 wrote: post #385
branko_d wrote: post #205

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…

> first cover everything with tests Beware this goal. I'm dealing with the consequences of TDD taken way too far right now. Someone apparently had this same idea. > management who do not fully understand the problem nor are incentivized to understand it They are definitely incentivized to understand the problem. However the developers often take it upon themselves to deceive management. This happens to be their incen…

Unit tests are just as important as integration tests as long as they're tightly scoped to business logic and aren't written just to improve coverage. Anything can be done badly, especially if it is quantified and used as a metric of success (Goodhart's law applies).

Integration tests can be just as bad in this regard. They can be flakey and take hours, give you a false sense of security and not even address the complexity of the business domain.

I've seen people argue against unit tests because they force you to decompose your system into discrete pieces. I hope that's not the core concern here becuase a well decomposed system is easier to maintain and extend as well as write unit tests for.

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

#482

Post by pjmlp »

bostik wrote: post #478
pjmlp wrote: post #425

Earlier quoted context omitted.

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

Friendliness? VSCode integration out of the box, that I can understand. But I have a really hard time calling Azure UI "friendly". Everything is behind layers of nested pointy-clicky chains with opaque or flat out misleading names. To make things worse, their APIs also follow the same design. Everything you actually would want to do is behind a long sequence of pointer-chasing across objects and service/resource mana…

Yes, some of us grew out of the 1970's approach to command line, unless there is no other way.

GCP is the worse some options are only available on the CLI, without any visual feedback on the dashboard.

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

#483

Post by robshippr »

The "too risky to deploy" problem is really a visibility problem. When you can't quickly see what's actually changing in a deploy, fear becomes the default. The teams that break out of this aren't the ones who stop shipping, they're the ones who build better signals before the deploy so engineers can ship with confidence instead of just hoping nothing breaks.

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

#485

Post by milesvp »

axelriet wrote: post #251
dbdr wrote: post #242

Earlier quoted context omitted.

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

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

It’s worse than that. Eventually everybody calls into code that hits hardware. That is the level that the compiler (ironically?) can no longer make guarantees. Registers change outside the scope of the currently running program all the time. Reading a register can cause other registers on a chip to change. Random chips with access to a shared memory bus can modify the memory that the comipler deduced was static. There be dragons everywhere at the hardware layer and no compiler can ever reason correctly about all of them, because, guess what, rev2 of the hardware could swap a footprint compatible chip clone that has undocumented behavior that. So even if you gave all you board information to the compiler, the program could only be verifiably correct for one potential state of one potential hardware rev.

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

#486

Post by cineticdaffodil »

mike_hearn wrote: post #351
dbdr wrote: post #242

Earlier quoted context omitted.

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

Hence the rewrite-it-in-Rust initiative, presumably. Management were aware of this problem at some level but chose a questionable solution. I don't think rewriting everything in Rust is at all compatible with their feature timelines or severe shortages of systems programming talent.

In a rewrite you can smuggle in a quality lift

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

#487

Post by TheNewsIsHere »

This write-up is a shining example of why I’ve been rebuilding my business slowly away from Microsoft technology. Entra as IdP is one of the last projects. I’m probably not going to escape Exchange Online, but I’m going to be happy to finally federate the tenant to our internally managed IdP.

My spouse’s employer mandated that everyone move off AWS “because they’re a competitor” (they’re absolutely not), and Microsoft was happy to roll out discounts for Azure.

To say that has gone poorly would be generous. Azure is impressive in its own right, but it’s not comparable to AWS. (Which has its own problems, to be clear.)

The stagnation in Azure is apparent everywhere you look. The capacity issues have only gotten worse. There are still change advisory callouts in the Azure Portal with dates in the year 2020.

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

#489

Post by Whyachi »

silvestrov wrote: post #311
delusional wrote: post #263

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.

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.

[dead]

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

#490

Post by 7bit »

asteroidburger wrote: post #109
abtinf wrote: post #50

Earlier quoted context omitted.

> risks to national security …really? Really. Apparently the Secretary of War agrees with him.

The United States does not have a Secretary of War, and has not since 1947.

Uhm:

> The United States secretary of defense (SecDef), secondarily titled the secretary of war (SecWar),[b] is the head of the United States Department of Defense (DoD), the executive department of the U.S. Armed Forces, and is a high-ranking member of the cabinet of the United States.[8][9][10]

Wikipedia

Post reply on HN