►
From YouTube: Keynote: Keeping Your Data in Kubernetes with Vitess - Sugu Sougoumarane, CTO, PlanetScale
Description
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects - Learn more at https://kubecon.io
Keynote: Keeping Your Data in Kubernetes with Vitess - Sugu Sougoumarane, CTO, PlanetScale
An increasing number of applications and workloads are being migrated to and are being built for Kubernetes. It has been sufficiently established that Kubernetes is the platform of the future. However, drilling down will reveal that the most successful of these workloads are stateless, and that the database/storage layers have mostly remained outside. This begs the question: What will it take to run everything in Kubernetes? What are the risks and benefits? In this respect, Vitess has a unique background. Due to the fact that it was built to run on Borg, it was ready for Kubernetes from day one. The best part of this is that many leading-edge adopters ran with Vitess very early on; this resulted in a diverse group of Vitess deployments on Kubernetes, from tiny Vitess installations all the way to JD’s colossal clusters. Organizations that have adopted this approach are reaping many unique benefits such as no vendor lock-in, unified management of infrastructure, and self-service based automations. We will cover all these use cases and go over the details of how these organizations benefited by going all in with Kubernetes.
https://sched.co/YW4L
A
Good
morning,
it's
almost
afternoon
cool
so
since
didn't
start
about
where
he
went
to
school
and
stuff
I
thought
I
should
one-up
him.
You
know
I'm
also
from
Palani
and
and
I
also
tamil
Marathi
and
Hindi
and
French.
Actually,
my
name
is
Melton
French.
That's
why
it
is
it's
kind
of
weird
it's
actually
just
super
modern,
No
cool,
so
talking
about
kubernetes
kubernetes
is
winning
the
platform.
Water
every
day
is
more
and
more
workloads
moving
to
kubernetes,
but
guess
which
workload
is
lagging
behind
a
big
time.
A
Data
bases
people
are
not
moving
data
bases
as
fast
as
they
are
moving
other
workloads,
and
why
is
that?
So
that's
what
I'm
going
to
talk
about
and
why
we
test
is
relevant
to
this
topic.
So
with
us
is
now
a
graduated
project
of
CN
CF
we
graduated
last
November
and
to
graduate
actually
you
go
through
a
pretty
extensive
scrutiny.
They
actually
make
sure
that
the
project
project
has
good
adoption
that
enough
people
are
using
it
and
they
are
not
looking
for.
A
Like
peripheral
uses,
they
want
to
see
production,
workloads,
mission,
critical
workloads,
they
want
to
see
maintaining
a
diversity
and
they
want
to
see
like
prolonged
maintenance,
maintainer
contribution.
Then
they
drill
into
the
project
make
sure
it's
healthy
and
stuff.
So
having
gone
through
all
that,
the
basic
certification
is
that
with
us,
is
actually
a
very
healthy
project
and
deserves
to
be
called
certified
one.
So
what
is
with
us?
We
test.
First
of
all
is
a
cloud
native
database.
So
we'll
definitely
talk
more
about
what
that
means.
A
A
It's
based
on
my
sequel,
which
means
that
if
you
are
running
on
my
sequel,
it's
quite
easy
to
move
to
the
test.
So
if
you
go
to
google
and
search
about
like
what
is
cloud
native
you'll
find
like
a
lot
of
definitions,
the
problem
is
many
of
them.
Most
of
them
are
like
kind
of
abstract
and
to
me
there's
a
much
simpler
way
to
look
at
it.
If
it
runs
on
kubernetes,
it
is
cloud
native,
so
Vitas
says
it
is
cloud
native,
which
means
that
runs
very
well
on
kubernetes,
and
here
we
have.
A
This
is
another
thing
everybody
is
showing
tweets,
so
I
should
also
show
tweets.
So
Kelsey
says:
don't
move
stateful
workloads
kubernetes,
you
are
going
to
regret
it.
So,
on
one
side
with
that
says,
you
should
move
stateful
workloads
to
kubernetes
and
kelsey
is
saying
something
else.
What
gives
who
is
right?
So
we
both
are.
Let's
talk
about
why
Kelsey
is
right,
so
what
he
is
saying
is
you
cannot
just
take
my
sequel
and
put
it
in
kubernetes
and
expect
it
to
work.
A
If
you
do
that,
you're
going
to
have
a
bad
experience,
lose
data
that
kind
of
experience.
So
why
is
that
so
reason
is
because
kubernetes
was
designed
mainly
keeping
stateless
workloads
in
mind,
so
stateful
workloads
are
kind
of
an
afterthought,
and
because
of
that,
you
cannot
just
take
databases
and
run
them
easily
in
kubernetes.
So
in
such
an
environment,
how
did
we
test
managed
to
overcome
these
obstacles
and
still
call
itself
cloud
native?
There
was
actually
a
lot
of
debate
when
we
test
went
to
CN
CF
and
say
that
we
are
cloud
native.
A
We
had
to
actually
show
a
lot
of
data
points
to
prove
ourselves
to
be
cloud
native.
So
there's
one
historical
reason,
which
is
where
we
test
came
from.
So
we
originally
built
with
tests
at
YouTube.
We
were
on
bare
metal
and
eventually,
after
Google
borders,
we
had
to
move
that
work
load
into
Google's
Borg.
The
Google's
Borg
is
Google's
private
cloud.
A
It
is
actually
the
predecessor
for
kubernetes
and
guess
what
Google's
Borg
is
also
not
friendly
to
stateful
workloads,
and
it's
not
a
coincidence
that
kubernetes
is
the
way
it
is
given
that
it
came
from
world.
So
how
did
we
manage
to
run
with
us
in
Google's
work
when
it's
not
friendly
to
stateful
workloads?
We
ran
it
as
if
it
was
a
stateless
application
and
I'll
talk
about
how
we
did
that.
So
the
fact
that
we
ran
in
Google's
work
when
kubernetes
came
out,
we
were
ready
for
it.
A
In
fact,
we
announced
that
we
TAS
is
ready
for
kubernetes
before
kubernetes
1.0
was
out,
but
the
best
of
all
this
is
we
kept
it
open
source,
and
you
can't
imagine
how
that
hard.
That
is
to
keep
something
open-source
while
running
inside
Google
the
number
of
proprietary
api's
in
Google
enormous,
but
we
built
an
abstraction
layer
for
each
and
every
one
of
those
things,
so
that
allowed
us
to
keep
with
us
an
open
source
project.
A
A
They
don't
seem
to
go
together,
but
that's
basically
what
we
did
with
us.
How
did
we
do
it?
So
we
ran
actually
every
with
a
spot,
ran
on
emptied
or
emptied.
Er
means
ephemeral.
Storage,
ephemeral,
storage
means
that
if
kubernetes
takes
your
part
down,
it
wipes
your
data.
So
how
do
you
run
a
database
where
every
time
a
part
goes
down,
all
your
data
is
wiped.
A
So
what
we
did
was
we
ran
enough
number
of
replicas
and
enable
this
feature
in
my
cycle
called
semi
sync
replication,
which
ensures
that
before
a
commit
is
acknowledged
at
least
one
other
replica
has
the
data.
So
if
a
master
goes
down,
we
know
that
data
is
somewhere.
All
we
have
to
do
is
figure
out
which
replicas
that
is
promote
that
as
the
master
and
continue
serving
and
then
build
this
failover
mechanism
when
something
goes
down,
actually
do
all
this
failover
without
losing
downtime
and
sometimes
that's.
A
This
is
actually
some
of
the
things
when
you
run
in
the
cloud.
There
are
situations
that
you
don't
usually
encounter
on
well
stable,
bare
metal
situations,
sometimes
there's
network
partitions,
you
can't
reach
the
old
master,
but
you
still
need
to
serve
right
traffic.
What
did
we
do
in
that
time
say:
okay,
replicas!
You
are
now
the
master
forget
about
that
one
and
when
that
happens,
there's
two
masters
that
try
to
report
themselves
as
being
master,
so
we
had
to
write
logic
to
actually
detect
who
the
correct
master
is
and
actually
ignore
the
imposter.
A
A
No
I
think
this
is
going
to
work
for
us,
so
in
2018
this
was
the
quote
that
came
out
of
slack
about
the
test.
Then
they
move
more
workloads
and
it
kept
scaling.
They
got
them
really
really
excited.
Now
you
can
see
the
change
in
the
tone,
so
this
is
actually
testimony
to
how
trusted
with
us
is
and
how
much
they
love
it.
A
In
fact,
even
last
week
they
published
a
blog
post
and
they
said
that
with
us
is
one
of
the
revolutionary
technologies
that
helped
slack
move
forward
in
business,
so
JD
calm,
so
I
talked
about
JD
dot-com
in
the
beginning.
Now,
let's
see
I'm
going
to
reveal
the
number
they
have
about
4,000
key
spaces,
and
that
translates
roughly
into
about
30,000
parts
and
they're
QPS
on
singles
day
was
35
million
QPS.
A
So
you
can
say
that
that's
massive
scale,
but
then,
on
the
other
hand,
there
is
nozzle,
which
is
actually
just
a
startup.
So
why
would
a
start-up
use
something
like
with
this
know?
They
used
with
test
because
they
wanted
to
run
all
in
kubernetes
and
that
actually
is
a
good
decision
and
I'm
just
going
to
tell
you
why.
So,
as
your
gives
them
a
good
deal,
give
them
a
good
meal,
they
said
well
good
pricing,
lot
of
credits,
so
they
ran
actually
their
software
on
aks.
A
But
then,
after
a
while
Google
Cloud
countered
that
this
happens
all
the
time,
what
did
they
do?
They
just
pack
their
bags
and
move
to
Google
Cloud
in
one
hour,
there's
actually
a
talk
by
direct
Perkins.
You
can
find
it
online,
and
that
is
what
you
get
if
you
move,
if
you
run
everything
in
kubernetes,
no
vendor
lock-in
anytime,
you
want
you,
can
just
pack
up
and
go
and
there's
no
vendor
that
can
hold
you
hostage
with
their
custom
features.
A
So,
in
other
words
conclude,
my
message
is:
if
you
are
moving
to
kubernetes,
don't
leave
your
data
behind,
keep
everything
with
you
and
the
benefits
are
huge.
So
we
test
has
a
very
healthy
community.
We
are
like
vibrant
excited
set
of
people.
You
can
see
here,
people
from
India
people
from
Venezuela
Canada
all
over
the
world
and
we
are
growing
so
you're
most
welcome
to
come
and
join
us.
If
you
go
to
Vitas
dot
IO,
you
can
actually
on
top
left
on
top
right.
There
is
a
button
you
can.