I was at event that Simon Sabin arranged, SQL SERVER TOOLS and SSDT shape the future and one of the questions that was asked, sorry, I forgot who asked (joys of leaving it too long before blogging about it – I want to say Gavin) was,

How does (Windows) Containers fit into SQL Server?

This is basically Microsoft integrating the Docker technology into the Windows OS, so you in effect, ship a more complete solution. So for example, traditionally you’d ship the .NET application, with “Docker” you’d ship .NET and the OS along with the application – its not quite right, but that’s the basic idea.

At one of my local user groups, Suffolk Devs, back in Sept 2015, Richard Vickerstaff done a talk on Docker. One of the things I took away was this was very dev friendly, Richard was honest in the fact he has yet to deploy to production in this manner and the general feedback from the room at the time was no one else had – this doesn’t mean no-one has since of course, but you start to get the feeling the DBAs back home wouldn’t be happy. The other thing was the dev nature of it, for example, when your developing, you don’t want to be held back by “rules” that protect data, it is after all, development, your not going to have production data in your dev environment, right? So, if you don’t “pin” your storage to a persistent path, it’ll get purge when you stop your docker image. Can you image if you forgot to set the production config correctly and come a reboot all your data disappears? I can already here my friendly DBA screaming.

To get a docker\container for SQL Server, you’d either have to select one from list of images with SQL Server and its going to be huge, at least until they get SQL Server 2016 on Nano Server. Or you’d have to have PowerShell DSC to install and configure SQL Server.

In terms of Microsoft SQL Server, or really any database, I don’t believe you’d need to have it in a container, docker or otherwise. Since SQL Server 2012 you could have contained databases, this is where the login information that is normally stored in the instance master database within the application database. This pretty much made database independent of each other within the same SQL Server instance. I’d admit this was introduced for Azure, but this leads me onto my next point.

The best thing to manage is the the thing you don’t have to manage. So why would you want to spend time setting up SQL Server (as developer), regardless of if its in a container if you can just click a button or run a script to auto provision a Azure DB? Surely if your developing anything new, which is going to use a SQL Server database, surely you should be aiming for Azure DB? Even if you’re not, there aren’t that many types of SQL Server, you don’t often run into dependency hell with SQL Server, none that justifies building individual containers, at least, in my opinion.