Windows Server and SQL Server licensing in containers
The "container" technology emerged a few years ago. At the time, there were no specific licensing rules for containers, and calculating the old licenses in "containerised" environments remains a grey area.
But even with the current versions of Microsoft software, there's considerable frustration because Windows Server and SQL Server are licensed differently. I encourage you not to confuse one with another.
But what is a container anyway?
Let's quickly dive into the fantastic world of virtualisation.
In the very beginning, computers were relatively simple. Every computer needed one operating system and several applications that ran inside it. For example, a typical office desktop would have a Microsoft Windows operating system installed, in which you would run applications like Microsoft Office.
Then, once upon a time, a clever person whose name I don't know had a brilliant idea: "why don't we 'fool' an application and create a virtual environment for it, which will look to that software as if it was a hardware computer?" I don't want to go deep into technical reasons, but such isolation has multiple technical and security benefits.
That new technology was named "virtualisation". Simplified, it looks like this:
A physical computer runs its usual operating system,
Inside the operating system runs an application called "hypervisor",
The hypervisor creates isolated "virtual environments" that can have their own operating systems installed. Each virtual environment looks like a "real" computer to those operating systems and their applications.
And that's my lousy explanation of what virtualisation is. It's about creating "virtual" computers inside a physical one. The physical computer has its own "physical" operating system, and each virtual computer has its own "virtual" operating system. Microsoft calls them "OSEs" – operating system environments, which is a more precise term.
But with all the benefits of virtualisation comes one problem. Each time you decide to virtualise an application in this "traditional" way, you must create and deploy a new operating system that requires computing resources and dedicated maintenance. And often, you don't need that level of isolation anyway.
So other clever people came up with a different idea: "Why don't we somehow isolate an application inside the core ("physical") operating system that runs on the computer without creating a virtual operating system for that?
"Let's create a "sandbox", a "bubble" that will share the computer's operating system's resources, but certain settings and certain things will be specific to the piece of software that runs inside it."
And they called it "containers".
Here's a simple comparison:
Each virtual machine is a separate operating system environment that looks like a complete computer;
Containers, on the other hand, do not create separate operating system environments; they run inside the core operating system of the computer.
But unfortunately, it doesn't end there. Microsoft created a new way to run containers in Windows Server, called "containers with Hyper-V isolation". Each "container" is technically a separate virtual machine that transparently to the user configures and runs its own copy of the Windows Server operating system.
And these "Hyper-V isolated" containers are the source of confusion around Microsoft licensing in containers. And let me remind you: there's a difference between Windows Server and SQL Server licensing.
Containers with "Hyper-V isolation" create virtual machines; therefore, they require Windows Server licenses the same way regular virtual machines would. So to calculate Windows Server licences, you need to consider each "container with Hyper-V isolation" to be a virtual machine. There is no effect on Windows Server Datacenter requirements. But if you plan to stack Windows Server Standard licences on a host, count both virtual machines and "Hyper-V" containers.
For SQL Server licensing, each container equals an operating system environment. Therefore, when you count licenses for SQL Server, treat each container as a virtual machine regardless of if it is "Hyper-V isolated" or not.
It affects the following:
The limit on the number of operating system environments when you don't have Software Assurance for SQL Server Enterprise licenses assigned to hosts,
Counting unlimited instances inside an OSE,
And all the other aspects of SQL Server licensing.
I know it's still complicated. Microsoft licensing is not easy, despite what you may have heard from your friends. But I sincerely hope I've removed at least some confusion.
Still in doubt? Talk to a Microsoft licensing expert
We are an independent consulting business that sells no licenses or Cloud services. That is on purpose, so our advice is unbiased.
Please tell us about your licensing challenges using the form below so we can look into them together.