profile for Gajendra D Ambi on Stack Exchange, a network of free, community-driven Q&A sites

Monday, July 23, 2018

Why containers and why not VMs?! or Vice Versa

I hope the above gives you a visual representation of what the container stuff is all about. Let me also collage some major differences.

A VM is limited to the hardware that it is running on. The maximum memory, cpu or network resource a VM can have is limited by the hardware that it is running on. Many a times there is also a limitation of the virtualization layer tech that you might be using. If it is VMware, my favorite one then you have a cap on what is the maximum cpu and memory that you can assign. It is a scale up architecture. It is a like a huge tall building with many floors. Ultimately there is a limitation (call it gravity, sustainibility or whatever) and you can't build a skyscraper tall enough to touch the moon.

Containers are scale out. you can always have a building which can be as wide as the earth allows it to be. Instead of getting big like a VM it multiplies or clones itself as and when needed and the clones disappear automagically when the load is low.

Containers are fairly new and thus they aren't as secure as a VM architecture is. It is not the fault of containers but the security itself and how the tools are developed and who is their main target audience. Most of the current IT security tools, software are all designed for a traditional datacenter and not the micro architecture. This can be countered if you develop your applications to be cloud ready or cloud native.

A tradition VM architecture is easier and faster to deploy and get started than a container based implementation unless you are starting off new and you start your development with container based architecture as your platform. The skillgap, industry readiness are also adding to this factor.

Max availability a VM based architecture provides a node failure. A node1 goes down with VM1 but node2 has a copy of that VM and that takes over without a downtime. What if the 3 nodes go down? or 5 nodes? Containers offer a never go down architecture  since it is a scale out architecture. You can have your copies of the container run on different nodes and you can just mention how many nodes you want to span them across and that is it. An orchestrator engine like kubernetes or docker swarm will take care of the rest.

Let us say you have the need of AI/ML frameworks for your project. You can spin up a kubernetes cluster on AKS (azure kubernetes service) to access azure ML/DL frameworks or do it on google to access their AI/ML/DL frameworks and they can easily span over to your on premise datacenter. You can migrate your workload/container between different cloud providers including your on/off premise datacenters. You start off with azure. Tomorrow you might want to go to google or aws or move back to your on premise hardware. That is all possible with containers and this is a big win.

Did I miss anything? Do let me know.