►
From YouTube: Lightboard VMs vs. Containers: Advanced Deep Dive
Description
VMware Staff Engineer Fabio Rapposelli goes through a deep dive of the technical differences between Containers and Virtual Machines.
A
The
size
can
range
from
tens
of
megabytes
up
to
gigabytes
and
that's
very
depending
on
the
depth
of
the
type
of
the
application
inside
it,
because
the
container
has
the
application
and
all
the
dependencies
that
that
application
requires
to
run.
If
we
take
an
example
of
goal
and
application,
meaning
an
application
with
an
end
goal.
A
But
if
the
application
is
either
a
traditional
application
of
a
platform
or
an
application
that
has
the
requires
user
space
tools
to
run
what
we
usually
do
is
we
create
a
container
based
on
a
base
container
that
contains
all
the
user
space
from
a
specific
Linux
distribution
and
one
of
the
most
one
known
example.
We
have
applications
that
are
creative,
starting
from
Ubuntu
base
container
and
the
Ubuntu
base
container.
That
only
contains
the
package
manager
and
a
few
other
user
space
tools
waits
at
least
100
120
megabytes.
A
Just
for
the
base
image,
and
that
has
to
include
the
application
and
other
things
as
well.
So
if
we
have
applications
that
lend
themself
very
well
being
containerized
like
golang
applications,
we
might
have
containers
that
are
very
small
in
size,
even
in
the
single
digits
digits
of
megabytes.
If
we
have
traditional
application,
we
may
end
up
with
containers
that
are
as
big
as
virtual
machines.
Disk
images.
A
Now,
let's
talk
about
isolation
or
security
in
a
VM,
the
process
of
isolation
is
very
straightforward,
because
what
we
have
is
we
have
boundaries
that
are
created
outside
the
x86
platform,
meaning
that
every
process
included
in
the
kernel,
the
init
system
and
even
the
bias
or
the
efi
subsystem
a
running
inside
a
sandbox.
The
one
you
see
here
so
escaping
from
this
x86
sandbox
is
extremely
difficult,
because
an
attacker
has
to
attack
the
process
of
the
application
and
then
try
to
escape
not
only
the
kernel
but
also
the
x86
boundary.
A
This
is
can
consider
extremely
difficult,
as
far
as
we
know
doesn't
mean
any
successful
attack
of
this
type
to
virtual
machine.
Yet
containers,
on
the
other
hand,
are
by
no
means
insecure,
but
they
are
I
secure
as
the
kernel
they're
running
on,
meaning
that
if
an
attacker
attacks
a
process
running
inside
a
container
and
the
kernel
has
a
security
bug
here,
the
user
attacking
this
process
can
potentially
escape
the
sandbox
and
reach
the
kernel,
leaving
the
Machine
vulnerable.
A
Now
this
is
considered
very
difficult
because
kernel
bugs
that
this
type
are
very
rare.
It
happened
in
the
past
that
these
kinds,
but
these
kind
of
bugs
were
discovered
by
the
security
community
and
the
popularity
of
containers,
make
the
security
community
well
aware
of
these
type
of,
but
meaning
that
the
security
posture
of
the
kernel
is
criticized
very
closely
by
that
community
and
last
but
not
least,
let's
talk
about
boot
times
in
a
VM.
We
have
several
startup
times
that
add
up
to
this.
A
The
startup
time
of
the
application
itself,
the
startup
times
are,
can
be
divided
in
two
sections.
One
is
the
System
Check
section
that
includes
the
x86
post,
the
EFI
or
boot
check
the
kernel
boot
and
the
init
startup,
and
then
the
process
run
the
initial
part
that
we
can
call
system
check.
That
includes
the
x86
post.
The
buyers
were
GFI
check.
The
kernel
startup
and
the
Enix
startups
usually
takes
around
three
to
four
seconds.
A
A
What
happens
is
we
run
the
process
and
we
have
to
set
up
the
sandbox,
so
the
sandbox
is
a
kernel
operation
that
takes
no
time
while
the
startup
of
the
process,
just
like
in
the
vm,
takes
about
500
milliseconds,
meaning
that
the
startup
time
of
a
container
is
extremely
fast
and
the
stream
is
straightforward,
because
the
only
two
operations
made
are
one
is
a
kernel
operation
which
is
setting
up
the
process
sandbox
and
the
other
one
is
starting
up
the
application
itself.
I
hope
you
found
this.