Going forward, there is little question that containers have become firmly established as the technology of choice for application deployment – at least until such a time as alternative approaches like serverless computing outgrow them in popularity. This is as true today in the enterprise as it was ten years ago when hyperscalers like Google first created usable and scalable containers
But enterprises have other concerns besides scaling out, such as the need for containers to integrate with their existing applications and infrastructure. For a great many enterprises, this means wrapping containers around their Windows Server systems software and applications, at least for on-premise deployments. However, Docker containers – which sparked the current enterprise craze for using containers to help developers move to a more rapid release cadence – were designed around Linux. Seeing which way the wind was blowing, Microsoft partnered with Docker back in 2014 to port the Docker Engine to run on Windows Server, which also involved adding some underlying mechanisms to support containers into the operating system.
We have covered Microsoft’s container support in more detail before, but the crux of it is that Windows containers must be built from a limited number of base images supplied by Microsoft that incorporate some or all of the Windows services layer that applications call upon to function. The upshot of this is that Windows containers are much larger than those running on Linux, often several gigabytes in size.
This isn’t the only limitation on Windows containers. A container will only run if it is deployed on a server running the same version of Windows as the base image from which it was created, meaning that enterprises have to rebuild their containers every time there is an updated release of Windows Server. Windows containers are also only supported on Windows Server 2016 and later, which means that the many enterprise firms which have yet to migrate from earlier releases of Windows Server cannot take advantage of containers. And the rub is putting old releases in new containers is precisely what many of them would like to do so they can support legacy applications.
Microsoft is not, however, the only game in town as far as containers on Windows are concerned, and other platforms exist. One, Windocks, grew out of a port of Docker’s own open source project aimed at Windows, and uses a different set of constructs to create and operate containers that enables it to operate on both Windows Server 2012 and Windows Server 2016.
First releases in 2016, Windocks has since developed a focus on supporting enterprise customers that want to run SQL Server inside containers, including versions from SQL Server 2008 onwards. As part of this slant, the platform now not only includes the usual tools that developers can use to create new containers, but also automates the process of adding database copies to the container or mounting of a remote database, which can be a clone of the production database that the developer can work with during testing before their code is promoted to production status.
According to Windocks, it has taken this approach because customers need a solution that fully supports SQL Server databases in addition to letting them modernise their software stack with containers, and their ability to offer this has seen the firm pick up a number of financial services customers such as John Hancock, Liberty Mutual, and Franklin Templeton Investments.
“The customers that we’re working with want to modernise their full stack software delivery, they want a solution that supports containers, because containers are the future, they want a solution that includes data delivery, but they also want a solution that works with their existing systems and infrastructure and isn’t limited to containers, so if you’ve got developers working on a shared SQL server instance, they want that to be supportable,” Windocks vice president Paul Stanton tells The Next Platform.
And one of the key differences between the Windocks container technology and Microsoft’s official container support for Windows turns out to be quite surprising: compatibility with existing applications and processes.
“It is not widely discussed, but SQL Server containers on the Microsoft Windows design do not even support Windows Authentication, which out of the gate rules it out for the vast majority of enterprise users. And in the SQL server world, volume shadow services in SQL are the basis for most backup applications – those do not operate with Microsoft’s SQL Containers,” Stanton claims.
This apparently comes down to the way that Microsoft implemented containers on Windows Server, copying the Linux model where the containers are largely isolated from the host operating system, which is why applications need to have the code libraries they depend on inside the container with them. In contrast, Windocks implemented a container mechanism whereby the container comprises just the application, running as a Windows service but created and managed with the Docker commands and API. (There is a bit more to it than that, such as resource management controls, but Windocks is coy about giving out full details).
The upshot of this is that SQL Server inside a Windocks container functions exactly like a normal SQL Server instance, because that is essentially what it is, but can be deployed and managed by Docker as a secure “SQL Server sandbox”, according to the firm.
There are further implications of this: while Microsoft’s containers require each container to be licensed as a virtual machine (with a minimum 4 core license for each container), Windocks containers are not treated as a container under Microsoft licensing, as they do not include any portions of the operating system code. As Windocks containers are clones of an installed/licensed SQL Server instance, the containers are considered additional named instances, and all SQL Server licenses allow for unlimited named instances on a licensed host.
Meanwhile, the database cloning support that Windocks added in 2017 provides users with the ability to clone a volume using either Windows Virtual Hard Drives (VHDs) or by tapping into the snapshot capabilities built into enterprise SAN arrays, and afterwards attach it to a SQL Server image when a container is provisioned at runtime.
In the case of VHDs, the parent VHD is a full duplicate copy of the data volume, with “differencing disks” that store any changes, providing one or more writable cloned databases. Scripts are run during the parent VHD build, according to Windocks, creating an “immutable artifact that incorporates user permissions, data masking, and other preparations for regulatory and policy compliance”.
Where a storage array is involved, Windocks automates and manages the creation of a snapshot of a volume, which is then mounted to the Windows Server, and the databases in that volume exposed to the user so they can choose which of them they need to work with. All of this is accomplished through standard Dockerfile commands and supports a broad range of enterprise SAN arrays – Windocks claims it has yet to find one that it cannot support.
“We’ve got customers that run Pure Storage, other customers running NetApp, others with EMC or Cohesity, and we’ve got customers that are using this process to deliver 25 TB data warehouses to their developers. So, on-demand, we’ve got a system at one client that delivers up to 50 independent containers, and each can be running a 25 TB data warehouse, and so it’s literally over a petabyte of data online. They’re using a Pure Storage array with Windocks managing the data lifecycle of this dynamic data for development and test,” Stanton says.
The most recent update to the Windocks platform was the addition of support for SQL Server Reporting Services (SSRS), Microsoft’s report generating system that is used by many organisations to generate web-based and printed document-style reports from data held in SQL Server databases, as well as other sources. This comes in the form of a new Windocks SQL Server image that includes the database engine and SSRS running inside a container.
According to Windocks, its customers are using this capability to add SSRS support to SQL Azure, which lacks this capability, and Microsoft instead touts Power BI as its cloud-based reporting platform. Enterprises would understandably prefer to be able to continue to use the reports that they have already amassed, both on premises and in the cloud.
Overall, Windocks does not appear to be trying to displace Microsoft’s Windows container technology, which after all has the major advantage in that it is baked into the operating system from Windows Server 2016 onwards. Instead, Windocks has focused on a number of key areas where Microsoft’s container support falls short of enterprise requirements, such as when modernising applications that use SQL Server, while .NET and Java, and other images are also available.
Windocks licenses start with a free Community Edition that is limited to two simultaneous containers. Paid-for licenses start at $499 per month for a server that supports 20 simultaneous containers.