Decoupling Microsoft, or Free Your App

Published: 2016 Feb 9 by Avi Deitcher

A few weeks ago, a colleague showed me a technology that was fascinating in and of itself, but the strategic ramifications are even greater.

For those of you who are technically inclined, look at these links:

These are, respectively, the Linux docker images for running Microsoft .Net and ASP.Net apps, and the open-source repository.

This is quite cool technically. After all, apps compiled for platform A, especially tightly closed platforms like Microsoft, usually aren't meant to run on platform B!

(To be fair, for those who understand how software actually works, it isn't that surprising, as they all deal with the same underlying processor. Further, many compiled modern server languages like Java and .Net aren't actually compiled into native CPU code, but rather some intermediary like "byte-code". But I digress.)

It is the strategic ramifications, however, that are the truly exciting part.

Microsoft earns its money primarily from a few places:

Operating system licenses - Windows
Productivity software licenses - Office
Server software licenses - Exchange, SharePoint, etc.

While much of server software licensing is shifting to Microsoft's cloud offerings, it still is part of the same "IT software to run your business".

A key part of the Microsoft business model always has been vertical lock-in. Exchange works on Windows, therefore, if you want to run Exchange, buy a Window server. Office runs on Windows 10, so if you want Excel, buy a Windows desktop.

The development environments and languages are a simple extension of that philosophy. .Net apps run on Windows. Therefore, if you like or have a history (or legacy) of .Net apps, invest in Windows servers.

The first step in breaking this linkage was Microsoft open-sourcing much of .Net, especially the CoreCLR, or software that runs .Net programs, like the Java Runtime Engine (JRE). We discussed this almost a year and a half ago here and here.

However, the above only made it possible, that someone would find a way to run .Net (i.e. Windows) applications on non-Windows operating systems.

For Microsoft itself to release and support elements the CoreCLR and tools to run .Net apps on non-Windows platforms is a whole other level.

Essentially, Microsoft is saying, "if you want to write/run/support Windows apps but not pay us to license servers because you are running the apps on some other platform, that is fine with us."

Put in other terms, Microsoft just freed thousands of companies from the shackles of paying Microsoft licensing fees! What could induce them to take this step?

One possibility is that Microsoft sees a downward trend in .Net adoption. Many startups will not touch .Net, and many VCs will not fund companies whose software is written in .Net. Decoupling the software and the platform reduces deadweight on .Net and may give it a new lease on life. After all, investors refuse .Net not because the technology is terrible - they simply do not care - but because they don't want their money going for Windows licenses when Linux (or SmartOS or FreeBSD) is a free alternative; there are better uses for scarce investor capital. Someone shared this link with me indicating that .Net still is the second most-used language. I do not know the date on this (in itself, suspicious), but I suspect that different methodologies will show a decline. Either way, the future, indicated by younger developers and companies, clearly points away from .Net.

A second possibility is funneling. If you have an operating system platform that is clearly superiour in terms of performance or manageability, then customers who care about it will buy it anyways. Decoupling the app platform (.Net) from the operating system platform lets independents and young companies with limited cash get used to .Net, only to come back to Microsoft and pay for the operating system platform when they need the manageability.

The problem with this second scenario is that, in scale, Microsoft platforms are harder to manage. Ask any seasoned large-scale IT or cloud systems manager what he or she would rather run, 1,000 Windows servers or 5,000 Linux instances. Uniformly, the answer is the latter. With the right tooling, Linux is far easier to manage at scale. Of course, Microsoft may not, or likely does not, see it that way.

Does all of this mean you should adopt .Net, or, if you were planning on replacing .Net with something open-source (or more natively open-source), stick with it?

The answer, as always, is "it depends." .Net on non-Windows platforms still is a very young technology with a way to go. It is unclear how long Microsoft will continue to support it, and how well it will be able to do so.

As an aside, the people at Joyent used their SmartOS-based platform with Dtrace to do some debugging and performance analysis of .Net apps that never could have happened on native Windows.

If your reasons for going .Net are significantly greater than an alternate platform, but the Windows-only was holding you back, then you may want to stay with it. If it is closer, then true open-source cross-platform languages are likely to serve you better.