Microsoft Dependency Has Risks

The trick with Microsoft is to very carefully separate the good parts from the bad ones.

Labeling all of Microsoft as banned is really constraining your technology options. This is a gigantic organization with a very diverse set of people in it.

There aren't many things like .NET, MSSQL and Visual Studio out there. The debugger experience in VS is the holy grail if you have super nasty real world technology situations. There's a reason every AAA game engine depends on it in some way.

Azure and Windows are where things start to get bad with Microsoft.

"There aren't many things like .NET, MSSQL and Visual Studio out there. The debugger experience in VS is the holy grail if you have super nasty real world technology situations. There's a reason every AAA game engine depends on it in some way."

I'm not interested in AAA games engines writing and nor is most of the world. If that is it, then you have damned MS with (very) faint praise.

To paint a picture: I’ve worked with Microsoft technologies almost exclusively for decades but recently I was forced to pick up some Node.js, Docker, and Linux tooling for a specific app.

I can’t express in words what a giant step backwards it is from ASP.NET and Visual Studio. It’s like bashing things with open source rocks after working in a rocket manufacturing facility festooned with Kuka robots.

It’s just… end-to-end bad. Everything from critical dependencies developed by one Russian kid that’s now getting shot at in Ukraine so “maintenance is paused” to everything being wired up with shell scripts that have fifty variants, no standards, and none of them work. I’ve spent more time just getting the builds and deployments to work (to an acceptable standard) for Node.js than I’ve spent developing entire .NET applications! [1]

I have had similar experiences every few years for decades. I touched PHP once and recoiled in horror. I tried to get a stable build going for some Python ML packages and learnt that they have a half-life measured in days or hours after which they become impossible to reproduce. Etc…

Keep on assuming “Microsoft is all bad” if you like. You’re tying both hands behind your back and poking the keyboard with your nose.

PS: The dotnet SDK is open source and works fine on Linux, and the IntelliJ Rider IDE is generally very good and cross-platform. You're not forced to use Windows.

[1] The effort required to get a NestJS app to have barely acceptable performance is significantly greater than the effort to rewrite it in .NET 9 which will immediately be faster and have a far bigger bag of performance tuning tools and technologies available if needed.

I tried developing an MS .NET app and it's indescribably bad. The deployment story is non-existent, monitoring, tracing, alarming is barely there. You have to work with MS libraries that are on life-support with glaring bugs still present.

> The deployment story is non-existent

Wrong! it is as simple as executing `dotnet publish`, zipping up the output folder and sending that package somewhere using whichever protocol and shell utility you like.

> monitoring, tracing, alarming is barely there

Also wrong. OpenTelemetry is fully supported by first-class packages and the dotnet runtime itself exposes a lot of counters. There are a lot of tools to monitor and collect traces of running dotnet processes [1]

> You have to work with MS libraries that are on life-support with glaring bugs still present

You don't have to. Every Microsoft.* library follows strict semantic versioning and is clearly labeled when it is deprecated. If you don't have a plan in place on how to manage your dependencies then this is on you.

[1] https://learn.microsoft.com/en-us/dotnet/core/diagnostics/to...

> Wrong! it is as simple as executing `dotnet publish`

Yeah. And now add a C/C++ component there. Or maybe a neural network in Python?

In my case, it was a ray tracer that used a GPU.

"Just zip it", yea sure.

> Yeah. And now add a C/C++ component there. Or maybe a neural network in Python?

How do you compile and package those components up? Answer that and you have your answer for this scenario.

>"Just zip it", yea sure.

I don't understand this. You can zip it. You can XCopy it. You can RSync it. Doesn't matter. What's your objection to that statement?

> How do you compile and package those components up? Answer that and you have your answer for this scenario.

I have a Dockerfile that contains the build instructions? How would I do that with MSVS?

> I don't understand this. You can zip it.

Yes, and then my Linux machine that runs the server will happily run a Windows application. With all the dependencies, including the GPU toolkits.

But even if we stay _within_ the MS ecosystem, the "just copy it" deployment doesn't cover everything. E.g. it can't change the settings of the "App Service Logs" from within the app itself. Of course you can also use Terraform for the infra, but at this point you're way off the "just copy a folder".

MSVS also supports containers, but if you do that it just becomes a UI for their configuration, not really any different from JetBrains.