Looking forward to Containers

Virtualization has long been a staple when it comes to computing. In essence, virtualization is really just the use of abstraction to make things either easier to manage or more fault-tolerant. Disks, for example, have long been virtualized in the sense that a single, physical, can easily be divided up into multiple logical (or virtual) volumes (or drives) just as easily as a number of discreet physical disks can also be virtualized into a single drive (via RAID) – which can further be partitioned into volumes, LUNs, and so.

Virtualization and SQL Server also have a long history. Clustering, for example, is virtualization that allows 2 or more discreet hosts to ‘behave’ (in conjunction with a domain controller) as if they were a single, virtual, server – or instance that is greater than the sum of its parts. Likewise, a single ‘server’ (or a clustered ‘virtual server’) can even end up hosting more than a single instance of SQL Server – whereby virtualization is used to make it possible for entire instances of SQL Server to run in isolation from each other – on the same hardware.

Of course, when the term virtualization is used today, it’s most commonly associated with full-blown OS (or system-level) virtualization – where entire operating systems are virtualized such that they’re allowed to run in isolation from each other on the same hardware as a means of helping avoid some of the conflicts, collisions, and ugliness that – for so long – went hand in hand with running multiple complex applications side by side on the same hardware.

Containers – A Different Approach to System-Level Virtualization

Of course, while system-level virtualization has been a tremendous win in terms of letting organizations consolidate hardware usage, optimize management, and decrease operational costs, the reality is that isolating applications into their own, discrete, copies of an entire ecosystem (i.e., an operating system) comes with some overhead. (Windows, for example, takes up around 11 – 14GB of ‘install space’ right out of the gate – and then gradually ‘bloats’ over time with various updates and service packs – all of which starts to take a toll when you’re isolating unruly (and even tame) apps into their own environment via full-blown system-level virtualization.)

Enter Containers, which – in overly-simplified terms – provide most of the same benefits as system-level virtualization (meaning that applications can be fully isolated from each other) without all of the bloat and overhead that comes from creating entire, ‘stand-alone’ machines or virtualized operating systems. Or, in other words (and, again, overly-simplified terms), while OS-level virtualization works by GIVING each application a full-blown, isolated, operating system which thinks it’s the only thing running on the underlying hardware, containers bump the ‘lies up a notch’ and let applications believe that they’re the only thing running on a given operating system – making for a much leaner (and more portable) solution that yields similar (and additional) benefits.

No wonder, then, that Containers are “all the rage” in tech circles these days. And I’ve only barely done them any justice. As such, if you’re still looking for some additional info and background on what Containers are, how they work, and why they’re going to be one of the “next big things”, then I can’t recommend Mark Russinovich’s recent post on what containers will mean from a Microsoft perspective enough.

Containers, Windows, and SQL Server

Of course, if you read that article (and you really should) – or if you already know a decent amount about Containers and/or use them already, you know that they’re effectively a ‘Linux Only’ solution – for now.  What’s great, though, is that they’re a big enough deal that they’re making their way to Windows. And, as Mark’s overview points out, they’ll be coming in two ‘flavors’ to Windows Server 2016 – and, personally, I think the direction that Microsoft has chosen for implementing Container support on Windows makes perfect sense.

The take-away, though, is that sooner (rather than later) we’re going to start seeing Containers make a splash in the Windows ecosystem. I’m confident that we’ll eventually see SQL Server instances somehow wrapped up as ‘deployable’ containers – complete with server-level config details like logins, trace-flags, and other settings, along with entire databases as well. My guess, though, is that when it comes to PRODUCTION environments, the use of Containers as a means of deploying and managing SQL Server itself will be more of an exception than the norm. Applications and ‘servers’ or software that needs to access production SQL Servers may eventually become much more “Container-ized” and pluggable as a means of improving scalability and management, but I’m guessing that full-blown Container-ized SQL Server instances for production servers won’t be that common.

On the other hand, I do see dev, testing, and staging environments eventually becoming replete with a heavy degree of Container integration – as the ability to shunt dev/testing workloads from one host to another (when and where needed – either to keep pace with various dev efforts, or to address issues with load balancing, or as a means of spinning up additional test cases) seems like a perfect fit.

Best of all, it now looks like Windows Server 2016 – with support for Containers – has made it to Technical Preview 3 – which you can download and start playing with today.