Click Here to Download a PDF of the Chart

For example, in a virtualization scenario, you might have a server running VMWare ESXi hypervisor software, upon which are four Unbuntu Linux virtual machines for Service X, two Red Hat Linux VMs for Service Y, and a couple of Windows 10 Server VMs to handle any Windows applications you have.

Using virtualization this way still provides big benefits over maintaining multiple physical machines. Administration is easier. Spinning up a new server or changing configurations of the individual VMs is much easier than tinkering with hardware. Communication between the VMs is very fast and efficient. The downside, as compared to containerization, is the relatively large overhead associated with virtualization. This is because each VM is running a complete OS kernel, each with their own dedicated memory and each using up a percentage of your CPU to mostly do a lot of the same things.

Containerization, by comparison, also allows the running of a number of different isolated services on one machine, but within containers rather than full virtual machines. Conceptually, a container can be thought of as a very lightweight, resource efficient VM. One container could host WheatNet-IP audio drivers and audio playback software, while another could host the station automation system, each totally isolated yet run off the same OS kernel. Because each container operates independently of the others, you can avoid unintended interactions between software components and eliminate a single point of failure. Each application or container communicates with the others only through their defined APIs. The container virtualization layer is extremely flexible and can scale up to meet rising demand for any of the services. Once you define what services are running in one or more containers, it’s possible to move those containerized services between on-premise machines and the public cloud. This allows you to more easily scale services locally at your regional studio or in a cloud provider such as AWS or Azure.

And unlike with virtualization, there is no extra supervisory overhead to contend for resources, and containerization platforms are even able to run on top of virtualization platforms. This last point is critical for long term planning, since Amazon, Microsoft and other public cloud providers are already running hypervisor software on their cloud instances. Attempting to add your own VM hypervisor on top of a cloud provider's machine instance may work poorly, or not at all. Containers, by contrast, work well on just about all the cloud providers and instance types. Most providers even offer tools to make it easy to manage and coordinate your containers running in their cloud.

Fundamentally, containerization and virtualization are two different ways of doing the same thing. Having several containers running separate services pushed up to a cloud won’t solve issues such as communication latency over the internet, but it will offer some added security protection, flexibility, and let you allocate resource more efficiently, which is the point of the cloud after all.

Scott Gerenser is a Senior Software Engineer at Wheatstone Corporation. View Gerenser’s presentation Studio Elasticity, from Hardware to Virtual to Cloud, right below this article.