Containerization Advantages Over VMs
Key Points
- Container technology dates back to Linux’s 2008 introduction of cgroups, which laid the groundwork for Docker, Kubernetes, Cloud Foundry, Rocket, and other runtimes.
- Unlike virtual machines that require a full guest OS and its libraries for each instance—often inflating a tiny Node.js app to 400 MB—containers bundle only the app and its direct dependencies, keeping the image under 15 MB.
- Scaling with VMs duplicates the entire guest OS each time, consuming excessive hardware resources, whereas containers share the host kernel and can be replicated with minimal overhead.
- Deploying directly to VMs can expose “works on my machine” incompatibilities (e.g., macOS development vs. Linux production), a problem containers mitigate by providing a consistent runtime environment across environments.
Full Transcript
# Containerization Advantages Over VMs **Source:** [https://www.youtube.com/watch?v=0qotVMX-J5s](https://www.youtube.com/watch?v=0qotVMX-J5s) **Duration:** 00:08:10 ## Summary - Container technology dates back to Linux’s 2008 introduction of cgroups, which laid the groundwork for Docker, Kubernetes, Cloud Foundry, Rocket, and other runtimes. - Unlike virtual machines that require a full guest OS and its libraries for each instance—often inflating a tiny Node.js app to 400 MB—containers bundle only the app and its direct dependencies, keeping the image under 15 MB. - Scaling with VMs duplicates the entire guest OS each time, consuming excessive hardware resources, whereas containers share the host kernel and can be replicated with minimal overhead. - Deploying directly to VMs can expose “works on my machine” incompatibilities (e.g., macOS development vs. Linux production), a problem containers mitigate by providing a consistent runtime environment across environments. ## Sections - [00:00:00](https://www.youtube.com/watch?v=0qotVMX-J5s&t=0s) **From VMs to Containers: Evolution** - The speaker outlines the history of container technology, explains how cgroups enabled modern containers, and contrasts deploying a Node.js app via traditional virtual machines versus lightweight containers. ## Full Transcript
hi everyone my name is Sai Benin and I'm
a developer advocate with IBM today I
want to talk about containerization
whenever I mentioned containers most
people tend to default to something like
docker or even kubernetes these days but
container technology has actually been
around for quite some time it's actually
back in 2008 that the Linux kernel
introduced C groups or control groups
that basically paved the way for all the
different container technologies we see
today so that includes docker but also
things like cloud foundry as well as
rocket and other container runtimes out
there let's get started with an example
and we'll say that I wasn't developer
and I've created a node.js application
and I want to push it into production
well take two different form factors to
kind of explain the advantages of
containerization so let's say that first
we'll talk about VMs and then we'll talk
about containers so first things first
let's introduce some of the things that
we've got here so we've got the hardware
itself just big box we've got the guest
or rather the host operating system as
well as the hypervisor hypervisor is
actually what allows us to spin up VMs
already we've let's take a look at this
shared pool of resources with the host
OS and hypervisor we can assume that
some of these resources have already
been consumed next let's go ahead and
take this JSON and push it in and to do
that I need a Linux VM so let's go ahead
and sketch out that Linux VM and in this
VM there's a few things to note here so
we've got another operating system in
addition to the host OS is going to be
the guest OS as well as some binaries
and libraries so that's one of the
things about Linux VMs that even though
we're working with a really lightweight
application to create that Linux VM we
have to put that guest OS in there in a
set of binaries and libraries and so
that really bloats it out in fact you
know I think the smallest node GS VM
that I've seen out there is 400 plus
megabytes whereas the the the node.js
runtime and app itself would be you know
under 15 so
we've got that with and we go ahead and
let's push that Jay s application into
it and just by doing that alone we're
going to consume a set of resources next
let's think about scaling this out right
so we'll create two additional copies of
it and you'll notice that even though
it's the exact same application we have
to use and deploy that's that's separate
guest OS and libraries every time and so
we'll do that three times and by doing
that essentially we can assume that for
this particular hardware we've consumed
all of the all of the resources and
there's another thing that I haven't
mentioned here but this jeaious
application I developed it on my macbook
so when I pushed it into production to
get it going on the VM and noticed that
there were some issues and
incompatibilities this is the the kind
of foundation of this big he-said
she-said issue where things might be
working on your local machine and work
great but when you try to push it into
production things start to break and
this really gets in the way of doing
agile devops and continuous integration
and delivery that's solved when you use
something like containers there's a
three-step process when kind of doing
anything container related and pushing
or creating containers and it almost
always starts with first some sort of a
manifest so something that describes the
container itself so in the darker world
this would be something like a docker
file and Cloud Foundry this would be a
manifest yamo next what you'll do is
create the actual image itself so for
the image you know in again if you're
working with something like docker that
could be something know be a docker
image for working with rocket it would
be an ACI or application container image
you know so regardless of the different
containerization technologies this
process stays the same
and the last thing you end up with it's
an actual container itself you know that
contains all of the runtimes and
libraries and binaries needed to run an
application that application runs on a
very similar set up to the VMS but what
we've got on this side is you know again
a host operating system the difference
here instead of a hypervisor we're going
to have
things like a runtime engine so if
you're using docker this would be the
docker engine and you know different
different containerization technologies
would have a different engine
regardless it's something that runs
those containers again we've got this
shared pool of resources so we can
assume that that alone consumes some set
of resources next let's think about
actually container izing this technology
so we talked about the three-step
process we create some you know a docker
file we build out the image we push it
to a registry and we have our container
and we can start pushing this out as
containers the great thing is these are
going to be much more lightweight so
deploying out multiple containers since
you don't have to worry about a guest OS
this time really just have the libraries
as well as the the application itself so
we've scaled that out three times and
because we don't have to duplicate all
of those operating system dependencies
and create bloated VMs we actually will
use less resources so she's a different
color here and scaling that out three
times we still have a good amount of
resources left next let's say that my
coworker decides hey for this j/s
application let's take advantage of a
third party you know let's say a
cognitive API to do something like image
recognition so you know let's say that
we've got our third party service and we
want to access that using maybe a Python
application so he's created that service
that accesses that third party API and
with our node.js application we want to
access that Python app to then access
that that service if we wanted to do
this in VMs I'm really tempted to
basically create a VM out of both the
JSO plication and the Python application
because essentially that would allow me
to continue to use the VMs that I have
but that's not truly cloud native right
because if I wanted to scale out the the
j/s but not the Python app I wouldn't be
able to if they were running in the same
VM so to do it
Trulli cloud native way essentially I
would have to free up some of these
resources basically get rid of one of
these VMs and then deployed the Python
application in it instead and you know
that's not ideal but with the container
based approach what we can do is simply
say since we're modulars we can say okay
just deploy one copy of the Python
application so we'll go ahead and do
that there's a different color here and
that consumes a little bit more
resources and then you know with those
those remaining resources the great
thing about container technology that
actually becomes shared between all the
processes running in fact another
advantage if something if these
container processes aren't actually
utilizing the CPU or memory all of those
shared resources become accessible for
the other containers running within that
within that hardware
so with container based technology we
can truly take advantage of cloud native
based architectures so we talked about
things like portability of the
containers we talked about how it's
easier to scale them out and then
overall with this kind of three-step
process and the way we push containers
allows for more agile devops and
continuous integration and delivery
thanks for tuning in for this broad
overview of container based technology
as always we're looking for feedback so
definitely drop a comment below and be
sure to subscribe to stay tuned for more
videos in the future thank you