►
From YouTube: The Benefits of Containers
Description
In this lightboard talk, Ben Corrie walks through the benefits of containers.
For more information, please visit the VMware’s Cloud-Native Apps website:
https://cloud.vmware.com/cloud-native-apps
A
A
Now
this
whole
area
of
automation
is
you
know
one
that
I
think
a
lot
of
people
are
really
starting
to
understand.
In
terms
of
the
benefits
of
containers
we
talked
previously
about
docker
file
and
how
useful
docker
file
is,
you
know,
being
able
to
express
an
environment,
and
the
text
file
is
pretty
useful,
but
it
goes
way
beyond
the
docker
file.
You
know
the
whole
move
towards
continuous
integration,
continuous
integration
pipelines
plugins
with
different
kinds
of
of
CI
systems.
A
Plugins
with
you
know,
development,
environment
containers
are
really
greasing
the
wheels
of
the
development
pipeline,
and
a
lot
of
that
you
know,
could
be
grouped
under
this
whole
question
of
automation,
images
we
talked
about.
Remember
we
mentioned
in
the
previous
presentation
that
an
image
is
the
binary
state
of
a
potential
container,
so
images
all
of
the
binary
dependencies
that
our
container
needs
when
it's
actually
instantiated
inside
of
an
operating
system
at
runtime.
So
when
we
think
about
the
benefits
of
containers,
because
the
word
container,
it
means
a
bunch
of
different
things.
A
A
Okay,
how
do
containers
help
us
to
be
more
operationally?
Efficient
I've
already
talked
a
little
bit
about
how
automation
is
really
helping
to
grease
the
wheels
in
terms
of
the
development
lifecycle,
but
we're
going
to
look
at
operational
efficiency
first,
but
I.
Think
runtime
really
is
its
own
area
right.
This
area
is
well,
you
know
what
are
all
the
benefits
I
get
from
the
container
workflow
from
working
with
containers
from
the
container.
A
You
know
from
all
of
the
things
that
I
can
do
right
up
until
the
point
at
which
the
container
is
instantiated
or
in
some
operating
system
somewhere.
At
that
point,
what
benefits
am
I
getting
right,
so
I'm
going
to
divide
them
into
into
two?
Let
us
think
about
operational
efficiency.
Now
we
talked
about
automation
and
the
way
that
you
know
containers
can
kind
of
flowed
through
systems
from
a
developer's
laptop
into
a
registry
out
into
maybe
Jenkins
and
then
out
again
and
into
somewhere
else.
A
Now
portability
of
containers.
What
does
that
really
mean?
Well,
what
it
means
is
I
build
a
container
on
my
laptop
I
can
run
that
container
anywhere,
that
there
is
a
compatible
operating
system
and
a
compatible
control
plane.
So
in
the
docker
case,
provided
that
docker
engine
is
running
on,
let's
say
Linux
somewhere
I
mean
we
have
docker
for
Windows.
A
Everything
is
packaged
up
as
a
container
so
that
we
can
then
shift
it
around
and
run
it
on
a
system
and
not
worry
about
what
dependencies
are
installed
on
that
system,
necessarily
right,
not
in
the
same
way
as
we
used
to
at
least
all
we
need
to
think
about
is
okay.
Well,
is
it
a
welcome
figured
system
with
offer
on
it
right,
I
mean
there's
security,
considerations
and
other
things,
but
that's
really
the
degree
of
our
concern.
That's
portability,
so
the
image
format
is
itself
I.
Think
a
significant
advantage.
A
Well,
what
benefits
do
we
get
from
the
image
format?
Well,
remember.
We
talked
in
the
previous
presentation
about
a
few
of
those
benefits.
The
fact
that
every
image
is
just
a
diff
right,
it's
a
snapshot,
so
it
allows
us
to
be
much
more
efficient
with
how
we
move
binaries
around,
because
we're
only
ever
moving
around
diffs
we're,
not
necessarily
moving
around
entire.
You
know
entire
stacks
of
single
files.
Well,
that's
that's!
That
really
helps
us
to
be
operationally
efficient.
A
We
talked
about
the
hierarchy
right,
so
you
can
basically
that
the
images
have
a
parent-child
relationship
and
you
have
effectively
a
tree
of
images
and
that's
potentially
also
really
really
helpful,
because
if
I
want
to
identify
a
particular
image
that
has
a
problem,
let's
say
a
vulnerability
or
a
fix
or
a
patch,
and
it
has
children
that
are
going
to
be
impacted
by
that
patch.
Well,
I
can
immediately
determine
which
of
the
applications
that
I'm
running
are
the
applications
that
contain
that
floor.
A
That
vulnerability,
because,
by
definition,
they're
the
children
of
this
image
in
the
tree.
So
if
I
fix
that
image
and
build
that
entire
subtree
I've,
hopefully
patched
everything
that
matters
right.
The
whole
notion
of
this,
this
parent-child
relationship
with
images
when
it
comes
to
actually
managing.
For
example,
many
companies
like
to
have
blessed
VMs
right
they'll
have
a
whole
department
that
says:
okay,
this
is
the
Linux
you
will
use
and
it
runs
this
and
it
does
X
Y
or
Z.
Well,
the
image
format.
A
A
Well,
this
is
our
blessed
Debian
plus
X,
and
this
is
our
blessed
Debian,
plus
X,
plus
y
right,
and
then
on
top
of
that
you
may
build
whatever
you
like,
but
it
allows
us
to
be
much
more
flexible
about
about
how
we
package
things
so
I
think
that's
another
big
advantage
now,
of
course,
with
the
image
the
docker
image.
Again,
you
know.
Sometimes
we
talk
generally
about
containers
oftentimes.
A
We
talk
specifically
about
docker,
because
that's
the
most
common
use
case
registries
are
the
docker
registries
are
a
big
part
of
why
this
docker
image
format
is
also
becoming
really
really
interesting
to
people
and
in
fact,
it's
worth
noting
that
many
third
parties
now
are
starting
to
ship
their
software
to
vendors,
to
to
customers
as
docker
images
they're
like
alright,
should
we
really
like
the
stock
or
image
format?
This
is
really
working
for
us,
and
part
of
this
is
down
to
these
benefits.
He
talked
about
partly
also
the
registry.
A
Well,
what
benefits
do
we
get
with
a
registry?
Well,
there
are
companies
furiously
innovating
in
this
space
right
now,
particularly
in
the
area
of
security
right,
so
role
based
access
control,
for
example,
I-
can
define
who
runs
what
image
and
on
what
endpoints.
That's
a
really
powerful
thing
to
be
able
to
do
vulnerability
scanning
so
scanning
scanning
vulnerability
scanning
is
big
business.
These
days
you
know,
do
you
know
I've
got
this
image
from
somewhere.
So
what's
one
of
my
developers
built
this
image?
A
Do
I
know
what's
in
it,
maybe
not
right
so
so
the
vulnerability
scanning
is
really
powerful
because
it
allows
me
to
know
exactly
what
is
in
it
and
I
may
then
even
be
able
to
apply
policies
around
who
could
deploy
what
was
types
of
vulnerability
again
and
the
question
of
image
provenance
and
by
inference
the
whole
question
of
signing
images
right.
Do
we
know
where
this
image
came
from?
Is
this?
A
I
would
say
that
another
big
thing
is
control
right
control
over
all
sorts
of
things.
We
talked
about
control
over
the
lifecycle
of
a
container
the
control
over
how
the
container
is
configured
and
packaged
and
presented,
and
all
those
other
things,
but
also
control
over
infrastructure.
We
talked
about
how
you
can
use
docker
to
manipulate
networks
and
create
networks
attached
containers
to
networks.
We
can
use
a
dock,
a
client
to
allocate
you
know
a
persistent
storage.
A
We
can
use
it
to
do
all
sorts
of
things
and
actually,
when
you
sit
down
with
a
docket
client-
and
you
use
it
the
first
time-
and
you
realize
that
just
about
everything
you
want
to
do
with
infrastructure
is
just
a
couple
of
commands
away.
You
get
a
little
dopamine
rush.
It's
it's
a
really
really
nice
experience
and
I
think
that
accounts
for
a
lot
of
why
people
really
loved
opera
in
the
first
place
was.
It
was
just
that
that
that
fluidity
I'd
be
able
to
express
what
you
want
with
infrastructure
and
control
it.
A
So
where
am
I
going
next?
Ok,
state
management,
state
management,
now
state
management
as
far
as
I'm
concerned,
really
has
two
facets
to
it.
There's
a
facet
of
the
state
that
your
application
writes
or
reads,
and
containers
kind
of
force
you
to
think
about
that
in
a
way
that
a
traditional
VM
doesn't
so
by
that
I
mean
what
a
container
has
really
three
kinds
of
storage.
It
has
the
images
that
are
presented
which
are
fundamentally
read-only.
It
has
the
volumes
that
you
can
create,
which
are
rewrite
and
persist
beyond
the
lifecycle
of
the
container.
A
And
then
you
have
the
container
file
system,
which
is
also
read/write.
Typically,
although
you
can
configure
it
to
be
read
only
and
does
not
persist
beyond
the
lifecycle
of
the
container.
So
so,
when
you're
actually
deploying
an
application
as
a
container,
it
forces
you
to
think
about
okay.
Well,
what
is
my
persistent
state?
What
is
my
ephemeral
state
and
where
do
I
want
that
to
go,
and
is
it
going
somewhere?
A
Reconfiguration,
it's
for
one
to
the
better
word,
so
one
of
the
things
we've
become
very
used
to
doing
in
production
is
having
long-running
things
that
we
gradually
poked
with
a
stick
every
once
in
a
while
and
do
something
to
write.
So
you
know
those
of
you
that
that
you
share
from
puppet
and
these
other
things.
You
know,
you'll
write
a
chef
recipe
and
you'll
have
maybe
a
hundred
instances
of
an
application,
and
you
need
to
update
it.
You
need
to
reconfigure
it.
You
need
to
make
some
change.
Okay,
so
update
it.
A
Hopefully
that's
worked
on
all
these
things
and
what
we're
doing
when
we
do
that
is
we're
taking
our
workloads
through
state
transitions,
so
we're
going
from
state
a
state
B,
maybe
tomorrow
I'm
going
to
take
a
receipt
via
state
C.
Maybe
a
week
later,
it's
going
to
go
from
state
C
to
state
D,
and
that's
all
that
sounds
fine.
That
sounds
great,
but
this
takes
little
account
often
for
the
fact
that
state
a
may
in
fact
go
to
state
B
fine,
but
then
it
may
go
to
state
c1,
which
is
a
slight
derivative
of
state.
A
Is
it
actually
in
state
C
right,
and
so
so
this
whole
this
whole
notion
of
taking
long
running
things
through
various
state
transitions
is,
is
a
useful?
No
question
is
useful,
but
it's
also
error-prone,
and
you
know
there
are
cases
where
we
just
end
up
giving
up
on
things,
because
they're
now
fundamental
and
configurable
and
they've
just
we
just
have
to
restart
them
now
where
the
container
model
comes
from,
is
it
basically
says?
Well,
we
should
just
never
do
that.
We
should
just
always
restart
right.
A
There
should
note
this
should
not
be
any
state
transition
in
terms
of
configuration,
changes
or
or
patches,
or
anything
like
that,
not
to
say
that
you
can't
do
that.
I
mean
you.
Can
you
can
make
it
do
that,
but
the
way
it's
designed
is
it's
really
designed
to
be
torn
down
and
and
brought
back
up
again,
so
any
update
any
change.
You
make
very
much
like
a
sealed
appliance
right.
You
bring
it
up.
You
do
something
it
functions
for
a
while.
You
need
to
update
it
and
you
literally
just
swap
it
out.
A
You
replace
it
so
state
management
again
to
two
facets:
to
that:
I
think
the
facet
of
application
state
and
the
facet
of
configuration
state-
that's
probably
enough
for
now
in
terms
of
the
operational
efficiency,
and
this
I
happen
to
think
of
anything.
What
we're
talking
about
runtime
efficiency,
but
let's
move
over
to
this
side
of
the
of
the
board
and
talk
about
well.
Okay,
given
that
we've
got
all
these
benefits
of
creating
containers
and
creating
container
images
when
we
actually
go
to
provision
them
into
into
a
guest
OS
into
a
runtime
of
some
kind.
A
What
benefits
are
we
expecting
at
the
moment
that
those
of
those
start
up
and
at
the
moment
that
we
we
get
those
things
running
well,
I,
would
say
the
most
obvious
benefit
that
people
often
point
to,
particularly
when
you're
at
a
conference,
and
they
show
a
thousand
instances
of
something
starting
at
once.
Containers
are
very
dynamic.
There's
no
question
that
you
know
the
ability
to
be
able
to
start
something
up
very
very
quickly
and
then
make
it
go
away
again,
very,
very
quickly
the
ability
to
do
transactional,
workloads
in
containers.
A
You
know
the
whole
dynamic
nature
of
the
container
runtime.
The
speed
and
efficiency
with
which
you
can
use
it
and
work
with
containers
is
very,
very
useful.
It's
not
necessary
for
everything,
but
it
certainly
very
very
useful
in
many
cases,
and
it
kind
of
it
kind
of
tempts
us
towards
more
of
these
stateless
horizontally
scaling.
A
You
know
farms
of
simple
small
services,
which
is
the
Nirvana
rule,
saying
that
we're
going
to
be
doing
in
the
last
year
next
year,
whenever
and
actually,
let's
write
down
horizontal
scaling
now,
I'm,
not
saying
that
just
because
you
use
containers
you're
automatically
going
to
do
horizontal
scaling,
but
I
think
there
has
been
an
interesting
shift
in
the
last
the
last
five
years,
maybe,
as
we've
moved
from
VMs
towards
containers
in
our
thinking,
VMs
were
very
much
oftentimes
about
vertical
scaling.
You
know,
if
you
wanted
more
performance
from
your
Java
workload.
What
did
you
do?
A
Well,
you
double
the
size
of
the
heap
right
and
then
and
then
double
the
size
of
the
VM
and
added
a
little
bit
extra
hooks
the
best
well
with
containers.
You
know
again,
that's
not
typically
the
way
that
we
that
we
think
or
the
way
that
we're
encouraged
to
think,
partly
because
the
more
that
we're
encouraged
to
think
about
containers
as
being
stateless
services
and
the
fact
that
containers
are
built
on
top
of
an
iOS
layer.
A
This
very
typically
doesn't
have
the
you
know,
there's
a
lot
of
the
complete,
complex
scheduling,
capabilities
of
something
like
this
via
has
I
mean
vSphere.
Has
you
know
it
has
a
you
know,
h.a
capabilities
that
has
live
migration.
It
has
all
of
those
things
all
those
things
are
great
for
stateful
workloads
because
to
be
able
to
live
migrate,
something
that's
stateful.
Oh
it's
just
wonderful
right!
A
You
don't
you
know
it's
and
all
of
these
things
that
we
spent
all
these
years
building
into
our
platform,
work
really
great
with
stateful
workloads,
but
once
you
get
towards
stateless
workloads
and
you
want
to
deploy
them
to
multiple
nodes
of
a
thing
right,
horizontal
scaling
is
such
a
natural
fit
with
that
model,
and
you
know
you'll
see
you
know
kubernetes
and
docker
data
center.
All
of
these
frameworks
have
notions
of
replicas
and
and
instances,
and
you
know
and
rolling
updates,
and
all
of
this
is
isn't
this
move
towards
horizontal
scaling.
A
So
if
I
want
to
move
towards
more
of
a
container
model,
I
often
find
myself
having
to
think
about
moving
towards
horizontal
scaling,
scheduling
clustering.
All
these
things,
that's
not
to
say,
by
the
way
that
virtual
xre
is
that
putting
legacy
workloads
into
containers
isn't
necessarily
a
bad
idea,
and
one
of
the
presentation
is
going
to
be
doing
after
this
is
actually
talking
about
we've.
Seen
more
and
more
of
this
talking
about
why
companies
actually
want
to
containerize
legacy
workloads
the
benefits
they
get
from
it
and
how
we
can
help
them
to
do
that
right.
A
A
Bare-Metal
is
another
interesting
item
on
this
list
in
that
I
think
the
containers
make
bare-metal
and
clusters
of
bare-metal
much
more
manageable.
If
that's,
what
you
want
to
use
I
mean
sometimes
containers
have
been
called
with.
Poor-Man's
virtualization
I
can
see
why
that
would
be
the
one
people
would
say
that,
because
actually,
a
container
host
has
very
many
of
the
same
facets
as
a
hypervisor,
and
it
has
a
control.
Plane
has
a
kernel
house
network.
Virtualization
has
storage
virtualization
it.
A
You
know
it
has
this
this
sandbox
construct
that
has
you
know
it's
a
private
namespace
with
resource
constraints.
There
are
so
many
similarities
between
the
two,
and
so
you
know
if
you're
a
company
and
and
what
you
need
to
do
is
you
need
to
spin
up
thousands
and
thousands
of
instances
of
a
thing.
A
bare-metal
silo
running
some
kind
of
container
engine
may
well
be
exactly
what
you
need.
There's
been
a
lot
of
presentations
from
from
Shopify
who
have
done
exactly
that.
They
have.
You
know
their
entire
application
built
into
containers.
A
Most
of
these
be.
My
customers,
however,
are
still
running
lots
and
lots
of
different
things
right:
everything
from
Windows
desktops
to
analytics
work,
clothes
to
databases
to
Hadoop.
To
you
know
you
name
it
they're
virtualized
just
about
everything,
and
so
in
that
heterogeneous
world
of
virtualization
there
is
still
very
much
a
place
for
for
the
traditional
VM
model,
but
I
can
see
why
you
know
them
containers
make
bare
metal
easy
to
consume.
This
is
the
way
I
would
put
it.
A
So
the
final
thing
actually
I
would
add
to
this,
which
I
probably
should
have
added.
The
Starks
is
one
of
the
more
obvious
things
to
add
is
consolidation
and
by
consolidation.
What
I
mean
is
that
you
can
run
with
containers.
You
can
run
multiple
of
a
thing
inside
of
inside
of
an
operating
system
and
have
those
things
be
isolated
from
each
other
right
in
the
same
way
as
you
can
run
multiple
processes
in
an
operating
system,
they're
not
isolated
in
the
same
way
with
containers,
you
can
run
multiple
containers
in
the
same
operating
system.
A
Now,
because
they're
sharing
a
kernel,
you
get
potentially
significant
consolidation
benefits
in
the
same
way
as
when
people
went
from
physical
to
virtual
and
they
found
they
got.
Consolidation
benefits
very
similar.
You
know,
if
you
go
from
containers
for
up
from
from
you
know,
a
legacy
workload
to
a
containerized
workload.
You
may
find
you
get
consolidation
benefits,
so
I
think
it's
fair
to
say
that
these
runtime
benefits
are
typically
like
where
people
are
going
when
they
think
about
deploying
containers.
A
You
know
on
the
runtime
side
and
it's
useful
to
think
about
these
as
separate
things,
partly
because
what
a
lot
of
companies
are
trying
to
do
today
is
they're
trying
to
just
get
a
handle
on
this
stuff
here
right
I
mean
they're
there.
This
stuff
feels
kind
of
scary
and
a
little
bit
out
there.
This
stuff
they
want
to
get
the
heads
around.
A
So
you
get
all
the
operational
efficiency
and
the
workflow
benefits
and
everything
everything
that
you
see
here,
but
you
don't
have
to
think
about
this
piece
being
a
different
model
or
a
model
that
you're
not
used
to
because
behind
the
curtain
it's
just
vSphere
infrastructure
and
VMs
and
visa
networks,
b/c
of
storage.
So
we'll
explore
much
more
about
that
when
we
get
into
the
victors
inton,
but
for
now.
Hopefully
that
was
interesting
and
see
you
them
soon.