►
From YouTube: CNCF Webinar - Introduction to Cloud Native Storage
Description
Full details here: https://www.cncf.io/event/webinar-cloudnativestorage/
Bringing all of your applications to a cloud native environment is going to be critical in ensuring you are taking full advantage of what containers can deliver. These environments present an opportunity to optimize your applications, including ones that need persistent data, for any cloud.
Join our webcast and hear from industry leaders about both traditional and modern applications and how they use data. Learn the basics of cloud native storage and how you might make choices about cloud and storage platforms supporting your applications.
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
All
right:
well,
let's
go
ahead
and
kick
it
off.
Welcome
to
the
fifth
installment
of
the
CMC
s
webinar
series:
my
name
is
Arielle
jetty
I'm,
an
ambassador
here
at
the
CNC
I,
also
organized
the
day:
George
City,
kubernetes,
meetup
and
I'm
a
co-founder
at
a
company
called
sac
point
cloud
where
provide
turnkey
to
green
IT
solutions.
A
A
couple
of
house
rules
you're
all
on
mute,
but
there
is
a
chat
window
in
a
Q&A
section
where
I
encourage
you
to
add
questions
and
then
I'll
try
to
find
opportune
moments
to
interrupt
the
group
and
present
them.
We're
also
recording
the
session
and
we'll
be
sending
that
out
to
everyone
after
the
events,
along
with
a
link
to
the
presentation
deck
so
without
further
ado
I'll
hand
it
over
to
mark
we'll
be
taking
it
from
here.
A
B
Thanks
very
much
Ariel
and
welcome
everyone
to
the
webinar
storage
has
changed
a
lot
in
recent
years.
As
the
data
persistence
requirements
of
cloud
native
apps
have
outgrown
the
traditional
enterprise
storage.
This
webinar
provides
an
overview
of
the
evolving
cloud
native
storage
requirements
and
data
architecture.
Well,
we'll
discuss
here
is
by
no
means
exclusive.
Everyone's
requirements
vary
and
we're
fortunate
to
have
a
rich
expanding
ecosystem
of
cloud
native
storage
technologies.
B
Before
we
begin
I
want
to
introduce
today's
speakers.
I'm
Mark,
Walsh,
VP
of
products
and
marketing
at
Diamanti,
joined
by
Eric
on
VP
of
Product,
Management
of
port
works
and
Clinton
technical
director
of
code
by
Dell
EMC,
thanks
very
much
for
the
presenters
and
everyone
who's
contributed
to
delivering
this
webinar
cloud.
Native
storage
is
a
fundamental
part
of
the
CN
CF
reference
architecture,
since
most
applications
require
some
form
of
persistent
data.
B
We
often
hear
about
stateless
micro
services,
and
it's
true
that
stateless
workloads
like
web
and
app
servers
are
foundational
to
modern
cloud
native
apps,
but
microservices,
however,
usually
have
some
dependence
on
Chris
datastores,
whether
they
are
retrieving
your
photo
album
or
confirming
a
restaurant
reservation.
That
data
has
a
lifecycle,
that's
far
beyond
the
momentary,
API
call
or
transaction
that's
executed
by
the
stateless
applications.
Here
in
this
presentation,
we'll
talk
about
modern
applications,
they're
diverse
data,
persistent
needs
and
the
new
approach
is
to
satisfy
those
requirements.
B
There
is
no
one
solution:
data
persistence
used
to
mean
choosing
between
a
limited
set
of
NFS
and
sequel
database
options.
Now
the
cloud
mated
ecosystem
takes
an
extensible
open-source
approach.
You've
got
abstractions
and
plugins
that
gives
users
choice
to
select
the
storage
technologies
that
fits
their
needs
so
Eric
over
to
you.
Thanks.
C
Mark
hi
everyone-
this
is
Eric
pleasure
to
be
here,
I
wanted
to
start
our
story
with
a
real-world
example.
So,
let's,
let's
just
jump
in
and
if
we
start
with
the
premise
that
everything
is
possible.
It's
not
enough
to
say
that
cloud
native
means
it
works
and
not
being
clouded
in
native
storage
means
that
it
doesn't
work.
Instead,
let's
focus
on
some
important
questions,
the
first
of
which
is
avoiding
a
monolithic
architecture.
C
C
What
I
want
to
describe
here
is
a
prototypical
or
an
example
application
and
from
the
user
experience
on
the
left
hand,
side
I
have
users
who
might
be
using
their
mobile
device,
they're
accessing
images,
they're
uploading
pictures
they
can
post
in
the
middle.
They
could
post
and
rate
things
and
drive
locations
and
maps
and,
on
the
right
hand,
side.
There's
a
bunch
of
trends
and
stats
leaderboards
that
make
it
part
of
the
interaction.
C
C
C
What
I
might
describe
here
is
that
I
have
thousands
of
events
and,
if
there's
a
before
the
before,
might
be
something
like
a
batch
processing
where
I
have
a
tons
of
events
coming
in
and
they're
launching
into
a
front
end
and
as
those
front
ends
are
processing
their
data
they're
being
batch
processed
through
a
thin
POSIX
layer,
and
that
batch
process
then
goes
to
my
sequel,
and
so
what
ends
up
happening?
Is
you
start
to
aggregate
and
serialize
the
demand?
C
So,
instead
of
having
that
experience,
if
I
look
at
a
cloud
native
pattern,
what
might
a
cloud
native
present
look
like
and
from
the
cloud
native
perspective?
What
I
instead
expect
is
the
process
the
demand
on
demand
in
a
current
real
world
fashion,
so
from
what
I
can
think
about
there
is
that,
instead
of
having
a
front-end
that
goes
to
a
batch
and
that
batch
goes
to
a
my
sequel,
I
could
let
developers
there
pick
the
stacks
of
choice.
C
So,
instead
of
just
having
two
kinds
of
application
stacks,
they
might
have
Kafka,
and
so
they
could
take
a
message
system
like
Kafka
that
takes
heavy
load
and
then
they
start
to
process
incoming
requests
in
real
time
using
something
like
spark.
So
these
can
become
evolved
into
something
like
a
smack
stack,
but
then
they
start
to
create
these
leaderboards
and
trends
and
they
can
use
Cassandra
to
cache
the
top
users
in
stats
and
they
can
still
use
the
my
sequel
to
bring
it
all
back.
C
So,
instead
of
having
a
serial
experience
where
I'm
going
into
a
front-end
layer,
a
batch
processing
on
my
sequel
I
can
instead
have
this
cloud
native
pattern,
and
this
cloud
native
pattern
means
that
I
have
real-time
response,
a
lot
more
user
interactivity
and
that's
all
enabled
by
the
fact
that
I'm
using
things
like
containers
to
let
developers
pick
the
stacks
of
choice
and
have
the
packaging
that
allows
me
to
have
this
flexibility.
But
it's
important
also
to
have
this
kind
of
density.
Otherwise
all
this
becomes
not
really
possible
in
production.
C
This
ring
times
is
subdividing
the
hosts
resources
and
the
first
iteration
of
the
ring-fence
might
look
something
like
this.
It's
a
useful
bootstrap,
but
as
I
look
at
that
bootstrap.
It's
thinking
about
things
of
how
do
I
create
a
handshake
and
how
does
a
container
on
the
left
and
a
container
on
the
right
get
storage
and
what
I
might
do
are
what
people
have
done
in
the
first
iteration
of
container
storage
is:
do
a
host
mount
and
what
all
that
really
means
is
they
do
this
handshake?
C
They
get
a
bootstrap
and
they
I'm
sorry
they
handshake
and
they
get
the
local
storage
and
this
proto
container
native
approach.
It
doesn't
really
give
persistence,
so
it
kind
of
works.
Your
applications
can
get
storage.
Each
container
can
take
a
portion
of
the
hosts,
but
at
the
same
time
there
is
no
persistence
beyond
the
hosts
existence.
C
So
the
host
reboots
or
dies
I
lose
access
to
my
data
and
since
containers
can
float
anywhere,
it's
important
that
I
have
a
pattern
that
makes
the
lifecycle
independent
and
it
becomes
prohibitive
for
stateful
workloads,
because
they
need
the
ability
to
manage
performance
and
capacity,
and
if
I
have
this
approach,
where
I've
tightly
coupled
the
container
and
the
host
and
the
storage
I,
don't
have
this
flexibility,
that's
important
for
me
in
production
next
slide.
Please.
C
So
this
one
we
spoke
to
will
keep
going
so
the
AHA
here
is
to
give
containers,
persistent
volumes
and
that's
to
say
that
beyond
the
handshake,
how
do
I
get
access
to
storage,
but
the
PV
themselves?
They're
important
becomes
because
they
become
the
persistent
volumes
become
the
building
blocks
for
running
cloud.
C
Natives
and
persistent
volumes
have
to
be
their
own
first-class
citizen
and
they
have
to
live
independently
of
the
host
and
the
container,
because
only
then
can
we
have
the
right
building
blocks
or
being
container
native,
and
it's
important
for
us
to
be
able
to
run
and
keep
the
applications
and
there
George
to
be
portable
across
the
environment
and
in
some
ways
that's
what
container
native
is
enabling
us.
So
it's
an
easy
way
to
illustrate
this
next
slide.
Please
is
to
describe
it
this
way.
The
AHA
or
the
translation
of
container
native
could
look
like
this.
C
It's
persistent
volumes
in
the
bottom
half
this
Volume
one
and
volume
2,
and
these
persistent
volumes
they
could
be
coming
from
a
mesh
of
hosts
and
external
systems
or,
however,
your
provider
implements
but
they're
external
and
these
volumes
have
a
different
life
span
than
the
host
and
the
container
and
we'll
come
back
to
a
kubernetes
example
that
flushes
this
out
with
a
diagram.
But
before
I
do
that
I'd
like
to
turn
it
over
to
our
next
speaker,
Clinton
Kitson
Clinton.
C
D
D
Today,
we've
got
three
major
platforms
in
their
cloud
native
states
that
enable
this
type
of
extensibility
types,
plugins,
first,
you've
got
dr.,
you've
got
mesas
and
you've
got
kubernetes
now,
there's
two
main
ways
to
to
describe
how
this
functionality
and
its
interoperability
works.
The
first
is
the
industry
method
increase
toward
plugins,
and
this
is
a
method
that
kubernetes
still
loses
tries
to.
D
This
is
a
great
approach
in
terms
of
the
user
experience,
because
there's
no
additional
installs
or
thing
for
the
user
need
to
know
how
to
run,
but
it's
difficult
for
the
ignited
codebase,
because
I
mean
all
the
source
plugins
are
encapsulated
inside
of
this
cookie
codebase.
So
it's
a
great
experience,
that's
difficult
in
the
long
term,
there's
also
what
we
call
out
of
tree
stores
look.
D
This
is
a
common
method
that
all
three
dr.,
Michos
and
community,
subscribe
to
and
approach
that
that's
actually
being
further
through
another
initiative
that
we
can
discuss
a
little
bit
later,
but
these
outer
treats
or
eclaim
is
really
to
flavors
of
them.
First
is
the
dr.
volume
driver
interface,
and
this
is
probably
provided
by
way
of
soccer
and
they
still
use
the
same
interface
for
sensibilities,
and
then
there
is
a
flex
interface
for
grenades.
D
So
the
goal
of
this
is
to
do
is
exactly
what
Eric
described
right.
We
want
to
have
this
plug-in
that
interoperate
and
bring
the
volumes
where
they
need
to
be.
We
want
to
enable
the
the
lifetime,
or
we
want
able
to
table
the
data
to
survive
separately
from
the
the
container,
the
pods
that
hosts
any
of
that
container
infrastructure.
D
We
also
want
the
application
itself
getting
define
what
its
requirements
are
per
source,
so
we
want
the
engineers
or
developers
or
operators
will
be
defined
with
the
application.
What
type
of
storage
that
basically
needs
in
order
to
satisfy
the
workload
and
the
last
days
that
we
know
that
the
pattern
we're
describing
here
is
portable
and
in
terms
of
cloud
native,
that's
a
really
important
facet
to
status
and
deposited
in
the
ecosystem.
We
want
to
make
sure
that
we're
portable
across
clouds
we'll
make
sure
reporter
pole
across
container
orchestrators.
D
B
Thanks
a
lot
clean,
so
cloud
native
storage
takes
many
forms,
there's
really
many
different
data
types.
It's
not
just
files
and
sequel
queries
like
you
might
have
had
years
ago,
there's
unstructured
data
and
metadata
streaming
data
logs,
blobs,
right
and
so
every
application.
Every
developer
is
going
to
select
the
data
types
that
are
that
are
most
advantageous
for
the
application,
and
no
single
storage
technology
is
going
to
meet
all
these
needs
all
the
time,
while
also
being
cost-effective
and
effectively
scaling
in
terms
of
performance.
B
Somehow
it
can
be
handled
at
the
application
layer
at
the
middleware
layer.
It
can
also
be
handled
at
the
storage
services
layer.
Sometimes
it's
handling
multiple
layers,
depending
on
what
the
application
requires
in
terms
of
redundancy
and
time
to
recover
from
failures,
then
you've
got
other
services
like
data
reduction,
compression
deduplication
encryption.
All
of
these
can
exist
at
multiple
layers
in
stack.
B
It's
important
to
have
interoperability
because
between
all
of
these
different
layers,
so
that
you
have
choice
about
where
you're
going
to
go
when
it
comes
to
storing
these
these
data
types
there's
also
the
issues
of
consistency.
Some
applications
require
very
strong
consistency.
For
example,
if
you're
handling
someone's
credit
card
information,
you
typically
want
to
make
sure
that
a
glitch
is
not
going
to
cause
a
you
know,
losing
track
of
who
ordered
what
and
what
people
pay
for,
but
some
other
applications
like
storing
photos.
B
It
may
be
okay
to
have
eventual
consistency
where,
as
long
as
the
photos
arrive
a
few
seconds
later,
maybe
a
couple
minutes
later,
that's
going
to
be
okay
for
your
application.
So,
as
with
anything
there
are,
there
are
trade-offs
between
cost
throughput
and
service
levels,
and
so
having
the
interoperable
cloud
native
storage
API
subscriptions,
lets
you
mix
and
match.
B
So
how
do
you
choose
the
cloud
native
storage
approaches
that
are
right
for
your
application
and
extent
approaches?
Plural,
because
most
likely
you're
going
to
choose
multiple
technologies
even
for
single
application,
because
many
applications
have
different
types
of
data
within
the
same
the
same
application.
So
one
of
the
first
things
is
to
recognize
the
difference
between
frequently
accessed
hot
data
and
less
frequently
access
cooler
data.
If
you
can
tolerate
a
dental
consistency
for
some
data
sets,
you'll
typically
save
a
lot
of
cost
and
complexity.
B
However,
your
application
then
has
to
deal
with
that,
so
your
application
has
to
deal
with
temporary
and
consistency
across
location.
It
works
for
some,
but
not
all
right
if
you
expect
to
be
able
to
cut
over
immediately
without
losing
anything.
You
have
to
then
handle
that
at
the
application
level,
if
you've
chosen
a
storage
technology
that
doesn't
have
strict
consistency,
you
know
I
talked
about
financial
applications
before
photos
before
right.
Each
of
these
is
a
trade-off
between
what's
implemented
at
the
storage
services
layer
and
what's
implemented
at
the
application
layer.
B
Some
developers
choose
implement
caching
on
their
own
so
that
they
can
decouple
from
the
underlying
storage
infrastructure,
but
some
applications,
it's
very
difficult
to
to
reinvent
the
wheel
and
try
to
build
your
own
caching.
So
you
rely
on
the
storage
system
to
do
that.
But
the
point
is
that
that
cloud
native
storage
should
automate
an
abstract
that
that
underlying
storage
infrastructure,
so
the
application
isn't
necessarily
tied
to
one
single
vendor
our
technology
and
you
can
choose
where
you
want
to
implement
those
capabilities.
So
just
like
Kermit
was
saying
earlier.
B
A
key
enabler
for
this
is
integrating
with
the
container
runtime
and
the
orchestration
software.
Rather
than
manually
configuring
storage.
The
infrastructure
should
be
managed
automatically.
As
a
consequence
of
deploying
your
containerized
application
and
as
with
other
cloud
resources,
cloud
native
storage
is
going
to
be
cooled
as
to
be
shared
across
multiple
tenants
for
the
maximum
efficiency,
and
so
you
need
to
make
sure
that
you
have
isolation,
and
you
have
quotas
to
that.
One
group
is
not
stepping
on
another
group,
so
all
of
that
has
to
be
managed
intelligently,
enforced
at
the
appropriate
service
level.
B
D
Right
so
now
we
start
to
think
about.
You
know
in
my
environment,
where
I'm
running
whether
it's
in
a
on-premise
cloud
or
in
a
public
cloud
do
I,
have
cloud
native
storage.
Do
I
have
some
storage
that
can
satisfy
what
Mark
is
just
having
there
and
one
of
the
first
things
they
look
for
is,
you
know,
am
I
in
or
interoperable
with
these
cos
and
the
rink
run-pass
there's
a
pretty
easy
way
to
take
a
look
at
this
you
can.
You
can
go
to
the
kubernetes
source
plugin.
D
D
So
interoperability
is
a
pretty
easy
thing
to
take
a
look
at,
and
it's
really
important
to
root,
to
understand
that
you
know
if
you're
running
a
human
in
a
cloud
right
now,
such
as
a
public
cloud,
the
sewer
services
that
are
there,
they
may
actually
satisfy
the
requirements
you
have
for
your
application,
but
you
know
if
they
don't
then
comes
time
to
start
thinking
about
what
a
storage
platform
may
look
like
to
help
satisfy
that.
So
so
you're
going
to
be
looking
at
these
platforms,
there's
some
characteristics
that
you
want
to
keep
in
mind.
D
You
want.
You
want
to
make
sure
that
the
core
capabilities
of
these
platforms
are
advertising
such
as
the
size,
the
volumes,
the
type
of
the
volume,
whether
it's
sitting,
that
disk
or
the
capabilities
of
iOS
that
are
available
to
the
volumes.
We
make
sure
those
types
of
core
capabilities
are
there,
so
you
can
make
them
available
to
empower
your
app
from
a
data
services
perspective.
Your
applications
may
may
benefit
from
snapshots,
replication
and
encryption
any
of
these
key
beta
services
that
we're
familiar
with
the
storage
world.
Those
should
be
available
through
your
or
interoperability.
D
A
platform
that
avocados
role-based
access
control
is
going
to
be
important,
so
if
your
platform
is
able
to
differentiate
access
levels
and
they're
going
to
have
more
use
of
that
platform,
so
as
you
give
to
keep
the
kingdom
to
to
developers,
these
gave
it
easy
to
get
into
your
container
for
castrator
I'm
very
to
limit
at
a
granular
level.
How
much
of
that
storage
platforms
is
available,
whether
it's
the
volumes
or
whether
exercise
only
signal
a
should
be
included
in
this
RDA
see.
You
know
a
really
important.
D
One
is
the
elasticity
of
the
capacity
and
the
performance
as
you
consume,
from
this
cloud
storage
resource,
whether
that's
on
Chrome
or
opera.
You
want
to
make
sure
that,
from
a
consumer
perspective
that
you're
not
limited
right,
that
the
consumer
kind
of
feels
that
there's
just
limitless
capability
of
consuming
data
one
way
or
another,
and
that
you're
able
to
properly
like
meter
that
you
can
make
sure
that
people
are
doing
the
right
thing.
So
I
left
it
is
elasticity
in
these
cloud.
D
Services
is
very
important
and
a
lot
of
point
here:
the
the
lifecycle
and
the
operations
being
automated.
If
you've
got
a
storage
possum
that
you're
using
takes
a
lot
of
manual
intervention
and
that's
likely
going
to
impact
the
elasticity
that
the
consumer
feels
of
that
resource,
you
want
to
make
sure,
as
much
of
it,
driven
through
software
as
possible
to
create
this
cloud
storage
service.
D
There's
some
key
things
to
stay
away
from.
So,
if
you're
looking
for
this
interoperability-
and
you
want
to
get
your
data
to
your
applications,
you
probably
don't
want
to
complex
storage
model
when
we
can
talk
about
this
in
the
form
of
being
hardware
design.
So
a
great
example
would
be
fiber
chat.
Fibre
channel
is,
you
know,
I'm
a
middleman
between
a
storage
platform
and
a
container
host,
and
that
represents
another
resource
that
needs
to
be
automated
in
order
to
make
that
connections
happen.
D
D
You
know
the
mark
to
find
a
lot
of
these
application
requirements
that
that
may
exist,
and
so
you
want
to
take
a
look
at
that
say.
I
may
have
something
that's
interoperable
endorse,
but
maybe
they've
got
Casey
requirements
such
as
snapshotting
or
applications
things
that
my
phone
doesn't
have,
which
is
going
to
cause
me
to
think
about
another
source
problems.
For
my
my
workload
and
then
let's
go
to
one
here.
Is
you
know
in
my
datacenter,
maybe
I'm
thinking
about
it
getting
running
containers
in
a
creamy
field
of
art?
D
So
if
it's
Greenfield,
then
you
probably
don't
have
a
shared
storage
service.
Yet
on
cram
that
you
can
supply
the
word
for
for
your
containers,
you're
going
to
think
about
a
platform
that
can
check
all
these
boxes
so
that
you
can
build
a
shared
source
service
that
you
can
interoperate
with
your
container
house.
If
all
this
place
now,
you're
not
checking
a
lot
of
boxes
with
the
source
platforms.
D
Is
you
have
another
alternative
which
is
going
to
be
very
common
on-premise
to
think
about
whether
you
have
a
virtualization
environment
to
support
a
lot
of
your
back-end
services?
So
if
you
have
fiber
channel
or
you
have
hardware
to
find
things
in
the
data
center,
it's
being
extracted
by
virtualization
that
it
was
a
virtualization
layer
that
can
help
you
in
terms
of
interoperability,
and
that
can
make
it
much
simpler
and
it
can
make
it
a
much
better
experience
for
year
in
terms
so
like
what
okay.
A
A
D
It
because
I
think
the
comparison
would
be
very
similar
as
you
look
at
that
converted,
virtualization
environment
yeah.
What
point
to
my
vm
stop,
stop
scale
might
or
stop,
or
am
I
think,
you're
going
to
find
that
at
at
one
point,
I
think
the
question
is
really
like.
Am
I
acting
officious?
Am
I
acting
additionally
for
all
over
clothes
that
are
introduced,
and
so,
if
I'm
thinking
about
my
cases,
maybe
it's
Cassandra
Cassandra
has
his
own
distributed
data
layer
company
about
running
that
on
top
of
virtualization.
Is
that
the
low
C
matter.
B
I
mean
so
so
every
every
solution
is
obviously
going
to
have
different
different
pricing,
relative
performance
and
escaped
elephant.
O
karna
I'll
answer
that
by
kind
of
continuing
from
the
previous
question
is
that
let's
say
that's
that
your
application
needs
to
be
able
to
store
blobs
whether
it's
you
know
videos,
people
are
uploading
photos.
You
know
cash
receipts
whatever
it
is.
You
can
have
an
option,
for
example,
to
put
push
that
over
an
HTTP
interface
to
an
object
store
without
having
to
deal
with.
B
You
know,
back-end
file
systems,
and
you
have
a
very
simple
HTTP
interface
and
you
may
not
need
to
access
those
blobs
very
often
so
one
question
to
think
about
in
terms
of
if
you're
trying
to
create
a
cost
and
capability,
you
know
do
I
need
that
that
fiber
channel
environment
claim
was
just
talking
about
or
can
I
use
an
object
store,
which
is
going
to
have
many
fewer
requirements
and
dependencies
on
my
application
stack
and
it's
more
portable
I
can
move
it
to
a
public
cloud.
A
private
cloud,
pretty
much
anywhere
I
have
HTTP
access.
B
I
can
access
that
that
object
store
right.
So
what
is
really
different,
I
think
about
climate
of
storage.
Is
that
it's
not
a
one-size-fits-all.
It's
saying
that
look.
My
application
has
a
variety
of
data.
Persistent
needs,
I've
got
infrequently
access,
blobs
that
I
can
put
an
object,
store,
I've
got.
You
know
financial
transactions
I'm
going
to
put
into
my
sequel
database
on
my
block,
store,
I've
got.
You
know,
key
values
that
I'm
going
to
be
looking
up
when
I'm
trying
to
allocate
users
with
Cassandra
right.
So
if
there
are
more
choices,
there
are
more
tools.
B
E
C
A
E
A
How
fast
an
engines
provide
storage
is
I
think
you
guys
touched
on
slightly
along
with
the
idea.
If
something
that
really
interests
me
from
the
presentation
is
the
idea
that
I
have
portability
across
orchestrators
and
so
I
guess,
could
you
can
you
highlight
a
little
bit
Dennis
if
I'm
misrepresenting
your
question
about
what
feels
like
a
comport
ability,
please
feel
free
to
chime
it
yeah.
D
This
would
be
I
think
more
clear,
like
I.
Think
that
the
point
is
great,
that
said,
Sam
and
when
you
say
Sam,
you
tend
to
be
discussing
a
team
of
people
that
manage
a
SAN
within
all
these
different
companies,
and
you
know
what
we're
moving
towards
is
a
highly
automated
environment
for
applications
to
just
automatically
satisfy
their
needs.
We
return
from
a
source
platform,
you
know,
Mark
was
talking
about
the
differentiation
of
data
services
and
how
we're
getting
more
efficient
with
providing
those
in
different
ways
to
help
satisfy
the
apps,
and
that's
definitely
not.
D
You
know
what
Sam
discussion,
but
getting
to
Sam
like.
If
your
concern
is
canteen,
they
may
not
move
as
quick
as
my
developers
needs
to
move.
Then
you
know
what
you
think
about
is
a
like
its
Gannett.
We're
describing,
you
know,
is
there
interoperability
in
place
right?
Are
there
plugins
that
make
it
easy
to
at
least
get
volumes
provision
and
made
available
to
my
container
hosts?
The
answer
is
yes,
and
you
know
you
can
definitely
look
at
the
plum
as
you're
out
there.
So
it
make
you
if
the
answer
is
no
and
you're.
D
You
know
the
Sam
team
takes
next
long-term
permission
to
volume,
etc.
They
don't
give
you
the
right
access
I
think
we
start
to
think
about
it
like
in
your
data
center,
it's
very
likely
that
you
have
a
hypervisor
or
virtualization
involved,
so
you've
got
other
than
abstracting
that
fan.
So
in
that
case,
you
would
have
just
an
advertising.
You
know
tapes
volumes
to
your
hypervisors
and
then,
as
a
matter
of
the
ability,
question
really
have
to
do
with
your
hypervisors
to
the
container
for
straighter,
so
the
ce
o--'s
are.
D
B
Know
one
common
also
there
I
agree
with
that,
and
you
know
vector
dennis,
is
point
around
the
orchestration
software.
You
know,
I
think,
about
interoperability
at
kind
of
two
different
claims.
There's
the
there's,
a
data
format,
an
api,
whether
its
block
storage,
whether
it's
sequel,
query,
an
HTTP
push
or
put
for
an
object
store.
You
know,
there's
that
which
is-
and
there
are
lots
of
interoperable
options
there
right.
If
you
understand
block
transactions
with
linux,
you
can
do
that
on
many
different
platforms.
B
It's
a
very
open
system,
for
example,
saying
with
HTTP
requests,
but
then
I've
been
in
dentists,
you're
also
talking
about
interoperability
at
the
orchestration
level.
Right
and
that's
you
know
back
to
coins
slide
earlier
around
the
plugin
architectures
and
there's
a
lot
of
work
going
on
in
the
CN
CF
and
the
compete
community
overall
to
to
drive
commonality
around
the
control
plane
interfaces
so
that
I'm,
you
know
using
kubernetes
or
I'm,
using
Mesa
or
any
other
solution.
I
have
a
consistent
operational
experience
in
terms
of
well.
B
How
do
I
specify
the
types
of
volumes
and
persistent
resources?
I
need
and
then
no
matter
what
orchestration
I'm
using
I
can
get
that
the
same
way.
Now,
to
be
honest,
we're
not
quite
there
yet
today
there
are
variations
as
you've
seen,
but
the
community
is
working
toward
that
and
I
think
everyone.
You
know
everyone
I've
seen
has
that
interest
to
try
to
to
try
to
make
that
more
uniform
so
that
there
are
fewer
speed
bumps
to
defining
your
persistence
requirements
and
then
deploying
them,
along
with
the
application
and.
D
C
Thank
you
for
that
and
Dennis
I
like
the
question
as
well.
So
let
me
just
talk
about
it
from
what
we
were
describing
earlier
as
the
aha
moment
of
giving
a
persistent
volume
and
what
it
could
look
like
in
kubernetes,
but
also
how
it
provides
that
cloud
portability
and
the
aspects
that
are
also
changing.
And
so,
if
I
think
about
an
application,
and
it
has
Kafka,
I
can
bundle
those
containers
and
pods
and
those
pods
will
need
to
get
volume
so
that
lower
right-hand,
the
persistent
volume
is
the
end
result
that
gets
returned.
C
But
how
do
I
get
there
and
what
becomes
important
is
as
we're
all
discussing
here
about
sand
and
other
forms
of
storage.
This
storage
class
becomes
a
way
to
have
this
abstraction,
so
I
can
have
my
best
stab
read:
storage
class
for
this
set
of
departments
or
the
set
of
use.
Cases
and
I
can
have
different
storage
classes
for
this
provider
and
that
provider
and
that's
represented
in
the
lower
right
in
the
green.
So
what
ends
up
happening
and
why?
This
is
important
that
we
have.
C
But
if
you,
if
you
click
one
more
click
mark,
the
important
thing
here
is
that
this
upper
layer
becomes
the
portability
aspect.
So
I
can
take
this
pod
definition
with
the
PVC
or
the
persistent
volume
claim.
The
persistent
volume
claim
we'll
talk
about.
I
need
8,
gigabytes
of
storage.
It
will
talk
about
the
environments
or
the
important
attributes
for
the
pod,
but
at
the
same
time,
this
upper
box
or
this
10
enclosure
is
portable
across
environments
or
that's
the
intent
here.
C
And
so
if
the
storage
class
happens
to
be
implemented
for
EBS
in
the
lower-left
with
Amazon
or
it
happens
to
be
Google,
Cloud
storage
or
your
vendor
of
choice,
hardware
or
other,
it
becomes
possible
that
I
can
have
the
same
application
portability
and
in
some
ways
that
kind
of
flexibility
is
what
gives
us
the
ability
to
run
in
production
with
developers,
ticking
stacks
of
choices
or
Redis
Kafka
running
that
and
describing
what
they
need
in
the
PVC.
But
at
the
same
time,
infrastructure.
C
Ops
teams
have
some
flexibility
in
terms
of
how
they
satisfy
it,
and
then
your
data
and
someone
else's
data
is
separated.
So
I
don't
have
this
notion
of
this
proto
approach
with
cloud
native,
this
proto
approach
of
being
post
bind
months.
Instead,
everyone
has
its
own
claim
volume
and
that
volume
liz's
independently
of
the
pod
so
I
have
both
the
lifecycle
satisfied
as
well
as
this
operator
versus
developer
separation.
C
C
If
you
click
Next-
and
the
first
step
here
is
that
PVC
is
created
and
that
PVC
says
I'm
looking
for
a
volume
that
volume
needs
to
be
8,
gigabytes
and
I'd
like
it
to
be
of
a
fast
type
or
that
fast
implementation
and
I
can
start
to
decorate
it
with
things
like
labels.
But
at
this
point
a
10
gigabyte
volume
could
satisfy
this
PVC
a
9
gigabyte,
but
this
pot
is
asking
for
at
least
8.
C
So
from
that
approach,
the
application
definition
can
be
run
in
dev
test
and
production,
and
if
I
go
to
the
storage
class
itself,
the
storage
class
itself
will
then
say.
I
implement
this
fast
and
I
have
all
this
provider
specific
provisioning.
That
can
then
make
it
the
best
for
my
ops
team,
but
at
the
same
time
the
application
is
completely
completely
portable
on
the
pod
and
the
PVC
level.
And
if
you
click
one
more
time-
and
this
is
the
last-
is
that
the
persistent
volume
itself
is
the
one
that
actually
gets
satisfied.
C
So
the
persistent
volume
becomes
where
I
write
to
the
application
actually
writes
to
a
persistent
volume
and
that
persistent
volume
in
this
case
is
the
es
or
it
could
be
GCE
TD
or
it
could
be
something
else
now
to
get
higher
levels
of
portability
or
to
have
another
form
of
portability
at
the
data
level.
That's
a
separate
topic,
but
at
least
from
the
application
definition
and
from
the
description
that
I
want
to
bring
into
different
environments.
I
solved
the
control
aspect.
C
Now
the
data
gravity
is
the
next
level
and
that's
a
little
bit
beyond
the
scope
of
this
discussion.
But
in
some
ways
I
wanted
to
highlight
how
all
that
operator
versus
developer
has
been
separated
out
in
a
clean
fashion
in
one
form
and
as
everyone's
pointing
out.
This
is
getting
better
and
refined
as
we
go
along.
Why
do
I
pause
there
and
that's
basically,
my
last
slide
and
I
wanted
to
say
thank
you
to
everyone
and
make
sure
that
we
made
time
for
questions.
A
D
Would
think
of
something
like
I'm,
not
a
technical
expert
on
open,
yes,
but
I.
Think
based
on
the
question,
there's
a
little
bit
of
a
description
done
it
in
there,
but
it
sounds
like
another
storage
platform
that
can
provide
a
layer
of
persistence
on
top
of
any
type
of
storage
resources.
I
think
you're
going
to
find
a
lot
of
platforms
and
murders
out
there
you're
going
to
find
more
and
more
than
being
software
based
and
in
the
future,
you're
probably
define
them
being.
You
know
managed
as
a
cloud
native
application.
D
So
it's
I
can't
really
point
to
a
single
project,
right
now
to
say:
that's
contributing
to
the
future
foundation
of
storage
and
a
cloud
native
landscape.
I
think
that
where
we
are
the
interoperability
and
maybe
use
of
the
cloud
services
that
are
available,
it's
likely
the
most
common
approaches,
but
there's
definitely
a
lot
of
enabling
features
and
capabilities.
The
different
HTML
form
for
our
merchants
to
make
it
more
interesting
to
cater.
A
C
C
C
But
if
I
went
back
to
my
diagram,
you
can
use
stateful,
sets
and
start
to
reuse
a
lot
of
the
same
concepts,
and
so
the
idea
of
the
rolling
upgrade
could
be
the
fact
that
I
set
the
replica
count
and
start
to
change
it
based
on
the
number
that
I
actually
want
to
create,
and
so
that
control
is
possible.
But
now,
in
terms
of
the
actual
data.
C
You're
writing
it
has
to
be
a
separate
control
aspect,
and
maybe
this
is
why
the
open
EBS
question
was
there
is
because
the
staple
set
is
about
the
control
and
how
I
create
volumes
and
start
to
grab
capacity.
At
the
same
time,
that
control
is
not
necessarily
talking
about
how
that
data
is
consistent
from
what
has
been
written
to
disk.
So
that's
possible.
The
open
EVs
question
was
there
is
like
how
do
I
make
sure
the
data
is
there
and
that's
up
to
a
provider
like
an
open
EBS.
So
then
I
would
say.
C
The
unification
of
these
two
topics
is:
how
do
I
take
a
staple
set
put
in
some
layer
that
controls
the
data
and
then
start
to
make
this
rolling
upgrade
and
that
that
would
be
possible.
But
it's
also
back
to
the
topic
of
whether
you're
a
business
with
a
Cassandra,
so
it
will
start
to
work
with
eventual
consistency
with
the
Postgres
that
can
work.
If
you
have
the
ability
to
synchronize
the
data
at
the
data
layer.
D
Basically,
point
to
I
think
in
an
interesting
area
that
you
know
the
cloud
native
storage
space
is
going
to
be
tracking.
Is
the
operator
automation
Network
finding,
and
you
know
how
I
simplify,
that
is
to
say
that
you
know
whatever
to
do
Cassandra
any
of
these
like
distributed
data
layers
which
are
more
complex
to
operate,
there
tends
to
be
kind
of
two
books
that
you
read
about
them.
D
One
book
is
you
know
how
I
what
I
did
to
date,
a
scientist
which
is
how
I
consume
from
something
like
to
do,
and
then
the
other
book
is
how
I
operate
the
thing
as
when
you
say
rolling
upgrade.
You
know,
I
tend
to
be
thinking
about
it
in
terms
of
the
container
storage
platform
and
not
necessarily
the
application
itself,
but
they're
interrelated
topics,
because
I
do
rolling
operate
them
in
container
storage
platform.
D
Automation
is
to
be
you
know,
awareness
that
we're
providing
and
the
interoperability
is
a
storage
layer.
I
think
that
a
really
upgrade
question
like
from
a
basic
perspective.
You
know
it's
going
to
work
fine
today
for
your
simple
ass.
If
we're
talking
about
really
operated
like
the
container
for
the
straighter,
but
from
a
more
complex
perspective
as
I
have
you
know
many
nodes
and
instances
that
satisfy
like
what
the
application
is?
D
B
So,
if
you
have
to
move
the
container,
you
know
if
your
replication
controller
ends
up
restarting
that
container
somewhere
else,
because
the
the
original
instance
has
to
be
killed
for
the
rolling
upgrade.
You
need
to
make
sure
that
that
storage
is
accessed,
regardless
of
where
the
container
gets
spun
up
again.
If
the
storage
system
is
being
is
having
a
rolling
up
right
across
scale
out
nodes
that
stores
just
and
have
to
deliver,
availability
of
those
ATIS,
both
the
control,
api's
and
the
data
api
is
consistently
and
obviously
you
know
that's
a
previous
point.
B
D
Yeah,
you
know
I
think
you
know
this
is
all
pretty
public
information,
a
CFC
and
I
end
up
for
for
vote
at
the
CNCs.
As
a
as
a
project
and
incubated
project
set
up
the
container
networking
interface
producing
a
presentation,
we
showed
a
slide
research
of
a
few
times,
which
should
some
of
the
complexity
of
their
ability
to
data
in
order
plugins
being
in
tree
out
of
tree.
Csi
represents
kind
of
a
industry
of
agreement
with
the
AT&T
network,
traitors
on
what
needs
are.
D
In
mesh-
and
that
is
a
very
much
active
right
now-
there
is
a
working
group
which
is
available
through
CMC
out
the
CVS
towards
working
group
together
with
github
page,
not
complex,
CMC
acted
see,
so
you
can
finally
feel
that,
if
you're
interested
in
participating
in
the
discussion
we're
currently
at
a
zero
point,
one
zero
versioning
of
CSS,
there
is
a
kind
of
an
active
spec
out
there
that
Google
through
kubernetes
and
Mesa,
clear
through
basis
and
and
docker
and
cloud
foundry
I'm
all
actively
participated
in.
So
these
are
making
progress.