Containerisation: cost-saving and a big leap forward?

by Ned Hallett
Published on March 2020

Containerisation is nothing new, but in recent years, it seems to have penetrated the tech world sufficiently for people to be asking questions like “will containers replace VMs?”, “Are containers the next big thing?” and of course – “what are containers?”

In this blog, we answer all of these questions, as well as the key consideration: “how will containers save you money?”

1. What is containerisation?


If you understand VMs, containerisation is not a difficult concept to grasp, as it’s essentially just another form of virtualisation. 

The same as VMs…

Both VMs and containers are attempts to make better use of server space by isolating parts of the server and simulating a computer within it.

These simulated computers – AKA virtual machines – allow servers to better house multiple applications, as, isolated, there is less conflict between the various applications’ dependencies. This is difficult to analogise, but you might think of a server with no VMs or containers as a country of people trying to talk to each other using a set of different and conflicting dictionaries, with some words meaning one thing to some and another to others.

Containers and VMs divide-up the dictionaries, and make sure everyone who needs to talk to each other is using the same one.

Cut up pages


…but different 

The essential difference between them, and where we get technical again, is that wherein the case of a VM a hypervisor translates messages sent between a host OS  (the physical server’s OS) and the guest OS (The VM’s virtual OS), in the case of a container, the container engine – Docker, Kubernetes, etc – sits directly between the host OS and the application itself.

So what?

  • The advantage of this is that containerised applications can be multiplied without the cost, in both monetary and computational terms, of replicating these virtual OS’, which, it turns out, are substantial. Of course, you are still limited by the host machine’s compute capacity and the capacity required to run the container platform itself, but, compared with VM replication, we have a much, much lighter process.
  • Further, this lack of a heavy guest OS makes containers lighter in other ways, generally speaking. With the right image and a well-built application, and the proper offloading of assets, containers have the potential to reach puny megabyte sizes, start-up in mere seconds, and be much more transportable between environments.

This is all rather intuitive, and partly why containerisation’s first meaning –  the putting of things in literal, metal shipping containers – has come to describe the technology.

What tests the brain slightly however, is that using the host’s OS rather than a virtual one makes containers more environment agnostic rather than less, meaning they can be transferred more easily and to a more diverse range of environments.

They’re light and hardy. Again, like literal containers.


 Broad implications for industry tech and culture trends

A graph showing an upward trend


  • Microservice applications are almost invariably going to be better suited to containerisation than VMs because of the cost of replication issue.
  • Likewise, the ‘lightness’ of containers shows an affinity for many other cultural and technology trends within the industry. The cultures that surround microservices, and DevOps culture more broadly, favour concepts like ‘agile’, ‘frictionless’ and the practices like CD/CI, all of which chime with what containers have to offer.

So with all these advantages, and these kinds of trends showing no sign of reversing, it isn’t surprising to see some questioning the relevance of VMs, and making statements like ‘containers ARE the future.’ 

However, the reality in the present… is a little more complicated. 

2. VMs vs containers 



A tool for every job 

One advantage of a virtualised OS is full access via a GUI and all the additional flexibility that brings. Plus, for the time being at least, most devs are going to be much more familiar with VMs than containers. 

Another advantage, which has a lot to do, again, with having an accessible OS, is that VMs can handle multiple jobs at once where containers can run only the application they contain.

This means that, in some cases, it would require ten containers to do what one VM could do ten times and much more efficiently. If we have ten back-ends, for example, we’d need ten Docker or Kubernetes files with all dependencies installed on each one. In the case of a VM, the dependencies are installed once, on the virtual OS, and spread across ten configs – which are much smaller than containers. 

So, although containers are ‘light’, we can see from the above example that it’s a case of knowing the right tool for the job.

The security issue 

The extra padding between VMs and their hosts serves to insulate them, in a sense. And when you use a container, there’s a greater chance of attackers breaching the host security, and gaining access to your whole system.

However, there is some debate around this topic 

IBM’s James Bottomley recently found, using a quantitative security test of his own devising, SOME containers were more secure than SOME VMs. And many container service teams are, as we speak, in the process of refining container security.

So again, a case of give and take.

3. Using containers to save you money 

The ways in which containers save you money, or can save you money, are simple enough, once you understand what containers are.

  • Because you can fit more of them on a single server, you save on infrastructure costs.
  • Because they’re light and environment agnostic, your team spends less time configuring the environment and is better able to implement cost-saving practices such as CI/CD.
  • On top of that, many container platforms, such as Docker, are open source.

The only other  significant thing to understand about containers, without going into much finer technical detail, is that, much like VMs, containers require…


An orchestration tool 

A music conductor

Here you have a choice between a provider-specific service like Amazon’s ECS – Elastic Container Service – and an open-source tool like Kubernetes, which will work with any type of container. 

Generally and unsurprisingly, provider-specific orchestration tools offer more of a plug-and-play service with their own containers and synergise better with other the services from that provider, whereas open-source tools offer broader scope but require a little extra expertise investment. 

Kubernetes in particular is  far more than a container orchestration tool, with really quite impressive extra features such as ‘auto-healing’, in which Kubernetes sends out ‘health probes’ and then shuts down and replaces faulty containers according to a user-defined protocol, auto-scaling and other such HAL-like acts of mechanical godliness.

For more info on Kubernetes, check out or piece on Kubernetes trends for 2020, including Kube Federation. 

The takeaways 

  • Containers are like VMs, in that both are forms of virtualisation designed to make better use of server space and contain applications.
  • However, containers share their host’s OS, making them lighter to transport and reproduce – which means they have a higher affinity for some industry culture and tech trends.
  • Containers aren’t preferable to VMs in every situation, as in some cases multiple having a virtual OS allows for more flexibility, and it’s what many devs will be used to.
  • Much like VMs, containers require an orchestration tool to be managed properly, i.e at scale.

For more information on containerisation – whether you’re looking for a few extra pointers or full implementation of a project – get in touch here.