Containers, Containers, Containers. It’s one of those things that apparently has been around “forever” but I just recently started to hear about it. As a Windows SQL DBA, things like Containers seems absolutely foreign to me.
Back in the day, the only option to install SQL Server was on a physical server. You bought the hardware, installed Windows Server on it, then SQL Server. After some time, we were introduced to the wonderful world of virtualization. This was a game changer because now you could buy a single huge server, and divvy up the resources on it to create individual Virtual Machines, each running its own operating system.
But “now” there are something called Containers. The biggest and most popular of the Container engine companies out there is Docker. According to a Stack Overflow 2019 Developer Survey, Docker ranked #1 in most wanted platform and #2 in most loved:
#Docker ranked first in the most wanted platform, second most loved platform, and third most broadly used platform in the @StackOverflow 2019 #Developer Survey by nearly 90,000 developers. Learn more: https://t.co/sLyZtZ1Rb8 pic.twitter.com/YkqxyicPnU— Docker (@Docker) April 12, 2019
So similar to the company VMWare having a product like VMWare Workstation, Docker (the company) has the Docker Container Engine.
What Are Docker Container?
According to Docker, “A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, run time, system tools, system libraries and settings.”
It sounds pretty cool to be able to wrap up all your code into one (or multiple containers) container image and be able to run that same container image on another machine. We’ve all dealt with something that worked fine on your laptop or development environment then absolutely bombs in production. The containerization of code seems to solve that issue.
An interesting point to note is how the architecture is built for containers. The below image is from Docker’s website.
So as you see in the base green “Infrastructure” layer, that is the physical (or virtual) server. The next layer up is the light blue “Host Operating System” layer. That can be Linux, or Windows Server 2016+. The next layer, is the blue “Docker” layer. This is the Docker Engine that is installed on top of the Host OS layer.
The one big key difference between container technology and VMWare (for example) is that all the container images (i.e. App A, App B, etc.) can be created on a single install of the Docker Engine on the Host OS. So if you have a server running Linux, you install one instance of the Docker Engine and you’re ready to create container images that all use that single Linux OS kernel.
In the VMWare example, you would have to install guest OS on each (App A, App B, etc.). So that single Host will end up running X number of operating systems and eating away at memory and CPU.
Here is a side-by-side image.
Another benefit to container images is the size. Containers take up less space than VMs. Container images are typically in the tens of megabytes in size. Of course that depends on the image, but overall container images are *way* smaller than VM sizes (in the gigabytes).
As a SQL DBA, you might be wondering, “cool, but what does all this have to do with my job? I’m not a developer.”
I will end with this…
The days of installing SQL Server on a Windows Server VM are numbered. There’s a reason why Microsoft has created SQL Server (2017 and 2019) container images.