►
From YouTube: Webinar: The evolution of cloud orchestration systems from ephemeral to persistent storage
Description
Public clouds, OpenStack, and Kubernetes all started by supporting only non-persistent “cattle” VMs and containers. Over time the cloud orchestration systems evolved to adding persistent storage support. In this talk, we’ll evaluate how different orchestration systems made the same choices and took a very similar path to evolving their storage features and why persistent storage matters.
Presenter:
Boyan Krosnov, CPO @StorPool
A
Okay,
so
good
morning,
good
evening,
good
night,
depending
on
where
you
are
in
the
world,
thanks
for
joining
today's
cncf
webinar,
the
evolution
of
cloud
orchestration
systems
for
ephemeral
to
persistent
storage,
I'm
christy
tan
I'll
be
moderating
today's
webinar.
We
would
like
to
like
to
welcome
a
presenter
boyan
carsonoff
cpo
at
starpool.
B
A
Before
we
get
started
during
the
webinar,
you
are
not
able
to
talk
as
an
attendee.
There
is
a
q,
a
box
at
the
bottom
of
your
screen.
Please
feel
free
to
drop
in
your
questions
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct.
Basically,
please
be
respectful
of
all
your
fellow
participants
and
presenters.
A
B
A
B
Like
you
may
notice
that
everyone
claims
these
things
like,
but
the
difference
with
total
is
that
we
actually
deliver
on
them.
We
don't
just
claim
them.
So
what
we
do
is
a
software
device,
storage
system,
software
defined
storage
system,
it's
api,
controlled.
It's
used
a
lot
in
kind
of
devops
and
sre
kind
of
environments.
It's
strongly
associated
with
new
iq,
as
opposed
to
traditional
it,
and
we
have
a
ton
of
integrations
with
popular
orchestration
systems.
A
B
Of
parts
which
are
relevant
to
the
kubernetes
ecosystem,
so,
as
I
said,
our
product
is
integrated
with
a
number
of
cloud:
orchestration
systems,
openstack
and
cloud
stack
and
open,
nebula
and
even
own
up
and
since
about
a
year
or
less
kubernetes.
So
we
see
some
patterns
of
how
storage
or
persistent
storage
functionality
evolves
in
these
different
cloud
orchestration
systems
over
time
and
in
this
presentation
I'll
try
to
give
you
some
kind
of
correlation
between
these
different
systems,
how
they
evolved
over
time
compared
to
kubernetes.
B
So
here's
my
agenda,
I'm
going
to
talk
a
little
bit
about
cattle
versus
pets,
and
I
know
it's
kind
of
an
old
and
tired
topic,
but
I'm
sure
there
are
some
people
in
the
audience
who
haven't
heard
of
this
concept
and
it
will
be
interesting
for
them
to
understand
it.
I'm
gonna
talk
about
the
separation
of
code
and
storage
and
some
historical
review
of
how
these
things
evolved
in
aws
and
in
openstack
and
in
kubernetes,
and
I'm
going
to
draw
some
conclusions
at
the
end.
B
So
here
we
go
so
first
of
all,
there's
this
concept
of
pets
and
cattle
and
you
can
think
of
pets.
As
everything
that
traditional
it
did
so
these
are
servers
or
pairs
of
servers
like
highly
available
pairs
of
servers,
which
are
unique
systems.
They
can
never
be
down,
they
cannot
be
automatically
deployed,
etc,
etc.
B
So
that
kind
of
one
of
the
main
differences
is
that
in
the
cattle
concept
no
individual
vmware
container
is
precious
to
you.
You
could
discard
it
at
any
time
and
you
wouldn't
lose
functionality
from
from
your
application,
while
in
the
pets
concept,
if
you
lose
a
server,
it's
a
big
deal
and
it
may
cause
down
time
and
it
causes
a
lot
of
people
to
react
to
that
situation,
etc.
B
So
one
thing
you
one
thing
to
understand
is
that
personal
storage
is
not
associated
only
with
pets,
so
so
traditional
I.t
is
pets.
Modernity
and
kind
of
devops
and
sle
concepts
are
mostly
cattle
with
some
small
number
of
pets
and
even
cattle
need
even
some
cattlemen,
persistent
storage,
meaning
that,
because
you
can
bring
up
another
instance
of
your
application,
that
doesn't
mean
the
application,
doesn't
need,
storage
right
and
there's
still,
because
this
transition
to
what
we
call
modernity
or
new
it
is
taking,
is
going
to
take
many
years.
B
There
are
still
many
pets
around
and
because
of
say
my
migrations
of
applications
from
physical
to
virtual
machines
or
from
from
virtual
machines
to
containers
without
significant
rewriting
of
these
applications.
So
so
this
causes
this
kind
of
a
decade,
perhaps
more
lag
of
all
applications
using
the
newer
concepts
of
everything
being
deployed
based
on
a
recipe.
So
infrastructure
is
cold
and
deploying
from
template
and
treating
every
individual
vmware
container
as
disposable.
B
Right
so
in
traditional
iot,
to
give
you
one
example,
code
of
the
application
and
storage
of
the
application
were
separated
on
separate
entities
on
separate
systems.
The
code
would
run
on,
say,
application
servers
and
these
would
be
standard,
x86
servers
and
they
would
host
what's
called
a
multi-tier
application,
so
that
may
have
say
a
database
and
or
business
logic,
tr
or
it
may
have
multiple
tiers,
say
above
that
it
may
have
a
load,
balancer,
etc,
and
local
disks
in
the
servers
would
be
used
just
for
the
operating
system.
B
Sometimes
the
servers
wouldn't
even
have
local
disks
and
persistence
in
the
introduction.
I
t
is
achieved
using
a
sun
or
a
nas,
and
this
these
systems
provide,
above
all,
high
availability
and
longevity
of
data.
So
whatever
happens
to
an
individual
application
server,
it
doesn't
affect
the
availability
or
persistence
of
data.
In
the
storage
system
there
are
shared
systems,
meaning
one
of
these
say.
B
Some
systems
will
be
used
by
multiple
applications
and
in
a
lot
of
cases,
the
same
data
may
be
accessed
by
multiple
servers,
and
this
is
in
both
cases
in
the
some
case
and
in
the
nas
case.
Now
this
concept
of
a
multi-tier
application
and
separating
where
we
run
code
and
where
we
store
data
also
translates
directly
into
modernity,
so
in
modernity
with
this
concept
of
containers,
the
main
thing
we
achieve
with
containers
is
not
is
not
kind
of
separating
resources
or
security
isolation
between
different
application
components.
B
The
main
thing
we
achieve
with
containers
is
packaging
called
packaging.
The
application.
What
does
that
mean
means
that,
instead
of
installing
the
application
as
a
software
package
on
a
standard
operating
system
and
having
to
deal
with
all
the
kind
of
continuously
changing
dependencies
in
that
traditional
linux
distribution
like
say,
redcat,
enterprise
linux?
B
What
we
do
is
we
take
the
application
we
package
it
together
with
all
of
its
dependencies
and
and
we
ship
it
as
one
whole,
so
the
application
and
all
of
these
dependencies
together
in
the
container
image.
So
we
get
rid
of
dev
and
rpm
and
npm
and
pip
etc,
external
dependencies,
which,
which
may
change
over
the
life
of
a
particular
server
and
that's
the
main
benefit
of
using
containers,
and
it
also
kubernetes
and
containers,
give
us
this
concept
of
packaging
whole
complex
applications.
B
So
you
could
have
say
a
helm
chart
which
describes
a
whole
application,
which
is
multiple
containers,
multiple
codes
which
we
didn't
have
in
traditional
it.
So
both
of
these
concepts
are
new
in
this
new
way
of
doing
applications
of
doing
ik.
What's
what's
changed.
Also,
is
that
initially,
in
this
great
new
world
of
everything,
is
going
to
be
a
container
persistence.
B
Replication
state
was
considered
to
be
someone
else's
problem
right,
so
kubernetes
didn't
didn't,
have
internal
mechanisms
of
how
it
could
do
persistence
at
all.
So
it
was
assumed
that
you
have
say
an
external
sql
database
or
an
external
object
store
or
an
external
file
or
a
file
system
or
kind
of
in
a
more
advanced
cases,
an
external
cassandra
cluster
and
over
time,
the
idea
that
we
could
also
take
the
persistence
layer,
the
storage
layer
of
the
application
and
move
it
inside
kubernetes
was
widely
accepted,
and
now
we
have
persistence
in
kubernetes
as
well.
B
So
it's
no
longer
someone
else's
problem,
so
persistence
is
something
if
you
think
the
application
has
several
layers,
and
one
of
these
layers
is
storage.
Now,
storage
is
considered
to
be
part
of
the
whole
application
package.
You
could
say,
and
it
runs
inside
on
the
same
notes
where
the
application
runs
right.
So
in
historically
this
this
pattern
that
a
new
say
cloud
service
or
cloud
orchestration
system
starts
with
the
concept
that
it's
going
to
support
only
cattle
and
it's
not
going
to
have
any
form
of
persistent
storage.
B
He
has
been
seen
a
number
of
times
and
in
amazon's
ebs.
Sorry,
amazon's,
aws
service
started
with
this
concept,
so
these
ec2
virtual
machines
initially
only
had
local
storage,
which
means
that
if
the
physical
host
they
run
on
died,
they
wouldn't
preserve
data
and
then
about
two
years
later,
amazon
introduced
the
elastic
block
storage
service.
B
So
during
these
two
years,
adoption
of
amazon
is
the
amazon.
Ec2
service
was
very
limited
because
it
didn't
support
kind
of
this
external
persistent
storage
layer
or
it
only
supported
external
storage
in
object,
storage,
which
means
for
a
lot
of
applications
means
rewriting
them
or
something
like
that.
B
Over
time
there
were
more
features
added
to
amazon
ebs,
so,
for
example,
even
booting
from
ebs
wasn't
a
feature
in
in
the
very
beginning
when
it
was
released,
creating
snapshots
of
it,
creating
creating
clones,
resizing,
evs
volumes,
etc.
These
are
all
features
which
are
added
after
the
initial
release
of
the
block
for
each
service.
B
So
the
conclusion
here
is:
it's
the
same
pattern
as
aws.
The
service
starts
without
proper
persistence.
Support
and
later
it
has
persistence,
and
my
understanding
is.
It
has
persistence
because
it's
required
by
the
users
of
of
this
cloud
orchestration
system
and
in
kubernetes
we
had
exactly
the
same
pattern,
so
the
first
public
release
was
in
2014.
B
in
2016.
The
kind
of
supporting
stateful
applications
became
an
explicit
project
goal,
meaning
kubernetes
kind
of
there
was
a
public
statement
saying
stateful
sets
or
pet
sets,
as
they
were
called
initially
are
very
important
to
us,
and
we
need
to
support
them.
There
was
some
persistence
volume
support
added
into
the
main
project
under
flex
volumes
and
then
in
28
2018,
which
is
four
years
after
the
initial
release.
B
Similarly
to
openstack
and
aws,
there
were,
there
were
and
still
are,
features
being
added
over
time,
such
as
support
for
raw
block,
instead
of
just
file
system,
support
for
cloning
for
snapshots
for
resizing,
etc.
So
these
are
features
which,
let's
say,
openstack
and
cinder
had
discovered,
are
kind
of
important
for
everyone.
And
if
you
have
an
api
control
storage
system,
you
should
have
these
features
and
in
kubernetes
and
csi
we
are
again
starting
from
scratch
and
adding
these
features
one
by
one.
B
A
B
So
until
we
get
all
applications
converted
to
this
new
operational
model,
there
will
still
be
many
pets
and
paid
pets
definitely
need
persistent
storage.
So,
for
these
two
use
cases
we
need
a
persistent
storage.
So
every
kubernetes
deployment
needs
storage
and
you
all
should
actually
need
a
good
solution
for
that,
because
it's
kind
of
a
very
important
and
integral
integral
part
of
your
private
cloud
or
public
cloud.
B
A
Great
thanks,
boyan
friendly
reminder
to
anyone
listening
in
here.
If
you
have
a
question
that
you'd
like
to
ask,
there
is
a
q,
a
box
at
the
bottom
of
the
screen
here,
we'd
love
for
you
to
submit
your
question
through
there
looks
like
we
are.
We
have
had
a
few
already
come
through,
so
I'll
just
go
ahead
and
start
them.
The
first
one
is:
why
did
store
pool
decide
to
integrate
with
kubernetes.
B
An
integration
with
kubernetes
was
the
obvious
choice
at
the
time
we
we
did
it
and
we
recognize
kind
of
containers
and
kubernetes
is
a
very
important
use
case
and
we
were
always
like
our
product
was
always
strongly
associated
with
new
it
or
modernity,
and
adding
support
for
kubernetes
was
kind
of
very
natural.
For
us,
it
wasn't
some
alien
concepts
that
we
had
to
add
to
the
product.
It's
just
another
api
integration
with
an
orchestration
system
for
us.
A
B
In
addition
to
being
like
a
proper
api,
controlled
storage
system,
store
pool
is
very
strong
in
reliability,
availabilities,
so
especially
if
you're
looking
to
do
a
production
application
on
a
private
cloud
environment
or
if
you,
if
you
want
to
a
service
provider
like
a
managed
service
provider,
for
example,
so
availability
and
performance
are
some
of
our
kind
of
strongest
features
of
the
product
from
day.
One.
B
Yeah,
so
operators
obviously
gives
you
if
you
write
an
operator
it
gives
you
more
control
over
these
stateful
services
right,
so
meaning
you
could
in
the
operator,
you
could
define
a
lot
of
application.
Specific
logic
right,
so
hem
charts
is
a
more
generic
tool.
So
it's
like
a
hammer
and
you
could
apply
that
to
to
running
statement
services,
but
if
you
want,
like
the
best
possible
behavior
of
a
say,
a
database
cluster,
the
best
way
to
do
that
would
be
with
an
operator
instead
of
the
generic
way
with
health
chart.
I
think.
A
B
So
csi
promises
to
to
give
you
like
a
unified
interface
to
all
persistent
storage
systems
and
which
is
twofold
one.
It
defines
like
a
set
of
apis
that
that
are
common
to
all
storage
right,
such
as
creating
a
volume
deleting
a
volume
resizing
a
volume,
etc,
creating
a
snapshot
creating
a
clone,
etc
and,
on
the
other
hand,
csi,
because
it's
like
a
fairly
stable
interface,
has
a
number,
so
tens
of
different
storage
providers
behind
it.
So
if
you
are
as
an
application
developer,
remember
I
mentioned
about
packaging.
B
B
So
this
gives
you
a
lot
of
kind
of
strength
amplification.
Once
you
package
your
application,
you
could
deploy
that
say
with
medium
minimal
modification.
You
could
deploy
that
on
on
different
infrastructure
and
you
could
achieve
that
because
of
csi,
because
csi
has
tens
of
different
storage
plugins
behind
and
it's
some
complexity,
that's
hidden
from
you.
As
a
user
of
kubernetes
yep,.