Criteria to Make the Choice of Containers vs. Virtual Machines in Infrastructure Cost Decisions

What are software containers? They can be thought of as lightweight Virtual Machines with much leaner system requirements. They have been around for a while now, architected into Linux in 2007, and they have been used in recent projects at IP Infusion, especially the VOLT-HA and ONOS-related projects, and the trend is increasing. Containers have a tiny footprint compared to Virtual Machines and they are quite portable, and they are making their way into many software runtime environments, not only for cloud giants, like Google, but for traditional enterprises.

Containers or VMs? Which should you use? VMs are already very reliable and they are deployed everywhere. Is there value in moving your existing environment to use containers instead?

In general, you can put two to three times as many as applications on a single server with containers than you can with a VM— a dramatic reduction in infrastructure cost. VMs take up a lot of system resources. Each VM runs not just a full copy of an operating system, but a virtual copy of all the hardware that the operating system needs to run. This quickly adds up to a lot of RAM and a lot of CPU cycles. All that a container requires is enough of an operating system, supporting programs and libraries, and system resources to run a specific program. This has been excellent news for the telecommunication industry which uses containers to create a portable, consistent operating environment for development, testing, and deployment.

Despite all these obviously clear advantages, containers also introduce a set of unique new risks because containers were not inherently architected with security in mind. Here’s a list of unique cybersecurity issues that come into play when containers are used:

  • On the host, control groups and namespaces are the key container isolation components. These control groups and namespaces must be appropriately and consistently configured, and configurations must comply with security policies.
  • User access control must be very tight. Different privileges are defined for different users for each container. Root access must be very restricted.
  • In the container itself, reducing the attack surface for the container is very important. Keep to a minimum the number of libraries and dependencies and only export the needed ports. Any code with vulnerabilities should be prevented from entering the environment.
  • Developers can easily create their own images, or they can download public images from the Docker Hub and other centralized open source registries. These container images need to be vetted and validated for vulnerabilities. The organization will need to have a container vulnerability assessment program in place. A continuous vulnerability assessment and remediation program needs to be an integral part of an organization’s IT risk and governance program.

A set of practices have been put in place to manually improve security further. For example:

  • Mounting a /sys file system as read-only
  • Force container processes to write only to container-specific file systems
  • Set up the networknamespace so it only connects with a specified private intranet

The decision to use containers or VMs should be considered carefully. As described, it takes an explicit effort and focus to secure containers, as opposed to VMs where the full OS is running. The more functionality integrated into a container, the more likely it is you should be using a Virtual Machine. The whole point of a container is to run a single application. If you want run multiple copies of a single application, for example MySQL, a container is appropriate. If you want the flexibility of running multiple applications, you use a Virtual Machine.

IP Infusion excels in using and securing containers for product deployments which require many services to be orchestrated simultaneously. We also use containers extensively in our testing environment where a very flexible approach to change in between versions to run is needed. This saves a large amount of time since the platform can be reused for any project that uses containers. If you need help in this area, we have the container expertise.