►
Description
Does Cloud Native Mean Container Native? - James Bottomley, IBM Research
"In the few years since containers rose to prominence, there has been much confusion about what containers are and whay they do for the cloud. This talk will try to unpick the separate concepts of cloud native, container native (and even container native bare metal) and explain where they fit into the pantheon. Although today it is true to say that Cloud Native methodologies cannot realistically be implemented without container technology, becuase of the dependence on container image formats, this talk will explore whether this is importand (do you need to understand containers to deliver cloud native) and will this always remain true or, as current trends indicate, there may be other implementation technologies that are also capable of capturing the cloud native banner.
Attendees will learn the difference between the terms cloud native and container native (and what container native bare metal means). What containers are, how they work and how they differ from other virtualization technologies. And finally we will look at some future looking technologies like lightweight virtual machines, and how they might bring the best of both worlds to cloud native."
About James Bottomley
James Bottomley is a Distinguished Engineer at IBM Research where he works on Cloud and Container technology. He is also Linux Kernel maintainer of the SCSI subsystem. He has been a Director on the Board of the Linux Foundation and Chair of its Technical Advisory Board. He went to university at Cambridge for both his undergraduate and doctoral degrees after which he joined AT&T Bell labs to work on Distributed Lock Manager technology for clustering. In 2000 he helped found SteelEye Technology, a High availability company for Linux and Windows, becoming Vice President and CTO. He joined Novell in 2008 as a Distinguished Engineer at Novell's SUSE Labs, Parallels (later Odin) in 2011 as CTO of Server Virtualization and IBM Research in 2016.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
Okay,
well,
thank
you
very
much
for
coming.
My
name
is
James.
Bottomley
I
actually
have
a
slide
about
myself
being
very
proud.
I
have
been
a
container
evangelist
and
an
open
source
advocate
for
a
reasonably
long
time,
not
as
long
as
I've
actually
been
a
kernel
developer
and
an
advocate
for
converting
to
open
source
and
also
in
the
very
dim
and
distant
past.
Even
a
Linux
architecture
maintainer,
the
one
I
actually
admit
to
is
Pierre
risk,
but
there's
also
a
Voyageur
architecture
buried
very
deeply
in
there.
One
of
the
things
I
do
for
my
day.
A
A
So,
in
order
to
answer
the
question
of
whether
container
native
and
cloud
native
of
the
same
thing,
the
first
question
you
really
have
to
answer
is
what
does
cloud
native
mean,
and
it
turns
out
that
this
question
is
actually
surprisingly
difficult
to
answer.
You'd
expect
that
since
we
have
a
cloud
native
computing
foundation-
and
they
are
sponsoring
this
conference,
they
would
actually
know
what
it
means,
but
in
fact,
if
you
search
the
entire
cnc
F
website,
you
will
not
find
a
definition
of
this.
Now
there
is
a
dirty
secret
here.
A
So
as
long
as
you
have
a
cloud
platform
and
you
write
for
it,
you
can
call
yourself
cloud
native,
which
sounds
good
until
you
realize
that
we
East
sitting
here,
believe
it's
something
like
KU,
benetti's
or
even
docker
swarm
or
one
of
the
modern
cloud
native
api's.
But
you
have
to
remember
that
long
ago
there
were
lots
of
other
clouds
that
still
ran
things
that
were
not
based
on
containers.
They
could
actually
be
deploying
virtual
machines.
A
This
is
what
an
infrastructure
cloud
was
in
the
old
days,
so
in
particular
anything
openstack-based
by
and
large
is
deploying
virtual
machines,
but
I
don't
think
anybody
in
the
room
would
disagree.
That
OpenStack
is
a
cloud
platform,
so
anything
written
for
OpenStack
could
also
be
described
as
cloud
native,
so
they're
going
yay
now
even
worse
than
that
anything
sort
of
written
for
vcloud
director,
which
is
VMware's
idea
of
how
to
organize
orchestrate
virtual
machines
written
for
them,
which
is
sort
of
90-odd
percent
of
the
enterprise.
A
So
anything
that
runs
in
vcloud
director,
which
is
all
your
legacy.
Virtual
machines
could
also
technically
be
described
as
a
client
native,
and
so
here
I'm
we're
starting
to
get
into
a
mismatch
in
that
I.
Think
if
you
went
to
any
person
on
the
street
who
understood
computing
and
said
you
know,
cloud
native
is
the
new
thing.
Do
you
think
that
prior
native
means
being
able
to
run
the
old
legacy
virtual
machines,
they
would
say
no,
and
so
there
is
really
a
mismatch
between
the
current
industry
definition
and
what
everybody
actually
thinks.
A
But
realistically,
if
I
follow
the
definition
cloud
native
means
nothing
different
from
I
ass,
which
I
think
is
wrong
and
fortunately,
I
think
about.
Ninety
percent
of
the
people
in
computing
would
think
is
wrong.
So
one
of
the
ways
of
actually
getting
at
what
cloud
native
means
is
to
actually
ask
customers
what
it
means
to
them
and
a
good
way
of
doing
this
is
actually
finding
customers
who
are
forced
to
do
cloud
native
stuff
and
asking
them
what
it
means.
A
A
A
long
time
ago,
when
I
first
came
to
the
states,
I
often
thought
that
the
difference
between
America
and
Great
Britain
was
well.
Firstly,
we
can
speak
English,
but
secondly,
it's
that
the
English
descriptions
of
vernacular
a
lot
richer.
But
I've
got
to
say
that
the
southern
phrase,
meaner
than
a
skillet
full
of
rattlesnakes,
does
describe
what
customers
become
when
you
do
this
to
them.
But
we
still
once
you've
done
it.
It
means
that
they
are
forced
to
think
in
these
terms,
and
you
can
actually
try
and
get
interesting
information
out
of
them.
A
When
I
say
you,
I'm
sort
of
speaking
advisedly,
I
didn't
actually
make
the
first
contact
being
a
distinguished
engineer
at
IBM.
Fortunately,
I
have
a
vice
president
I
can
deploy
to
go
and
make
first
contact
with
customers,
who'd
be
described
as
meaner
than
a
skillet
full
of
rattlesnakes,
and
when
he
came
back
and
had
him,
we
had
him
patched
up.
We
could
do
a
debriefing,
the
good
thing
about
the
anger
of
customers,
as
it
is
very
short-lived.
A
So
once
you've
deployed
your
vice
president,
you
can
actually
go
and
make
the
second
contact
in
person
it's
something
reasonably
useful.
So
the
first
thing
that
came
out
of
this
is
that
customers
definitely
think
of
cloud
native
as
meaning
adopting
new
technologies.
So
any
definition
of
cloud
native
that
still
covers
old
technologies.
They
don't
really
accept
so
the
industry
standard
definition
of
anything
written
for
a
cloud
platform.
If
you
actually
just
inserted
a
new
cloud
platform,
it
makes
it
not
very
useful
as
a
definition,
but
it
is
roughly
what
customers
are
thinking
at
first
blush.
A
It
also
means
to
them
anything
that
makes
development
and
deployment
for
the
cloud
easier.
So
this
is
where
we're
getting
a
lot
further
away
from
the
concept
of
a
virtual
machine,
because,
as
we
all
know,
virtual
machines
having
used
them
for
the
last
15
years,
have
a
lot
of
significant
problems
when
it
comes
to
life
cycles.
Customers
who've,
been
forced
to
live
in
a
virtual
machine
world
have
a
lot
a
real
fear
of
actually
managing
virtual
machine
life
cycles.
A
So
when
they
say
development
and
deployment
easier,
they're
talking
about
life
cycle
here
and
the
final
thing
when
you're
actually
big
down,
is
that
they
want
something
that
allows
them
to
concentrate
on
applications,
not
infrastructure.
If
I
really
emphasize
this,
I
think
this
is
the
key
to
the
heart
of
being
cloud
native,
anything
that
actually
allows
you
to
build
your
application
for
the
cloud
and
not
have
to
worry
about
all
the
old-fashioned
infrastructure
by
infrastructure.
I
mean
all
of
the
crap
who
used
to
go
into
virtual
machines.
A
So
one
of
the
true
genesis
of
what
could
be
considered,
the
cloud
native
revolution
is
going
from
this
idea
of
virtual
machines
with
their
horrible
infrastructure
drift.
The
reason
they
drift
is
because
a
virtual
machine
image
can
be
booted
up
change
taken
down
whatever
you
did
to
it.
You've
changed
it.
A
If
you
go
to
any
person,
who's
actually
running
a
large-scale
enterprise
based
on
virtual
machines,
image
drift
is
one
of
their
nightmares,
because
eventually
you
find
that
you
have
a
plethora
of
virtual
machines
lying
around,
some
of
which
people
haven't
booted
up
for
years,
which
are
in
various
states
of
security,
non-compliance
and
whatever,
and
just
looking
at
the
image
is
actually
very
difficult
to
find
out
what
the
hell
is
going
on
here.
So
this
all
changed
when
we
got
the
idea
of
immutable
infrastructure.
This
in
many
ways
is
really
the
key
to
the
revolution.
A
It's
not
entirely
due
to
containers
technology.
It's
due
to
the
idea
of
having
a
mutable
infrastructure.
This
is
the
innovation
that
led
to
something
called
the
DevOps
cycle,
which
I
assume
you've
been
to
talk
after
talk
after
talk
about
the
other
thing
it
led
to
is
the
ability
to
share
images
once
the
infrastructure
is
immutable.
Images
can
be
safely
shared
because
they
can
be
transport
between
people,
so
anybody
can
build
say
in
a
bun
214
image
and
put
it
on
the
docker
hub,
but
chances
are
when
a
bunt
who
does
it.
A
This
gives
you
one
canonical
image
that
you
can
then
begin
to
base
your
actual
images
that
do
stuff
off
so
effectively.
You
get
the
concept
of
image
via
overlay,
so
the
true
thing
that
actually
allowed
this
immutable
infrastructure
to
work
wasn't
actually
containers
technology.
It
was
the
various
overlay
file
systems
and,
as
you
know,
if
you've
been
to
the
talk
about
graph
drivers,
there
are
still
rather
a
lot
of
these
lying
around.
So
I'm
going
to
condense
this,
to
what
I'm
overlay
really
does.
A
So,
if
you're
building
an
image
using
docker,
you
often
begin
by
downloading
a
base
layer
from
somewhere.
This
is
usually
your
bun
to
thing
or
eventually,
you'll
be
able
to
get
windows
things
or
any
other
operating
system.
That's
describable
in
this
way,
but
right
at
the
moment
it
tends
to
mostly
be
Linux.
The
base
layer
comes
with
a
char,
256
description,
then,
on
top
of
that,
you
usually
get
somebody
else
to
provision
your
middleware.
This
is
indulging
in
the
DevOps
cycle,
and
on
top
of
that,
you
tend
to
get
your
application.
A
So
this
these
things
together,
when
combined,
constitute
an
image
that
you
could
then
actually
deploy
anywhere
or
ship
off
to
the
docker
hub.
So
what
we're
hoping
is
that
customers
think
of
this
thing,
this
sort
of
combined
image
and
the
DevOps
cycle
that
goes
with
it
that
allow
you
easily
to
take
this
immutable
thing
break
it
down,
build
it
back
up
as
the
solution
to
their
infrastructure
problems.
A
The
problem
with
all
of
this
is
that
sharing
images
means
sort
of
like
sharing
Hank,
achieves
or
sharing
coffee
cups.
We
share
security
issues
and
bugs,
and
the
estimate
for
people
who
want
to
frighten
you
about
security
is
that
seventy
percent
of
images
on
almost
all
of
the
hub's
are
insecure,
and
this
leads
to
a
lot
of
projects
that
try
and
fix
this
security,
and
you
have
to
remember
that
there's
been
an
awful
lot
of
I
won't
call
it
fun,
because
I
believe
this,
seventy
percent
figure
is
true.
A
The
real
secret
of
this
is
that,
if
you
crack
open
all
of
those
virtual
machines,
you'll
find
this
figure
is
going
to
be
a
lot
higher
than
seventy
percent.
The
only
reason
that
nobody
is
making
a
huge
fuss
about
this
is
because
it's
very
difficult
to
do
for
virtual
machines.
It's
one
of
the
ironies
of
the
technology
that
allows
us
to
do
this,
and
this
is
in
some
ways
a
technology
thing.
Containers
are
often
very
transparent
and
virtual
machines
based
on
hypervisors
are
actually
very
opaque.
A
So
the
transparency
of
containers
leaked
into
this
and
almost
based
on
the
show
some
and
how
it's
built.
You
can
tell
whether
this
image
is
secure
or
not,
and
it
actually
makes
looking
for
security
problems
a
lot
easier
with
these
new
immutable
infrastructure
technologies
than
it
ever
did
with
the
virtual
machine
technologies
and
because
it's
easier,
amazingly
enough,
we
find
all
of
the
problems.
A
This
is
where
containers
as
a
transparent
mechanism
for
deploying
is
much
better
than
virtual
machines
in
order
to
get
into
a
virtual
machine
to
see
if
what
it's
running
is
insecure,
you
have
to
find
a
way
of
getting
inside
it.
So
often
you
have
to
do
this
with
agents
which
then
make
it
much
more
difficult
and
intrusive
to
do.
Containers
can
very
simply
be
scanned
from
the
host
operating
system,
because
everything
a
container
does
is
vis
able
to
the
host
operating
system.
A
So
runtime
scanning
is
perfectly
possible
with
any
image
vulnerability
technology
that
is
actually
invented
to
cope
with
containers.
So
both
of
these
can
tell
you,
based
on
the
current
list
of
bugs,
so
here's
the
key.
If
there's
a
bug,
that's
discovered
after
you
run
the
scam
you'll
see,
your
container
will
still
be
certified
as
secure,
even
though
it's
not
both
can
tell
you
whether
your
images,
a
secure
or
not
and
vulnerability
analyzer
can
actually
even
warned
you
about
running
images
that
become
insecure.
A
So
as
long
as
your
scanner
is
actually
connected
to
a
current
source
of
data,
if
a
CVE
comes
out
tomorrow
and
it
can
scan
your
running
container,
it
can
suddenly
tell
you
that
what
you
thought
was
a
secure
image
running
in
your
cloud
has
suddenly
become
an
insecure
one
and
you
can
take
policy
decisions
based
on
that
and
the
policy
decisions
that
all
of
these
technologies
allow
is
usually
worn,
allow
Warner
and
allowed
to
run
or
stop
running.
It's
usually
a
fairly
simple
policy
decision.
A
Now,
here's
one
of
the
problems
where
the
idea
of
taking
over
the
infrastructure
from
the
customer
meets
our
new
technologies,
because
if
a
customer
is
thinking
that
the
cloud
service
provider
is
moving
further
up
the
stack
and
they
just
become
responsible
for
the
application,
why
do
they
then
have
to
start
worrying
about?
My
image
has
been
stopped
from
running?
What
do
I
do
now
and
we
say:
well,
you
go
back
through
your
DevOps
cycle
and
you
rebuild
it
with
a
passion
of
whatever
it
was.
A
The
CVE
told
you
was
vulnerable
and
customers
say,
but
that's
not
what
you
promised
me.
What
I
want
is
for
you,
as
the
cloud
service
provider,
to
take
over
all
of
my
infrastructure
problems.
This
doesn't
just
mean
some
of
my
deployment
problems.
It
actually
means
taking
responsibility
for
the
bits
that
I
really
don't
want
to
bother
with
it
anymore
I.
Am
your
customer
I
want
my
field
of
expertise
to
be
my
wonderful
application
that
deploys
marvelous
things
through
the
cloud.
A
A
Now
this
is
often
obscured
because
DevOps
is
making
great
hay
inside
the
enterprise,
and
the
enterprise
has
been
so
far
behind
on
it's
sort
of
building
virtual
machines
and
deploying
them
that
the
enterprise
is
truly
happy
that
DevOps
came
along
and
this
moves
much
faster.
The
enterprise,
mostly
if
you're,
a
really
large
company,
has
all
the
departments
necessary
to
rebuild
this
image.
But
you
have
to
remember
the
lot
of
what
the
cloud
does.
Is
it
actually
allows
much
smaller
companies
to
come
to
the
forefront
with
truly
innovative
applications
that
they
think
of
that?
A
Usually
we
dinosaurs,
an
industry,
don't
necessarily
do
and
deploy
to
the
customers
for
them.
This
DevOps
cycle
thing
is
still
a
problem
because
they
don't
have
all
of
the
in-house
expertise
to
run
it,
and
the
question
is
for
us,
since
we
at
this
conference
or
or
pushing
this
DevOps
thing
is
what
do
we
do
about
that?
How
do
we
actually
satisfy
our
customers,
while
not
requiring
them
to
be
so
big
that
they
have
15
different
departments?
A
So
the
way
a
customer
thinks
when
they
look
at
this
image,
is
that
if
I
pick
up
and
let's
for
sake
of
argument,
say
the
heartbleed,
if
I
picked
up
heartbleed
and
my
base
layer
suddenly
becomes
insecure,
but
the
application
that
I'm
running
is
still,
to
all
intents
and
purposes.
This
is
the
thing
I'm
an
expert
in
is
still
secure.
I,
don't
want
to
have
to
rebuild
this
image.
Take
it
back
to
my
department,
redeploy
it
certify
that
I'm
free.
I
want
you,
mr.
A
cloud
service
provider,
just
to
do
this
for
me,
so
I
want
the
cloud
service
provider
themselves
to
actually
be
able
to
take
my
base
layer
off
and
obviously
the
image
shell
would
change
as
well.
So
effectively
they've
changed
my
image.
So
what
we're
actually
moving
towards
is
immutable
infrastructure,
for
us
was
a
great
innovation
because
it
led
to
a
complete
revolution
and
how
we
thought
about
building
images.
But
if
you
actually
go
to
a
customer
on
the
street
and
find
out
what
they
want,
you
talk
to
them
about
immutable
infrastructure
and
its
benefits.
A
They
say
yes,
I
really
want
that.
And
then,
if
you
talk
about
problems
like
this,
they
say
well,
okay,
perhaps
I
want
slightly
mutable
infrastructure,
so
they
don't
want
the
entirety
of.
We
have
to
take
it
back
to
our
shop
and
rebuild
it,
because
if
you
think
about
it,
let's
say
I'm,
a
really
small
customer
I
only
really
understand
my
application.
A
Let's
say
I
contracted
with
someone
else
to
rebuild
this
and
I
have
to
go
back
to
them
and
say:
okay,
you're
responsible
for
this,
you
rebuild
it
a
they
might
be
going
to
charge
something
for
me,
be
they
might
say
well
in
a
couple
of
weeks
or
see
there
might
be
all
sorts
of
other
problems
in
doing
this.
If
I
don't
run
my
develop
cycle
completely
in-house
rebuilding
this
image
fast
to
get
patched,
the
vulnerability
becomes
a
monster
headache
in
the
nightmare.
A
A
So
how
do
we
do
this?
One
thing
we
could
offer
as
cloud
service
providers
is
actually
to
participate
in
the
customers
develop
cycle,
so
we
could
become
part
of
DevOps.
With
the
customer.
I
can
see.
Glazed
looks
from
people
who
run
cloud
service
providers
at
least
I
didn't
get
screams.
I
was
actually
expecting
them.
A
There's
no
real
way
that
a
cloud
service
provider
who's
trying
to
deploy
all
things
cheaply
really
wants
to
be
involved
in
the
customers
DevOps
cycle,
because
it
makes
you
as
the
CSP
far
too
responsible
for
what
the
customer
deploys
is
the
image.
This
basically
means
that
any
screw
up
the
customer
does
and
the
application
is
most
likely
to
become
your
fault,
because
they're
going
to
be
able
to
blame
you
somehow
for
the
middleware
or
everything.
So
if
we
conclude
that
making
the
CSP
run
DevOps
for
the
customer
is
not
really
what
we
want
to
do.
A
The
next
question
is:
what
really
do
we
as
cloud
service
providers
want
and
realistically
what
we
really
want
is
the
ability
to
add
image
patching.
This
would
be
where
the
immutable
infrastructure
goes
from,
being
completely
immutable
to
being
slightly
immutable
with
it
slightly
suitable,
but
within
really
stiff
prescribed
bounds,
so
overlays
as
Linux
on
almost
every
other
file
system.
Thinks
of
them
are
all
about
base
images
and
things
that
cover
it.
So
there's
no
concept
in
an
overlay
of
actually
doing
a
merge.
What
an
overlay
does
is
if
a
higher
image
has
a
file.
A
That's
got
the
same
name
as
one
in
the
base
image.
The
file
and
the
higher
image
prevails.
There's
no
concept
of
actually
merging
this
or
doing
anything,
but
it
does
allow
us
to
think
about
how
we
would
actually
do
this
type
of
replacement,
because
we
can
look
at
what
the
customer
has
inside
their
application
layer
and
at
a
file
level.
We
can
tell
what
files
it
overlays
and
based
on
the
differences.
So
we
can
see.
Look
at
a
diff
between
the
unpatched
base
image
and
the
patch
based
image.
A
We
can
see
what
files
that
changes
chances
are
if
the
customer
did
everything
right,
which
to
be
honest
for
a
lot
of
customers,
is
a
big.
If
so,
I
am
NOT
going
to
pretend
this
will
work
unless
the
customer
does
it
right,
we
can
actually
tell
whether
any
changes
in
the
image
would
be
interfered
with
by
anything
the
application
is
done,
and
if
that
set
the
difference
between
the
what
the
application
wants
to
change
and
what
the
patch
wants
to
change
is
empty.
We
can
pretty
safely
deploy
this
overlay
and
effectively
do
the
rebuild
now.
A
This
could
be
just
like
a
nice
DevOps
rebuild,
but
if
we
have
cover
of
it
being
a
patching
process,
we
become
as
cloud
service
providers
much
less
responsible
for
this
than
the
customer
actually
thinks
largely
because
the
set
of
patches
that
we're
allowed
to
do
would
be
generated
by
someone
else,
and
we
could
say
we're
just
following
that.
So
a
patch
process
for
all
of
these
images
and
overlays
is
actually
very
possible.
It's
just
something
we
haven't
actually
been
thinking
about.
A
One
of
the
really
great
things
that
immutable
infrastructure
brings
is
the
ability
to
deploy
a
precise
environment
anywhere
now,
if
we
allow
mutability
of
the
base
image,
one
of
the
chances
we
run
is
that
we're
actually
going
to
destroy
this
or
at
least
damage
it
in
some
form.
So
the
chances
are
that
we
might
get
a
patched
image
that
is
no
longer
deployable
because
something
changed
in
the
base
operating
system.
The
application
was
relying
on
this
type
of
interaction
happens
a
lot
in
theory,
if
you're
very
careful
about
patching.
A
A
So
in
theory,
as
long
as
we're
very
careful
about
the
patching
process,
we
should
be
able
to
preserve
the
precise
environment
deployment,
even
if
we
actually
do
this
patching
thing,
I'm
not
going
to
promise
that
this
is
always
going
to
work
out
at
the
box,
because
some
people's
idea
of
what
constitutes
a
patch
is
very
different
from
other
people's.
We
would
actually
have
to
be
very
strict
about
patches,
really
any
fixed
budget
bugs
they
don't
slide
quietly
and
features
that
other
customers
have
asked
for.
A
But
the
point
is
this
is
possible,
and
this
is
what
customers
want.
Therefore,
we
should
be
thinking
about
this.
How
would
we
actually
deploy
this
I
mean?
The
immediate
problem
that
springs
to
mind
is
the
sha-256
sums
are
not
ordered,
there's
no
real
way
to
order
a
patching
thing
without
a
whole
lot
of
metadata.
That
tells
you
you
know
this
is
ubuntu
version
14.1.
This
is
we've
a
bun
to
version
14.1
with
heartbleed
fix
and
then
the
Drowned
fix
and
then
all
the
other
fixes
that
went
into
it.
A
We
need
somebody
to
maintain
the
metadata
that
actually
correlates
this
and
tells
us
what
a
patch
sequence
is.
It
does
actually
shovel
a
lot
of
the
responsibility
onto
the
people
supplying
the
other
layers
of
the
infrastructure,
and
it's
a
thing
that
large
enterprises
aren't
really
going
to
care
about,
because
they
can
still
follow
their
develop
cycle
and
rebuild
the
image.
It
only
really
matters
the
smaller
customers
who
want
somebody
else
to
be
responsible
for
this
problem.
A
So,
like
I
said
all
of
this
is
possible.
It
only
involves
metadata
tracking.
The
thing
that
we
need
to
think
about,
if
we
want
cloud
native
really
to
work,
is,
is
this
a
problem
we
should
actually
be
discussing.
So
if
you
raise
your
hand
in
any
session
where
dr.
people
are
or
core
OS,
people
are
and
say
what
about
the
patching
problem?
They'll
always
say:
yes,
we're
thinking
about
that,
but
in
fact
nothing
ever
pops
out
at
the
other
end.
A
So
we
need
to
go
from
thinking
about
it
to
actually
try
and
do
it
in
order
to
give
customers
the
assurance
they
need
that
the
cloud
service
provider
is
actually
taking
responsibility
for
more
and
more
of
their
infrastructure.
Now,
if
we
were
really
old-fashioned,
the
thing
you
could
be
telling
me
is:
why
not
use
just
use
platform
as
a
service
platform
as
a
service
did
all
of
this,
because
it
made
the
cloud
service
provider
responsible
for
the
entire
teaser
plat
of
the
platform.
A
The
problem
that
we
cannot
now
fix
the
genius
basically
out
of
the
bottle
is
that
almost
every
image
out
there,
if
you
look
at
the
docker
hub,
starts
with
a
very
slightly
different
version
of
the
base,
they're,
almost
all
written,
with
fairly
different
tools,
so
platforms
have
gone
from
being
vulcanized,
as
they
were
in
the
old
days
to
being
completely
fragmented
in
the
new
doc
a
day.
It
is
no
longer
possible
for
us
to
pull
all
of
this
in
and
say.
A
So,
as
cloud
service
providers,
we
end
up
having
to
be
responsible
for
a
whole
lot
of
stuff
that
we
didn't
really
necessarily
want
responsibility
for,
but
again,
if
all
we're
doing
is
building
stuff
that
shipped
to
us
by
other
people
with
their
assurances,
it
becomes
possible
just
rather
difficult
and
I
think
the
reason
why
nobody
is
actually
seriously
tackling
this
is.
It
does
look
like
one
of
the
harder
problems,
but
again,
if
we're
promising
customers
we're
moving
up
the
stack
into
being
responsible,
taking
away
all
the
infrastructure
issues,
these
are
the
hard
problems.
A
They
expect
us
to
be
solving
not
telling
them
that
oh
I'm,
sorry,
you
need
to
reveal
the
image.
This
is
all
your
fault.
This
is
your
responsibility
and
one
of
the
problems
that
we're
going
to
run
into
eventually.
Is
there
not
having
the
capability
of
doing
this
not
being
able
to
move
fully
up
the
stack,
even
the
stack
inside
the
dot,
doc
or
oci
image
is
going
to
mean
that
customers
don't
really
think
of
what
we
believed
to
be
current
technologies
as
cloud
native.
A
This
is
already
in
some
sense
happening,
so
the
promise
of
cloud
native
goes
beyond
what
we
currently
have,
and
this
is
one
of
the
dangers
of
this
term,
especially
when
you
think
of
how
customers
are
putting
their
faith
in
us
at
the
moment.
So
one
of
the
other
things
I
promised
to
talk
about
was
cloud
native
bare
metal
coming
from
IBM
bluemix
I
really
like
this,
because
the
bluemix
itself
is
container
native
their
metal.
A
It
simply
means
that
you
run
containers
is
the
only
virtualization
technology,
no
intervening
virtual
machines
or
hypervisors
or
anything
anywhere.
You
trust
container
technology
enough.
You
think
it's
secure
enough
that
you
can
deploy
a
customer
containers
straight
on
to
a
host
it
also,
if
you
actually
find
somebody
that
does
contain
a
native
their
metal.
It
also
means
that
when
the
cloud
service
provider
promises
you
management,
it
does
not
mean
he's
going
to
shove
doctor
or
something
into
a
virtual
machine
hand
you
this
virtual
machine
and
tell
you
to
manage
it.
A
Another
great
advantage
is,
it
gives
near
bare
metal
performance,
practically
everything
because
container
of
technology
as
you've
heard
long
ago
and
in
all
these
talks
is
a
lot
thinner.
So
it
means
that
stuff
is
just
running
much
closer
to
the
metal
of
the
host
and
therefore
can
run
practically
a
bare
metal
performance
levels.
This
is
useful,
but
if
you're
charging
your
customers,
you
know
for
the
CPU
are
in
a
thing
who
notices
the
overhead
depends
on
how
you
pay
for
it.
A
If
you
are,
can
contain
a
native
bare
metal.
The
other
thing
that
being
contained
a
native
bare
metal,
hopefully
shows
is
the
cloud
service
provider
really
understands
the
container
technology
they're,
not
just
leaping
on
the
bandwagon,
so
this
realistically
is
nothing
to
do
with
technology.
This
is
an
expression
of
faith,
but
building
a
bridge
of
faith
that
the
customer
knows
that
you're
going
to
do
the
right
thing
for
them,
because
you've
already
done
it
in
your
cloud
is
actually
a
really
important
thing
to
do.
A
In
fact,
in
many
ways
I
would
say
this
is
one
of
the
really
significant
and
important
things
that
contain
a
native
bare
metal
actually
means
is
it's
an
expression
of
faith
to
the
customer
that
I'm
only
running
containers.
So
if
you
come
to
me
and
give
me
your
applications,
whatever
happens
in
the
future,
I
will
still
realistically
only
be
running
containers.
A
I
will
help
take
you
through
whatever
the
transitions
and
the
problems
you
get,
whereas
if
your
statement
to
the
customer
as
well
I'm
running
containers
at
the
top,
but
then
I
have
a
hypervisor
in
the
middle
and
all
of
this
bits
and
pieces
which
insulate
you
from
all
of
this.
It
becomes
a
much
more
difficult
story
to
make
that
well,
whatever
comes
down
the
pipe
with
container
technologies,
I'm
going
to
be
there
for
you,
because
I
can
just
sequester
you
off
into
some
other
virtual
machine
thing.
If
I
decide,
this
is
getting
too
difficult.
A
A
But
these
script
fragments
do
need
to
run
in
an
isolated
way,
but
they
also
need
to
run
incredibly
fast
a
lot
of
these
script,
fragments
if
you
look
at
them
either
on
Amazon
or
on
the
open,
whiskey
experimental
plan,
they
run
very
very
fast.
The
object
is
to
run
them
in
milliseconds.
Some
can
run
in
hundreds
of
milliseconds
some
take
a
few
seconds
to
run,
but
if
you
want
them
to
be
protected
inside
some
sort
of
virtual
environment,
it
has
to
be
spun
out
and
spun
down
very
fast
and
again
for
doing
this.
A
That
means
that
containers
are
coming
much
closer
to
the
ability
to
do
this
than
any
form
of
hypervisor
based
virtual
machine.
In
fact,
in
many
ways
it
wouldn't
be
an
untrue
statement
to
say
things
like
whisk
and
lambda
are
almost
impossible
if
we
didn't
have
the
container
technology
to
actually
allow
us
to
do
this.
A
The
reason
we
need
containment
is
because
the
customer
wrote
the
script
so
either
you
to
trust
the
script
platform
or
you
have
to
contain
whatever
they
did
in
such
a
way
that
security
problems
don't
leak
into
you
as
the
cloud
service
provider
and
obviously
the
ideal
executor
is
something
like
a
micro
container
which
just
provides
enough
containment
to
keep
the
script
in
bounds
and
nothing
more.
The
lighter
you
make
it.
A
The
faster
will
actually
spin
up,
and
this
idea
of
the
script
basically
needing
an
invariant
environment
is
starting
to
fade
because
whatever
actually
runs,
the
scripting
language
does
not
need
support.
It
needs
support
from
an
operating
system,
but
it
does
not
need
the
writer
of
the
script
to
prescribe
all
the
way
down
to
the
metal
of
the
operating
system.
A
But
the
thing
you're
containing
and
describing
is
really
just
the
script
and
possibly
something
to
hook
into
its
environment,
say
it's
version
X
of
no
das
or
Swift
or
whatever
other
language.
Du
jour
happens
to
be
what
the
customer
wants
to
program
into,
and
so
this
is
moving
us
away
from
the
docker
idea
of
the
prescription
being
all
the
way
down
to
the
base
operating
system
itself.
A
So
conclusions
did
I
actually
answer
the
question
that
I
posed
at
the
beginning
cloud
native
definitely
means
different
things
to
customers
than
it
does
to
us.
We
really
have
to
be
aware
of
this
patting
ourselves
on
the
back
at
a
conference
like
this
and
saying
we
achieve
cloud
native,
won't
necessarily
fly
when
you
get
to
ask
answer
hard
questions
from
your
customers,
we
really
need
to
think
about
what
cloud
native
means
to
our
customers
and
our
audience
into
their
customers.
A
Now
I
think
I've,
pretty
much
proven,
especially
with
the
industry
definition
that
just
because
something
is
container
native
doesn't
mean
it's
cloud
native,
and
proof
of
this
is
really
that
in
customer
terms,
thinking
of
the
next
generation
docker
itself,
which
is
the
poster
tired
child
for
container
technologies,
is
not
actually
cloud
native
because
it
can't
deliver
them
the
services
they
think
they
want
things
like
patching
things
like
micro
containers.
That
doesn't
mean
it
won't.
A
The
reason
this
is
true
is
because
hypervisors
cannot
move
away
from
the
virtual
machine
monitor
base.
Hypervisors
are
a
description,
basically
of
something
that
runs
on
a
model
of
hardware,
and
if
you
can't
move
away
from
that,
you
cannot
get
rid
of
all
the
legacy
that
has
to
go
along
with
that.
You
know
Colonel
to
run
it
things
like
this,
it's
much
harder
with
a
hypervisor
to
move
up
the
stack
the
customers
want
us
to
move
up
than
it
is
with
a
container,
so
this
basically
means
that
containers
are
becoming
essential
for
any
technology.
A
That
is
going
to
be
cloud
native
just
because
they
can
contain
things
that
are
much
smaller
and
much
sure
to
lift
so
container
native
may
not
be
sufficient
for
being
cloud
native,
but
I
believe
in
future.
It
is
definitely
going
to
become
necessary
for
cloud
native
and
with
that
I
think
I've
got
five
minutes
for
questions.
This
was
presented
using
impressed,
ojs
I
rather
like
it.
It
does
make
me
a
web
developer,
for
which
I'm
truly
sorry
for
all
my
kernel,
friends
and
I'll
say
thank
you
and
call
the
questions.
A
A
The
kernel
is
not
part
of
the
description,
so
it
is
possible
for
you
to
bring
up
a
virtual,
a
lightweight
virtual
machine
that
actually
contains
the
kernel
of
its
base
and
obviously
any
bug.
That's
a
security
bug,
that's
caused
by
the
kernel
you
can
fix
in
this
image
easily,
but
the
cloud
service
provider
would
say
that
for
all
containers
they
will
share
the
same
kernel
of
the
host
level.
If
we're
only
deploying
containers.
A
If
I'm
running
this
core
OS
idea
of
a
lightweight
virtual
machine,
every
separate
kernel
that
they
run
has
to
be
patched,
and
this
becomes
much
more
of
a
patching
problem
and
then
again
the
customer
image
itself
is
still
this
immutable
thing.
It
doesn't
get
patched
so
the
way
we
have
to
solve
the
patching
problem
is
to
actually
make
it
possible
for
the
customer
themselves.
So
if
we
could
pull
away
responsibility
for
all
of
these
layers
from
the
customer,
so
the
image
the
customer
deploys
to
us
does
not
contain
them.
We
take
full
responsibility
for
them.
A
We
are
becoming
much
more
like
core
OS,
but
right
at
the
moment,
with
the
docker
way
of
doing
things,
images
on
the
hub.
We
cannot
pull
the
machine
images
apart
like
this,
but
we
still
need
to
be
thinking
about
how
we
could
actually
do
it.
So
the
patch
process
that
I
sort
of
speculated
about
involving
the
overlays
isn't
the
only
way
of
doing
this.
If
a
customer
could
just
give
us
that
application,
an
XML
file
describing
their
application
plus
a
list
of
dependencies
that
it
wanted
and
we
could
guarantee
this
was
completely
transportable
and
immutable.
A
We
probably
have
solved
the
problem
in
its
entirety,
so
it's
not
impossible
that
something
like
core
OS
is
beginning
by
taking
responsibility
for
the
colonel
could
also
be
taking
responsibility
for
the
operating
system
above
it
and
everything
else.
The
problem
with
that
is
managing
the
dependencies
right
at
the
moment.
When
core
OS
takes
responsibility
for
Colonel,
then
you
have
a
single
kernel.
A
Customers
are
not
going
to
accept
a
single
operating
system
and
a
single
middleware,
so
there's
still
a
parity
mismatch
between
customer
expectations
and
what
we
can
deliver
doing
this
so
I,
don't
ever
believe
that
what
core
OS
is
doing
with
the
colonel
will
necessarily
be
the
solution
to
the
problem.
It
might
be
a
path
we
could
possibly
go
down,
but
it's
not
going
to
be
the
final
solution.
B
A
Okay,
so
the
question
is
predicated
on
the
idea
that
what
happens
if
different
containers
need
different
features
from
the
colonel,
so
one
of
the
things
that
actually
allowed
the
container
revolution
to
happen
was
the
fact
that
Linux
has
a
very
tight
ABI
difference
between
the
kernel
and
the
user
space.
So
with
a
linux
kernel,
I
can
actually
bring
up
a
variety
of
different
operating
systems
in
some
ways
it's
a
bit
of
a
trick,
but
it's
actually
allowed
operating
system
based
containers
to
have
been
around
in
Linux
for
a
long
long
time.
A
So,
if
you've
taken
responsibility
for
your
developing
your
operating
system
in
a
way
that
just
shields
the
customers
from
all
of
this,
they
are
much
less
likely
to
demand
that
the
container
that
you're
running
be
prefixed
to
the
version
of
the
kernel.
You're
actually
running.
The
only
thing
where
a
customer
may
demand
sort
of
different
versions
of
the
colonel
is
the
device
driver
problem.
A
So,
if
you're
taking
a
device
that
a
customer
wants
to
use-
let's
say
the
modern,
the
modern
genre,
is
they
basically
want
access
to
the
GPU
for
running
things
like
Bitcoin,
mining
or
everything
else?
And
the
worry
is
that
an
earlier
kernel
will
not
have
access
in
the
later
kernel.
Will
all
you
actually
have
to
have
from
your
cloud
service
provider
is
a
guarantee
that
the
host
is
running
this
kernel
later,
because
you
know
it
can
provide
your
hardware
and
the
backward
compat
compatibility
guarantees.
A
The
kernel
provides
mean
that
nobody
else's
containers
ever
care
about
this.
So
this
gives
you
a
way,
at
least
with
Linux,
of
categorically
solving
this
problem.
It
becomes
harder
with
other
operating
systems
if
you
actually
run
contamination
across
this
kernel
to
userspace
ABI,
so
an
operating
system
where
you
actually
have
to
upgrade
the
user
space
and
lockstep
with
the
colonel,
it
does
become
much
more
difficult
to
do
this,
but
at
least
there
are
a
set
of
operating
systems
out
there,
for
which
we
can
make
this
guarantee.