Containers are a fantastic technology when it comes to allowing more portability of applications or services across operating systems and physical or virtual infrastructure. The idea of containers is to provide an abstraction layer between an application/service and the underlying operating system, similar to the abstraction layer provided by hypervisors between an operating system and the underlying hardware. This new abstraction layer is intended to allow an application and all ancillary files to be packaged together in a lightweight and portable container that can easily be moved from one host to another. An application that is placed into a container is therefore more (or even completely) separated from the infrastructure that it is running on top of. There are no requirements to ensure that the infrastructure is regularly patched or even held on a certain patch level. There are no dependencies between the container and the infrastructure that hosts the container.

In the preceding figure, we see the difference in the logical structure of a Virtual Machine on a host machine (on the left) and an application/service hosted inside a container (on the right). The subtle but important difference is that a Virtual Machine requires the operating system, the binaries, and application data to be packaged together into a logical unit. A container separates the operating system and the application/binaries. This makes a container a lighter logical object to control, because the operating system is no longer a requirement for the container. This spares us from needing to patch and update/administer the operating system for each and every container. We can also note that all containers on a host effectively share some resources found in the host and the container service. It is possible to isolate the separate containers even further by running the containers as Hyper-V containers. This is a special type of container that utilizes the Hyper-V features inside Windows to further isolate containers and their resources from one-another.

Containerization is not particularly new in the IT world (it has existed in one form or another since around since 2000). However, SQL Server 2017 is now supported when run inside a container on Windows, Linux, or macOS (yes, the operating system running the container service is pretty much irrelevant). However, this is not to say that the container contents are Windows, Linux, or MacOS; rather the operating system hosting the container service can be one of those three. This is a scenario distinct from the official support for installing and running SQL Server on Linux, which is also supported from SQL Server 2017 onward.

There are a few questions we ask ourselves when we hear that SQL Server can now be hosted inside a container:

• How does SQL Server work inside a container?
• What performance difference can we expect with SQL Server in a container versus on a Virtual Machine or physical host?
• What benefit(s) do we get from using containers with SQL Server?

The next section will provide guidance on all three points so that you can see the benefits and drawbacks of using containers, and identify where they can assist you as a developer. We will begin by taking the first steps to create a SQL Server 2017 instance inside a container and discover how containers work.