Understanding Containers and Virtual Machines

One of the key challenges in software development is getting code to run in exactly the same way in multiple places. Often times developers will have code that runs as they expect on their local machine, but then it fails when they ship it to a remote server somewhere.

This idea of running the same code on different servers in exactly the same way was traditionally managed with virtual machines (VMs), because they can be spun up and provisioned in exactly the same way time and again, regardless of where they are running. And while VMs still have their place in software development, containers have become increasingly popular as a solution to this same problem of getting code to run in the same way on any machine, whether it’s a local development environment, or a remote production environment that is serving actual users of an application.

How are VMs different than containers?

VMs, while not physical machines, are complete, virtualized computers that are running a full operating system. That is, they include software representations of both the hardware and software you need to run a computer. Because of this, they are considered stand-alone compute resources – they are completely self-contained. They do need a physical host on which to run, but they don’t rely on any parts of the host in order to operate. They are effectively full computers in and of themselves.

Containers, on the other hand, are just the topmost layer of a computer – called the application layer. They not only need a physical host on which to run, but they also interact with that host, and utilize certain parts of the underlying host in order to run. The primary advantage to this approach is that containers are “light-weight” when compared to VMs, because they don’t have as many pieces included. Instead of shipping with everything a computer needs to run, they package up only the operating system, which makes the images, or blueprints if you will, that define them much smaller, and thus easier to move around between physical machines.

Why choose one over the other?

Container technology is generally preferred to virtual machines except in the rare case that a process cannot run in a container. This could happen for a number of reasons, but they all center around the fact that containers only provide the application layer to a given operating system – such as your favorite Linux distribution. This means that the container relies on the host machine for “filling in the gaps” in what ships with the container. Virtual machines, on the other hand, provide a complete operating system that is fully distinct from the host machine.

So, if your application needs access to these low level processes that are not directly available in a container, the container will need to be run in a privileged mode, which can open a different can of worms related to security best practices. In the same vein, there are cases in which an application needs to be run in isolation from other processes for security reasons.

The solution to these problems is generally to provide a completely virtualized operating system, via a VM, that can do everything it is asked to do without any elevated privileges as far as the way that it is interacting with the physical host machine that it is running on.

Solutions for Cloud Deployments

Most often, cloud deployments of software are achieved with containers, as they are lightweight and ultimately consume fewer compute resources when compared to a full VM. This means that it generally costs less to run them in the cloud, and they generally scale to accommodate a larger volume of requests more fluidly than VMs.

However, it is possible, and in some cases necessary to deploy software to the cloud in full VMs. Software that requires macOS to run is a case in point, as macOS cannot be run in a container, which means that software that runs on macOS, in turn, cannot be run directly in a container either. MacStadium’s flagship product, Orka, is an excellent candidate for such deployments.

Orka supports both Intel-based and Apple Silicon-based macOS VMs in Kubernetes clusters. VM configuration and deployment can be controlled via the Orka CLI or the Orka API, and it is a very powerful platform for executing continuous integration for iOS and macOS applications in the cloud.

Takeaways

Containers and VMs serve similar purposes, but they are fundamentally different implementations. VMs are virtualized, complete computers that are self-contained, so they don’t interact with the physical host they are running on. This can be very useful when you need to isolate a given process for security reasons, and it is necessary to virtualize certain operating systems, such as macOS.

Containers, on the other hand, consist of only the topmost portion of an operating system – called the application layer. This makes the images that define them much smaller and easier to work with in many cases; however, in order to run, containers must interact with the underlying, physical host machine they are running on in order to operate.