Containers vs VM's

Containers versus VM's. Do they complement or compete against each other? They actually work quite well but each has its own separate use cases.

Episode Transcription
Welcome back to this episode of The Byte. Today we will be talking about containers versus VM's. Many people have the misconception that it's versus containers or VM's's. I mean, we're really looking at either it's a container or a VM. However, I must say that they work quite well together. I mean, most instances that we've come across is VM's compliment containers. How do you orchestrate the hardware? I mean, you still need to orchestrate the hardware somehow, and you also need some sort of abstraction where you can install Docker, and to build a spawn off your containers. In essence, they work well together. I mean, they'll be use cases where VM's will do much better, or it's a better use case, and the container's on the other side, but we really need to understand the difference between containers, and VM's. To understand that, there are two types of containers that we currently see. They're short-lived containers, and there are long-lived containers. 

Now, short-lived containers typically are in production anywhere from one, and a half to three days. That means they're really microservices, they're on a pipeline, and they're changing very frequently. Now, this particular use case is where containers get the most value. They bring the most value to your product, your application, your developers because you're able to quickly make changes to these applications, and bring value very quickly. On the other hand, you have long-lived containers. Long-lived containers they're on the other side of the spectrum. I mean, typically they're around nine months in production, so they're databases or their applications that don't do a lot of changes.

When I look at this picture of short-lived, and long-lived, you have nine months versus a couple of days, the long-lived side is where I draw a line, and say okay, maybe on the very edge of long-lived is where I would say it's a VM use case, or it's a use case where, it's a database that doesn't change very often and doesn't bring a ton of value putting in a container, or it's a huge mission to containerize this specific application, and it doesn't change often. Maybe it's just better to keep it as a VM, or there are other use cases where I've seen where the database, or the actual VM, or the container as large as the VM underneath it.

Now, that's not exactly ideal, because you can't move this around. It's hard to like, have high availability, and disaster recovery when your container is the same size as a VM. You basically have a VM container, and I mean, they both have their great use cases. I mean, containers do a great job, but when you orchestrate your hardware with some sort of virtualization, KVM, VMWare, whatever, and then, you add containers on top of it, it's really the best use case. Now, VM's are typically an operating system, Windows, or Linux, and if we're talking about Windows, I mean, the operating system is around 80 to 100 gigabytes right off the bat, then add a couple of cores, few gigabytes of RAM.

And, typically, a VM is for one application, or maybe an application stack, but it's very dedicated to this. It's hard to say, can I consolidate the resources? Or, if the application is just running like 20% CPU, you're not really taking advantage of the resources underneath it, so that's where the container side comes in. If we can actually optimize the infrastructure, and really be able to pack this VM full of containers, and optimize resources underneath, we can actually get maybe 80 to 90% utilization that we're aiming for.
As I said, we can have a VM running, we can put containers on top. That's the ideal situation. I've actually seen it also where you have bare metal containers, where you're running directly on bare metal, which is also a great use case, but I mean, there are tons of use cases, but what we're seeing mostly is containers running on top of a VM, and their orchestrated It's the same if you go to cloud, when you go cloud as well. I mean, underneath your cloud instances, some sort of hypervisor, so you're already in a virtualization environment. Your container's running there.

Now, if you're using like a managed service, obviously, they're taking care of all the virtualization, and the hardware orchestration, but that's really what we're talking about today is containers versus VM's. I mean, we shouldn't say versus, we should say complementing each other. Vm's compliment containers and vice versa. Let's look at it this way. I mean, they work well together. We can actually treat VM's as containers now, which I'll talk about in a future episode where there are a couple of companies like Weaveworks and Amazon that are treating VM's like containers, which is an interesting concept, because then you can orchestrate it kind of the same way, and have some sort of orchestrator that makes it work, and treats it as a totally different application cycle.

That's all for today's episode, containers versus VM's Let me know your thoughts on Twitter, and we'll hear you, and see you in the next episode. Have a great day.

© 2020 TheByte