►
From YouTube: Christian Posta: Service mesh options with Istio, Linkerd, and/or Consul - Craft Conference 2019
Description
Service mesh abstracts the network from developers to solve three main pain points:
How do services communicate securely with one another
How can services implement network resilience
When things go wrong, can we identify what and why
Service mesh implementations usually follow a similar architecture: traffic flows through control points between services (usually service proxies deployed as sidecar processes) while an out-of-band set of nodes is responsible for defining the behavior and management of the control points. This loosely breaks out into an architecture of a "data plane" through which requests flow and a "control plane" for managing a service mesh.
Different service mesh implementations use different data planes depending on their use cases and familiarity with particular technology. The control plane implementations vary between service-mesh implementations as well. In this talk, we'll take a look at three different control plane implementations with Istio, Linkerd and Consul, their strengths, and their specific tradeoffs to see how they chose to solve each of the three pain points from above. We can use this information to make choices about a service mesh or to inform our journey if we choose to build a control plane ourselves. - Captured Live on Ustream at http://www.ustream.tv/channel/craftconf3
A
All
right,
thank
you.
So
much
for
those
of
you
that
joined
me
here
today.
I
hear
there's
other
speakers
going
on
right
now.
Actually,
my
boss
is
speaking
right
now
she
probably
took
all
of
the
all
of
the
attendees
I'm
talking
about
service
mesh
with
linker
D
is
ste
o
at
mesh
and
console
it's
kind
of
a
lot
of
stuff.
How
many
people
have
heard
of
service
mesh?
A
Okay,
good?
How
many
people
just
curiously,
are
running
in
their
applications
in
kubernetes,
okay,
so
service
mesh,
you're,
probably
going
to
start
hearing
about
it
more,
especially
in
terms
of
containers
and
kubernetes,
but
we're
gonna
talk
today
about
what
it
is
and
why
you
might
use
it
and
we're
gonna
look
at
four
different
options.
A
So
again
my
name
is
Christian.
I
live
in
Phoenix
Arizona
I
recently
left
Red
Hat,
where
I
was
chief
architect
of
cloud
application.
Development
and
I
helped
the
Red
Hat
customers
across
mostly
North
America,
build
applications
on
top
of
kubernetes
and
what
that
means
is
building
distributed
systems
systems
that
are
built
to
be
resilient
and
I've
come
across
a
lot
of
the
patterns
that
we'll
talk
about
today
and
I.
Think
service
mesh
is
a
really
good
way
to
implement
them.
I've
written
a
couple
books,
I'm,
currently,
writing
is
do
in
action.
A
I
worked
on
a
lot
of
open
source
projects,
including
SDO
for
the
last
probably
two
years
and
I'm
excited
to
be
here
and
speak
and
talk
about
these
technologies.
So
again,
the
flow
of
the
talk
will
look
something
like
this.
Where
we'll
talk
about
the
problem,
what
is
the
service
mesh
we'll
try
to
define
it
and
then
we'll
look
at
for
implementations
of
service
mesh
technology
and
then
how
to
how
you
can
get
started
with
these
different
technologies?
A
So
we'll
set
the
context
with
the
problem
that
we're
talking
about
so
when
we
start
to
go
toward
services,
style
architectures
and
we
build
them
into
platforms
like
kubernetes
and
so
on.
We
do
that
for
a
specific
reason.
We
do
that
because
we
want
to
go
faster.
The
talkin
here
previously
I
think
was
on
continuous
experimentation.
A
A
How
quick,
how
often
you're
introducing
failures
into
production
and
measuring
that
that
window
is
growing
all
right,
so
we
see
technologies
like
kubernetes
things
like
continuous
integration,
continuous
delivery,
we're
able
to
get
our
code
out
to
production
faster,
but
we're
not
delivering
better
quality
code,
and
when
we
introduce
failures,
we
are
not
able
to
very
quickly
determine
that
and
reverse
that.
So
the
rest
of
the
talk
when
you,
when
we
start
talk
about
service
mesh,
is
about
how
do
we
address
those
last
two
concerns.
How
do
we
reduce
the
risk
of
making
changes
to
production?
A
How
do
we
build
resiliency
and
dynamic
the
the
ability
to
adapt
to
the
environment
when
we
do
our
deployments
and
build
their
applications,
but
you're
probably
saying
well?
How
hard
can
this
really
be?
We're
going
to
microservices
we're
doing
rests
we're
doing
api's
we're
going
away
from
old
proprietary,
closed
source,
vendor
ESB
that
kind
of
infrastructure
which
was
more
complicated.
A
So
it's
got
to
be
easier
right,
but
even
if
you
take
the
most
simple
use
case
of
service,
a
talking-to
service,
B
servus
a
doesn't
really
talk
to
serve
as
be
it's
connected
by
a
wire
somehow
right
it
put
bytes
and
bits
on
top
of
this
wire
and
then
they
get
transferred
over
to
service
B.
There's
an
inherent
delay
in
there.
It's
called
the
speed
of
light.
It's
not
immediate,
there's
a
delay
between
when
a
talks
to
B
and
actually
practically
over
a
wire
there's
that
we
get
degradation
in
the
signal.
A
So
it's
not
even
the
speed
of
light,
so
there's
there's
slower
than
the
speed
of
light,
but
there's
some
delay
right
now.
You
expand
that
out
to
what
our
real
cloud
networks
look
like
in
our
networks
in
our
enterprise,
it's
not
a
straight
a
wire
from
A
to
B.
It's
all
these
different
hops
through
the
network,
switches
and
routers
and
other
computers
where
any
of
them
can
fail.
Any
of
them
can
queue
up
and
slow
down
the
bytes
and
bits
that
are
going
over
the
wire
and
some
of
them
can
can
just
lose
messages
right.
A
So
we
get
into
how
many
of
you've
heard
of
the
the
fallacies
of
distributed
computing
yeah.
So
that's
that's.
What
we're
going
with
this
right?
We
have
to
build
our
applications
in
such
a
way
that
they
can
withstand
these.
These
types
of
failures,
you
put
a
message
out
on
the
wire
and
you
don't
hear
anything
back
so
do
you
retry?
Is
it
safe
to
retry?
Maybe
you
do
get
an
error,
but
was
the
error
from
the
machine
on
the
other
side?
A
Maybe
it
processed
the
message
already,
so
you
get
into
a
lot
of
these
inconsistent
states
and
as
we
move
away
from
our
nice
comfortable
world
of
the
model,
if
everything
is
running
co-located
and
everything
is
running
in
a
single
system
and
a
single
process
to
one
where
it's
distributed.
Now
you
have
to
talk
over
the
network
and
you
end
up
with
all
these
uncertainties.
We
start
to
move
the
complexity
of
our
services
between
the
services
and
heavily
dependent
on
how
they
communicate.
A
So
this
is
magnified
even
more
when
we
go
into
cloud
infrastructure
like
kubernetes,
where
in
the
past
we
could
say
well,
we'll
just
make
the
database
highly
available.
We'll
just
make
this
Network
highly
available,
and
we
built
our
application
with
those
assumptions
in
them
and
that
when
the
database
went
down,
we
found
out
very
quickly
that
it
wasn't
highly
available
with
kubernetes
and
cloud
and
the
way
we're
rethinking
how
we
design
our
applications.
A
We
should
design
them,
knowing
that
they
will
fail,
things
will
fail,
the
network
will
fail,
and
so
there
are
a
handful
of
patterns
that
we
can
use
to
mitigate
and
work
around
the
expectation
that
things
will
fail.
So,
for
example,
there
are
things
like
service
discovery
right
in
the
past.
We
would
we
would
use
IP
addresses
to
talk
to
the
other
computer
and
now
in
a
cloud
platform
where
services
can
be
coming
and
going
Auto
scaled
become
unhealthy
for
unknown
reasons.
The
network,
as
I
just
mentioned.
A
We
need
to
be
able
to
find
these
services
at
run
time,
service
discovery,
load,
balancing
when
we
start
sending
requests
out
to
these
different
services.
We
want
to
work
around
the
slower
ones
and,
as
they
move
around
as
they
fail,
we
might
need
to
do
timeouts
and
retries
and
employee
things.
Like
the
circuit
breaker
pattern,
security,
our
security
attack
surfaces,
become
become
greater.
We
need
to
account
for
things
like
being
able
to
route
messages
between
new
versions
as
we
deploy
new
versions
and
make
changes
to
our
software
and
the
previous.
A
In
the
previous
talk
again,
you
talked
about
continuous
experimentation
where
you
are
able
to
bring
an
experiment,
bring
a
change
out
to
production
and
limit
the
scope
to
which
the
traffic
can
get
to
us.
You
can
limit
the
blast
radius
when
things
go
badly,
but
you
can
only
do
that
if
you
have
a
way
to
control
the
traffic
and
and
honest,
we
need
to
collect
metrics
and
telemetry
about
what
the
services
are
doing,
how
many
requests
for
seconds,
how
many
are
failing,
how
many
being
retried
and
how
many
circuit
breaker
events
and
so
on?
A
We
need
to
build
this.
Our
applications
need
to
be
able
to
to
do
this,
and
this
is
not
an
entirely
new
idea,
but
the
big
cloud-
vendors,
the
Amazons,
the
Facebook's
googles
and
so
on.
They
they've
been
building
their
applications
in
this
kind
of
environment.
For
the
last
ten
years,
Netflix
was
kind
of
a
pioneer
in
the
open
source
space,
at
least
in
terms
of
sharing
their
code
sharing
the
way
they
solved
these
problems.
A
They
implemented
a
bunch
of
libraries
internally
for
for
Java
that
did
things
like
circuit
breaking
that
did
things
like
traffic
control
through
and
routers,
client-side,
load,
balancing
and
so
on,
and
that
started
to
pick
up
steam.
So
Netflix
release
a
lot
of
this
stuff
in
2012
around
I
think
it
was
2014
or
so
2015
spring
and
pivotal,
and
some
of
the
other
open
source
communities.
They
picked
up
this
Netflix
technology
and
started
run
with
it.
So
we
saw
a
derivative
technologies
like
spring
cloud,
how
many
people
were
I've
heard
of
spring
cloud
or
Java?
A
Maybe
how
many
people
are
Java
developers
just
a
handful
now
with
spring
cloud.
All
you
had
to
do
was
add
a
couple
annotations
and
you
could
get
all
of
this
wonderful,
Netflix,
behavior
right,
but
the
application
developer
was
still
responsible
for
putting
it
in
the
right
spot.
Configuring
it
the
right
way.
If
they
didn't,
then
it
wouldn't
be
consistent
with
the
rest
of
the
folks
that
we're
using
it.
But
what?
If
you're
gonna?
Maybe
your
Java?
A
Maybe
you
want
to
use
a
different
framework,
vertex
reactive
based
framework,
the
original
Netflix
OSS
libraries
we're
not
built
for
this
type
of
model.
What,
if
you're
saying
I?
Don't
Java,
that's
old
stuff,
I,
don't
I,
don't
care
about
that!
I'm
gonna
use
nodejs,
that's
what
the
cool
kids
are
using
and
then
you're
stuck
now.
That's
bring
bets
no
J.
This
is
actually
for
kids.
We're
gonna
use
golang,
but
python
is
actually
a
really
pretty
to
look
at
programming
language
and
believe
it
or
not.
People
are
still
using
Perl
to
build
their
applications.
A
A
You
also
have
to
hope
and
cross
your
fingers
that
each
language,
the
way
they
implemented
circuit
breaking,
let's
say,
is
implemented
exactly
the
same
across
all
the
languages
and
operationally
once
you
deploy
these
things
into
production,
this
becomes
very
untenable,
very
hard
to
to
maintain.
So
what
if
we
could
take
that
functionality?
That's
not
tied
to
any
specific
language
or
framework
right.
This
is
these
are
cross-cutting
concerns.
What
if
we
could
take
that
implement
it
in
one
place
and
allow
any
language
and
any
framework
to
to
leverage
that
that
implementation.
A
So
we're
look.
We
look
now
at
a
possible
solution.
How
many
people
have
heard
of
Andre
curious
awesome,
yeah
on
boys
in
the
CN
CF
I'm?
Always
one
of
the
time.
One
of
the
four
graduated
projects
in
the
CN
CF
so
envoy
is
a
service
proxy
that
is
written
in
C++
is
basically
a
network
filter,
so
the
bits
and
bytes
can
flow
through
envoy,
but
it
also
has
a
plug-in
system
or
you
can
implement
different
protocols,
application
level
protocols.
A
All
of
these
different
properties
that
we
need
these
capabilities
that
we
need
in
our
applications,
especially
as
we
start
to
go
toward
cloud-based
micro
services
to
all
applications.
We
need
to
solve
these
problems
an
envoy
does
this
anomaly
was
specifically
built
to
solve
this
problem
envoy
came
out
a
lift
the
ride-sharing
company,
and
it
was
specifically
built
in
C++
because
in
previous
generations
of
the
infrastructure
mat
client
who
built
it
came
from
Twitter.
A
He
a
lot
of
that
infrastructure
was
built
on
Java
on
the
JVM
and
at
high
load
JVM
would
be
doing
random
garbage
collections
and
so
on.
It
was
kind
of
hard
to
reason
about
at
this
load,
so
he
specifically
picked
C++
now
the
biggest
thing
about
Envoy
that
that
makes
it
appropriate
for
this
discussion
is,
it
has
all
of
these
functionality
and
we
can
apply
it
consistently
to
any
language,
any
framework
that
we
that
we
want,
but
this
very
last
bullet
that
it's
dynamically
configurable.
A
So
as
the
topologies
change
as
the
environment
changes,
we
can
dynamically
update
envoy
and
tell
it
more
about
its
environment,
so
it
can
work
around
failures
and
security
issues
and
and
so
on.
So
this
becomes
closer
to
what
the
architecture
looks
like
you
have
your
application
and
it
wants
to
talk
to
the
outside
service
or
database
or
message
queue,
and
all
of
that
communication
goes
through
envoy
as
a
little
bit
closer.
Look.
A
Now
we
start
to
form
a
an
understandable,
a
consistent
communications
mesh
and
that's
where
the
term
service
mesh
comes
from.
In
the
past,
we
tried
to
solve
these
types
of
problems,
like
I
said,
with
the
application
libraries
operationally
there's
some
challenges
with
that.
Even
before
then
we
solved
them
with
things
like
message,
queues
and
Enterprise,
Service,
bus
and
so
on.
Those
were
highly
centralized
systems.
A
Sota
smash
is
different
in
that
it's
not
language,
specific.
It's
not
framework
specific.
It's
a
highly
decentralized
implementation
of
solving
these
problems
and
it
solves
for
things
like
traffic
routing
traffic
control
security,
so
with
service
mesh.
Since
the
proxies
are
on
both
ends
of
the
transport,
we
can
do
things
like
automatically
encrypt
the
transport
without
the
application
having
to
know
anything,
we
can
do
things
like
policy
enforcement.
When
we
increase
both
ends
of
the
channel,
we
can
say
an
assert
that
service
eight
really
is
service.
A
and
service
B
really
is
service
B.
A
Now
we
can
write
policies
about
whether
or
not
they're
allowed
to
talk
with
each
other
and
then,
of
course,
the
resiliency
aspect,
the
timeouts
of
retries
circuit,
braking
and
and
I
saved
this
for
last,
but
it's
probably
the
most
important.
It's
the
metrics
collection,
telemetry
collection.
So
you
can
understand
what
it
is.
Your
system
is
doing
at
run
time,
so
you
can
understand
this
is
this?
Is
the
good
behavior
that
we
want?
So
you
can
know
you
can
see
it.
A
You
have
the
data
and
then,
when
you
introduce
new
software
code
changes
first
of
all,
you
can
use
traffic
control
to
limit
who
actually
gets
to
see
these
changes
and
then,
second
of
all,
you
have
access
to
all
of
the
network
telemetry
that
can
help
you
pinpoint
where
issues
are
so
we
can
drive
down
the
risk
of
doing
changes
and
we
can
lower
the
mean
time
to
recover
so
generically.
What
a
service
mission
implementation
looks
like
is
these
applications
running
with
their
sidecar
processes,
these
service
proxies
and
this
in
the
service
mesh
lingo?
A
Is
the
data
called
the
data
plane,
there's
where
all
the
requests
and
messages,
and
so
on
are
flowing
through
the
the
control
plane
is
the
set
of
components
that
is
used
to
manage
and
configure
and
and
inform
the
data
plane
about
how
it's
supposed
to
behave?
What
policies
it's
supposed
to
enforce,
what
circuit,
braking
and
load
balancing
algorithms?
It
should
be
using
now,
like
I
said
when
the
app
is
talking
out.
A
It
talks
first
through
the
proxy
if
any
traffic
is
trying
to
talk
to
the
app
that
first,
that
comes
in
through
the
proxy
and
then
when
it's
deployed
is
talking
with
other
services.
If
those
other
services
are
in
the
mesh,
then
we
can.
We
can
achieve
further
functionality
like
securing
the
communication,
asserting
identity
of
the
services
and
building
policy
on
on
top
of
that,
so
generically
service
mesh
technologies
typically
provide
these.
These
function,
this
functionality
load
balancing
circuit,
breaking
service,
discovery,
traffic
control,
shaping
the
last
bullet
again
very
important,
a
programmable
interface
programmable
interface.
A
So,
let's
take
a
look
at
a
few
implementations
and
some
of
the
details.
Some
of
you
might
be
interested
in
exploring
service
mesh
you've
heard
of
maybe
Sto
and
a
couple
of
these
others
and
you're
wondering
which
ones
should
you
use?
What
are
the
capabilities?
What
are
the
drawbacks?
We're
gonna
look
at
linker
D.
First,
how
many
people
have
heard
of
linker
D,
just
kind
of
curious,
okay,
linker
D
is
the
one
that's
been
around
the
longest.
A
It's
changed
its
implementation
recently,
the
last
couple
years
a
year
and
a
half
it's
backed
by
a
startup
called
buoyant,
but
it
is
part
of
the
CNC
F,
so
it
is
governed
by
a
neutral
semi
neutral
party.
It
is
intended
to
be
100%
kubernetes,
specific
they're,
not
trying
to
solve
service
mesh
problems
outside
of
kubernetes.
Of
course,
you
can
imagine
that
the
same
problems
we're
talking
about
exist
outside
of
kubernetes
and
we'll
look
at
other
implementations
that
are
trying
to
solve
that,
but
linker
D
is
not
trying
to
solve
that
they
have
their
control
plane.
A
So
they
followed
the
same
generic
architecture.
They
have
a
control,
plane
and
they're
their
data
plane
they've
built
the
custom
built
from
the
ground
up
their
data
plane.
They
call
it
the
linker,
D
proxy
in
a
language
called
rust
and
they're
in
the
middle
of
implementing,
and
continue
to
improve
that
and
continue
to
improve
the
languages
and
frameworks
that
they
use.
Underneath
the
link
OD
proxy
linker
DS
strong
focus
is
on
observability
and
observability
and
ease
of
so
what
that
means
is.
A
A
It
focuses
on
ease-of-use
and
grabbing
telemetry
from
your
services
and
being
able
to
inspect
the
telemetry
and
get
that
10-1
telemetry,
pretty
fine
grain.
Recently
in
the
2.3
release,
they
released
an
always-on
mutual
TLS,
so
encryption,
but
it's
the
encryption
part
if
the
proxies
are
running
on
both
sides
of
the
of
the
service
and
we
can
encrypt
the
traffic
going
over
the
over
the
transport.
A
It's
like
I,
said
built
for
kubernetes
attempting
to
be
as
simple
as
possible,
secure
by
default
and
deploy
transparently
to
the
application.
So
when
you
take
your
applications,
you're
writing
them
not.
Knowing
that
the
service
meshes
there
and
linker
D
allows
you
allows
you
to
do
that.
Console
is
another
implementation
of
service
mesh,
and
that
comes
from
the
past
record
folks,
so
the
same
ones
that
make
vault
and
terraform
and
and
others
now
console
Connect
is
pretty
new.
A
It
was
announced
last
summer
and
they
they
launched
with
a
particular
implementation
focus
really
at
the
elf
four.
So
not
the
application
level.
So
I
was
talking
about
how,
with
the
service
mess
with
envoy,
for
example,
we
can
understand
what
requests
and
messages
our
console
doesn't
have
functionality
built
at
that
level.
Right
now
they
say
its
forthcoming,
so
we'll
have
to
we'll
have
to
wait
and
see,
but
what
they
do,
focus
on
so
consoles
main
claim
to
fame
is
being
able
to
establish
identity
between
the
services.
A
So
they
come
from
a
background
of
being
a
service
discovery
registry.
So
they
know
a
lot
about
the
services
that
you're
using
and
they
issue
certificates
and
and
prove
identity
through
that
through
that
system
and
so
forth
at
once,
once
you
have
the
identity
proven,
then
you
can
use
those
certificates
to
encrypt
the
traffic.
A
Now
console
does
actually
leverage
envoy
but
they've
not
like
I,
said
they've,
not
built
up
the
capabilities
to
take
advantage
of
that
level,
seven
or
that
application
layer
capabilities.
So
the
control
plane
for
console
is
a
little
bit
different.
There's,
definitely
the
difference:
the
separation
between
control,
plane
and
data
plane
and
console.
A
This
follows
that
same
model
and
the
agents
are
in
charge
of
configuring,
the
proxies
and
and
and
getting
configuration
and
updating
them
and
so
on,
but
the
same
communication
model
with
with
console
where
the
applications
talk
to
each
other
through
their
through
their
proxies
here
are
some
of
the
strengths
and
opportunities
for
a
console.
Console
was
or
is
focused
on
being
kubernetes
based,
but
also
outside
of
kubernetes
console
has
a
lot
of
deployments
in.
A
The
applications
need
to
know
that
they're
talking
to
or
that
they're
in
the
console
environment
console
prefers
that
your
applications
talk
to
local
host
and
to
specific
ports
that
represent
other
services
in
a
kubernetes
environment.
You
can't
use
kubernetes
DNS,
which
is
unfortunate,
there's
no
l7
implementation
right
now.
You
have
to
manage
the
database
part
yourself
so
for
some
of
the
kubernetes
native
implementations
like
link
rd,
you
don't
have
to
because
Cabernets
itself
has
a
database
and
you
can
use
the
extensions
to
kubernetes
like
CR,
DS
and
so
on.
A
To
implement
em
sto
is
an
open
source
project.
This
is
the
book
on
topic
which
I'm
writing,
and
it
is
probably
feature.
Why
is
the
most
most
comprehensive?
It
is
backed
by
Google,
IBM,
lyft,
Red,
Hat,
pivotal
and
and
many
others,
big
big
community.
It's
it's
open
source
and
all
of
the
three
that
I've
talked
about,
including
SEO
right
now
are
open
source.
A
It
started
off
as
a
kubernetes
native
implementation,
but
there
are
works
by
other
companies
to
try
to
extend
SEO
to
play
nicer
outside,
let's
say
and
traditional
VMs
and
other
deployment
platforms
like
pivotal
is
written
extensions
for
a
CEO
to
run
in
Cloud.
Foundry
SEO
recently
has
kind
of
come
under
fire
for
being
too
big
and
too
complex
too
many
moving
pieces
too
difficult
to
understand.
A
But
if
CEO
does
a
lot
of
stuff
and
I'll
make
the
point
in
a
little
stronger
and
Allah
in
a
little
bit,
but
you
don't
have
to
use
all
of
that
stuff.
You
can
pick
the
pieces
that
you
need,
but
it
does
have
a
lot
of
stuff
the
different
components
for
managing
the
container
plane.
The
Citadel
you
see
on
the
left
for
managing
certificates
and
issuing
certificates.
The
mixer
component,
which
is
kind
of
become
controversial
for
doing
things
like
policy
enforcement
and
telemetry
collection,
SEO
strikes
it's
it's
a
fairly
large
project.
A
Sco
1.1
was
just
back
in
March
and
is
definitely
a
more
production-ready
version.
It's
based
on
envoy.
It
has
the
it
has
the
ingress
capability
out
of
the
box.
None
of
the
other
two
service
meshes
I
talked
about,
had
have
that
and
and
is
starting
to
support,
more
complex,
more
advanced
multi
cluster
and
multi
zone
and
multi-region
deployments.
Now.
The
the
other
side
is
that
when
you
do
first
approach,
SEO
you're
the
documentation
when
you
first
install
it,
it
does
install
a
lot
of
things.
A
A
Well
at
least
to
me
that
SEO
I
think
is
gonna,
follow
the
same
path
that
kubernetes
did
kubernetes
when
it
first
came
out.
1.0
1.1,
which
is
about
where
it
co,
is
right.
Now
kubernetes
was
not
very
good.
Mais
au
s--
was
kind
of
a
leader,
Cloud
Foundry
was
was
leading.
Docker
swarm
had
a
great
developer
experience,
but
Google
had
been
running
containers
and
running
infrastructure
like
kubernetes
for
the
last
12
years,
and
so
they
knew
where
all
of
the
bottlenecks
were,
and
not
only
did,
they
know
where
they
were.
A
A
The
last
match
that
we'll
look
at
is
the
AWS
app
mesh,
and
this
was
just
recently
announced
back
in
November
and
also
recently
went
generally
available
in
March
at
mesh
is
based
on
envoy,
which
is
awesome.
The
control
plant
components
you
don't
get
to
see.
That's
a
black
box,
that's
a
managed
service
from
Amazon.
A
Now
the
good
thing
about
at
mesh
is
that
it
does
support
more
than
just
kubernetes
or
container
based
workloads.
It
supports
things
running
on
eks.
Obviously,
you
can
bring
your
own
kubernetes,
but
you
can
also
run
app
mesh
on
ec2,
so
VMs
ACS
and
Fargate
ECS
they're
their
own
container
orchestration
system,
and
it
follows
a
very
similar
model
to
the
rest
of
the
service.
A
The
the
target
use
case
that
they
have
right
now
is
really
kind
of
light
traffic
traffic
control
and
weighted
routing.
There's
it
doesn't
do
too
much
if
you
want
to
use
the
observer
ability
pieces,
you
have
to
go
configure
envoy
yourself
now
the
interesting
thing
about
AWS
is
they
always
start
off
kind
of
small
and
then
slowly
and
incrementally
build
based
on
what
the
user
use
cases
are.
So
these
are
all
of
the
comparisons
that
I'm
talking
about
today.
These
are
obviously
just
point
in
time.
Comparisons.
A
A
Now
you
may
have
seen
different
articles,
especially
more
recently,
comparing
let's
say,
linker,
D
and
SEO,
and
in
one
article
written
by
the
Shopify
folks
and
where
it
was
awesome
that
they
shared
this.
They
found
that
in
the
default
setup,
Tio's
control,
plane
and
data
plane
used
vastly
more
cpu
than
linker
DS
and,
like
I
said
earlier.
Linker
D
is
very
purpose-built
and
very
focused
on
on
these
types
of
use
cases,
but
then,
in
a
follow-up
article
they
to
dis
do
a
little
bit
more.
A
They
took
the
mixer
component
out,
which
I
mentioned
this
kind
of
a
contentious
component,
and
they
saw
the
opposite.
They
saw
sto
Zim
performance
better
than
the
linker
D
performance
and
I
guess.
You
know:
I
talked
about
the
service
mesh.
Why
it's
there?
While
we
need
it,
we
looked
at
some
comparisons
of
strengths
and
we
and
opportunities
for
some
of
these
different
implementations.
I
pointed
out
that
these
are
just
point
in
time
descriptions.
A
But
the
point
is
I
I'm
not
going
to
come
up
here
and
compare
them
for
you,
it's
very
impossible
to
do
that,
even
in
a
single
organization,
what
you
should
focus
on
is
exploring
the
service
mesh
implementations,
picking
the
implementation
that
solves
an
immediate
need
that
you
have
today.
So
even
if
you're
going
to
go,
explore
sto,
don't
try
to
use
everything
or
put
everything
into
production.
A
Now
what
I've
seen
so
that
that's
kind
of
some
of
the
patterns
that
I've
seen
with
some
of
our
customers.
So
lo,
where
I
work
right
now
and
red
hat
before
so
one
of
the
other
important
things
is
I
see
people
implement
their
own,
their
own
configuration
objects
that
fit
their
model
and
workflow
better
because
these
serviced
mesh
configuration
objects
are
very
focused
on
what
the
service
mesh
capability
is,
but
the
successful
companies
that
have
seen
they've
kind
of
gone
off
and
built
their
own
call
it
an
API
on
top
of
this.
A
Now,
if
you're
going
to
go
off
and
try
service
mesh,
the
easiest
way
to
get
started
with
that
is
using
an
open-source
project
called
super
glue
from
solo
eyewear,
where
I
work.
But
the
point
of
super
glue
is
to
create
a
unified
API
that
abstract
away
any
of
the
implementation
details
of
any
one
specific
mesh,
and
you
use
that
use
that
API
and
you
can
get
started
very
quickly.
You
can
the
Shopify
person
when
he
was
doing
the
comparisons
between
the
different
meshes.
A
He
used
super
glue
to
quickly
get
up
and
running,
and
going
now
the
the
point
of
creating
this
API
on
top
of
service
mesh
is
really
so
that
we
can
manage
them.
These
service
mesh
implementations
at
scale
can
be
complicated,
so
super
glue
is
intending
to
be
able
to
support
multi
cluster
mesh
deployments,
Multi
mesh
implementation
and
multi
cluster
deployments,
but
we're
starting
off
with
a
nice
simplified,
open
API
that
eventually
people
can
also
extend
the
service
smash
without
having
to
worry
about.
Well,
that
is
do
when
it
changed.
A
It
changed
the
API
and
pray
and
make
breaking
changes.
What
if
I
start
with
linker
D,
maybe
maybe
I
start
with
linker
D?
Maybe
I
want
to
go
to
is
do
or
the
other
way
around
super
glue
allows
that
that
movement
here
was
Michael
kipper
when
he
was
the
Shopify
person
he
he
suggests
using
using
super
glue
to
do
that
now.
I'll
leave
you
I'm,
hoping
to
do
a
quick
demo
if
I
have
I
have
a
little
bit
of
time.
Is
that
all
right,
I'll
leave
you
with
I'll
post
the
slides?
A
We
have
leave
additional
resources
here,
reach
out
to
me.
I
know
it
kind
of
is
kind
of
a
whirlwind
tour
through
these
different
technologies
that
can
be
kind
of
complicated
I'll,
be
here
for
a
little
bit
after
so
come
find
me
and
ask
ask
questions
or
reach
out
to
me
on
any
of
these.
These
ways.
Ok,
so
I
do
want
to
show
you.
A
Real
quick,
how
we
can
use
super
glue
to
quickly
get
started
with
any
surface
finish,
so
the
first
thing
we're
gonna
do
is
we're
gonna
install
Sto.
Now
this
is
a
live
demo
I'm
running
on
a
cloud
provider.
You'll
notice
that
the
the
script
that
I
have
here
is
going
to
type
the
words
out
for
me
on
the
keyboard.
That
doesn't
mean
it's.
A
video
I
mean
it's
still
a
live
demo
things
good
falen
did
fail
on
Tuesday.
So
please
cross
your
fingers
for
me,
but
this
is.
A
This
is
gonna
type
it
out
for
me,
so
what
one
is
we're
gonna
do
is
super
glue.
Install
is
that
zoom
in
super
glue,
install,
is
do
and
give
it
a
name,
and
that
creates
a
CR
D.
So
this
is
running
in
kubernetes
if
you're
familiar
with
that,
it's
the
extension
model
of
kubernetes
and
the
CRT
is
used
to
track
the
installation.
A
A
A
A
With
Amazon
we
don't
create
the
control
plane.
Remember
that's
managed
by
AWS.
What
we're
gonna
do
here
is
register
the
mesh
with
AWS
and
then
we'll
use
we'll
use
glue
to
our
solo
or
superglue
to
be
able
to
install
this,
the
sidecars
service
or
the
service
proxies
into
the
applications.
So
if
we
do
demo
mesh
give
it
a
name
will
store
the
CRD,
the
the
registers
are
installed
CRD
into
a
particular
communities
namespace.
A
We
have
to
use
a
specific
secret
because
when
we're
talking
to
the
AWS
api's,
we
need
to
authenticate
ourselves
we're
going
to
run
this
in
the
same
region
where
our
kubernetes
cluster
is,
which
is
us
West
two,
and
it's
going
to
ask:
do
we
want
to
do
the
auto
injection?
So
when
we
create
a
new
service
or
set
of
services,
we
can
just
have
the
auto
injector
automatically
add
the
service
proxy.
A
A
A
B
For
the
amazing
talk
Christian
as
someone
who's,
only
dabbled
in
kubernetes
I
have
to
admit
that
I
understood
some
of
these
words,
but,
based
on
the
number
of
questions
you
you
received,
I
mean
slider
is
on
fire.
I.
Think
your
speech
was
invigorating
for
those
who
know
what
you're
talking
about
our
first
question
is
from
a
previous
speaker
of
ours.
Pavel
thanks
for
the
question
bubble,
how
do
you
ensure
a
control
plane
does
not
become
your
single
point
of
failure
and
if
it's
scaled,
how
do
you
sync
configuration
deployments.
A
So
I'm
gonna
I'm
gonna
give
the
answer
from
the
perspective
of
one
of
the
service
meshes
because
we
could
spend
all
day
talking
about
four
of
them,
but
so,
for
example,
in
a
NIST
EO.
The
control
plane
is
not
in
the
request
path.
So
when
requests
are
coming
in
from
users
and
they're
going
from
service
to
service
to
service
its
do
control
plane
is
not
in
the
request
path.
A
So
I
can't
get
updated.
But
you
know
if
the
control
plane
goes
down,
there's
probably
other
bigger
problems
that
you
need
to
solve
for
it,
but
it
won't
immediately
impact
the
the
request
flow
and
then
how
do
you
sync
configuration
deployments
in
is
Co
running
on
kubernetes.
The
configurations
come
from
the
kubernetes
database,
so
that
is
a
highly
ability
to
pull
highly
available
and
consistent
database.
So
all
of
the
configuration
that
we
give
to
sto
gets
stored
in
this
database
and
anytime.
A
B
A
Each
other
well
so
Google
started,
probably
called
key
native,
and
the
initial
implementation
of
of
K
native
came
with
sto
as
the
underlying
routing
layer,
so
K
native
was
intended
to
be
a
kubernetes
focused,
set
of
components
to
build
server
lists
or
function
as
a
service
style
applications.
So
SEO
is
an
option
as
a
routing
layer
there.
If
you
need
more,
a
more
simple
routing
layer
as
a
open
source
project
from
solo
called
glue.