It’s hard to believe that almost three years have passed since I wrote my first blog entry discussing Windows running on the ARM processor. Over that time, we’ve seen an increasing onslaught of client devices (tablets and phones) running on ARM, and we’ve watched Windows expand to several Windows RT-based devices, and retract back to the Surface RT and Surface 2 being the only ARM-based Windows tablets, and now with the impending Nokia 2520 being the only non-Microsoft (and the only non-Nvidia) Windows RT tablets – that is, for as long as Nokia isn’t a part of Microsoft.
Before I dive in to the topic of Windows on ARM servers, I think it is important to take a step back and assess Windows RT.
Windows RT 8.1 likely shows the way that Microsoft’s non-x64 tablets will go – with less and less emphasis on the desktop over time, specifically as we see more touch-friendly Office applications in the modern shell. In essence, the strength that Microsoft has been promoting Windows RT upon (Office! The desktop you know!) is also it’s Achilles heel, due to the bifurcated roles of the desktop and modern UIs. But that’s the client – where, if Microsoft succeeds, the desktop becomes less important over time, and the modern interface becomes more important. A completely different direction than servers.
Microsoft will surely tell you that Windows RT, like the Windows Store and Surface, are investments in the long term. They aren’t short-term bets. That said, I think you’d have to really question anybody who tells you “Windows RT is doing really well.” Many partners kicking Windows RT’s tires ahead of launch bolted before the OS arrived, and every other ODM/OEM building or selling Windows RT devices has abandoned the platform in favor of low-cost Intel silicon instead. The Windows Store may be growing in some aspects, but until it is healthy and standing on its own, Windows RT is a second fiddle to Windows 8.x, where the desktop can be available to run “old software”, as much as that may be uninspiring on a tablet.
For some odd reason, people are fascinated with the idea of ARM-based servers. I’ve wound up in several debates/discussions with people on Twitter about Windows on ARM servers. I hope it never happens, and I don’t believe it will. Moreover, if it does, I believe it will fail.
ARM is ideal for a client platform – especially a clean client platform with no legacy baggage (Android, iOS, etc). It is low-power and highly customizable silicon. Certainly, when you look at data centers, the first thing you’ll notice is the energy consumption. Sure, it’d be great if we could conceptually reduce that by using ARM. But I’m really not sure replacing systems running one instruction set with systems running another is really a)viable or b)the most cost effective way to go about making the infrastructure more energy efficient.
Windows RT is, in effect, a power-optimized version of Windows 8, targeted to Nvidia and Qualcomm SoCs. It cannot run (most) troublesome desktop applications, and as a result doesn’t suffer from decades of Win32 development bad habits, with applications constantly pushing, pulling, polling and waiting… Instead, Windows RT is predominantly based around WinRT, a new, tightly marshaled API set intended to (in addition to favoring touch) minimize power consumption of non-foreground applications (you’ll note, the complete opposite of what servers do). Many people contemplating ARM-based Windows servers don’t seem to understand how horribly this model (WinRT) would translate to Windows server.
I talked earlier this year about the fork in the road ahead of Windows Server and the Windows client. I feel that it is very important to understand this fork, as Windows Server and client are headed in totally different directions in terms of how you interact with them and how they fulfill their expected role:
- Windows client shell is Start screen/modern/Explorer first. Focuses on low-power, foreground-led applications, ARM and x86/x64, predominantly emphasizing WinRT.
- Windows Server shell is increasingly PowerShell first. Focuses on virtualization, storage, and networking, efficient use of background processes, x64 only, predominantly emphasizing .NET and ASP.NET.
For years, Microsoft fought Linux tooth and nail to be the OS of choice for hosters. There’s really not much money to be made at that low end when you’re fighting against free and can’t charge for client access licenses, where Microsoft loves to make bread and butter. Microsoft offered low-end variants of Windows Server to try and break into this market. Cheaper prices mixed with hamstrung feature capabilities, etc. In time the custom edition was dropped in favor of less restrictive licensing of the regular editions of Windows Server 2012. But this isn’t a licensing piece, so I digress.
It is my sincere hope that there are enough people left at Microsoft who can still remember the Itanium. We’ll never know how much money ($MM? $BB?) was wasted on trying to make Windows Server and a few other workloads successful on the Itanium processor. Microsoft spent considerable time and money getting Windows (initially client and server, eventually just server) and select server applications/workloads ported to Itanium. Not much in terms of software ever actually made it over. Now it is dead – like every other architecture Windows NT has been ported to other than x64 (technically a port, but quite different) and, for now, ARM.
That in mind, I invite you to ponder what it would take to get a Windows Server ecosystem running on ARM processors, doing the things servers need to do. You’d need:
- 64-bit ARM processors from Nvidia or Qualcomm (SoCs already supported by Windows, but in 64-bit forms)
- Server hardware built around these processors – likely blade servers
- Server workloads for Windows built around these processors – likely IIS and a select other range of roles such as a Hadoop node, etc.
- .NET framework and other third-party/dev dependencies (many of these in place due to Windows RT, but are likely 32-bit, not 64-bit)
- Your code, running on ARM. Many things might just work, lots of things just won’t.
That’s just the technical side. It isn’t to say you couldn’t do it – or that part of it might not already be done within Microsoft already, but otherwise it would be a fairly large amount of work with likely a very, very low payoff for Microsoft, which leads us, briefly, to the licensing side. You think ARM-based clients are scraping the bottom of the pricing barrel? I don’t think Microsoft could charge nearly the price they do for Windows Server 2012 R2 Standard on an ARM-based server and have it be commercially viable (when going up against free operating systems). Charge less than Windows Server on x64, and you’re cannibalizing your own platform – something Microsoft doesn’t like to do.
Of course, the biggest argument against Windows Server on ARM processors is this: www.windowsazure.com. Any role that you would likely find an ARM server well-suited for, Microsoft would be happy to sublet you time on Windows Azure to accomplish the same task. Web hosting, Web application, task node, Hadoop node, etc. Sure, it isn’t on-premises, but if your primary consideration is cost, using Azure instead of building out a new ARM-based data center is probably a more financially viable direction, and is what Microsoft would much rather see going forward. The energy efficiency is explicit – you likely pay fractions of what you might for the same fixed hardware workload on premises running on x64 Windows, and you pay “nothing” when the workload is off in Azure – you can also expand or contract your scale as you need to, without investing in more hardware (but you run the same code you would on-premises – not the same as ARM would need). Microsoft, being a Devices and Services company now, would much rather sell you a steady supply of Windows Azure-based services instead of Windows Server licenses that might never be updated again.
Certainly, anything is possible. We could see Windows Server on ARM processors. We could even see Microsoft-branded server hardware (please no, Microsoft). But I don’t believe Microsoft sees either of those as a path forward. For on-premises, the future of energy efficiency with Windows Server lies in virtualization and consolidation on top of Hyper-V and Windows Server 2012+. For off-premises, the future of energy efficiency with Windows Server appears rather Azure. I certainly don’t expect to see an ARM-based Windows Server anytime soon. If I do, I’d really like to see the economic model that justifies it, and what the OS would sell for.