►
Description
As services move to the cloud many organizations are looking to microservices to streamline development, improve reliability, and accelerate feature delivery. Developing and deploying microservices can have a hidden complexity - data. If you are migrating away from a monolithic service that uses transactions to keep data safe and consistent how do you translate that to a distributed micro-service world? In this tutorial, we will show how to use the Cloud Native Database Vitess to create safe ACID distributed transactions that behave exactly like transactions on a monolithic system, with no additional complexity. Using Vitess's gRPC API we will create an application that pushes transaction state into a client-side object that can live across multiple microservices without any modification to business logic.
Presenter:
Daniel Kozlowski, Minister of Engineering @PlanetScale
A
A
Excuse
me
transactional
microservices,
with
the
test
coordination
without
scale,
I'm
jerry
fallon
and
I
will
be
moderating
today's
webinar.
We
would
like
to
welcome
our
presenter
today,
daniel
kozlowski
minister
of
engineering,
at
plan
at
planetscale,
just
a
few
housekeeping
items
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
your
questions
in
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
A
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
the
code
of
conduct.
Please
be
respectful
of
your
fellow
participants
and
presenters.
Please
also
note
that
the
reporting
on
slides
will
be
posted
later
today
to
the
cncf
webinar
page
at
cncf,
dot,
io
webinars,
and
with
that
I
will
hand
it
over
to
daniel
for
today's
webinar.
B
B
B
There
are
lots
of
problems
that
we
see
people
face
and
as
database
scaling
experts,
we
generally
have
some
advice
for
them
about
what
you
can
do
and
how
you
can
use
the
test
to
solve
those
problems,
but
as
we're
developing
the
product,
the
test
also
brings
some
extra
features
to
the
database
realm
that
are
really
unique
to
the
test
that
allow
you
to
do
some
things
that
I
don't
think
any
other
database
lets.
You.
C
B
B
So
some
of
the
things
that
you're
going
to
see
today
are
brand
new.
The
code
will
be
made
available
and
please
write
down
as
many
questions
as
you
have.
I'm
not
used
to
this
one-sided
talking
thing.
I
really
like
interactions
so
would
love
to
answer
your
questions
as
we
move
through
the
presentation,
but
I
have
to
wait
till
the
end.
So
let's
get
started
first.
What
is
what
do
I
mean
when
I
say
monolith
and
microservice
right
so
a
monolith?
I
generally
would
define
like
this.
B
It
is
a
service
which
may
be
split
into
different
modules,
depending
on
the
size
of
the
service,
depending
on
the
size
of
the
team.
It
may
be
split
apart,
but
generally
the
defining
characteristic
is
it's
built
and
deployed
as
a
single
service
as
a
single
binary,
a
single
process.
So
this
may
be
in
java,
it
may
be
in,
go,
could
be
in
ruby
could
be
in
any
language,
but
it's
going
to
be
one
deployable
that
goes
out
and
it
doesn't
mean
it's.
It's
singular.
There
may
be
multiple,
so
you
are
obviously
following
best
practices.
B
B
B
This
is
really
useful
because
your
application
probably
has
some
transaction
architecture
built
into
it
very
common
for
any
service
that
has
complex
logic
to
require
transactions,
and
so
your
transaction
architecture
may
look
like
this.
It
may
go
to
one
module
which
begins
a
transaction
gets
some
data
that
connection
which
contains
the
transaction
information
is
passed
to
another
module
through
ipc,
and
then
we
can
do
some
more
selects,
maybe
an
insert.
Maybe
an
update.
Finally,
we
will
commit
the
transaction
and
everything
is
either
going
to
happen
or
it's
not
going
to
happen.
B
Well,
what
happens
when
we
move
to
microservices
generally,
the
best
practice
when
you're
moving
to
microservices
is
to
have
an
architecture
that
looks
something
like
this.
You
may
have
multiple
services.
Those
services
will
probably
sit
behind
some
sort
of
coordinator
in
this
diagram.
Here
I
have
an
api
gateway,
but
there's
lots
of
ways
to
do
it
and
you're
still
following
that
great
12-factor
methodology,
so
you're,
not
storing
state
in
your
services,
you
are
pushing
the
state
outside
of
your
service
into
a
database.
B
You'll
find
a
lot
of
different
information
about
how
this
should
be
done,
because
there
really
isn't
a
great
way
to
do
this,
there's
trade-offs
on
either
side.
I
think
the
general
recommendation,
if
you
were
to
ask
a
hundred
people
most
of
them,
would
say
you
do
database
per
service.
This
is
what
we
have
seen
at
planetscale.
As
people
have
come
to
us.
We
have
seen
individuals
going
database
per
service,
so
my
modules
have
turned
into
services.
B
The
defining
characteristic
here
is,
I
can
have
shared
code.
I
can
have
not
shared
code,
but
what
I
have
is
three
separate
deployable
objects:
they're
versioned,
independently
they're
deployed
independently.
I
can
life
cycle
them
independently
and
because
of
that
they're
talking
to
databases
independently.
B
That
causes
some
issues
when
we're
talking
about
our
transaction
architecture,
because
in
the
monolithic
architecture
we
were
passing,
we
were
passing
our
connection
through
ipc,
so
we
could
actually
maintain
the
same
database
connection
and
we
could
maintain
a
transaction
between
right
between
the
different
modules.
As
soon
as
we
moved
to
microservices,
we
lose
that
capability.
You
can't
actually
maintain
the
transaction.
B
There
are
different
databases,
so
you
have
to
do
something
else:
to
have
transactions
or
have
any
complex
business
logic
with
your
microservices,
but
wait
what
if
I
just
use
the
same
database
well,
this
is
not
really
going
to
solve
any
of
your
problems.
What's
going
to
happen.
Here
is
your
independent
services,
while
they
are
still
microservices,
they're
still
versioned
and
life
cycled
independently,
they
now
have
a
shared
external
dependency,
which
needs
to
be
managed
in
unison
with
all
of
them.
So
you
have
a
single
point
of
failure.
B
Also,
while
you
may
be
able
to
have
all
of
your
data
in
one
spot,
nothing
says
that
that
data
is
going
to
remain
consistent
across
multiple
versions
of
your
service.
It's
very
common
in
this
scenario,
for
the
user
service
to
make
a
schema
change,
but
since
the
campaign
service
is
a
different
module,
it
may
not
know
about
that
schema
change
and
all
of
a
sudden,
its
queries
start
failing.
B
So
there's
a
lot
of
hidden
problems
there
and
to
make
matters
even
worse.
You
still
can't
do
distributed
transactions
because
the
different
services
can't
actually
share
that
connection.
Each
different
process
is
going
to
have
a
different
connection
to
the
database
and
there's
no
way
for
those
processes
to
share
that
information.
B
So
what
this
actually
shows
us
is
we've
been
lying
to
ourselves
this
whole
time
right.
We've
said
we
followed
the
12
sec
factor
methodology.
We
said
that
our
services
don't
have
state
it's
all
pushed
out
to
the
database.
That
was
a
lie.
It
was
a
horrible
lie
because
we
had
this,
this
implicit
state
that
we
don't
really
think
about
and
that's
the
connection
our
connection
to
the
database
actually
carries
a
good
deal
of
state
with
it.
B
B
It
is
a
distributed
database
solution,
so
people
will
call
it
a
new
sql
database.
People
will
call
it
a
sharding
system.
People
will
call
it
many
things,
but
what
it
does
is
it
takes
the
traditional
database
and
it
splits
it
up
into
a
couple
different
parts
that
we
can
then
have
behave
in
interesting
ways.
So
every
test
deployment
has
a
few
components
that
it
needs
at
the
very
end
of
a
test
deployment
you're
going
to
have
a
set
of
shards,
you
can
have
one
charge,
you
can
have
many
shards.
B
The
shard
is
just
a
portion
of
your
database.
The
shard
is
going
to
be
made
up
of
tablets
and
each
tablet
is
going
to
have
a
my
sequel
process
that
actually
stores
your
data.
At
the
end
of
the
day,
all
data
in
the
test
is
stored.
On
my
sql
in
front
of
that
mysql
process.
There
is
a
tender
process
which
we
call
vt
tablet.
B
That
is
the
process
that
actually
connects
to
my
sql
and
actually
handles
the
running
of
queries
again,
and
we
can
have
as
many
shrouds
as
we
like
at
any
point
in
time.
One
of
those
tablets
and
one
of
those
my
sql
processes
is
going
to
be
the
leader
of
a
shard,
and
then
there
can
be
any
number
of
replicas
who
are
receiving
updates
via
binary
logs.
The
test
actually
manages
that
relationship
there.
B
It
knows
how
to
switch
between
which
tablet
is
the
leader
and
which
tablets
are
the
replicas
and
make
sure
that
everything
stays
in
sync.
On
top
of
that,
there
is
a
number
of
stateless
gateways.
We
call
these
vt
gates,
you
can
have
as
many
or
a
few
of
them
as
they
like,
and
this
is
where
the
magic
in
this
demonstration
is
going
to
happen.
B
Vtgate
exposes
my
sql
dialect,
so
you
can
connect
to
it
through
port
3306
and
you
can
speak
the
stock.
My
sql
protocol
most
drivers
that
you'll
find
for
most
popular
programming
languages
work
directly
with
this,
as
well
as
the
mysql
command
line
tools
it
behaves
generally
like
you
would
expect
a
traditional
mysql
database
to
behave.
It
takes
ddl
statements,
it
takes
the
ml
statements
and
it
modifies
your
database.
B
There
are
some
other
parts
of
a
test
cluster
that
aren't
really
important
for
this
demonstration.
So
we
will
just
ignore
those
for
now,
while
I'm
still
on
this
page,
it's
important
to
note
that
this
is
a
distributed
database
right.
These
components
are
all
running
on
different
machines.
They
could
be
located
in
different
continents
in
different
data
centers
and
so
to
communicate
between
them.
B
Well,
it
turns
out
that
the
vt
gate
not
only
talks
down
to
the
vt
tablets
with
grpc,
but
it
also
exposes
its
own
grpc
endpoint.
So
the
grpc
endpoint
that
it
exposes
has
a
number
of
different
functions.
They
are
all
defined
in
the
protocol
buffers
in
the
the
test
code
base,
but
the
two
really
important
ones
are
the
execute,
request
and
execute
response.
Vtgate
has
a
rpc
method
called
execute,
which
is
really
what
we're
going
to
be
abusing
to
do
all
this,
and
it
looks
like
you
would
expect
this
request
to
look.
B
There
is
a
bound
query,
which
is
a
query
with
optionally
bound
parameters.
There
is
a
caller
id,
which
is
a
it's,
not
the
authentication
method,
but
it's
actually
a
second
level
of
identification
that
you
can
use
to
sort
of
further
refine.
Who
is
actually
calling
a
specific
query
and
then
there's
that
session
object.
B
Well,
it
turns
out
that,
because
of
grpc,
what
the
test
authors
did
is
they
took
all
of
the
information
that
is
normally
implicitly
shared
in
the
database
connection
and
they
turned
it
into
a
session,
and
so
the
session
object
is
exchanged
like
a
cookie
and
when
the
test
authors
wrote
this
down,
they
probably
didn't
mean
actually
like
a
cookie,
but
when
I
read
it,
that's
exactly
how
you
can
use
it.
So
we
have
this
message,
this
part
of
the
rpc
transaction
that
actually
maintains
all
of
the
state
and
what
originally?
B
What
this
allows
you
to
do
is
this
makes
the
vt
gate
actually
stateless.
If
you
are
using
the
grpc
endpoint
and
if
you
are
maintaining
the
session,
your
vt
gates
contain
absolutely
no
state,
you
can
actually
multiplex
between
them
and
you
won't
notice
any
difference.
So
if
today,
you
are
using
the
the
test
drivers
that
are
written
in
golang
or
the
jdbc
drivers
that
use
the
grpc
endpoint
either
one
of
those
you
can
use
this
grpcn
grpc
endpoint
from
your
programming
language
and
your
vt
gates
will
become
completely
stateless.
B
B
But
there's
nothing
that
says
it
has
to
be
used
that
way.
So,
while
that
is
the
way
the
jrpc
and
golang
drivers
work
we're,
this
is
a
normal
grpc
interface.
We
can
do
anything
we'd
like
with
it.
So
what
if
we
were
to
just
pull
that
even
a
little
farther
out
and
move
it
outside
of
the
service
and
push
it
down
to
the
client,
and
so
that's
what
I'm
going
to
show?
B
I
have
a
theoretical
micro
service
architecture
that
looks
like
this
same
thing,
except
instead
of
having
a
database
per
service.
We
just
have
a
single
the
test
database.
I
know
what
you're
saying
I
just
said:
this
was
a
bad
idea.
It
turns
out
that
it's
not
just
this
grpc
magic
that
allows
if
it
has
to
operate
like
this
there's
also
a
number
of
other
features
about
the
tests
that
make
this
a
really
good
solution.
B
The
ones
that
I
want
to
just
touch
on
right
now
is
that
this
allows
you
to
scale,
because
the
test
has
a
built-in
sharding
and
scaling
solution.
So
you
get
scale
without
complexity.
It
also
has
built-in
management
features.
So
we
can
do
things
like
online
schema
changes.
We
can
do
things
like
transaction
killers
and
query
watchers,
which
help
eliminate
bad
actors
from
bringing
down
your
database
all
right.
So
what
does
this
look
like?
B
I'm
going
to
walk
you
through
an
example
here
using
javascript
that
is
going
to
use
the
grpc
endpoint
and
is
going
to
display
some
of
these
properties.
So
I'm
going
to
switch
to
my
text
editor
and
what
I've
done
here
is.
I
have
written
a
pretty
quick,
typescript
library
here,
just
to
show
how
you
could
pull
the
grpc
endpoint
into
your
programming
language
and
you
could
use
it
to
run.
Queries
like
you
would
on
any
database,
but
then
also
how
you
can
use
it
to
explicitly
pass
state
so
walking
you
through
this
code.
Here.
B
B
B
B
B
B
Well,
this
was
my
lovely
lovely
text.
Editor.
The
connection
code
is
located
here
again,
it's
it's
split
into
a
standard
connection
and
then
a
connection
with
session
and
again
stock
grpc
code.
All
the
the
code
was
generated
with
the
grpc
code
generator
and
then
we
just
wired
it
up
here
again
code
will
be
online.
You
will
be
able
to
see
it.
B
B
B
The
other
thing
that
I'm
going
to
do
is
when
I
am
done,
I'm
actually
going
to
pass
my
session
out
to
the
next
caller.
So
when
a
request
comes
in,
I'm
actually
going
to
check
that
it's
got
a
whether
or
not
it
has
a
session.
If
it
doesn't
I'm
going
to
create
a
new
one
and
then
when
I'm
done
with
it,
I'm
going
to
pass
the
session
back
out
all
right.
B
Well,
what
does
this
look
like
in
practice?
I
have
a
a
sample
javascript
app
here
that
I'm
going
to
run
from
the
command
line.
So
you
can
do
this
one
of
two
ways
you
could
either
do
it
with
complete
user
control.
This
could
be
pushed
all
the
way
out
to
your
user's
browser
and
that's
kind
of
how
I
have
it
set
up
or
you
can
do
it
in
a
microservice
that
microservice
can
just
pass
the
transaction
information
to
other
services
as
it
does
coordination
locally.
B
So
for
the
effect
of
this
demo,
I've
created
a
transaction
microservice
which
will
do
my
begins
and
commits.
So
I'm
first
going
to
ask
for
a
transaction
to
begin
and
then
I'm
going
to
insert
some
data
and
then
I'm
going
to
commit
that
transaction
and
again
this
is
going
to
happen
in
two
separate
microservices.
D
B
Beautiful
all
right,
so
I'm
gonna
paste
this
script.
It's
gonna
do
some
stuff,
but
before
that
I'm
gonna
go
ahead
to
a
mysql
prompt.
This
is
standard
mysql.
This
is
not
anything
special
to
the
test,
although
you
can
see
that
when
I
connected
I
connected
to
of
a
test
server,
so
I
can
say,
show
tables,
hopefully
didn't
drop
my
session
nope
and
I
can
select
star
from
campaign.
B
And
I
don't
have
anything
in
there,
alright,
so
what
I'm
going
to
do
is
I'm
actually
going
to
paste
this
and
all
that
text
that
just
scrolled
past
your
screens
is
me
actually
running
the
the
transaction,
so
I
have
created
transaction.
I
have
inserted
some
data,
and
now
I'm
actually
waiting
at
the
commit
stage
and
what's
really
cool
here
is
if
I
do
that
same
select
it's
empty,
because,
even
though
I
have
inserted
the
data
I
haven't
committed
yet
so
it's
not
crossing
the
boundaries
of
that
connection.
B
If
I
go
ahead
and
commit
the
data
all
right,
my
commit
has
happened.
I've
gotten
back
at
200,
okay,
now
my
data
has
made
it
in
my
transaction
has
been
committed
and
we
can
go
along
and
this
would
work
for
again.
I've
pulled
this
all
the
way
out
to
the
user,
but
this
would
work
inside
the
service
as
well.
B
B
I
can
upgrade
my
services
without
dropping
transactions
without
dropping
any
user
requests,
so
I've
pushed
even
more
of
my
maintenance
burden
off
into
the
tests
and
then
again
the
code
to
use
this
looks
exactly
like
database
code.
In
fact,
it's
compatible
with
a
lot
of
your
orms
and
your
other
tooling
that
you
use
for
your
database
today
with
the
extra
features
that
you
can
pull
in
things
like
this
grbc
endpoint,
to
be
able
to
do
even
more
things
that
you
can't
do
with
other
database
systems.
B
B
So
you
don't
have
to
worry
about
doing
an
all
or
nothing
or
doing
a
database
migration
with
the
tess.
You
can
actually
move
your
monolith
into
microservices
easier
than
if
you
were
to
adopt
a
different
style
database,
but
if
you
use
the
same
database,
you
won't
have
independent
services,
like
I
had
said
before.
The
test
actually
takes
all
the
problems
that
you
would
have
by
using
the
same
database,
and
it
removes
all
of
them.
It
has
built-in
sharding
to
allow
you
to
scale
it
has
built
in
management.
B
Like
online
schema
change
to
allow
you
to
do
maintenance
actions
without
impacting
other
services,
and
then
it's
got
on.
It's
got
protections
built
in
like
query,
timeouts
and
query
throttling
that
will
allow
you
to
use
a
single
database
service
but
make
sure
that
all
the
independent
services
can't
negatively
affect
each
other,
and
it.
A
B
Aside
from
all
that,
by
having
the
test,
you
also
get
additional
visibility
into
your
database.
So
how
I
said
that
I
had
that
caller
id
well
now
I
can
actually
see
which
which
service
or
which
process
is
running,
those
queries
that
are
slowing
down
the
database
or
that
are
causing
my
are
causing
my
response
time
to
balloon.
B
But
you
could
do
the
same
thing
with
cqrs
or
something
like
the
saga
pattern.
This
is
entirely
true
and
actually
what
you're
seeing
here
is
the
same
kind
of
functionality.
You
would
get
with
cqrs
or
saga
you're
getting
for
free
with
the
tests,
so
you
can
have
a
two-phase
commit.
You
can
have
a
multi-shard
best
effort
commit.
B
So
that's
a
little
bit
about
running
microservices
with
the
tess
again.
This
is
not.
This
is
something
that
we
hear
a
lot
of.
It
is
not
necessarily
something
that
a
lot
of
people
are
doing
today,
but
this
is
functionality
that
has
been
built
into
the
test
and
has
been
used
for
a
long
time
like
I
said,
the
golang
and
jdbc
drivers
both
use
this
same
interface
and
they
use
these
same
mechanisms.
It's
just
we're
taking
it
a
step
farther
here.
B
A
Thank
you
very
much
daniel
for
a
wonderful
presentation,
our
first
question.
This
is
my
first
encounter
with
the
test.
I'm
still
a
bit
unclear
what
current
problem
with
my
sql.
The
test
is
trying
to
solve.
If
I
have
a
set
of
microservices
talking
to
mysql
endpoint,
are
there
any
concerns
there?
If
the
sql
client
info
is
stored
in
the
microservice,
are
there
any
problems
with
data
integrity?
In
this
case.
B
So
if,
if
you're
doing
the
you
know,
one
of
the
stock
examples
for
a
microservice
has
always
been
the
online
store
right.
Where
a
user
wants
to
buy
something,
and
so
you
may
have
a
user
service
and
an
inventory
service.
And
then
you
may
have
something
like
a
credit
service,
that's
determining
if
this
transaction
can
go
through.
B
If
you
had
a
single
database,
those
three
would
be
modules
and
that
whole
interaction
would
happen
in
a
transaction.
So
either
the
user's
order
is
going
to
go
through
we're
going
to
check
that
they
have
credit
and
we're
going
to
check
that
they
have
inventory
and
then
we're
going
to
return
back
that.
Yes,
the
order
completed
and
the
user,
the
user's
order
has
happened
or
something
occurred
either
the
credit
was
insufficient
or
we
didn't
have
inventory
so
we're
actually
going
to
roll
back
that
transaction
and
that
order
isn't
going
to
happen.
B
B
A
B
So
the
explicit
session
with
the
tests
is
a
bit
of
a
complex
object.
What
it
actually
does
is
when
the
test
services,
your
query,
the
query
will
come
in
through
the
vt
gate.
Vtgate
has
a
full
sql
parser
in
it,
and
it
knows
how
to
route
your
queries
to
either
a
single
or
multiple
charts,
when
your
client
sends
that,
if
you're
using
the
my
sql
port,
the
connection
is
maintained
inside
of
vt
gate
that
any
packets
coming
across
this
any
packets.
B
For
this
connection,
id
are
going
to
go
back
to
this
client,
but
then,
as
soon
as
it
goes
down
to
the
vt
tablets,
it
actually
switches
to
grpc
internally,
which
multiplexes
all
client
connections
across
a
single
grpc
tunnel
between
the
vt
gate
and
the
vt
tablet
to
keep
everything
in
line.
The
vt
tablet
actually
establishes
a
connection
id
for
every
single
client
connection.
That's
inbound.
B
The
vt
tablet
establishes
a
connection
id
and
it
uses
that
to
pass
information
down
to
the
backing
my
sequel
and
then
return
that
back
to
the
vt
gate,
because
that's
all
multiplexed
it
needs
to
pass
along
some
information
to
the
vt
gate.
So
the
vt
gate
knows
which
mysql
connection
to
return
the
information
to
what
the
grpc
endpoint
does.
B
I'm
just
going
to
pass
this
down
to
my
vt
tablet
and
when
it
comes
back,
I'm
going
to
send
it
back
up
to
the
client.
I
know
that's
not
the
world's
best
explanation.
It's
a
lot
better!
If
you
have
a
whiteboard
or
some
code
in
front
of
you,
so
you
can
see
how
this
is
all
being
wired
together,
but
that
is
how
it
actually
works.
C
B
B
When
you
have
lots
of
transactional
data-
and
you
have
a
very
dynamic
runtime
environment
works
really
well
on
things
like
kubernetes,
because
it's
kind
of
built
for
the
idea
that
at
any
point
in
time
any
single
part
of
a
test
can
go
away
and
your
queries
are
still
going
to
be
serviced
and
that's
it's
kind
of
what
has
led
to
this
kind
of
functionality,
because
it
is
built
with
failure
in
mind
right.
It's
built
to
know
that
at
any
point
in
time
a
single
component
could
go
down.
B
We
have
really
tried
hard
to
push
state
out
and
to
reduce
single
points
of
failure
so
that
almost
any
part
of
your
database
cluster
can
go
down
and
your
transactions
are
still
going
to
be
serviced.
Your
queries
are
still
going
to
be
serviced.
So
when
you
think
about
it,
it's
built
for
sort
of
the
five
nines
uptime
of
very
fast
transactions,
and
that's
you
know
that
lends
itself
to
be
a
little
bit
more
complex.
But
it
also
gives
you
a
little
bit
more
flexibility.
A
B
No
well
there
there
is
locks,
get
established
like
they
would
in
a
standard,
my
sql
database.
So
if
I
did
an
insert
on
a
row
and
then
I
tried
to
delete
all
of
the
data
in
that
table,
the
delete
wouldn't
happen
until
the
transaction
lock
cleared
either
by
committing
the
transaction
or
allowing
the
transaction
timeout
to
occur.
B
But
it's
it
is
not
actually
imposed
by
the
test
it's
imposed
at
the
my
sequel
layer.
So
it's
the
standard,
the
standard,
locking
that
you
would
get
in
a
9odb
database,
there's
many
different
kinds
of
locking,
but
there's
no
additional
locking.
That
happens
because
of
a
test
there's
a
bit
of
a
performance
penalty
and
that
grpc
is
less
performant
than
the
my
sequel
connection.
B
Yeah,
so
there's
a
couple
different
ways:
you
can
do
this
at
the
end
of
the
day.
Schema
updates
are
very
much
up
to
the
user.
So
if
you
want
to
completely
decouple
your
schema
of
your
microservices,
this
gives
you
a
path
to
do
it.
You
can
have
completely
decoupled
schemas
and
interactions
between
those
can
happen
just
at
the
microservice
layer.
So
in
my
example,
I
actually
used
a
join
to
resolve
a
profile
id
to
a
profile
name.
B
However,
the
test
gives
you
some
additional
features
that
mean
you
don't
have
to
do
that,
and
you
can
start
to
really
use
the
power
of
joins
and
use
all
the
sql
things
that
you
would
like,
because
we
can
do
some
things
to
decouple
your
services.
A
little
bit
better,
we
can't
make
up,
for
you,
know
a
user,
creating
a
schema
change
that
isn't
updated
in
code,
and
so
your
code
queries
break,
but
what
we
can
do
is
we
can
make
those
schema
changes
completely
transparent.
B
One
of
the
problems
that
we
see
with
microservices
is
even
if
you
have
robust
testing,
to
make
sure
that
schema
changes
don't
break
independent
services.
What
will
happen
is,
as
every
single
independent
service
releases,
you
will
start
a
schema
change.
Schema
changes
are
generally
lock
the
world
kind
of
operations.
So
if
I
have
a
very
large
table
on
the
order
of
one
to
two
terabytes
and
I
have
to
add
a
column
or
drop
a
column
that
can
take
hours
or
days
where
I
cannot
update
that
table.
B
So,
even
if
you
have
really
good
testing-
and
you
know
that
nobody
is
going
to
change
a
schema
to
break
your
other
services-
the
fact
that
you
now
have
10
different
services
trying
to
make
changes
to
the
schema
means
that
you're
going
to
incur
outages
what
the
test
gives
you
is
things
like
online
schema
change,
so
we
have
been
working
on
and
releasing
online
schema
change
functionality
built
into
the
test.
Historically,
we've
used
external
tools
to
do
this,
but
now
it
is
built
into
the
test.
B
So,
as
you
make
schema
changes,
they
happen
online,
you
can
roll
forwards
and
backwards
between
schema
changes.
I
believe
deepti
can
correct
me
if
that
is
not
built
in
yet
I
believe
you
can
move
forwards
and
backwards
and
schema
changes,
so
you
can
actually
make
your
changes
with
your
services
and
then
be
completely
transparent
to
your
downstream
services,
so
that
frees
you
up
to
version
and
life
cycle
all
of
your
services
independently.
B
A
A
B
B
If
you
have
a
recent
version
of
the
test,
I
believe
you're
going
to
have
to
have
version
80..
It
actually
is
just
an
annotation
on
the
ddl
statement,
which
allows
you
to
trigger
an
online
schema
change,
and
I
believe,
if
you
join
us
on
the
test
slack
channel,
which
is
on
the
screen
now
the
test.io
forward,
slash
slack,
we
can
explain
to
you
in
detail
how
that
whole
process
works
and
how
to
get
started
again.
A
A
D
A
C
B
B
B
D
B
No,
not
really
yeah
it's
I.
I
have
base64
encoded
the
header.
Let
me
go
ahead
and
stop
sharing
my
screen
and
then
try
to
share
my
screen
again.
I
can
show
you
exactly
what
it
looks
like
base64
encoded,
so
again
here
was
that
that
session
that
I
had
ran
at
its
at
its
biggest
here
is
what
the
session
looks
like.
B
C
A
A
A
B
B
My
sql
any
point
in
time,
but
there's
going
to
be
some
things
that
once
you
start
using
the
tests
getting
into
other
systems,
there's
just
not
too
many
alternatives
out
there
right
now,
so
it
really,
if
you're,
using
this
simply
for
the
management
and
some
of
the
extra
features
and
your
database,
your
data
could
be
serviced
by
a
different
mysql
server.
Then
there's
no
lock-in,
you
can
actually
just
turn
the
tess
off
and
you'll.
Have
your
mysql
server
in
the
background
connect
directly
to
it,
your
queries
will
stay.
The
same.
B
A
B
So
there,
yes,
there
is
the
the
there
are
interfaces
where,
if
you
were
to
implement
that
interface
for
a
back
end,
it
would
work
with
that
back
end.
So
dp,
you
would
know
better
than
me,
but
I
think
if
you
were
to
implement
the
query
server,
you
could
pretty
much
put
whatever
you
wanted
behind
that
query.
Server
and.
D
Yeah
but
it
would
be
a
significant
rewriting,
a
significant
portion
of
the
code,
so
there
is
the
interaction
with
the
backend
database
for
management
functions,
which
is
one
part
of
it,
but
there's
also
the
parsing
and
the
parser
right
now
is
a
mysql
compatible
parser.
So
we
would
need
to
build
a
way
of
plugging
in
a
different
parser
depending
on
the
backend
flavor.
B
And
that
the
the
parser,
the
parser
planner
construct,
which
actually
does
most
of
the
work,
because
we
have
a
mysql
database
as
the
back
end.
The
planner
in
the
test
is
going
to
look
a
little
bit
different
than
the
planner.
In
some
other
databases,
we
don't
translate
down
to
like
a
block
fetch
or
to
a
key
fetch.
The
way
some
other
distributed.
Databases
do
where
queries
are
parsed
and
then
they're
planned
down
to
a
key
fetch
and
then
they're
sent
to
the
back
end.
Just
for
a
key
fetch.
A
A
B
B
But
what
we
do
is
we
actually
do
a
full
parse
of
the
sql
query.
So
we
have
a
custom
written
sql
parser,
which
creates
an
ast
and
then
that
ast,
instead
of
again,
instead
of
going
down
to
a
block
fetch
the
the
planner
translates
it.
The
planner
uses
the
v
schema,
along
with
the
shard
information
that
is,
live
updated
from
the
lock
server,
which
is
one
of
those
components
that
we
sort
of
breezed
over
in
the
architecture,
diagram
to
actually
create
a
routing
and
execution
plan.
B
B
We
can
rewrite
it
and
then
serialize
it
back
to
a
query
and
pass
it
down
to
my
sql.
The
exact
steps
of
that
are
no
it's
as
it's
as
complex
as
any
of
your
planners
would
be,
which
again,
I'm
not
the
expert
in
the
actual
details
for
that
hit
up
the
slack
channel,
and
we
can
get
you
online
with
somebody
who
does
know
more
than
me.
A
All
right
well,
thank
you
very
much
daniel
for
all
of
your
time
today
and
thank
you
to
everybody
who
took
time
out
of
the
day
for
attending
today's
webinar.
As
I
said
before,
today's
presentation
will
be
available
later
on
on
the
cncf
webinar
page
at
cncf,
dot,
io,
slash
webinars,
along
with
the
slides
that
were
used
today.
Thank
you.
Everyone
for
joining
us
today,
please
take
care,
stay
safe,
have
a
wonderful
weekend
and
we'll
see
you
all
next.