Much of my recent professional life has been dominated by the Microsoft development stack – Visual Studio, C#, SQL Server and related technologies, and in recent years, the popular JavaScript frameworks and libraries, Angular and React.
Developers who work with a similar technology stack, would often use a Windows machine as their primary development workstation, as I did. But, my preferred personal computing platform, has always been Mac OS and Mac hardware. So my employer’s or client’s workstations have almost always been powerful Intel-based Windows Workstations, but my personal machines have almost always been Macs.
When doing work at home on my Macs over the years, I’ve tried using various flavours of virtualisation on Mac OS, to run instances of Windows, on Mac hardware. I did this to run:
- Windows-based Dev Tools, such as Visual Studio, and Visual Studio Code, or
- Windows-based Services, such as SQL Server, or Internet Information Services, both of which stretched the capabilities of a virtualised Windows environment extremely, or
- Other software or services for which there wasn’t a non-Windows option.
Initially, I used VMWare Fusion extensively, and more recently, particularly since Apple Silicon, Parallels. Both Fusion and Parallels are excellent products, but in recent times I’ve begun to re-consider the value of virtualisation of Windows on Mac for development activities.
While using VMware Fusion on Intel Macs, to support the development activities I’ve described, running Windows under “direct Intel based” Virtualisation, made sense. I could almost guarantee that if I had a sufficiently powerful Intel based Mac, I could run a Virtualised Windows workstation on this well resourced Mac which could run:
- Visual Studio or Visual Studio Code, and
- SQL Server, and
- Any other Microsoft Server or Services I needed, and
- Pretty much any Intel dependent software I needed.
However, Apple’s migration to Apple Silicon changed all that. Parallels was “first out of the blocks” with support for Virtualisation of Windows on Apple Silicon, but it’s initial support – as I found – had the somewhat restrictive requirement of using a specific version of Windows for ARM. The software that could be installed on that platform was very limited.
Recent versions of Parallel’s support for Windows is less restrictive and a smoother installation experience – Creating a new Windows 11 Virtual Machine is very straightforward – the installation image is downloaded on your behalf by Parallels, but the usefulness of the Windows workstation created, is diminished by the fact that the Windows workstation is ARM based.
Here are some of what I consider the advantages, and perhaps now the outweighing disadvantages of Windows platform virtualisation on Mac platforms.
Cost
Don’t get me wrong – both Fusion and Parallels are excellent products, but they’re not inexpensive products to use.
Fusion, which I don’t use anymore, generally suggested (and occasionally required) annual updates, to take advantage of the new features that each new release of Mac OS delivered. Perhaps not unreasonable, but it was also quite expensive.
Parallels takes a different approach. It uses an Annual Subscription licensing model, and the subscription is per machine. So, as I have a Desktop iMac and a Mac Book Pro, the cost of two Annual Licenses is not cheap.
compatibility and utility
What I mean by this is:
Given what I need to do in a Windows environment, how much can I do on a virtualised Windows environment on my Mac today – and by this I mean my Apple Silicon Mac.
And the answer is very much a mixed bag. I installed Windows 11 on Parallels (which Parallels assists with greatly) on my M1 Pro Mac Book Pro, to do a lot of this testing. I felt this was the most appropriate and “forward looking” platform to test on. I could have used my powerful, but slightly aging Intel based iMac but, I didn’t think that was the most sensible approach. Testing virtualisation on an Apple Silicon Platform is what most people will be doing from now on. Here’s what I found:
- Development Tooling: There has been quite a bit of progress in this area recently. Theoretically, the Visual Studio installer should install an ARM version of the Visual Studio 2022 onto a Windows 11 for ARM installation, but I struggled to get that to work correctly. I tried for some time, but couldn’t get it to install fully. Visual Studio Code for ARM did install correctly, and worked just fine, so VS Code, which has always been intended to be multi platform works very well.
- Database Tooling: I couldn’t find a way to get a Developer edition of SQL Server going within my ARM based Windows 11 – NOTE: There are a number of threads on Parallels community suggesting it can be done, but they are certainly not conclusive. However, I did use the unix based sqledge Docker Image and launched that on the underlying Mac OS under Docker to test connectivity. I was able to install SQL Server Management Studio – perhaps surprisingly – and Azure Data Studio under Windows 11 ARM.
- Networking and Connectivity: One of the difficulties I’ve faced in the past when working with virtualised environments are the challenges of connectivity between individual sub-systems and services across separate environments. And so it proved when trying to access the Docker based SQL Server instance from the Parallels based Windows 11 instance. I knew the Docker based SQL Server instance was accessible, as I could access it successfully from a Mac OS based database querying tool, but as I’ve found at other times, configuring the inbound and outbound network connectivity from and to virtual machines can be challenging, tricky and complicated. I am not saying that it is not doable, just that after half an hour of trying various combinations at the Parallels end, I could not establish TCP/IP connectivity between the SQL Server tools running inside Parallels and the Docker based SQL Server instance.
- Software Compatibility: Although most software installed, I did see one message come up during one installation – in a command line window – which was then closed without user intervention – which said “this tool can only be installed on ‘x86’ architecture”, so I’m not 100% certain whether all of the software I installed succeeded completely. Once again, the Windows 11 instance installed is Windows 11 ARM, and if any software is not “ARM Aware”, we may not get 100% compatibility.
- Performance: Despite the very impressive performance of the M1 Pro MacBook Pro, the virtualised Windows 11 Machine was no speed demon. Applications did not start very quickly, and so my hopes that the virtualisation of the Windows environment would prove to be a superior experience was not fulfilled.
To provide a baseline, I decided to compare it with my now aging Windows I7 laptop. I hadn’t done work on this machine for some time – most of my recent work having been related to Azure based applications recently. The machine is an aging Dell XPS 9560. It was an absolute beast of a machine when originally purchased, but now is certainly showing its age. I wanted to get a feel for how it compared with these virtualised environments. So after starting it up, I did the following:
- Updated all of the software – both OS updates, and development tools.
- Confirmed that I could Remote Desktop to it from both my Macs, and could use either 1 or multiple monitors on those Macs to do so. The multiple monitor connectivity via RDP provides an optimal Development environment.
- I got a subjective feel for just how performant the machine was still.
I went back to the original documentation about the laptop and was surprised to find it was purchased way back in June 2017! So the machine is approaching 6 years old, and even though it had the top of the line 7th generation I7 in 2017, is clearly well behind the pace now. I was pleasantly surprised by how performant tools like Visual Studio 2022, Visual Studio Code, SQL Server Management Studio, and SQL Server 2016 Developer Edition – installed locally – performed.
I cloned some repositories from Github, both Visual Studio based, and some other smaller Visual Studio Code based ones. The build, run and debug performance was excellent, as you’d expect, because it’s all running on a “conventionally” networked workstation, none of the problems I’d faced with virtualised workstations regarding networking were an issue. And I ran some quite demanding SQL Server queries on some large datasets and sample databases that were still on the machine.
Final Thoughts
After validating the viability of using my aging Dell laptop for Windows based development activities, I’m now leaning more strongly towards stepping away from virtualisation of Windows workstations on Mac OS. Even if my Dell laptop failed tomorrow, I could almost certainly buy an equally, if not more powerful, Windows based laptop for $750 AUD. And my annual subscription for 2 licenses of Parallels is the best part of $300 AUD, for what I have concluded, is a less capable solution.
There’s another important reason that makes using virtualisation less compelling for me – the ever improving capability of development tools for the Mac environment. Visual Studio Code already has parity across all platforms, and Visual Studio for the Mac is becoming more capable with every edition. And JetBrains Rider provides a fabulous alternative – once again, platform agnostic.
As I mentioned earlier, more and more of my work is moving away from “on-premise” development. The need for me to “host” on-premise services such as SQL Server or web servers such as IIS, arises much less frequently these days, and as tools become less and less platform dependent, my dependence on Windows diminishes by the day.
So taking all of these factors into account, in my particular circumstances, the need to virtualise Windows environments on Mac Hardware for development purposes, becomes marginal at best. For me, the conclusion is that I won’t be renewing my Parallels licenses when they become due. I’ll keep using my aging laptop for any “on-premise” Windows development activities, and if it were to fail, I’ll consider carefully whether I really need another one.