Earlier quoted context omitted.
What's the most common architecture you see for CMMC enclaves, especially those built by outside consulting firms?
I don’t work in defense, and neither does FedRAMP.
Decisions that eroded trust in Azure – by a former Azure Core engineer
691–697 of 697 posts
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#692I suppose that’s the point where you look for a job elsewhere. But maybe if you stuck around you would get the satisfaction of finally fixing the broken stuff (if you were still employed after the disaster that is). Wishful thinking?
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#693I'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.
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#694Earlier quoted context omitted.
It came from the top of Azure and for Azure only. Specifically the mandate was for all new code that cannot use a GC i.e. no more new C or C++ specifically. I think the CTO was very public about that at RustCon and other places where he spoke. The examples he gave were contrived, though, mostly tiny bits of old GDI code rewritten in Rust as success stories to justify his mandate. Not convincing at all. Azure node sof…
I have followed it from the outside, including talks at Rust Nation. However the reality you described on the ground is quite different from e.g. Rust Nation UK 2025 talks, or those being done by Victor Ciura. It seems more in line with the rejections that took place against previous efforts regarding Singularity, Midori, Phoenix compiler toolchain, Longhorn,.... only to be redone with WinRT and COM, in C++ naturally…
The whole memory safety chapter is a human problem first and foremost.
Some humans haven’t written a memory-safety bug in decades, but it requires a discipline the recent hire never acquired.
I always advocated fixing issues at their root. Humans write bugs, fix the humans. Somehow this was always regarded as taboo ever since I started at Microsoft in 2013.
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#695Earlier quoted context omitted.
“No, there is another”—Yoda, The Empire Strikes Back :) What you describe carries the risk that secrets end up in crash dumps and be exfiltrated. Imagine an attacker owns the host to some extent and can do that. The data is then on disk first, then stored somewhere else. You probably need per-tenant/per-VM encryption in your cache, since you can never protect against someone with elevated privileges from crashing or…
Of course, putting the metadata service into its own separate system is better. That's how Amazon does it with the modern AWS. A separate Nitro card handles all the networking and management. But if you're within the classic hypervisor model, then it doesn't really matter that much. The attack surface of a simple plain HTTP key-value storage is negligible compared to all other privileged code that needs to run on the…
…unless you use a general-purpose web server with its own set of challenges as far as policies and configuration. I’ll leave it there.
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#696I 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…
This isn't incentivized in corporate environment. Noticed how "the talent left after the launch" is mentioned in the article? Same problem. You don't get rewarded for cleaning up mess (despite lip service from management) nor for maintaining the product after the launch. Only big launches matter. The other corporate problem is that it takes time before the cleanup produces measurable benefits and you may as well get…
Also they too often remove features of their products and I have no desire to migrate working stuff because MS wants to move people to other products.
And these tend to be worse in recent times. Exemplary for that is PowerAutomate for me. Theoretically a neat tool that is well integrated into the cloud landscape. Practically you cannot implement reliable workflows with it because of numerous reasons.
> If you’re running production workloads on Azure or relying on it for mission-critical systems, this story matters more than you think.
Well, it doesn't explode, but I really question how reliable some of these systems really are. In my experience, not at all. There was or is some genuinely good engineering below some of these systems, but I think all the buggy fluff build upon it really introduces friction.
Re: Decisions that eroded trust in Azure – by a former Azure Core engineer
#697"isolveproblems", really?