Hello, Azurebook: Why Microsoft's Windows future is Intel-free and cloudy
In a previous post, before Apple's 2020 WWDC, I pondered the potential development path of an Arm-based Mac. As it happened, this thought exercise turned out to be more accurate than I thought, but I made a few assumptions about Apple's intentions to lock down its ecosystem that may have been premature.
Featured
Part of the reason why it is challenging to be accurate about this kind of crystal-ball staring, as it pertains to companies like Apple, is that they are so secretive that having any sort of visibility into their development processes is nearly impossible. You can read tea leaves, and you can go by what exists in terms of overall technology trends, and what it has already done and made investments in. However, because the company isn't transparent at all about what it does, you might as well try to engage in Kremlinology about North Korea.
The natural response to Apple's Arm migration is "What is Microsoft doing?"
Is the company similarly going to do a full port of Windows to Arm and work with the OEM ecosystem to make Arm PCs? Because Microsoft is a much more transparent company than Apple, we already have many of the answers. So let's engage in a similar thought exercise, and see where we end up.
Windows on Arm
Traditionally, Microsoft is a very different company than Apple, in the sense that it doesn't have full autonomy over its ecosystem, and is predominantly a software and cloud infrastructure company, rather than a hardware player. Microsoft develops Windows and then sells licenses to OEMs; of that group, the big three (Dell, HP, and Lenovo) are continuing to increase their share as the number of other participants and the overall PC market continue to shrink dramatically. Microsoft also produces the Surface line of computer systems, which is becoming an increasingly important aspect of its business.
The question of whether or not Microsoft will port Windows 10 to Arm is a non-issue. A 64-bit Arm version already runs on the Surface Pro X and the Samsung Galaxy Book S (both recent models introduced in late 2019 and early 2020, respectively), and also on the Lenovo C630 and the HP Envy x2. The latter two are from the first wave of Windows 10 Arm systems released about two years ago, and are overdue for a refresh. Dell is currently conspicuous in its absence and has previously stated its intention to wait and see how other Windows 10 Arm systems fare in the marketplace before jumping in.
The overwhelming migration issue isn't porting the OS -- Microsoft has already produced a complete port of Windows 10 to Arm. It does currently have several limitations, however. Windows 10 on Arm can run 32-bit Win32 apps originally written for x86, unmodified -- but its x86 emulator won't run 64-bit Win32 apps from that platform. It can also run Arm32 and Arm64 UWP apps from the Windows Store. Currently, other than the Chromium version of Edge, there are no native Win32 Arm apps to run on these systems. Still, Microsoft has recently unveiled "Project Reunion" that will allow developers to create hybridized Win32/UWP apps and deploy on multiple architectures, so it should now be easier to do, provided Microsoft has a distribution mechanism for them, theoretically.
The main drawback with these current-generation Arm Windows systems is their high cost, and also their performance. All use SoCs that have been adapted from those used on smartphones, such as the Qualcomm Snapdragon 850 (which is used on the Lenovo C630), the Qualcomm Snapdragon 8CX (which is used on the Samsung Galaxy Book S) and the Qualcomm SQ1 (which is used on the Surface Pro X).
Because the most popular Windows applications have not been ported to Arm, they need to run as 32-bit Win32 apps with Intel emulation -- which is not a recipe for high performance when you consider these Arm SoCs are less potent than their Intel counterparts.
The ideal end-state is to have native 64-bit Win32 apps running along with their UWP counterparts on Arm chips that match or exceed the performance of existing Intel systems. Currently, we're a long way from realizing that because existing Arm silicon from Qualcomm, Samsung, and others is nowhere near as fast in terms of core performance as what Apple has demonstrated to date with its silicon, even when running apps in emulation.
The app gap and the compatibility curse
The lack of native Arm Windows apps has been problematic. But this is to be expected because the challenges that Microsoft has in getting OEMs and enterprises to shift to a new PC architecture are immense compared to what Apple has to deal with. There are some 35 million application titles and greater than 175 million application versions, which use APIs that go back at least 25 years.
The Mac, by comparison, has only about 30,000 applications total, most of which use APIs that only go back about a decade. The company recently eliminated the use of all the legacy "Carbon" APIs from its classic OS that predated Mac OS X, in 2019 with Catalina, as well as support for all 32-bit apps. There are probably two or three dozen heavily used professional apps on Mac that are of paramount importance that need to get ported to Arm, and the rest is going to come from the considerable stable of iPad applications and ported to Apple Silicon's Catalyst.
If Microsoft intends to proceed with a similar project to leave the x86 behind on the PC, then it has a massive task ahead of it. Part of this has to involve deciding which APIs and libraries to leave behind and which ones to move forward. In addition to applications written in multiple generations of .Net, which originated as early as the year 2000, there are also Windows applications in the wild that use APIs from the 1990s.
Many of these are apps are in-house developed, highly complex enterprise applications that use a multitude of programming languages, frameworks, toolsets, and libraries. They include runtime environments from hundreds of vendors -- not all of which still exist or actively develop those tools, but still may be used.
That Windows 10 can still run these applications is both a gift and also a curse. While Apple is known to throw out its babies with the proverbial bathwater whenever it goes through a major version or platform change, Microsoft has never thrown out any of its compatibility in x86 versions of Windows. It is still possible to run 16-bit Windows 3.x applications and DOS apps on Windows 10, provided you have all the necessary application libraries and subsystems installed to support it. This rich legacy compatibility that has endured for decades would be the rough equivalent of Apple allowing end-users to run Classic Mac apps from the 1980s on current Mac OS X versions, which it doesn't.
Cloud
However, moving all of these APIs and subsystems to Arm would not be practical, because applications that are under active development today do not use them. So Microsoft would need to make hard choices as to what languages, frameworks, libraries, and APIs would be supported natively on Arm going forward, much as Apple is doing with the new Arm-based Macs.
Containerization and the Cloud
In addition to the Windows 10 Arm port itself, Microsoft has been making other architectural changes in Windows that would be needed for a major platform shift -- most notably the use of containerization.
Over the last three years, the company has made significant investments in containerization technology -- starting in Azure, for its own internal SaaS and PaaS offerings. Eventually, it rolled out containers to customers using Docker and the Azure Container Service. Container technology has also been rolled out in Windows Server 2019 and in recent public builds of Windows 10. These have already been deployed to millions of end-users, and tech containerization technology complements the built-in Hyper-V hypervisor/virtualization engine that the platform has had over a decade. Windows 10 X, which is slated to run on the Surface Neo, uses an entirely containerized, componentized OS and app system.
Containerization is important not just because it allows applications and environments to be easily isolated from each other, but also allows applications and parts of Windows itself to be more componentized. By mixing virtualization (VMs) and containers, a hyperscale cloud environment can provide rapid provisioning, much simpler patch management, and the ability to support tens of millions of users at a time that would not be possible with just VMs alone.
VMs are much more resource-intensive, as they are used to run full copies of the OS and can fully emulate hardware. They are ideal for allowing applications and environments to run completely unmodified so that a "lift and shift" approach is possible for those applications that need it. Virtualization eases migration concerns, but given that VMs are more resource-intensive to host than a container or an app service (PaaS), they also much more expensive to run in terms of compute cycles, provisioned memory, storage, and I/O -- so you want to use them sparingly.
In addition to moving applications to the cloud, containers would be needed to move Windows to Arm on the client. This is because of the improved security model for containerization and for supporting all sorts of legacy applications that might not behave properly or might pose potential security risks. For similar reasons, in addition to a new Apple hypervisor for hosting virtual machines, Apple's new Arm-based Macs run the Rosetta x86 emulation layer, the iPad runtime environment, and Catalyst apps in a containerized fashion.
However, given that Microsoft has such extensive cloud-based resources, it begs the question as to whether or not it makes sense for the company to undergo the level of effort to run native Windows applications on less powerful chips that will not provide the performance that end-users would expect on their existing PCs.
For this reason, I believe that Microsoft will not pursue an Apple-like path to a new PC platform running on Arm -- it will do something else entirely.
Enter the Azurebook
The Windows 10 user experience has now been ported to Arm, which gets us most of the way to moving to a new desktop paradigm. However, without a powerful enough Arm processor, you can't locally run the apps users will want to move to the new platform.
Indeed, Microsoft could continue to invest tens of billions of dollars in creating its own desktop SoCs and PCs like Surface Pro X with Qualcomm. Alternatively, it could buy a semiconductor company like AMD or even Qualcomm itself to get to parity with Apple if it went on a crash program to build Microsoft Silicon. But that doesn't make sense when the company has virtually unlimited computing horsepower in the form of over 100 Azure datacenters situated around the globe -- and growing.
I believe that the future of the PC is not a PC at all, but what I call an "Azurebook."
An Azurebook would be an Arm-based (or even a license-free RISC-V or OpenPower-based) system running a stripped-down version of Windows 10 whose sole purpose is to run the new Chromium-based version of the Edge browser, managed UWP Windows Store apps and, most importantly, legacy Windows apps hosted on Azure. It could be configured as a desktop-style device connected to a full-sized keyboard and large monitors, or as a laptop.
It would not have any legacy compatibility libraries at all. All the apps that we know and love, such as Office -- would be hosted entirely on Azure itself, running in containers and VMs. Rather than engaging in a crash Arm-porting program with its developers as Apple is doing, Microsoft would encourage ISV's to containerize their Win32 apps to run on hosted environments, so that they would become subscriber services, as SaaS. Legacy apps could run in the cloud on virtual infrastructure, or in private data centers, unmodified, running on solutions such as Citrix. All that is missing in this scenario is a user-friendly front-end for end-users and enterprises to access the apps, in a store-like UX.
It wouldn't all have to live on Azure, either. Microsoft is the primary force behind the CNAB application bundling standard, which allows apps to be packaged in such a way that they can be deployed the same on any hyperscale cloud or hosted datacenter environment, whether it is Azure, Amazon Web Services, Google Cloud, OpenStack, and anything else.
Microsoft has already begun to deploy Windows Virtual Desktops in Azure, priced so that enterprises can access them, license-free, provided they have the appropriate Microsoft 365 entitlements. They simply need to pay for the VM compute, storage, and applicable networking costs. But Microsoft could sweeten the deal even further if it were to eliminate the VM requirement and run remote Windows 10 environments and hosted apps in containers -- then you would only be paying for access to the applications themselves.
User acceptance, not technical implementation, is the major obstacle
For end-users to abandon legacy Intel PCs and move to what would effectively be a thin client device, this would need to be a significantly better experience, and it would also need to be less expensive than what they have now.
I think it is safe to say that nobody is going to throw out perfectly good systems that they already use -- the replacement cycle for home PCs typically occurs when those devices cannot be repaired. But with more and more employees shifting their workplace to home-based settings due to increased social distancing, there are practical matters of ongoing IT support that need to be taken into account.
Any organization with home-based employees is going to need to get IT assets into the field -- and remote PC and application support under the traditional model is an unsustainable nightmare. The future of remote work requires an entirely new approach.
An "Azurebook" would be a zero-configuration device that would be tied into Azure Active Directory identity management. It would effectively be an appliance because all it needs to do is use lightweight, bandwidth-conserving RDP or ICA-based connection protocols to get to remote apps running in the cloud, and a menu and icons that were populated as needed to access the resources as provisioned. This would be the Windows equivalent to a Chromebook (or Chromebox) -- but with a Microsoft UX.
Such a device needs just enough horsepower to provide a snappy-enough GUI front-end on the local device -- all of the heavy application processing will occur in the cloud datacenters, which have vast amounts of computing power. So, in theory, it should not be difficult to build a terminal type device for $300 that runs on a low-power Arm chip, complete with networking and underlying storage. It doesn't need to have the local horsepower of something like an iPad Pro to do what it needs to do. Any number of inexpensive SoCs that exist in the supply chain for building today's Android tablets and smartphones would be suitable for manufacturing such devices and allow manufacturers to keep the price affordable.
That solves the problem for SMBs and enterprises, but what about your average home user? Arguably, the PC has been disappearing in homes for years, and there are millions of people who do not own personal computers at all, having replaced their computing experience with a smartphone or a tablet. Still, a $300-$500 device, with integrated display, and consumer subscription services, which could connect to external monitors and mouse/keyboard could easily replace a home PC if the hosted cloud applications were appropriately robust.
Google has already made significant inroads with equipping students with Chromebooks and providing them with access to GSuite. Microsoft could do the same thing by investing more resources in the Web UX for Office. While not all the features of the desktop version have been ported over, such as for multi-author collaboration, it's already most of the way there and entirely usable.
The free, web version of Microsoft 365 is undoubtedly "good enough" for most end-users to do typical productivity stuff. If a 365 entitlement isn't provided by their workplace or educational institution, and they need the additional functionality of the business product, single and family entitlements are quite affordable -- it's $69 a year for an individual user and $99 for six users, assuming educational discounts or benefits aren't applied.
The challenge will not be the technical implementation and creating an acceptable experience for the end-user. There's no question that a hybrid cloud-based experience would be better performing, would be more secure, and would be virtually maintenance-free for everyone using it. It will be the perception that the cloud is slower, that the hosted apps aren't as rich or feature-intensive, that it poses some sort of boogeyman security or privacy risk, or that the connectivity won't be reliable.
Yes, there are concerns that any loss of connectivity makes such an environment useless. Still, the cloud is already pervasive in end-user environments, and any loss of connectivity would make remote work come to a halt regardless. It doesn't matter if your app is local or remote, because all access to your corporate data has to transit the internet regardless. For most remote work use cases, If your broadband goes down, your work is going to stop whether you are using a PC, a Mac, or a terminal.
There are also the inevitable "I don't trust the cloud because X" and "I want full possession of my data" naysayers who have been resisting upgrading to cloud-based services for years. Some run esoteric types of applications which may not yet have cloud equivalents, and some mobile workers have to work in the field as well.
Those people may never be able to migrate to a system like this, and for those, there will always be a need for a full-fledged PC or at least mobile devices with local applications running. But these are more of the edge cases and the outliers than the norm -- who can easily make use of a managed, cloud-based application environment.
Will Microsoft build full-fledged, Arm-based PCs to compete with the new Apple Silicon Macs? Or will it take an Azurebook approach? Talk Back and Let Me Know.