The Dilemma between VMs and Containers

The Dilemma of VMs or Containers: Which will most often minimize TCO for agile secure scalable migration of workloads ?

While propensity in favor of containers today is obvious some positives of VMs cannot be underestimated. One can argue the other way around too..

Clear Positives: 

• Complete abstraction of the system: Because all of the pieces of your application are running on the same “server” or servers, communication between them is straightforward, no need to complicate  IP flows or networking nodes
• Decomposing the application Not needed at all : Because one is running in an environment similar to a bare metal machine, there’s no need to alter the architecture of the application itself.
• Run multiple applications at the same time: It’s common to run multiple applications on a single VM, simplifying management of the overall infrastructure and the good part all VMS can still be secure and diverse operating systems are still available: Within a hypervisor, one can use virtually any operating system, so you can run multiple operating systems on a single physical server.

Cons

• They can be big: VMs can be large, both in terms of images required to define them, and in terms of resources needed to run them.
• They can be slow to start: Starting a VM is the same as starting a computer; it can take some time. If you’re just starting it once and letting it run for a few weeks or months or years, this may not be an issue. But if you’re dealing with a process that must be constantly spun up, this latency can definitely be a problem.
• They can be slow to run: Obviously application will run a little slower. So, running on VMs are often not as performant as those running on bare metal. While it is possible to run a VM within another VM under some circumstances, it’s not always an option. But when it is an option, the performance penalty can be huge.
• Careful security configuration is a must: The platform that hosts your VMs needs to be carefully investigated, analyzed and configured to prevent potential security problems due to security domains bridging  or components that span multiple security domains, such as public and management, or management and data.

Pros and cons of containers

Just as the death of containers has been overstated, containers aren’t universally great. Let’s look at the pros and cons here, as well.

Pros

• Relatively small size: Containers share the host’s kernel, they only include the absolutely necessary operating system and library components, and they (generally should) limit themselves to a single function, so they tend to be very small.
• Fast: Because they are small, they can start in a matter of seconds, or even less, making them useful for applications that need to be repeatedly spun up and down, such as so-called “serverless” applications.
• CI/CD: Containers are made to start and restart frequently, so it’s easy to pick up changes.
• Portable: Because they’re self-contained, containers can be moved between machines with relative ease, as long as the correct kernel is in place
• Lifecycle and delivery model: The structure of the containerized lifecycle makes it easier to incorporate advanced features such as vulnerability assessments and image registry signing.

Cons

• They can require complicated networking: Because functions are (ideally) broken out into multiple containers, these containers need to communicate with each other to get anything done. But because containers are not a single unit, they have to communicate with each other. Some orchestration systems such as Kubernetes have higher level units such as multi-container pods that make this a little easier, but it’s still more complex than using VMs. It is now getting more obvious that actually, the L3 networking model in Kubernetes is much simpler than the L2 model in OpenStack. So the amount of work you’re going to need to do on networking depends on whether you’re looking at communicating between functions or between VMs.
• Security Angle: Containers may not be as secure as VMs, for a number of different reasons, but efficiency matrix may not show true results.  If in a cloud native application using containers may be still OK but decomposing  your application into its various constituent services, which, while beneficial, isn’t necessary if you are using VMs.
• Sometimes they can be expensive and unreliable: While this  sounds negative, containers are generally designed for cloud native computing, which assumes that any component can die at any time; you will need to ensure that your application is properly architected for this eventuality.

 So what is the bottom line recommendation? Simply moving it to a VM is not a bad idea, where it will experience the least disruption. If you are to create a brand new  application from scratch, starting with containers will pay you richer dividends.