►
From YouTube: Storage WG Intro – Ben Hindman, Mesosphere, Clint Kitson, VMware & Quinton Hoole, Huawei
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18)
Storage WG Intro – Ben Hindman, Mesosphere, Clint Kitson, VMware & Quinton Hoole, Huawei (Any Skill Level)
The storage working group has been collaborating on all things storage in the cloud native eco-system. This session includes a panel and review of some of the basics about the working group and some general patterns that they are focused on.
About Quinton
Quinton is currently Technical Vice President of Cloud Computing at Huawei. Previously he spend five years at Google, where he was an Engineering Lead on the Kubernetes team, and Technical Lead and Manager of Ads Serving SRE. He was also the founding engineer of the Amazon EC2 cloud computing project (2005-2009) where he lead much of the early design, implementation and operation. As a lead engineer at Nimbula (a startup that was sold to Oracle in 2012), lead the design and development of their Cloud IAAS product (both private and public cloud). His experience prior to EC2 includes telecommunications (call center switches, CTI systems, mobile billing systems), financial (data exchanges, point-of-sale systems), travel (internet booking systems, airline and hotel reservation systems) and mobile (aviation GPS navigation, banking etc). Quinton is also part of the 15 member kubernetes steering committee.
About Clint
N/A
About Ben
Ben Hindman is one of the creators of Apache Mesos, a platform for building and running resource-efficient distributed systems at scale. Ben started working on Mesos as a PhD student at Berkeley before he brought it to Twitter where it runs on thousands of machines. An academic at heart, his research in programming languages and distributed systems has been published in leading academic conferences.
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
So
you
guys
are
in
the
swg
intro
session,
so
the
storage
working
group
under
the
CNC
F
we've
actually
got
a
panel
for
you
guys
today.
So
I'm
gonna
start
with
a
little
intro
of
what
the
sob
is
all
about.
What
we've
been
doing
over
the
past
year,
some
the
projects
that
we've
been
talking
about
a
little
bit
of
landscape
and
then
we'll
do
a
a
panel
that
the
Ben's
gonna
help
us
moderate.
A
So,
first
of
all,
the
storage
working
group
I
started
about
a
year
and
a
half
ago
or
so
and
CNC
F
and
we
were
meeting
bi-weekly.
And
so
you
know,
if
you
get
anything
from
this
presentation,
the
takeaway
is
please
join
us.
Please
contribute
if
you're
interested
in
chatting
about
anything
storage
within
the
CNC
F
landscape
like
please
come
join
our
meeting.
If
you're
interested
in
presenting
anything
storage
and
you've
got
you
know,
topics
or
projects,
so
you
may
think,
are
they
you
think
are
interesting
to
the
community?
A
Then
we'd
love
to
hear
about
them
within
the
working
group.
So
this
is
the
way
that
you
engage
us,
whether
it's
through
the
the
github
repo
or
through
our
Google
Groups
write.
All
these
different
ways
are
places
that
we're
here
kind
of
listening
and
and
collaborating
we've
got
a
actually
really
good
collaboration
from
some
of
the
biggest
names
or
you
know
some
of
the
names
and
a
lot
of
you
guys
probably
recognize
within
the
storage
industry,
so
whether
it's
doTERRA
del
diamante
docker,
you
can
guys
can
see
the
list
there.
A
A
So
why
is
storage
critical
I
like
hey?
If
we're
talking
about
cloud
native,
you
know
the
perspective.
If
you
rewind
the
clock
like
four
years
ago
was
hey
cloud
native
is
just
about
stateless
right.
It's
about
running
micro
services
right!
It's
about
like
these
new
ways
of
running
applications
that
ended
to
be
stateless
and
the
reality
is
that
you
know
there
is
safe.
All
right
like
if
you're
gonna
build
a
an
application,
you're
gonna
move
it
from
a
monolith
to
a
micro
service,
there's
a
certain
aspect
of
that
application
that
stores
data
somewhere
right.
A
So
if
you
forget
about
that
problem,
right,
you're,
just
shifting
the
blame
or
shifting
the
problem
to
some
other
team,
so
at
the
end
of
the
day
like
if
you're
gonna
rebuild
your
app,
if
you're
gonna
focus
on
these
cloud,
maven
environments-
you
have
to
have
like
comprehensive
lends
to
doing
that.
So
you
have
to
think
about
state.
So
the
second
point
here
is
that
you
know
that
there's
tons
of
patterns
within
cloud
native
and
portability
is
actually
one
of
those
patterns
that
we
want
to
enable.
A
So
if
you
don't
think
about
state-
and
you
just
rely
on
a
certain
other--
team,
then
you
can
only
move
that
application
to
wherever
that
team
supports.
So
we
want
to
think
about
portability
as
a
key
key
aspect
and
when
we
make
sure
that
we
enable
applications,
we
enable
them
to
run
in
any
cloud
that
you
want,
and
then
the
last
point
here
is
that
you
know
in
cloud
native.
A
Interoperability
is
key,
and
if
we
have
applications,
we
want
to
make
sure
that
you
know
many
of
the
applications
become
relevant
relevant
to
these
cloud
native
environments.
So
you
know
the
patterns
of
like
dynamically
managing
applications.
We
want
to
make
sure
that
we
can
actually
do
that
for
all
types
of
applications,
not
just
the
stateless
ones.
So
a
couple
of
few
key
points
and
I
think
the
the
biggest
one
here
is
we're
gonna
expand
the
relevance
of
all
these
key
innovations
that
cloud
natives
bringing
to
our
applications,
especially
when
it
comes
to
persistent
apps.
A
So
the
the
goal
of
storage
within
the
CN
CF.
In
order
to
drive
the
ubiquity
of
storage
ubiquity
of
cloud
native
computing,
the
CN
CF
intends
to
enable
a
thriving
storage
ecosystem
that
is
vendor
and
platform
neutral
and
interoperable
for
applications
all
right.
So
we
want
to
make
sure
that
all
types
of
storage
projects
are
thought
about
within
the
CN
CF
landscape,
and
we
want
to
make
sure
that
we
essentially
create
a
view
of
the
world
that
incorporates
all
of
them.
A
So
what
is
the
mandate
for
the
sword's
working
group?
The
the
TOC
within
CN
CF
have
given
us
these
three
key
things
that
we're
trying
to
focus
on.
The
first
of
all
is
to
create
this
common
body
of
knowledge.
So
we
want
to
clarify
the
terminology
and
the
landscape
of
different
components
that
make
storage
successful
within
cloud
native.
A
The
second
is
that
we
want
to
compare
the
components
and
see
how
they're
used
in
different
cloud
environments,
so,
whether
it's
on
Prem
off
Prem,
whether
it's
across
different
types
of
clouds
or
whether
it's
just
the
key
fundamental
technology
of
you
know,
is
it
a
key
value
story
as
a
relational
database.
We
want
to
define
like
what
all
this
types
of
storage
are
within
this
to
to
be
able
to
place
them
in
the
landscape,
and
the
last
key
point
is
that
we
want
to
compare
and
contrast
the
different
properties
of
the
storage.
A
So
in
cloud
native
there
may
be
certain
things
that
are
more
important
like
what's
the
availability
of
my
app,
especially
if
I'm
gonna
choose
a
cloud
service
to
run.
My
persistent
application
on
top
of
I
probably
want
to
know
like
what
the
availability
constraints
are
and
what's
gonna
be
important
for
that
application.
So
we
want
to
comparing
entraps
and
different
technologies
and
then
look
at
some
of
the
properties
across
these
technologies
to
figure
out
like
where
are
they
on
the
cloud
native
ecosystem?
A
And
so
those
are
the
key
things
that
you'll
see
the
actual
working
group
approaching
moving
forward
so
projects.
The
other
thing
that
we're
doing
in
order
to
kind
of
like
round
out
our
our
view
of
storage
and
cloud
native
is
that
we're
constantly
reviewing
and
hearing
from
different
projects
from
the
community
so
up
here
is
a
list
of
the
projects
that
we've
actually
heard
from
in
the
past
year.
If
we
look
at
this
list
CSI,
you
know
that's
a
container
storage
interface.
A
You
know
we
heard
from
that
earlier
in
the
year
or
last
year,
rook,
which
is
now
a
CN
CF
project
presented
to
us.
Rex
Dre
took
the
pink
app
so
all
types
of
different
projects
and,
if
I,
just
kind
of
like
classify
somebody's
real,
quick
you've
got
projects
that
are
interfaces
for
interoperability,
such
as
CSI,
you've
got
projects
that
are
storage
platforms
and
maybe
that's
database
storage
platforms,
and
that
would
be
a
pink
cap
and
tick.
A
V
you've
got
newer
storage
platforms
for
containers
such
as
dot
mesh
and
open
the
EBS,
and
then
you've
got
even
Vitesse,
which
was
discussed
today
within
the
keynote,
which
is
like
a
sharding
technology
for
a
database
technology
or
for
my
sequel.
So
the
project's
all
kind
of
range
storage
related
that
we've
heard
from
this
year.
A
So
storage
is
a
kind
of
a
critical
resource
when
you,
when
you
break
down
the
infrastructure
components
in
these
cloud
native
environments.
On
the
on
the
left
side,
you
can
see
that
the
storage
really
integrates
directly
and
works
with
the
orchestration
and
management
components,
but
also
with
the
layer
below,
like
the
the
run
I'm
component
and
then
on
the
right
side.
There's
a
few
key
things
that
we
think
about
with
storage
and
cloud
native:
one
is
the
volumes
and
drivers,
local
storage
management
and
remote
storage
access.
A
A
Here's
a
kind
of
an
how
we'd
like
to
think
about
the
different
types
of
storage
that
will
be
discussing
within
the
within
the
working
group.
If
you
go
kind
of
north
and
south,
you
look
at
the
the
way
that
people
tend
to
think
of
volumes
or
our
traditional
POSIX
based
storage,
POSIX
or
LBA
based
storage,
and
this
is
where
a
container
is
actually
like
reading
and
writing
blocks
down
to
files
that
are
provided
by
way
of
a
file
system.
Alright,
so
the
volume
aspect
of
storage
is,
is
one
key
thing
to
think
about.
A
If
you
go
east
and
west,
then
we
also
have
other
types
of
storage,
and
that
includes
data
services,
so
higher
order
data
services
like
sequel,
no
sequel,
log
streaming
right.
Those
are
all
also
storage
services
as
well
that
we
care
about
so
whether
it's
east
and
west,
and
using
the
networking
stack
to
go
out
to
another
service
that
may
be
provided
by
a
cloud
or
maybe
you're,
running
yourself
or
whether
it's
north
and
south,
going
down
to
disks
and
volumes
and
NFS
shares
those
are
both.
Those
are
both
like
relevant
targets.
A
As
we
talked
about
storage
and
cloud
native,
there's
a
few
key
patterns
early
on
that
we've
identified
within
a
storage
working
group
that
can
help
us
understand.
You
know
different
components.
I
think
one
of
the
most
important
patterns
is
interoperability,
so
we're
not
talking
about
like
stacking
data
services,
right
we're
talking
about
just
inter
operating
across
data
services,
a
lot
of
these
aspects
or
a
lot
of
these
components,
and
so
the
interfaces
that
are
defined
and
become
really
critical.
A
To
make
that
happen,
we
want
to
make
sure
that
the
the
platforms
in
cloud
native
storage
are
self-service,
so
the
expectation
from
a
user
experience
perspective
is
that
you
know
if
you
have
someone
who's
gonna
consume
an
application
that
they're
able
to
define
what
type
of
storage
that
application
needs
and
that
you
know
on
the
backend
as
a
storage
platform
is
servicing.
The
application
that
is
able
to
provision
and
make
that
storage
available,
so
self-service
is
a
key
pattern.
I
talked
about
interfaces
a
little
bit
without
interoperability.
A
The
next
one
here
is
API
frameworks
and
tools,
so
in
terms
of
building
the
tool
or
the
plugin
that
helps
you,
interoperate
with
storage.
Sometimes
frameworks
can
be
helpful
and
these
frameworks
can
actually
show
up
as
tools.
So
we
want
to
try
to
classify
and
understand
the
ecosystem
with
with
some
of
these
key
heat
patterns,
as
we
get
to
this
next
piece.
We're
talking
about
you
know.
A
So
if
I'm
in
Amazon,
then
maybe
I'm
using
RDS
for
my
sequel
services,
if
I'm
on
Prem,
then
maybe
I'm
using
the
tests
to
run
my
my
sequel
services
right,
just
both
both
types
of
patterns,
whether
you're
operating
yourself
or
you're,
using
an
external
service
or
both
relevant
and
then
there's
the
storage
access
method.
So
how
am
I
actually
accessing
the
data?
What's
the
protocol
that
I'm
using
to
make
my
connect
my
application
to
to
the
storage?
A
This
is
one
of
the
ways
that
we're
looking
at
the
landscape
in
terms
of
those
different
components
or
patterns
from
the
top
you've
got
your
container
Orchestrator.
The
next
level
down
is
the
interface
between
the
CEO
and
the
storage
system.
So
you
can
see
that
we've
defined
some
of
the
key
projects
such
as
CSI,
the
docker
volume
driver
interface,
the
Flex
volume,
interface
or
native
a
native
interface,
and
you
know
here
you
can
see
on
the
bottom
left
side
where
the
frameworks
and
tools
come
into
play
is
you
know,
maybe
I'm
gonna
build
this
tool.
A
Might
this
plug-in
myself
to
inter
interface,
these
two
components,
or
maybe
I'm,
going
to
use
like
a
framework
in
a
tool
to
help
me
interface,
these
components
together?
What
that
all
ends
up
building
us
is
this
like.
If
I
can
interoperate,
you
know
between
a
cluster,
Orchestrator
and
a
storage
platform,
then
what
I
can
actually
do
is
connect
my
workloads
directly
to
storage
systems,
apparently
all
right,
so
the
the
landscape
is
kind
of
fulfilling.
A
So
what
are
the
the
next
steps
for
the
working
group?
We've
done,
a
I
mean
you've.
We've
we've
heard
from
lots
of
different
projects
relating
to
storage,
I
think
where
we've
all
become
a
bit
more
educated
on
what
this
ecosystem
looks
like
and
what
the
landscape
looks
like.
The
next
steps
is
that
we're
actually
getting
more
direction
from
the
tos,
the
CNC,
F,
TOC
and
they've,
given
us
more
guidance
on
what
they
actually
want
and
we're
gonna
be
working
on
a
a
white
paper
and
actually
giving
some
deliverables
back
to
the
TOC.
A
If
you
guys
are
interested
in
participating
in
a
sort
working
group,
whether
you
want
to
present
the
projects
talk
to
us,
just
join
us
and
collaborate,
we'd
love
to
have
you.
We
actually
have
another
session
of
the
conference
today.
So
there's
not
today,
but
tomorrow,
there's
gonna
be
an
advanced
session
for
the
swg
and
that's
where
we're
gonna
have
a
roundtable
talking
about
the
the
next
things
that
the
SDB
G's
gonna
be
working
on.
A
So
there's
plenty
of
opportunities
to
join
sub
groups
and
talk
about
things
that
are
storage
related,
there's
also
other
sessions
to
hear
from
at
the
conference.
So
so
it's
got
a
couple
of
intercessions
for
kubernetes
and
storage.
I
highly
recommend
you
go
check.
Those
out
Michelle
also
has
a
local
storage
session
on
kubernetes.
So
this
is
about
using
local
storage
resources
for
your
applications.
That
should
be
a
great
one
as
well.
A
G
is
gonna,
be
talking
about
the
container
storage
interface
project,
so
one
of
the
really
critical
projects
we
have
in
the
kubernetes
ecosystem
and
the
container
ecosystem
here
and
then
Shane's
gonna
be
talking
about
the
snapshot,
support
within
kubernetes,
so
other
great
storage
sessions
to
see
with
that,
that's
the
kind
of
like
intro
to
storage,
we're
gonna,
kick
it
off
and
ask
our
panel
members
to
come
up
and
Ben
is
going
to
help
us
moderate.
A
few
questions
all.
B
B
Clint,
do
we
wanna
is
Quentin
back?
Do
we
want
to
go
and
see
if
we
can
pull
him
from
next
door
and
what
wall
wall
Clint's
doing
that
we'll
start
off
with
come
on
up
Steve,
we'll
start
off
with?
Let's
do
some
some
quick
intros
and
let's
also
do
something
outside
of
storage,
that
you'd
love
to
talk
to
anybody
about
at
the
conference
over
the
next
couple
days.
Okay,
who
wants
to
start.
E
Hey
everyone,
my
name
is
Saad:
I
am
co-lead
of
kubernetes
storage,
sig
and
I
work
at
Google,
primarily
on
the
storage
side
of
things
for
kubernetes
over
the
past
year,
or
so
my
primary
focus
has
been
CSI.
I've
worked
closely
with
G
to
co-author
that
and
outside
of
storage
at
this
conference.
I
am
interested
in
learning
about
how
we're
gonna
continue
to
scale
the
kubernetes
community.
We've
got
4,000
attendees
I
cubic
on,
and
so
just
seeing
what
we're
gonna
do
to
grow
to
the
next
4,000
is
going
to
be
a
very
interesting
challenge.
F
Hi
I'm
Quinton
hull,
currently
with
Huawei,
previously
Google,
previously
Amazon
and
many
things
before
that.
My
history
of
the
project,
some
of
you
might
have
run
across
me
in
the
very
early
days
of
AWS,
was
one
of
the
early
architects
and
engineers
on
that
project.
On
ec2,
then
I
did
a
couple
of
startups.
Join
Google
eventually
ended
up
on
the
kubernetes
project.
Few
years
back,
I
guess
pioneered
the
the
multi
cluster
Federation
side
of
the
kubernetes
project.
F
F
I
also
did
a
couple
of
storage
systems
after
that
and
various
startups,
so
I'm
very
interested
in
that
space
and
trying
to
help
out
the
working
group
here
as
best
I
can
pretty
late
comer
to
the
CN
CF
storage
working
group,
but
I'm,
hoping
that
I
can
ramp
up
in
in
the
coming
weeks
to
be
of
some
use
there
outside
of
storage,
as
I
mentioned.
Federation
is
one
of
my
things:
I've
also
I've
got
this
big
passion
at
the
moment
about
distributed
operating
systems.
I
think
we
need
better
ways
to
build
distributed.
F
Applications
at
the
moment
which
we
have
barely
scratched.
The
surface
of
we've
got
bits
and
pieces
of
them,
but
we
don't
really
have
a
coherent
distributed
operating
system
and
outside
of
technology
entirely.
I
grow
coral
reefs
in
my
lounge
and
so
anyone
who's
into
coral
reefs,
fish,
nerds,
Cole,
Mertz
and
they're.
B
Awesome
all
right,
great
and
Quinton
is
actually
going
to
be
I'm,
going
to
be
handing
the
baton
from
Quinton
as
the
TOC
representative
chair
for
the
storage
working
group
and
be
hanging
that
baton
Quinton,
actually
here
so
quentin
great
to
have
you
jump
in
with
the
storage
working
group?
Okay,
so
the
first
question,
I'm
gonna,
ask
a
couple
and
then
we'll
open
it
up
to
questions
from
the
audience.
So
the
first
one
is
CSI
and
the
storage
working
group
were
kind
of
getting
kicked
off
at
the
same
time.
E
So
CSI
kind
of
got
started
around
the
same
time
as
this
group
completely
independent
of
this
group
and
independent
of
the
kubernetes
storage
sig.
It
was
a
collaboration
between
multiple
cluster
orchestration
systems,
including
kubernetes
mezzos
docker
cloud
foundry.
The
purpose
was,
we
were
all
kind
of
facing
the
same
set
of
challenges
which
is
coming
up
with
a
volume.
Interface
kubernetes
had
a
very,
very
powerful
volume,
plug-in
interface,
but
the
problem
was
that
adding
new
volumes
to
this
interface
is
painful,
because
you
have
to
check
code
into
kubernetes
as
developers
of
kubernetes.
E
We
don't
like
this
because
it's
difficult
to
maintain
difficult
to
test.
Also
it
requires
that
we
give
permissions
for
our
kubernetes
components
to
these
volume
plugins,
which
is
not
something
we
necessarily
want
beyond
that.
Develop
developers
of
these
storage
plugins
hate
having
to
check
code
into
kubernetes
to
be
able
to
add
new
volume,
plugins
or
fix
bugs
in
their
plugins.
So
ideally,
we
want
something
that
is
external.
We
could
have
gone
at
this
completely
on
our
own,
but
what
we
realized
is
the
entire
industry
is
facing
this
challenge.
E
Other
container
orchestration
systems
and
vendors
would
really
like
to
be
able
to
write
just
a
single
plugin
that
would
work
everywhere.
So
we
decided
we
would
collaborate
and
come
up
with
something
that
would
be
beneficial
to
all
of
us
and
that's
where
the
CSI
project
was
born.
It
was
born
as
an
independent
project.
E
Normally
projects
are
inducted
into
the
CNC
F.
We
haven't
gone
through
that
process.
Yet
in
order
to
go
through
that
process,
you
have
to
show
viability,
show
adoption
and
various
other
things
that
probably
Quentin
can
tell
you
more
about
I
think
we're
getting
close
to
getting
getting
to
the
point
where
we
can
go
ahead
and
start
that
process.
B
C
Yeah,
there
definitely
are
gaps
now:
they're
they're
gaps
in
what's
slated
to
be
delivered
in
the
early
releases,
but
I
think
we've
had
vigorous
discussions
roadmap
discussions,
so
we're
well
aware
that
these
have
to
be
covered
and
I.
Think
one
of
the
big
things
is
snap
shot
which
leads
into
using
these
snapshots
to
perform
backups.
You
know
the
the
whole
goal
of
these
external
volume
mounts
is
to
support
stateful,
apps
and
stateful.
Apps
aren't
new.
C
What's
new
is
running
them
in
containers
and
people
have
been
using
it
in
virtual
virtualization
infrastructure
and
on
bare
metal
for
decades
when
they
do
this
they're
going
to
usually
find
that
the
keys
to
the
kingdom
are
held
in
these
stateful
apps,
and
you
don't
want
it.
You
can't
afford
for
most
of
these
applications
to
permanently
lose
this.
C
All
of
those
should
be
viable
and
there
are
perfectly
valid
use
cases
for
that
going
beyond
backup.
Those
snapshots
potentially
are
useful
for
replication
scenarios
to
where
these
would
be
actually
kept,
live
at
a
DR
site
based
on
capabilities
of
underlying
storage-
and
you
know
I
think
that's
where
I
see
CSI
going
and
there's
there's
demand,
there's
plenty
of
users
who
are
asking
why
they
can't
have
it
now
so,
but
I
think
it's
better
to
get.
You
know
the
first
version
out
there
in
production
quickly,
rather
than
wait
for
it,
but
there
are
already
people.
D
D
Complex
workflows,
but
as
far
as
so
the
challenge
that
I
see
with
CSI
is
that
one
is
this
might
be
from
the
point
of
vendors
who
are
enabling
CSI.
Is
that
the
level
of
support
from
different
orchestrators
for
storage
and
is
somewhat
different?
For
example,
let's
say
if
a
node
fails
what
should
happen,
whether
the
plugin,
you
know
would
take
care
of
doing
the
cleanup
better?
No,
no
historic
is
attached
on
a
different
note.
D
Kubernetes
has
some
mechanisms
in
this
space,
but
that
level
of
functionality
and
support
is
not
uniform
across
all
the
different
content
orchestrators,
and
that
may
lead
to
more
complications
about
the
CSI
plugins.
You
know
whether
they
should
maintain
any
state,
whether
you
know
and
the
complex
workflows
which
complex
complicates
the
current
design.
So
these
are
some
of
the
things
that
I
think
the
community
should
really
look
into
add
more
depth
beyond
just
API
specification.
B
F
Yeah
I
think
one
of
the
interesting
aspects
of
storage
in
a
cloud
native
context
is
that
there
are
so
many.
You
know,
I
think
in
I'm,
gonna
go
out
on
a
limb
here
and
say
you
know
in
a
traditional,
you
know
single
machine
kind
of
the
environment
or
server
environment,
they're,
a
relatively
limited
number
of
storage
types
that
are
useful
and
they
cover
a
fairly
broad
spectrum
of
use
cases.
But
as
soon
as
you
introduce
this
kind
of
distributed
system
distributed,
storage,
consistency
becomes
a
problem.
Performance
becomes
a
problem.
Durability
becomes
a
problem
there.
F
There
are
a
whole
bunch
of
new
problems
that
kind
of
didn't
exist
to
the
same
extent,
in
in
a
more
traditional
IT
environment
and
as
a
result,
what
I've
seen
anyway,
we
discovered
pretty
early
on
at
Amazon
and
Google's
had
exactly
the
same
experience.
So
I
think
this
is
probably
fairly
universal,
that
you
end
up
with
a
bunch
of
much
more
specialized
kinds
of
storage
and
often
they're
built
in
stacks.
So
you
know:
you'll
have
consistent
key
value
stores
and
eventually
consistent
key
value
stores
and
various
different.
F
You
know
more
specialized
flavors
of
storage
and
figuring
out
how
all
of
these
things
fit
together
and
and
there's
no,
you
know
strictly
vertical
stack
of
these
things.
In
many
cases
you
have,
you
know,
layers
in
the
stack
being
excluded
or
replicated
or
whatever
so
I
think
that's
the
most
interesting
area
and
I
guess
of
that
spectrum
of
things.
What
I
think
is
possibly
one
of
the
more
interesting
areas
is,
is
very
well
defined.
F
Consistency
and
transaction
semantics
in
particular
storage
systems,
so
Google
has
a
project
called
spanner,
which
was
initiated
many
years
ago
and
which
many
of
the
systems
run
on
there
and
there's
cockroach,
DB
and
titanium
DB
and
numerous
other
very
similar
systems,
based
typically
on
consensus,
based
record
replication
and
transactions.
I
think
that
is
a
area
that's
likely
to
explode
in
the
coming
years.
Simply
because
you
know
there
are
tons
of
applications
that
actually
need
semantically,
sound
consistency
and
transactions,
and
a
lot
of
that
is
missing
from
many
of
the
so-called
no
sequel
databases.
C
So
I'm
excited
about
changes
in
a
number
of
areas,
I
think
from
a
storage
provider
technology
thing
things
like
persistent
memory.
That
fits,
maybe
you
know
its
memory-
that
is
persistent
and
can
be
treated
like
SSD,
but
has
performance
characteristics
closer
to
DRAM
should
enable
some
exciting
new
applications.
C
Even
connection
technology,
like
nvme
over
fabric,
has
the
potential
to
eliminate
largely
the
tacks
for
attaching
external
storage
and
separating
from
your
server.
You
know
we're
talking
about
potentially
I've
seen
articles
claiming
that
you
can
expect
sub
10,
microseconds,
latency
penalties
for
that
storage
being
actually
remote,
attachable
and
those
kinds
of
revolutions.
Changelings
I
mean
I,
think
back
to
say,
2006
when
Hadoop
came
out
and
they
challenged.
You
know
for
data
analytics.
This
idea
was
that
they
needed
to
bring
compute
to
the
storage
because
of
the
penalty
to
try
to
separate
it
over
the
network.
C
But
some
of
those
things
that
are
the
basis
for
things
in
widespread
use
have
effectively
been
invalidated
now
by
the
technologies
and
it
takes
a
while
for
the
software
to
catch
up
and
take
advantage
of
that
and
I
think
there's
some
real
opportunities
in
the
whole
streaming.
Data
analytics
stack
to
take
advantage
of
these
and
they're
going
to
revolutionize
things.
C
Container
orchestration
will
be
a
part
of
that.
Some
of
this
revolution
is
already
I,
think
lagging.
You
know
the
things
like
the
12
factors
were
built
to
kick
stateful
out
of
your
containers,
but
as
we
enable
stateful
running
in
containers
with
things
like
the
orchestrators
and
CSI,
you
have
to
reevaluate
some
of
those
decisions
to
do
things
right
and
people
already
I.
C
Think
there's
a
general
consensus
that
monoliths
and
software
are
bad,
that
you
need
to
break
things
up
into
micro
services,
but
most
people
still
have
this
old
stodgy
attitude
that
you
know
they're
perfectly
happy
with
running
a
monolithic
database
because
they
have
the
DBA,
who
was
the
keeper
of
the
kingdom
and
they'll
put
many
things
in
the
same
database
server
just
because
it's
deemed
as
a
resource
that
has
to
be
managed
by
an
expert
and
the
tables
or
the
databases
in
that
server
are
completely
unrelated.
But
it
creates
these
things.
C
We're
doing
an
update
to
that
database
takes
forever.
It
starts
to
look
like
potentially
draining
the
Atlantic
Ocean
into
the
Pacific.
You've
got
five
different
users
of
this
servers,
who
all
have
to
be
contacted?
Hey?
Can
we
afford
to
take
this
down
this
weekend
to
apply
the
security
patch
to
really
take
advantage
of
what
things
like
CSI
and
running
stateful
and
containers?
Are
you
have
to
change
your
attitude
and
take
it
to
the
next
step
to
actually
rethink
some
of
those
decisions
that
you
made
and,
if
never
questioned
for
a
decade
or
more.
B
Some
thanks
Steve,
so
everything
everything
old
is
new
again
it'll
just
keep
repeating
these
cycles,
and
maybe
eight
years
from
now
we'll
be
rearing
compute
back
to
storage,
because
it'll
be
software
will
be
fast
again.
Okay,
so
I
think
we
got
about
five
minutes.
We'd
love
to
open
question
up
to
the
audience.
You
were
the
first
gentleman.
Oh
here
we
go
bringing
the
mic
to
you.
B
G
You
mentioned
persistent
memory
and
I'm
curious
how
persistent
memory
kind
of
plays
into
like
as
persistent
memory
becomes
an
actual
thing,
and
you
know
later
this
year,
we've
probably
things
start
shipping
and
stuff
like
that.
How
does
that
change
with
regard
to
storage?
I
mean?
Obviously,
storage
is
gonna
be
around
for
a
long
time,
but
as
applications
start
moving
towards
persistent
memory.
G
C
Think
it
creates
a
scenario
where
you
really
need
things
like
abstraction
layers
like
CSI,
where
you're
not
dependent,
and
you
isolate
what
the
actual
underlying
technology
is
without
requiring
a
total
rewrite
of
an
Orchestrator
or
even
a
plugin,
so
step.
One
is
to
enable
the
use
of
this
kind
of
transparently
I.
C
Think
already
many
of
the
orchestrators
have
scheduling
mechanisms
like
labeling
taints,
whatever,
so
that
they're
flexible
enough
that,
regardless
of
whether
you're
bringing
compute
to
the
storage
storage
to
the
compute
and
the
in
the
case
where
the
storage
itself
is
containerized
and
potentially
could
move
around
as
I
see
it.
Those
things
are
all
potentially
enabled.
C
So
this
flexibility
of
a
control
container
Orchestrator
enables
an
app
developer
and
it's
up
to
you
if
you're,
an
app
developer
and
by
app
I
have
a
pretty
broad
sense
where
this
could
be
full
and
tier
big
picture
kind
of
stuff
that
you
want
to
gravitate
towards
platforms
that
will
enable
you
to
have
all
this
flexibility
without
rewriting
a
bunch
of
stuff
and
maybe
even
deal
with
this,
not
with
code,
but
with
configuration
information.
So.
D
Adding
to
that,
so
persistent
memory
has
somewhat
different
qualities
that
traditional
hdds
or
SSDs,
where
it's
right
there
access
through
the
block
in
your
face,
7
4,
K
blocks.
These
are
by
that
resemble,
so
you
be
a
different
way
of
accessing
your
storage.
However,
a
lot
of
problems
that
are
present
with
carnation
ease
and
SSDs
like
for
backup
are
still
going
to
be
relevant
for
persistent
memory.
You
still
have
to
manage
backup
to
a
remote
site,
whether
it's
a
remote
node
or
somewhere
else.
You
still
have
to
manage
snapshots
of
your
persistent
memory,
somehow
also.
D
A
B
H
Is
there
a
danger,
and
are
we
aware
that
there's
a
potential
danger
of
trying
to
be
everything
to
everybody,
I
mean
even
just
in
the
storage
space?
There
is
so
much
potential
for
all
these
different
things
that
it
does,
and
half
of
me
is
afraid
that
it
gets
so
complex
in
the
end
that
it
makes
maybe
OpenStack
looks
simple,
and
is
there
a
danger
in
trying
to
be
everything
for
everybody
and
covering
every
niche
use
case,
and
things
like
that.
E
Yes,
absolutely
there
is.
We
recognize
that,
and
we've
purposefully
started
with
a
smaller
set
of
use
cases.
So,
for
example,
Ortolan
pointed
out,
if
you
look
at
the
CSI
interface,
it's
very
very
basic
right
now,
and
that
was
purposeful,
primarily
because
the
idea
is
to
capture
the
essential,
the
bare
essential
neccessity
in
the
API
that
all
storage
systems
are
going
to
need
and
then
slowly
expand
beyond
that.
E
There
we're
going
to
get
to
a
point
where
there
will
be
features
that
apply
to
a
certain
subset
of
storage
that
don't
apply
to
other
kinds
of
storage.
What
we've
done
so
far
is
try
and
design
the
API
in
such
a
way
that
different
types
of
storage
can
expose
the
powerful
power.
If
they're,
you
know,
that's
unique
to
their
system
without
having
to
modify
the
the
interface.
We
do
this
on
the
kubernetes
side,
with
things
like
storage
classes
and
persistent
volume.
E
Persistent
volume
claims
within
the
CSI
spec
you'll
see
that
we
have
opaque
parameters
that
we
allow
passing
through
to
allow
tweaking
of
knobs
on
the
underlying
storage
system,
so
that
the
things
that
are
captured
within
the
interface
are
only
the
things
that
are
absolutely
essential
for
the
full
set.
It
is
going
to
be
a
struggle
moving
forward
to
continue
to
make
sure
that
we
don't
become.
You
know
a
beast
that
is
trying
to
be
everything
and
good
for
no
one
it'll
be
something
that
people
close
eye
on
all.
A
Right,
so
thank
you
very
much
to
the
panel
for
helping
us
out
today.
Good
news
for
you
guys
is
like
they're
in
our
bi-weekly
meetings.
So
if
you
guys
have
any
questions,
you
want
to
chat
more
about
anything
storage
related,
come
work
with
us
collaborate
with
us,
we'd
love
to
have
you
and
to
close
it
out.
I
want
to
thank
Ben
for
the
leadership
of
the
fwg,
taking
that
from
2
to
50
fantastic
work
so
really
appreciate
the
help.
Thank
you.