►
Description
The Service Mesh: Past, Present, and Future [B] - William Morgan, Buoyant
In this talk, we describe the service mesh, a runtime infrastructure layer that’s rapidly rising to prominence with the advent of open source projects like Istio, Envoy, and Linkerd. We trace the evolution of the service mesh model through three-tiered apps and “fat clients” to the modern, sidecar-based implementations, compare and contrast with ESBs and API gateways, and show that, as with most “new” technology, the ideas and principles behind the service mesh have been around for a long time.
About William Morgan
William is the cofounder and CEO of Buoyant, a startup focused on building service mesh technology. Prior to Buoyant, he was an infrastructure engineer at Twitter, where he helped move Twitter from a failing monolithic Ruby on Rails app to a highly distributed, fault-tolerant microservice architecture. He was a software engineer at Powerset, Microsoft, and Adap.tv, a research scientist at MITRE, and holds an MS in computer science from Stanford University.
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
here
we
are
the
service
mesh
past
present
and
future
I.
Don't
even
remember
submitting
this
talk
like
the
tox
emissions
for
coop
Connor.
So
far
in
the
past
that
you
know,
everything
has
changed
in
my
life,
but
I
also
have
to
kind
of
apologize
that
I
have
like
jammed
three
presentations
together
and
they
all
have
totally
different
styles
and,
like
there's
all
sorts
of
weird
animation.
So
this
is
just
gonna,
be
a
disaster
visually
vaguely
a
disaster.
The
audio
track
is
gonna,
be
incredible.
A
Okay,
so
let
me
give
you
thirty,
a
30-second
kind
of
overview
of
who
this
person
is
who's
up
here.
So
my
name
is
William
Morgan,
that's
not
on
the
slides
of
course,
I
used
to
work
at
a
company
called
Twitter
where
I
learned
a
lot
of
things.
Those
things
turned
into
a
lot
of
what
we're
building
at
buoyant
and
we
had
these
two
service
missions.
A
A
Instead
of
docker,
we
used
like
C
groups,
and
we
were
on
the
JVM,
so
we
had
kind
of
you
know,
resource
isolation
and
in
the
packaging
mechanism,
and
then
we
had
this
other
kind
of
part
of
the
stack
called
finagle,
which
was
this
library
and
the
library
was
used
for
managing
all
service
to
service
communication.
So
the
way
that
you
would
build
a
service
at
Twitter,
if
you
wanted
to
add
any
microt
service
to
the
Twitter
stack
you'd,
build
it
using
finagle
and
finagle.
Was
this
cool
functional
program?
Anything
right?
A
We
were
all
scallop
programmers,
so
we
were
gonna,
do
like
functional
programming
on
top
of
RPC
calls.
We
use
thrift
for
whatever
reasons
and
Scala
and
so
like
we
needed
a
cool
way
of
doing
functional
programming.
On
top
of
these
first
calls
we
were
making
and
that
turned
into
finagle
and
finagle
has
kind
of
this
long
history
at
Twitter,
where
it
became
this.
You
know
over
time.
It
became
this
kind
of
very
rich
form
with
all
these
features
and
you
as
a
service
owner.
A
You
know
you,
you
were
treating
finagles
like
this
nice
library
that
you
could
say:
hey
I'm
service,
a
and
I
want
to
talk
to
service,
B
and
finagle.
Don't
make
that
call
and
give
me
back
the
result
and
under
the
hood,
finagle
was
doing
all
these
things.
It
was
like
load,
balancing
and
and
routing
requests,
and
it
was
like
even
the
load
balancing
was
like
based
on
application
instance.
A
Layton
sees
and
like
try
and
you
know,
send
traffic
to
the
fastest
thing
and
it
would
do
circuit
braking
and
you
know-
and
it
was
a
it-
had-
a
consistent
layer
of
telemetry
and
all
sorts
of
cool
stuff.
So
that's
kind
of
like
the
history
of
why
why
you
know
why
I'm,
even
here,
why
I'm
talking
about
any
of
that
stuff,
so
I'm
gonna,
take
like
a
philosophical
second
for
a
couple
slides
and
let's
just
talk
about
this
idea
of
resilience
right,
it's
good.
A
This
is
this
is
kind
of
what
we're
trying
to
trying
to
build
in
these
software
systems
right
we're
moving
on
to
the
cloud,
the
cloud
scary,
clouds,
weird,
we
don't
know
no
hardware,
it's
like
all
different.
Now,
right-
and
so
we
have
to,
but
we
still
have
to
build
these
reliable
systems-
it's
not
okay
to
have
scheduled
maintenance
anymore.
All
right,
you
used
to
used
to
be
able
to
do
that,
but
you
can't
do
that
anymore
and
you
have
to
take
into
account
the
fact
that
you
know
when
you're
running
in
a
cloud
environment.
A
50%
of
your
is
broken
at
any
point
in
time,
so
you
want
to
build
software
that
can
still,
you
know,
still
work
under
these
conditions.
So
there's
a
material
science
definition
resilience.
You
know
basically,
like
you
got
to
send,
it's
got
a
handle
stuff
without
getting
totally
busted.
It's
a
short
story.
A
Some
people
like
to
talk
about
antifragility,
but
you
know
it's
I,
think
that's
just
a
nicer
kind
of
marketing
term,
and
so
you
know
the
basic
got
hit
in
software
is
okay:
we've
got
these
forms
of
stress,
we're
building
the
system
right
and,
like
we've,
got
unpredictable
load
from
the
outside
world.
Right
people
are
sending
requests
to
us.
Presumably
you
know
we're
getting
traffic
from
the
outside
world.
We've
got
flaky
hardware,
you
got
buggy
software
I
think
you
could
add.
A
You
know
a
couple
more
things
in
the
in
the
cloud
environment
like
I'm
running
on
this
AWS
instance,
and
suddenly
some
other
Adel
us
tenant
like
gets
all
the
resources.
Who
knows
why
and
I
get
none
and,
like
that's
just
unpredictable,
and
then
you
know
in
in
response
to
all
these
sources
of
stress
from
the
inside
from
from
inside
the
application
from
out
the
outside
world.
We
want
to
be
resilient.
How
do
we
do
that
in
software?
Well,
you
know
we
can
show
it.
A
We
want
to
be
able
to
shed
load
and
doesn't
penalize
the
entire
system.
We
want
to
be
able
to
handle
failures,
gracefully
and-
and
you
know
we
want
to
be
able
to
provision
and
then
kind
of
scale
and
and
and
all
that
good
stuff.
Okay,
and
if
you
look
at
the
history
of
software
engineering,
you
know
back
in
the
early
days
of
software,
so
you
know
internet
software,
I,
guess
you
know
the
way
that
you
would
build
resilient
systems
or
reliable
systems.
Is
you
buy
the
big
iron
and
you
buy
to
f5
things?
A
And
you
know-
and
you
don't
have
everything-
and
this
was
all
running
you
know-
in
your
data
center,
like
in
the
closet
in
the
back
of
the
office
or
whatever,
and
this
kind
of
worked
right.
It
was
kind
of
okay.
It
had
had
a
series
of
problems
right,
but
it
was
a.
It
was
a
way
of
building
reliable
software.
So
now
we
advanced,
you
know
17
years
to
a
world
where
that's
not
really,
it's
not
really
feasible.
A
To
do
that
for
four
reasons:
1
through
100
we're
now
moving
into
you
know
the
cloud
right,
and
so
how
do
we
accomplish
a
similar
thing?
Well,
we
don't
have
anything
guarantees
that
we
had
in
from
from
hardware
right.
We
don't
have
the
you
know.
We
don't
have
the
guarantees
where
this
is.
My
machine.
I'm
gonna
get
a
hundred
percent
of
its
usage
and
if
it
dies,
I'm,
like
you
know,
Sally
from
the
hardware
department
will
come
here
and
like
replace
it
with
another
one.
A
You
know
we
don't
have
any
of
those
guarantees,
so
there's
guarantee
the
guarantees
that
we
around
reliability
that
we
lost
to
a
hardware.
We
now
have
to
replicate
in
software
and
that's
the
idea,
that's
kind
of
the
idea
of
this
like
cloud
native
environment,
okay,
so
what's
cloud
native?
Well,
we
have
a
foundation
now
and
we
have
a
conference
and,
like
you
know,
everything
is
great
and
kind
of
at
the
surface
level.
You
know
in
order
to
be
cloud
native,
you
should
be
using
containers
and
you
should
be
running
an
Orchestrator.
A
It
should
be
building
micro
services.
That's
a
pretty
prescriptive
definition!
I
think
you
know.
If
you,
if
you
look
behind,
you
know,
look
behind
the
implementation,
details
cloud,
what
cloud
native
means
and
why
I
kind
of
like
the
term
is
it
software?
That's
designed
to
run
in
these
cloud
environments
right
in
environments
where
you
just
don't
have
a
lot
of
reliability,
guarantees
from
any
of
the
underlying
systems,
this
team?
Okay,
so
far?
A
A
You
know
and
the
IP
addresses-
and
we
were
monitoring
these
servers
and
whatever
else
and
now
in
this
cloud
native
world,
we've
kind
of
abstracted
a
lot
of
that
stuff
away
right,
we're
talking
about
services
now
and
service
discovery,
service,
monitoring,
micro
services
right
and
and
we're
not
worrying
about
individual
servers
or
individual
IP
addresses
or
any
of
that
stuff.
We've
tracked
it
a
bunch
of
that
stuff
away.
We're
not
worrying
about
individual
TCP
connections,
like
we
kind
of
assume
that
that's
you
know
going
to
work
90,
whatever
percent
of
the
time.
A
Instead
we're
thinking
about
well
how
our
REST
API
is
formed
and
how
are
we
gonna
use
G
RPC
and
are
we
you
know
doing
flow
control
over
HTTP
to
streaming?
You
know
semantics
or
whatever
right,
so
those
abstractions
have
all
changed
right
and
and
the
thing
the
thing
that
we've
introduced
right.
The
thing
that
we've
introduced
by
doing
this
shift-
you
know,
especially
with
kind
of
the
micro
services
aspect
us
now.
We've
introduced
this
notion
of
runtime
communication.
A
That
is
not
just
you
know,
not
just
its
kind
of
one-off
okay,
the
web
server
talks
to
the
app
server
and
the
app
server
talks
to
the
database,
but
this
is
actually
pervasive
part
of
our
application.
Now
we
never
had
this
before
right
and
when
you
think
about
it,
when
you
think
about
it
in
your
head.
Well,
it's
it's
kind
of.
It
looks,
looks
kind
of
like
this
right:
okay,
service,
a
talks
to
B,
&,
B,
talk
to
C
and
the
response
comes
back,
and
you
know
great
right.
A
What
could
go
wrong
you
know
and
in
in
in
reality,
what
happens?
Is
you
end
up
with
you?
Don't
end
up
with
like
a
and
B
and
T,
you
end
up
with
a
big
hairy
mess
like
this,
and
this
is
the
architecture
of
Twitter
circa
2013
I'm
gonna
continue
using
this
diagram
until
the
day
I
die,
because
it's
just
so
good
yeah
like
it's
just
like
who,
who
wants
to
be
on
call
for
this
right?
A
You
know,
but
we
were
I
was
I
had
to
wake
up.
You
know,
and
he
can
see.
There's
this
poor
little
service
down.
There
called
gizmo
doc,
you
know
it
was
basically
the
user
service,
and
you
know
everyone
talked
to
and
like
it's
just
as
complicated
topology
of
things,
and
so
this
is
this.
Is
you
know?
The
previous
slide
was
like?
A
You
know
how
you
imagine,
micro
services
are
going
to
be,
and
this
is
like
how
micro
services
really
are,
and
so
I'll
give
you
I'll
give
you
one
quick
example
about
why
you
know
just
make
it
super
concrete
about
why
the
introduction
of
this
very
pervasive
services,
service
communication
becomes
complicated
right,
and
this
is
an
example
that
I
like,
because
it's
clear
this
there's
like
20
other
things
that
fall
in
the
same
category.
So
here
I've
got
this
system
right
in
the
very
simple
twittery
system.
A
I've
got
a
web
service
that
talks
to
this
time
line
service
which
talks
to
the
user
service,
which
talks
to
the
database
and
okay.
Each
of
these
things
I've
got
like
you
know:
I
got
a
account
for
the
fact
that
the
you
know
and
might
be
down,
or
it
might
be
frozen
or
something
so
I
set
a
timeout
and
I
set
some
number
of
retries,
and
you
know
here
we
go
ready
for
action.
Right,
does
any
one
spot
a
problem
with
this.
A
A
Yeah,
the
downstream
service
retries
are
useless.
That's
right!
That's
right!
So
you
know.
If
you
look
at
what
what
happens
here,
if
the
database
starts
failing
right,
let's
say
we're
not
failing.
Let's
say
it's
hanging
because
failing
is
easy
right
hanging
is
something
for
the
thing.
That's
really
painful
database
starts
hanging
because
it's
overloaded.
Well,
we
start
hitting
this
retry.
A
You
know
the
timeout
on
the
user
service
and
user
service
starts
retrying,
stuff,
okay,
but
now
we're
hitting
it
that's
tied
on
the
time
line,
service
and
timeline
starts
retrying
stuff
and
then
we're
hitting
a
timeout
and
the
web
servers,
and
you
know
pretty
soon
one
tiny
little
you
know
slowdown
in
the
database.
A
little
slow
suddenly
gets
compounded
because
we're
sending
all
these
requests
right,
and
so
this
is
a
general
class
of
like
it's
really
hard.
It's
really
hard
to
manage
this
communication
and
the
way
that
we
parameterize
it
makes
a
big
difference
right.
A
So
we're
used
to
kind
of
thinking
about
our
our
telephone
talking
to
the
Twitter
server
right,
and
what
does
it
do
it
like
makes
us?
It
makes
a
recovery
web
browser
talking
to
a
web
service
and
you
make
a
request
and
you
wait
500
milliseconds
and
make
another
one,
and
if
you're
really
fancy
you
do
the
exponential
back-off,
but
that
pattern
really
starts
breaking
down
when
you
apply
the
scale,
because
this
parametrization
doesn't
doesn't
compose
right
and
this
gets
even
worse.
When
you
get
a
lot
more
services,
every
service
is
owned
by
a
different
team.
A
The
teams
are
not
talking
to
each
other
because
they
all
hate
each
other,
because
you
no
one's
written
in
Java
on
one
threatened
and
go
or
whatever
yeah.
Okay,
so
lots
lots
more
examples
of
that.
But
I
think
that's
that's
a
fun
one.
Okay!
So
what's
missing!
Well,
you
know
now
now
I
have
to
do
the
selling
bit.
You
know
we've
got
docker,
we've
got
kubernetes
like
surely
at
this
point,
we're
ready
we're
ready
for
anything
or
any
like
we
can
scale.
A
We
got
containers
and
what's
missing
really
the
is
is
what
was
missing
from
the
Twitter
story
up
until
the
point
where
we
got
finagle.
What's
missing?
Is
this
idea
of
the
service
mesh
some
way
of
a
managing
communication
between
these
services
consistently
across
across
the
entire
application?
You
know-
and
ideally
this
happens
in
a
way
where
you
don't
have
to
you
know,
get
the
developers
to
redeploy
their
services
right.
That
was
kind
of
the
problem
with
Twitter.
Yes,
you
made
a
change
if
an
angle
finagle
out
a
bug,
and
then
you
fixed
it
great.
A
It
would
take
like
six
months
to
get
everyone
on
to
the
latest
version
of
finning.
I
mean
why
you
have
found
another
bug
right,
and
so
that's
that
makes
life
difficult.
Okay,
so
I
think
you
know,
if
you
think
about
security,
you
know
being
kind
of
this
thing
that
you
have
to
implement
in
layers.
I,
think
reliability
is
one
of
those
things
that
you
have
to
do
in
layers
as
well.
Where
you
know
docker
gives
you
a
certain
amount
of
reliability.
Kubernetes
gives
you
a
certain
amount
of
reliability
right,
like
the.
A
Go
down
and
like
everything
gets
automatically
restarted
and
rescheduled,
but
there's
still
another
layer
on
top
of
that,
which
is
the
service
to
service
communication,
okay,
so
the
service
mesh.
Finally,
maybe
I
should
have
started
with
the
slide.
What
is
a
service
mesh?
It's
a
dedicated
software
layer
for
managing
the
service
communication.
Alright,
so
the
idea
is,
we
want
to
pull
it
out
of
the
applications
right
and
put
it
into
the
underlying
infrastructure
yeah.
A
My
apologies
apologize
for
these
animations,
so
you
know
quick.
This
is
very
overly
simplified
history
of
software
architecture,
but
you
know
we,
we
started
with
a
lamp
stack
back
when
we
were
all
children,
like
all
that
we
had
was
a
lamp
stack,
and
you
know
you
had
this:
you
had
service,
you
had
communication
internal
communication
here
right,
you
had
a
communication
from
between
Apache
and
PHP
and
between
PHP
and
my
sequel.
Alright,
but
though
that
communication
was
very
specific,
like
these
use,
cases
were
very
you
know.
A
Wasn't
this
general,
like
service
of
service
thing
right
and
Apache,
was
really
really
good
at
balancing
load
over
a
bunch
of
PHP
instances
and
the
PHP?
My
sequel,
clients
got
very,
very
good
at
talking
to
my
sequel.
You
know
so
you
had
these
specialized
clients
right.
You
fast
forward
a
little
bit
from
that
into
the
world
of
this
is
kind
of
where
Twitter
was
you
know
into
this
world
of
fad
clients,
so
the
the
early
web
scale
companies
like
Twitter
and
Facebook
and
Netflix
and
Google.
A
This
was
a
better
approach
right
and
they
all
kind
of
had
to
do
this
because
there
was
no
way
no
way
of
avoiding
it
and
the
service
Misha
is
really
just
taking
that
same
logic
and
moving
it
into
a
separate
layer.
All
right.
That's
all
it
is:
it's
not
new
functionality.
It's
not
stuff
that
we
haven't
thought
of
before,
like
oh
we've,
never
load-balanced
before.
A
Well,
we've
been
load
balancing
since
since
load
existed,
you
know,
but
it's
it's
moving
it
out
of
the
out
of
the
developer
and
into
the
out
of
the
the
hands
of
the
service
operator
into
the
underlying
platform.
So
I
have
a
little
diagram
of
like
what
this
actually
looks
like
in
practice.
This
is
for
linker
D
for
conduit,
I,
don't
have
a
diagram,
but
it
looks
a
little
different
because
of
sidecars
rather
than
per
host.
But
you
know,
though,
so
what
does
a
service
mesh
look
like
in
practice?
A
You've
got
two
hops
in
there
and
the
reason
to
put
two
hops
and
there's
because
then
you
can
control
both
sides,
so
you
can
add
TLS
and
then
terminate
it
or
you
can
like
upgrade
from
HTTP
one
to
HP,
two
or
whatever.
Basically
you
want
to
give
the
mesh,
you
know
the
you
want
to
give
it
ownership
over
that
communication,
layer
and
the
reason
to
do
it
as
a
separate
proxy.
Well,
it's
because
then
you
don't
have
the
library
problem
or
anything
you
don't
have
to
you
don't
have
to
a
like.
A
He
can
be
polyglot
right.
You
don't
have
to
like
maintain
the
same
library
across
in
different
languages
and
be
especially
for
bigger
companies.
You
don't
have
to
convince
them
the
the
developers
to
redeploy
their
services
ever.
You
want
every
time
you
want
to
make
a
change,
and
this
is
all
made
possible.
It's
only
made
possible
because
we
have
things
like
docker
and
kubernetes
that,
like
make
doing
this
sort
of
thing
easy,
you
know
we
could
have
done
this
at
Twitter.
We
could
have
done
this.
A
You
know
15
years
ago,
but
it
was
really
really
hard
right.
Now
we
have
things
that
make
it
easy,
so
it's
enabled
kind
of
this.
The
sort
of
architecture-
let's
see
yeah
surface
finish-
does
a
whole
bunch
of
stuff
reliability.
Visibility,
I'm,
not
gonna.
Well,
maybe
I'll
spend
30
seconds
on
this.
So
largely
what
I've
been
talking
about
has
been
the
reliability
semantics
like
retries
and
timeouts,
and
how
you
might
want
to
parametrize
them
differently
and,
like
you
know,
the
service
mesh
can
do
some
of
that.
A
For
you
right
we,
if
it
knows
our
request,
is
idempotent.
It
can
retry
it.
If
it
knows,
you
know
that
you
know
this
application
instance
is
returning.
You
know
application
level
errors.
Well,
we
can
just
circuit
break
and
kick
it
out
of
the
load,
balancing
pool
all
right.
We
can
do
a
bunch
of
that
reliability
stuff.
A
It's
also
the
visibility,
and
maybe
visibility
should
have
been
first
in
this
time,
because
that's
really
the
thing
that
I
think
gets
people
hooked
on
linker
D
on
conduit
on
any
service
mesh
first
is
the
fact
that
you
suddenly
have
this
visibility
into
you
know
into
into
these
critical,
like
the
top
line
service
metrics.
These
are
the
things
you've
never
had
before.
I
mean
it's
like
success
rate
and
requests
volume
and
service
latency,
you
probably
hopefully,
you've
had
them
before,
but
now
you've
got
a
consistent.
A
You
know
consistent
way
of
getting
them
across
your
entire
application.
Stack,
that's
independent
of
what
language
are
in
an
independent
of
what
libraries
are
using
independent
of
the
frameworks.
You
suddenly
have
all
this
visibility,
and
this
is
a
top
line
service
metrics.
These
are
the
things
you
want
to
wake
up
for
at
3:00
a.m.
there's,
a
bunch
of
cool
security
stuff
which
I'm
going
to
skip
over
governance.
I,
don't
even
know
what
that
means.
A
That's
it's
really
expensive.
Whatever
it
is,
link
rity
has
some
production
users
and
some
things:
okay,
I'm
just
kind
of
gonna
skip
through
this
okay,
the
future,
all
right,
so
I
guess
what
I've
already
done
is
the
past
in
the
present,
so
I
guess
we're
moving
into
the
future
okay,
so
the
fuel
is
future
of
the
surface
mesh.
A
This
is
this
is
fairly
link
or
D
specific,
so
you'll
have
to
you'll.
Have
to
forgive
me,
you
know
so
I
think
security
is
a
pretty
interesting
is
a
pretty
interesting
topic.
This
is
certainly
one
that
comes
up
a
whole
lot
for
us,
as
people
are
moving
into
the
cloud
native
environments,
you
want
to
do
things
like
isolation
of
services.
You
want
to
do
things
like
having
policy
on
on
top
of,
like
which
services
can
talk
to
which
other
services,
which
calls
are
they
allowed
to
make.
A
You
know
how
do
how
do
we
know,
which
you
know
who?
How
do
we
know
whether
a
service
is
who
it
claims
it
is,
and
how
do
we
apply
policy
on
top
of
that,
and
are
we
doing
this,
like
you
know
what
what
layer
are
we
doing?
This
is
per
service
as
a
per
request,
or
do
we
have
this
notion
of
customers
or
tenants
because
we're
like
running
of
this
multi-tenant
application,
you
know
and
then
there's
the
question
of
like
well.
What
about
the
mesh
itself?
How
secure
is
that
thing
right?
A
A
Performance
this
is
you
know,
this
is
a
big
one.
You
know,
because
what
we're
asking
people
to
do
is
to
install
these
proxies
everywhere,
Brian
to
just
jam
them
in
into
every
single
application
call
not
just
once
but
twice
okay.
So
that
means
it's
pretty
fast.
We're
gonna
make
it
really
lightweight.
Now
we
got
to
make
its
behavior
predictable
right.
That's
that
almost
might
be
more
important
than
any
of
the
other
things
if
you're
introducing
a
constant
time
cost.
Well,
that's
that's!
That's
understandable!
A
So
when
the
service
mesh
goes
wrong
or
when
something
is
going
wrong,
how
do
you
know?
How
do
you
know
where
the
promise
this
is
a
problem
with
my
service?
Isn't
a
problem
with
the
underlying
network?
Is
it
a
problem
with
the
the
service
mesh?
You
know
like
it's
just
hard,
it's
really
hard
to
know
when
there's
so
many
moving
pieces.
A
So
how
understandable?
Can
you
make
the
service
mesh,
so
you
you
have
a
sense
when
you're
relying
on
saying
you
have
it,
you
have
a
sense
that
you
can
rely
on
it
that
it's
understandable
and
it's
predictable
and
then
the
other
thing
that's
really
interesting
for
us
is
like
I
said
here,
but
the
definite
separation
concerns
between
Devon,
ops,
I
think
maybe
a
better
way
would
be
saying
of
saying
that
would
be
separation
of
concerns
between
the
service
owner
and
then
kind
of
the
platform
owner
right
because
they
are.
A
Those
are
two
engineering
groups
that
have
fairly
different
goals
in
in
fairly
different
requirements
in
kind
of
a
larger
organization
and
I.
Think
a
lot
of
the
values
of
service
finishes
in
allowing
that
separation
in
kind
of
increasing
the
separation
of
concerns
between
those
two
groups.
Okay,
great.
So
that
is
that's
the
future.
Oh
wait!
No!
The
answer!
Yes,
these
are
all
questions.
A
Here's
the
answer
all
right,
conduit
the
answer:
okay
and
to
talk
done
yeah,
so
we
I
wanted
to
spend
just
a
minute
on
conduit
because
we
launched
this
thing
yesterday
and
you
know
I
guess.
A
lot
of
the
questions
in
the
previous
session
were
kind
of
you
know
segues
into
conduit,
because
a
lot
of
what
we
tried
to
do
with
conduit
is
is
address
exactly
those
concerns
based
on
the
the
you
know,
the
18
months
of
production
experience
with
with
linker
D.
You
know
at
a
variety
of
companies
around
the
around
the
globe.
A
Some
were
very,
very
happy
with
linker
D,
some
who
have
had
problems
with
linker
dan,
like
some
who
have
not
been
able
to
adopt
it
for
a
variety
of
reasons.
Right
and
so
the
goal
with
Condit
was
conduit,
was
not
only
make
something.
It's
really
specific
to
kubernetes
right
and
like
just
let's
just
absorb
those
idioms
and
make
sure
it
works.
You
know
in
conjunction
with
coop
cuddle
and
make
sure
you
know
it
uses
the
kubernetes
like
you
know,
ontology
and
we're
talking
about
deployments
and
pods
and
all
those
things
you
know
which
linker
d44.
A
You
know,
for
all
of
its
benefits
was
a
very
abstract.
You
know
generic
layers
I
could
talk
to
20
different
things
and
which
made
it
very
difficult
to
talk
to
one
specific
or
to
configure
it
in
terms
of
one
specific
thing.
So,
let's
like
let's
fix
up
to
kubernetes
right
and
then,
let's
just
make
it
incredibly
fast
and
incredibly
lightweight
linker.
Do
you
always
interesting
how
plain
kadia
that
you
know
all
that
rely
all
the
all
the
building
blocks
that
we
built
on
top
of
things
like
finagle?
A
You
know
which
in
turn
was
built
on
top
of
Neddie,
which
you
know
and
and
Scala
and
which,
in
turn
built
on
top
of
the
JVM,
like
all
those
components,
are
really
good
at
scaling
up
right.
You
give
them
enough
memory
and
you
give
them
enough
CPU
cores
Michel
incurred.
He
can
just
practice.
You
know
it
can
process
tons
of
traffic.
It's
just
crazy,
like
just
throw
tens
of
thousands
of
requests
through
a
single
instance,
but
in
the
kubernetes
world,
especially
if
you
want
to
deploy
as
a
sidecar,
you
kind
of
want
the
opposite
right.
A
You
want
something
that
doesn't
have
to
handle
that
much
traffic
yeah
handles
a
thousand
requests,
a
second
or
something
cuz,
you're
deploying
one
per
application.
Instance
alright,
but
it
has
to
be
really
really
tiny.
It
has
to
be
really
lightweight
and
you
want
to
have
a
really
predictable.
You
know
p99
latency,
and
that
was
where
leek
heard
he
had
had
trouble.
So
the
production
users
of
linker
D.
Well,
it
kind
of
depends,
you
know,
depends
on
what
the
size,
your
services.
A
We
have
many
people
who
use
it
in
production
as
a
sidecar,
because
their
services
are
big.
They're
running
these
heavyweight
JVM
services
that
take
a
big
heap,
and
so
you,
you
know,
I
spend
two
hundred
Meg's
on
a
link
or
D
container.
You
know
whatever
it's
not
that
bad,
but
then
we
have
folks
who
are
writing,
go
microservices
and
nother
take
15
eggs
and
then
it's
a
little
silly
to
you
know
to
ask
in
the
put
linker
D.
You
know
it's
a
sidecar,
so
we
do
it
as
a
demon
said
and
like
they
could
see.
A
A
bunch
of
you
know
at
least
lets
you
amortize
those
resources,
but
it's
not
ideal
right.
We
wanted
to
have.
We
want
to
do
something
that
we
want
to
do
something
that
was
right
from
the
start
and
the
other
big
thing
that
we
did
was
trying
to
sign
this
with
security
in
mind,
especially
for
our
users
who
have
PII
or
PCI
compliance
issues
or
HIPAA
data
or
whatever,
like.
We
really
want
to
ensure
that
you
know
this
data
plane.
That's
in
there.
That's
touching
everything
is
as
reliable
and
as
secure
as
it
possibly
can
be.
A
So
we
built
the
data
plane
and
rust,
which
six
months
ago
seemed
totally
crazy
and
risky
right
now
seems
awesome
because
it
worked
and
what
rust
gives
us
is
not
only
the
ability
to
run
native
to
write
native
code.
So
you
know
it's
about
as
fast
as
programming
as
code
can
be
until
you,
you
know
till
you
drop
down
to
assembly,
but
it's
also
guaranteed
to
be
memory
safe.
A
All
right,
so
we
avoid
a
whole
class
of
buffer
overflow
exploits
and
things
like
that,
and
it
does
not
have
a
garbage,
collector
and
that's
important,
because
that
means
that
drastically
reduces
of
the
variability
of
the
lane
to
means
things
are
really
really
predictable
and
I'm.
Not
a
rust
expert
at
all,
but
I
know
a
little
bit
about
what
we've
done
and
it's
super
cool,
because
the
rust
language
features
allow
you
to
very
easily
express
these.
You
know
these
things.
A
We're
like
I
want
to
tie
all
you
know,
I'm
allocating
memory
as
part
of
processing
this
request
and
then,
when
the
request
terminates,
I
want
to
just
free
all
that
memory
at
once.
Right
and
when
you
do
things
like
that,
you
can
amortize
the
cost
of
the
memory
allocation
de-allocation
over
every
request
and
the
thing
that's
become
very,
very
predictable
and
then
all
sorts
of
cool,
powerful
features
I'm
actually
not
going
to
have
time
for
dental,
because
I
want
to
do
a
little
bit
of
questions
afterwards.
A
But
we'll
do
one
at
the
cig
or
the
the
salon
tomorrow.
But
powerful
features
one
of
the
things
that
Oliver
showed
off.
You
know
during
the
demo
is
this
idea
of
tap
where,
if
I
have
services
running
you
know
in
production,
I
should
be
able
to
just
kind
of
TCP
dump
into
those
requests.
Like
just
show
me,
you
know
just
show
me
what's
going
on,
and
so
we
did
a
lot
of
work
to
make
things.
I
got
powerful
possible.
A
A
B
A
Yeah,
we're
not
we're
not
ruling
it
out.
I
think
that
it's
it's
not
it's
not
like.
The
first
does
not
like
the
future
of
protocols,
but
it's
also
a
really
simple
protocol,
so
it
might
be
easy
to
just
do
it
and
then
you
know
the
next
question
was
okay.
What
you
know,
what
about
linker
D?
Are
we
throwing
and
throwing
that
thing
away
and,
like
sorry,
linger
to
use
or
the
answer's,
no
linker
DS
gonna
have
a
whole
lot
of
use.
A
Yeah,
if
you
were
deploying
a
service
mesh
in
kubernetes
a
month,
let's
say
two
months
from
now:
we
got
to
get
production
ready.
Then
yeah
I
would
start
with
conduit
yeah.
Unless,
unless
you
had
some
really
specific
requirements
around
I
have
existing,
you
know
mais
au
s--
infrastructure.
I
have
existing
zookeeper
or
I
have
you
know
nomad
over
here
and
I
like
need
to
make
this
stuff
all
work
together,
because
that's
the
kind
of
stuff
that
linker
d
is
really
really
good
at
the
conduit.
A
A
That's
sacrilege:
the
question
was:
what
happens
when
kubernetes
is
replaced
by
whatever
comes
after
kubernetes?
That's
going
to
be
the
next
the
new
hotness
wow.
That
would,
of
course,
never
happen
because
kubernetes
is
perfect
in
every
way,
but
I
think
you
know
what
one
of
the
funny
things
about
the
about
the
whole
service
mission
model
is
that
it's
not
actually
that
tightly
tied
to
the
orchestrator
right
at
the
tech
level.
You
know
we
integrate
both
link.
Turning
and
conduit,
integrate
with
kubernetes
that's
kind
of
a
service
discovery
endpoint.
A
You
know
we
call
a
couple
api's,
but
that
integration
is
not
really
that
tight.
The
usage.
You
know
the
adoption
is
like
super
tight,
but
the
the
tech
integration
is
not
that
tight,
so
actually
I
think
that'd
be
fine.
You
know,
I
I,
don't
think
it
would
be
that
much
work
to
make
a
linker.
Do
you
work
at
or
and
conduit
work
with,
whatever
the
kubernetes
after
next.
B
A
Yeah,
a
great
question:
mm-hmm
yeah,
yeah
great
question-
so
is
conduit
a
data
plane
or
is
it
a
control
plane
Conner
has
both
actually
Lake
Ernie
has
both.
We
just
did
a
bad
job
of
talking
about
it
all
right,
so
linker
D,
you
know
we
all
we've
all
almost
always
talked
about
this
thing.
So
let
me
let
me
take
one
step
back
and
kind
of
describe
this
distinction.
Matt
Klein
actually
has
a
really
good
thought
of
envoy
has
a
really
good
blog
post
about
data
planes
versus
control
plane.
A
The
idea
is
that
in
a
service
mesh
there
actually
are
these
two
kind
of
logical
components.
At
least
you
know,
one
is
what's
actually
proxying,
they're
pressed,
what's
handling
those
bits,
you
know
what's
what's
it?
What
is
seeing
user
data
what's
exposed
to
PII
and
all
that
and
that's
the
data
plane
and
then
the
other
component
is
well.
What
are
you
using
to
kind
of
orchestrate?
Maybe
that's
a
bad
choice
of
work,
what
are
using
to
control
all
of
those
all
of
those
proxies
and
that's
the
control
plane
and
with
linker
D?
A
We
almost
always
talk
about
data
plane
terms,
but
there
is
a
control,
plane
called
name
or
D
with
conduit.
One
of
the
you
know
big
lessons
that
we
learned
is.
We
talk
very
explicitly
about
the
Kandra
data
plane
and
the
conduit
control
plane
and
those
are
two
things
or
two
separate
code
bases.
The
control
plane
is
actually
written
in,
go
alright,
so,
which
makes
it
easy
to.
You
know,
use
all
these
kubernetes
libraries,
which
is
nice
for
us
the
day
the
planes
are
in
and
rust
and
having
that
distinction
has
has
made
us.
It's
been.
A
A
Yeah,
so
how
does
this
compare
to
Envoy?
It's
a
very
different
beast,
because
envoy
is
I.
Think
much
more
of
a
data
plane
then
consul
conduit
is
both
control
plane
and
a
data
plane
on
boy
is
pretty
much
a
data
player
right
and
the
way
envoys
use
that
lift
is
with
a
with
a
non
open-source
control.
Plane.
A
I'm
gonna
put
this
over
here
with
an
on
open-source
control
plane.
The
way
that
you
see,
use
with
this
do
is
is
to
you
as
a
control
plane
and
on
points
of
data
plane
with
conduit.
We
have
both
pieces.
So
it's
it's
not
really
an
apples
to
apples,
comparison,
I
think
a
better
comparison
was
would
be
with
sto
an
envoy
right,
because
that
that
is
kind
of
the
same
thing
right
this.
It's
they're
both
service
missions.
They
have
a
control,
plane,
written
and
go
I'm,
sorry
sto
and
convent
yeah
yeah.
A
Yeah
great
question:
the
question
was:
what's
the:
what
are
the
security
implications?
Basically,
if
using
daemon
sets
versus
sidecars
right
and
the
big
implication
there,
and
the
reason
why
the
sidecar
model
is
so
compelling
is
if
you
want
to
do
service
any
kind
of
service
off
or
service
kind
of
identity.
All
right,
then
doing
that
as
a
daemon
set,
doesn't
make
a
lot
of
sense
because
you
want
to
have
a
sir.
You
know
presumably
you're
doing
this
with
kill
us
there's
other
ways
of
doing
it.
A
But
if
you're
doing
this
TLS,
then
you'd
have
a
cert
per
service.
Okay
and
then
a
demon
set
like
you're
just
giving
all
the
certs
to
this
thing
and
like
you've,
lost
the
entire,
you
know
so.
You've
lost
all
your
security
boundaries.
So
that's
why
the
sidecar
model
is
so
interesting,
and
so
compelling
is
because
if
you
want
to
do
any
kind
of
service
identity
and
build
policy
on
top
of
that,
you
got
to
be
sidecars,
yeah
really
good
question
all
right.
So
let's
do
in
the
back.
A
B
A
So
the
question
was
in
the
library
case:
if
you
make
an
update
to
library,
then
have
to
roll
all
your
services
in
the
in
the
sidecar
case.
Don't
you
have
the
exact
same
thing
where,
if
you
have
to
update
your
sidecar,
you
then
have
to
you
know,
redeploy
your
services
and
the
answer
is
it's:
it's
not
quite
the
same
because
you
don't
have
to
get
developers
involved.
You
don't
have
to
get
the
service
owners
involved
right.
If
you
update
the
sidecar
and
you
you
know
and
I
think
Oliver
basically
did
this
trim
the
live
demo.
A
This
morning
you
you
update.
Like
the
you
know,
the
deployment
spec
to
include
the
new
thing,
and
then
you
roll
in
the
deployment
right
and
that's
a
pure,
like
platform
owner
kind
of
operation,
is
there's
no
recompilation,
there's
no
like
going
through
CI,
CD
or
unit
testing,
or
anything
like
that.
Oh
gosh,
when
I
say
it
like
that,
it
sounds
really
scary.
There's
definitely
integration
testing
that
you
do
before
before
that.
B
A
A
It's
linker
D
connecting
with
this
you
know,
so
we
have
a
very
preliminary
integration
that
we
did
back
when
this
deal
was
first
announced
to
have
linker
D
act
as
a
data
plane
for
sto,
so
you
could
run
the
SCO
as
a
control
plane
in
liquor
D
as
the
data
plane.
We
didn't
get
a
lot
of
interest
in
that
we
did
it
and
it
worked.
You
know
it
only
supported.
Maybe
60%
of
this.
You
know
API
at
the
time,
but
we
didn't
really
see
any
adoption.
No
one
was
really
interested
in
using
it.