►
Description
Istio: Weaving the Service Mesh [I] - Shriram Rajagopalan, IBM & Louis Ryan, Google
With the rapid adoption of microservices new tools are needed to load-balance, route, secure and monitor the traffic that flows between them. Istio provides a common networking, security, policy and telemetry substrate for services that we call a ‘Service-Mesh’. Come learn how the service-mesh helps with the transition to microservices, to empower operations teams, to adopt security best-practices and much more. We’ll also cover the state of the project, where it’s headed and how you can get involved.
About Shriram Rajagopalan
Shriram Rajagopalan is a researcher at IBM Research. He works closely with IBM's enterprise customers developing platforms and solutions for microservice deployments. He has had diverse experience in developing various aspects of the software stack over the last decade. He has worked on the Xen hypervisor, the Linux kernel, network function virtualization, and recently on the Istio service mesh and Lyft's Envoy.
About Louis Ryan
Louis Ryan is a Principal Engineer at Google working on APIs and microservices. Prior to working on Istio he co-authored the GRPC spec and ran the infrastructure that supports Googles consumer facing APIs.
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
A
So
we're
gonna
we're
gonna,
do
a
very
quick
run
through
a
bunch
of
stuff
about
sto.
You
know
that
the
content
is
pretty
dense.
The
timeframe
is
short,
we'll
leave
some
time
for
Q&A
at
the
end.
But
if
that
doesn't
work
out,
then
you
know
just
come.
Find
us
we'll
be
outside
and
happy
to
answer
as
many
questions
as
you
guys
have.
Okay,
so
we're
gonna
kind
of
power
through
this
a
little
bit.
So
what
is
the
service
mesh?
You
know.
A
The
mental
model
that
we
like
to
use
is
that
it's
a
a
network
for
services
and
love
for
bytes
all
right
today,
when
you
write
applications
today,
there's
a
lot
of
things.
Your
applications
have
to
worry
about
that
are
features
of
the
networking
layer
right
you
have
to
worry
about.
You
know
how
do
I
get
my
service
on
to
the
network?
How
do
I
expose
ports?
A
How
do
I
talk
to
other
services
on
the
network
and
there's
just
a
lot
of
networking
stuff
that
you
then
have
to
start
to
take
account
of
when
you
build
up
your
application
right?
Maybe
you?
You
know
you
have
our
pcs
going
between
two
different
services
in
your
network
or
your
REST
API
calls,
or
something
like
that,
and
the
network
doesn't
help
you
with
problems
that
you
face
at
layer,
7
right.
If
one
of
those
API
calls
fail,
your
application
has
to
deal
with
the
problem.
Right
maybe
has
to
retry.
A
Maybe
it
wants
to
know,
take
a
cached
response
and
serve
that
or
feed
that
information
back
upstream
instead
of
you
know,
trying
to
go
and
do
something
else
in
the
network.
So
there's
a
lot
of
networking
features
that
are,
you
know
you
end
up
putting
in
your
application
code
and
what
you'll
find
you
know
in
you
know
larger
IT
organizations
is
that
application
code
doesn't
just
happen
once
it
happens.
A
Or
maybe
you
don't,
you
know
your
your
teams
are
developing
these
features
differently
or
they
can't
agree
on
what
those
features
are
supposed
to
be
so
there's
a
lot
of
these
networking
features
that
now
being
baked
into
your
application
code
that
you
know
really
shouldn't
be
there
right.
There
should
be
something
that's
doing
this
stuff
for
you
and
that's
what
is
is
trying
to
do
right.
It's
trying
to
help
you
with
a
number
of
these
key
problems,
so
one
you
know
I
want
to
be
able
to
know
how
my
applications
talk
to
each
other.
A
You
want
resiliency,
so
I
do
a
little
bit
a
little
bit
about
load
bouncing
and
you
know
circuit
breakers,
failovers,
retry
and
there's
just
a
lot
of
complexity
and
that
stuff
that
if
you
end
up
implementing
yourself,
there
will
be
mistakes.
I've
certainly
implemented
resiliency
features
in
client,
libraries
before
and
regretted
some
of
the
horrible
things
that
I've
done
and
I've
seen.
These
things
fail
at
massive
scale,
so
be
very
cognizant
of
the
amount
of
actual
work
that
goes
into
making
this
stuff
fly.
A
You
want
control
of
your
traffic
right,
so
maybe
you
have
problems
like
you
know:
I
have
service
and
I'm
trying
to
roll
out
a
new
version
of
it.
I
have
to
move
traffic
from
the
clients
of
that
service
to
the
new
version,
but
I
don't
just
want
to
do
that.
You
know
all
at
once.
That's
that's
a
great
way
to
have
outages,
and
so
you
want
to
be
able
to
incremental
move
traffic,
and
sometimes
traffic
means
something
more
than
just
sockets
right.
A
It
means
you
know:
I
want
to
be
able
to
move
a
very
small
amount
of
HTTP
requests.
I
want
to
move
0.1%
of
HTTP
requests.
This
is
something
we
do
all
the
time
at
Google
when
we
do
production
or
all
that's
right.
We
very
carefully
siphon
all
the
percentages
of
traffic
or
subset
of
subtropic
to
new
versions
of
services
as
part
of
rolla,
and
then
you
want
to
be
able
to
do
policy
enforcement
on
the
traffic
right.
You
have
all
these
services,
you
need
to
know
who's
talking
to
them.
A
A
The
other
thing
you
want
all
this
stuff
for
free
right,
I
mean
you
guys.
This
is
an
open
source
conference.
You
guys
like
free
stuff,
I,
don't
mean
free
in
the
sense
that
you
don't
pay
any
money
for
it.
I
mean
free
in
the
sense
that
it's
not
part
of
your
total
cost
of
ownership.
Right.
It's
not
in
your
application
code.
You
don't
have
to
maintain
it
right.
If
you,
if
you're,
writing,
ten
load-balancing
libraries
in
ten
different
languages,
that's
actually
costs
an
awful
lot
of
engineering
effort
to
do
that.
Right.
A
I
know
because
I
worked
on
the
GBC
team
for
several
years,
and
we
did
that,
and
it
was
a
lot
of
effort
and
I
would
say
that
we're
still
working
on
it.
So
these
types
of
things
shouldn't
be
multiplicative
development
effort
costs
for
you
right.
They
should
be
something
in
the
infrastructure.
They
should
be
something
that
you
get
to
use
and
you
should
care
a
lot
more
about
that
than
you
know
the
dollar
price
tag.
You
know
you
call
attribute
to
buying
a
particular
feature.
A
Okay
and
last
of
all,
you
wanna
be
able
to
do
this
without
really
having
to
change
your
application
code
right
again,
a
total
cost
of
ownership
thing.
The
truth
is,
you
know,
having
worked
on
G
or
PC,
one
of
the
main
pieces
of
feedback
we
got
gee
herb
is
he
does
a
lot
of
this
stuff?
Is
that
that's
great,
but
I
have
40
applications
that
were
written
by
contractor
teams
two
years
ago.
Nobody
knows
how
to
change
the
code,
and
so
I
can't
adopt
it.
A
A
Okay,
so
we
talked
a
little
bit
about
you
know
a
network
for
services
and
not
for
bytes
I'm,
actually
gonna
hand
over
to
Sriram
at
this
point
and
he's
gonna
kind
of
go
through
some
of
the
implementation
detail
about.
How
is
geo
makes
this
magic
happen
and
then
I'll
come
back
in
at
the
end
and
talk
a
little
bit
about
security
and
policy
and
some
of
the
road
map
stuff.
B
B
Then
you
have
this
nice
property
where
all
of
these
ID
cards
together
form
a
service
mesh
in
some
sense,
a
layer,
7
Service
mesh,
where
you
can
have
full
control
over
how
traffic
transits
from
one
application
to
the
other,
which
versions
are
touches.
What
kind
of
timeouts
and
retry
policies
it
has:
the
access,
control
policies,
security
mechanisms
and
so
on
and
so
forth,
but
one
of
the
things
that
we
actually
did
and
it's
a
constant
decision
that
we
did
was
to
have
the
side
on
both
the
inbound
and
the
outbound
traffic.
B
The
idea
here
being
that
like,
then,
you
have,
you
have
a
psyche
on
the
outbound
traffic.
You
get
a
standard
set
of
features
like
timeouts,
retries,
tracing
fault
injection
and
you
know,
and
so
on.
Whereas
when
you
put
the
sidecar
on
the
inbound
path,
you
can
actually
impose
policy
control
mechanisms
like
who
can
access
the
service
or
rate
limit
mechanisms
and
so
on.
B
In
addition
to
being
able
to
do
other
features
like
you
know,
terminating
request,
traces
to
like
compute,
the
spans
and
the
causality
relationships,
you
can
do
fault
injection
and
you
can
do
a
whole
bunch
of
other
things
as
well.
So
with
this
as
the
foundational
thing,
if
you,
if
you
were
to
simply
look
at
this
picture
as
it
is,
you
will
quickly
like
you
know,
find
that
this
is
a
nightmare
to
manager
and
an
armada
of
side
cars
in
your
mesh,
and
so
naturally,
what
flows
out
of
this
is
a
control
plane.
B
Once
again,
it's
like
it's
extremely
hard
rocket
science,
but
it's
just
it's
a
bad
joke
away
with
within
our
control
plane.
What
we
have
is
like
a
standard
set
of
like
three
components
that
will
manage
anti
steel
mesh.
The
the
first
one
is
the
pilot
which
is
responsible
for
programming.
All
of
these
side.
Cars
like
whatever
configurations
they
want
in
terms
of
like
routing
to
different
services,
the
load
balancing
on
finishing
time
out
right-
and
you
know
the
traffic
routing
configuration
so
on.
B
But
you
have
an
application.
Writer
will
have
absolutely
no
idea
the
of
the
fact
that
the
sidecar
does
exist.
You
do
not
have
to
be
cognizant
of
the
fact
that
you
have
a
talk
to
sidecar.
It
happens
transparently
under
the
hood.
You
can
choose
dr.
sidecar
directly
if
you
want
to,
but
for
all
intents
and
purposes
this
is
completely
decoupled
from
your
development
processes.
B
So
what
happens
here
is
that
after
you
evaluate
the
policy
once
it
gets
cached
and
there's
like
a
sophisticated
caching
mechanism,
it
happens
within
the
proxies
such
that
for
the
next
I
don't
know
few
hours
or,
however
it
is
you
configure
it.
You
are
not
going
to
be
touching
the
mixer
at
all.
So,
for
all
intents
and
purposes,
there's
actually
no
mixer
in
the
data
path
or
it's
sort
of
an
in-place
component
that
happens
once
in
every
thousand
requests
would
matter.
B
So
with
this
we
chose
our
mo
as
the
our
preferred
sidecar.
Mostly
because,
like
you
know,
it's
compiled
attendance
rate
has
very
low
overhead
and
it's
the
native
language,
which
means
the
performance
gaps
is
like
you
know,
with
all
day,
garbage
collectors,
and
so
on
does
not
exist,
and
you
know
they.
It
has
been
battle
tested
and
run
at
large
scale.
The
folks
at
left
right
run
it
on
like
across
20,000
VMs
anding
about
five
million
service
requests
per
second
with
in
the
service
mash.
B
If
you
were
to
do
it
in
a
production
thing
and
the
ability
to
like
you
know
the
fault
injection
traffic
diverting,
as
you
know,
in
your
native
fashion,
like
as
a
core
feature
with
an
envoy
and
not
have
to
do
like
map
cookies
and
map
parts
of
request
and
do
like
you
know
all
sorts
of
circus
within
the
cycle.
So
with
all
of
this,
that
plus
you
know
these
guys
in
Seattle
are
just
nice,
so
first
to
be
a
very
nice
team
that
we
work
with,
and
so
it's
a
great
community
to
work
with.
B
That's
it
you're
not
tied
to
use
of
envoy
with
a
nice
to
your
mesh.
If
you
have
your
own
bespoke
sidecars
within
your
organization,
because
you've
already
spent
time
and
effort
incorporating
your
internal
protocols
in
it.
You're
welcome
to
like
just
swap
unwind
use
that
side
card
as
it
is,
and
there
is
nothing
that
prevents
you
from
doing
so,
and
there
been
folks
that
have
done
that
for
certain
internal
deployments
or
as
proof
of
concepts
as
well.
B
So
what
do
you
get
out
of
the
box
from
this
deal?
The
first
and
foremost
has
to
do.
Is
talked
about
is
visibility,
observability
and
metrics.
You
don't
have
to
rely
on
each
and
every
team
to
emit,
and
now,
like
one
or
mometrix
or
like
you
know,
you
don't
have
to
worry
about
the
fact
that
they
had
a
typo
in
all
the
matrix
names
and
suddenly
your
graph
on
our
dashboards
are
all
screwed
up,
because
somebody
missed
a
few
metrics
each
and
every
envoy
sidecar.
B
The
system
will
emit
a
consistent
set
of
metrics,
along
with
some
of
these
two
related
metrics,
that
every
service
in
the
system
will
actually
get
out
of
the
box.
So
this
reduces
this
has
a
tremendous
impact
in
terms
of
the
ops
overhead
you
no
longer
have
to
worry
about.
Like
you
know,
is
the
service
like
doing
like
working
properly
or
not
working
properly
know
each
and
every
service
is
emitting
the
same
stuff
like
heartbeat
metrics
that
you
want
to
look
for
like
response
time.
B
Latency
is
the
error
codes
histograms
for
like
certain
specific
properties,
daily
agencies
and
so
on
and
so
forth.
That
just
makes
life
so
much
more
easier.
In
addition
to
metrics,
we
also
have
support
for
the
quest
tracing.
This
is
essentially
useful
if
you
want
to
narrow
down,
you
know,
find
out
who's
causing
the
most
like
highest.
The
whose
share
of
latency
is
highest
in
a
request.
So
many
day
latencies
are
like
you
know,
exceeding
your
SLO
threshold.
Then
you'd
really
want
to
drill
down
on
those
specific
requests,
and
you
won't
actually
start
seeing
like.
B
Where
is
this
latency
or
energy
from?
Is
that
from
the
network?
Or
is
it
from
the
caller
or
the?
You
know
the
receiver
a
service,
and
this
is
where
tracing
actually
comes
in
helpful,
so
ARMA
has
support
for
like
open
tracing
by
default,
which
means
you
can
actually
use
a
favorite
pressing
provider
example,
candy,
ager,
light
step,
and
so
on
and
so
forth.
B
We
would
configure
tracing
across
the
services
and
as
well
as
application
writer,
the
only
responsibility
you
have
is
to
propagate
the
trace
headers
as
it
enters
your
application,
as
it
leaves
the
application
everything
else
will
be
taken
care
of
by
on
what
sector.
In
addition,
you
can
also
decide
to
vertically
trace
the
application.
Let's
say
you
have
a
big
java
application
and
you
want
to
trace
across
different
modules
within
the
application.
You
can
definitely
do
those
and
you
can
emit
the
same
set
of
traces
and
the
same
set
of
metrics.
B
That
is
to
your
image
to
the
mixer,
and
all
of
these
metrics
will
go
to
the
mixer
and
at
the
mixer
you
can
write
adapters
that
would
take
these
metrics
and
traces
and
send
them
to
any
internal
like
matrix
in
my
monitoring
system
that
you
want,
or
you
can
just
send
them
to
any
of
the
cloud
provider
systems.
This
once
again
has
a
big
benefit,
because
you're
no
longer
required
to
add
agents
that
are
specific
H
in
every
monitoring
system,
since
these
metrics
are
all
normalized
and
flow
into
the
mixer.
B
The
second
feature
that
you
actually
get
is
traffic,
splitting
traffic
steering
and
so
on.
This
is
a
slew
is
mentioned.
If
you're
going
to
be
like
in
under
probably
multiple
versions
of
a
service,
you
don't
want
to
have
a
different
service
for
each
and
every
version.
You're,
probably
gonna,
be
labeling.
B
So
this
is
an
example
of
a
routing
dude
that
you
would
just
that
you
would
write
and
you
don't
have
to
do
any
sort
of
the
deployment,
the
rolling
deployments
or
anything
about
sort
within
kubernetes
and
the
key
principle
or
the
key
takeaway
here
is
that
the
traffic
control
here
is
explicitly
decoupled
from
the
infrastructure
scaling.
So
unlike
kubernetes
and
maze
where
the
amount
of
traffic
that
a
pod
receives
is
a
proportional
to
the
number
of
pods
of
that
particular
type.
You
don't
have
that
requirement
here.
B
You
could
have
two
pods
and
split
traffic
99%
to
one
person
without
having
to
worry
about.
Like
you
know,
the
rolling
deployments
as
it
is
the
benefit
of
this
model
is
that
you
can
now
apply
Auto
scalars
on
each
and
every
version,
and
you
can
dynamically
scale
these
like
sort
of
pods
based
on
the
actual
node
that
they
get
so
like.
In
other
words,
not
all
of
us
received
like
five
million
requests
per
second
and
peak
load
day
in
day
out.
So
in
other
words,
not
all
of
us
have
like
a
million
pods
running.
B
At
the
same
time,
we
have
like
ten
pots,
2400
pots
and
being
able
to
do
these
kind
of
traffic.
Splits
is
intensely
helpful
in
such
scenarios,
and
so
the
other
thing
that
we
kept
being
asked
about
commonly
is
Hollway
like
expand.
The
service
mesh
I
have
my
own,
like
service
register
system
that
I've
been
to
keeper.
My
whole
infrastructure
is
running
on,
like
you
know,
like
para
metal,
or
it's
running
on
that
cloud,
foundry
and
console,
and
so
on.
B
A
There's
a
lot
of
things
you
want
to
make
do
implement
to
make
sure
that
your
systems
are
secure
right
and
there's
a
lot
of
different
threats
that
you
have
against
your
network.
I
mean
you
know
the
bigger
the
company.
You
are
perhaps
the
the
more
you
have
to
worry
about
these
threats.
These
are
things
that
we
worry
a
lot
about
at
at
Google.
A
Probably
the
first
thing:
it's
that
big,
bold
bullet
item,
big
bold
piece
of
text
at
the
bottom
Google
treats
its
internal
network,
says
insecure.
It's
not
that
they
are
insecure.
It's
just
that
this
is
the
mental
model
that
we
have.
When
we
come
to
security,
we
want
defense-in-depth.
We
don't
just
trust
the
network
blindly
to
protect
us
from
all
of
these
horrible
things
that
can
happen,
and
so,
if
you
don't
trust
the
network,
you
know
what
you
want
to
do
to
make
sure
that
your
services
are
secure
right.
A
A
What
was
the
chain
of
trust
between
developer
writing
code
bills,
getting
created
images
getting
put
on
a
repository
and
those
images
being
started
up
in
kubernetes
and
how
are
all
those
identities
tied
together
and
then
one
of
those
services
start
talking
to
each
other?
How
do
they
know
who
they
are?
A
These
are
all
the
types
of
you
know,
hard
security
problems
that
you
want
to
address.
If
you
want
to
have
these
types
of
defense-in-depth
postures
and
there's
a
bunch
of
stuff
that
you
guys
probably
want
out
of
the
system-
and
you
know
that
Google
does
right-
we
want
the
notions
of
workload,
mobility
and
we
want
the
workload
mobility
to
work
with
security
right
Network
perimeter
security
is
working
against
workload.
Mobility
in
some
sense
right.
It's
it's!
A
If
I
want
to
make
dynamic
choices
about
where
I
put
my
workload,
if
I'm
constrained
by
the
network
or
network
security
models
from
doing
that,
then
I
have
some
tension.
I
want
to
be
able
to
do
remote
admin
and
deployment
right
I.
If
I
have
to
be
on
the
physical
network
to
do
administration
of
services
right,
that's
gonna
make
your
ops
team,
not
pretty
responsive
right,
everybody
you
know
gets
to
go
home
for
the
evening,
gets
to
work
from
the
beach
hopefully,
and
so
you
can't
always
be
on
the
network
per
se
right.
A
You
also
want
a
security
model
that
works
across
vendors
and
third
parties
right,
and
you
want
to
be
able
to
share
your
notions
of
identity
with
them
so
that
your
services
can
interoperate
with
their
services.
These
are
important
things
and
you'd
like
to
build.
Do
this
again
for
not
very
much
cost
right,
so
you
like
this
to
work
with
your
existing
infrastructure,
and
you
know
that
means
working
with
your
existing
identity
models,
or
you
know
in
the
case
of
kubernetes
working
the
kubernetes
identity
model.
A
If
that's
what
you're
using
for
deployment,
you
want
to
rely
on
kind
of
commodity
technologies
to
plug
all
this
stuff
together.
So
you
know,
there's
a
kind
of
host
of
issues
in
this
space
that
we
want
to
solve,
and
SEO
is
trying
to
put
together
a
system
that
helps
you
get
eight
more
flexible
network
model,
while
also
having
a
stronger
notion
of
security.
So
how
do
we
do
this?
A
But
it's
this
emerging
specification
about
how
workloads
should
receive
identities
and
represent
those
identities,
so
they
can
communicate
with
each
other
in
a
secure
way,
and
so
we
have
the
SEO
certificate
authority
which
issues
certificates
to
kubernetes,
pods
and
rotates
them,
and
the
reason
why
we
rotate
them
and
we
rotate
them
quite
quickly.
Is
you
know
one
of
the
potential
attacks?
Is
those
certificates
get
stolen
or
the
workload
could
get
compromised?
A
And
so,
if
you
rotate
those
certificates
quickly,
if
one
of
your
security
responses
is
I'm
no
longer
going
to
issue
certificates
to
that
workload,
then
that
will
prevent
that
workload
from
able
to
talk
to
other
services
on
the
network
very
quickly
right
and
now,
you've
limited
the
blast
radius
of
your
security
exploit
in
time
right
when
you
think
about
security
right
and
you
think
about
attacks
against
systems.
Even
if
you
have
penetration
attacks,
you
want
to
be
able
to
respond
both
in
space
and
time,
and
this
helps
you
respond
in
time.
A
The
fact
that
we're
strongly
asserting
identities
between
services-
and
we
have
aqua
policies
that
says
service
a
and
a
strong
notion
of
what
service
a
is,
can
or
cannot
talk
to
service
B
allows
you
to
control
the
system
in
space,
and
so
you
get
those
two
properties
out
of
this
model.
So
that's
it's!
Do
security?
There's
up,
there's
a
whole
bunch
of
detail
here.
A
A
Don't
know
what's
going
on
with
the
Wi-Fi,
that's
great
okay!
So,
given
that
we
have
no
slides-
and
you
know
yesterday,
we
had
some
logistical
issues
too,
that's
kind
of
funny,
so
we
have
these
two,
your
security
model,
and
so
you
know
Shriram
talked
a
little
bit
about
this,
this
the
service
mesh
and
we
talked
about
policy
right,
and
so
you
know
you
want
to
be
able
to
enforce
ackles
or
constraints
and
how
services
talk
to
each
other,
all
right.
So,
based
on
these
strong
notions
of
identity,
you
know
when
service
a
called
service
B.
A
You
know
the
policy
may
not
be
as
simple
as
do
I
give
access
or
not
right.
You
might
want
to
enforce
a
constraint
on
how
many
resources
it
consumes.
You
might
want
to
use
quotas.
You
might
want
simple
rate
limiting
quotas,
where
you
say
service,
a
can't
call
service
be
more
than
a
thousand
times
a
second
or
you
might
want
something,
a
bit
more
refined
than
that
says
well
service
a
is
allowed
to
call
service
B
between
the
hours
of
8
a.m.
and
5
p.m.
A
in
Eastern
Standard
Time,
and
it
can't
use
more
than
a
thousand
calls
a
day
right.
So
we
have
a
component
which
you
know
you
saw
in
the
earlier
diagram
is
called
mixer
and
mixer
is
really
the
integration
point
in
sto
that
allows
you
to
customize
policy,
and
so
you
know
we
ship
or
we'll
ship
integrations
with
common
policy
engines
out
of
the
box,
and
we
know
we
build
in
some
of
our
own
policy.
A
Things
too,
for
you
to
use,
but
the
real
value
in
mixer
is
that
it's
this
convenient
integration
point
to
be
able
to
inject
policy
into
the
mesh.
That's
who
you
sto
will
help
you
get
all
this
stuff
running
and
you
know
bring
this
topology
so
that
you
can
then
start
to
enforce
policies
in
a
consistent
way
right.
A
So
let
me
talk
a
little
bit
about
the
roadmap
or
we
buddy
yeah,
so
one
of
the
key
things
for
the
math,
obviously
to
expand
the
mesh
to
as
many
places
as
possible
right,
we
started
out
with
kubernetes
because
we
like
to
run
at
ease
a
lot,
it's
a
great
way
to
run
workloads.
It's
also
a
very
convenient
integration
point
for
us
because
of
the
properties
it
has
as
an
orchestration
system,
but
most
of
you
probably
have
workloads
well
I.
A
That's
one
that
maybe
you
know
developers
doing
work
on
their
local
laptops.
It
may
be
your
massive
investment
in
a
proprietary
or
private
data
center.
It
may
be
a
rack
sitting
in
a
closet
in
your
office,
but
you
probably
at
the
ends.
You
have
a
whole
bunch
of
different
workloads
and
we
just
need
to
bring
more
and
more
of
that
stuff
into
the
mesh.
A
And
so
you
know,
shreya
I'm
talked
a
bit
earlier
about
how
we
start
expanding
the
mesh
to
include
service
registries,
which
is
a
convenient
way
being
able
to
get
more
information
about
workloads.
So
we
obviously
going
to
continue
to
add
support
for
service
registries
and
integrate
with
other
orchestration
frameworks.
A
So
we
have
these
two
kind
of
deployment
models
and,
if
you're
going
up,
might
you
know
migrating
a
large
service
over
it'll
almost
certainly
be
in
a
situation
where
you
know
you're,
starting
to
run
some
of
it
in
kubernetes,
but
you're,
still
keeping
other
stuff
in
another
environment
and
all
the
other
services
that
want
to
talk
to
it.
Shouldn't
have
to
care
about
where
that
workload
is
running
right.
We
want
to
it's
a
basic
premise
of
the
service
mesh
that
services
when
they
talk
to
each
other
shouldn't
care,
how
the
other
services
being
run.
A
As
part
of
that-
and
that
also
means
we
have
to
solve
some
network
visibility
problems
all
right.
So
when
service
wants
it
to
pay
once
just
want
to
service,
be
it
shouldn't
really
care
about
the
underlying
network.
But
that
means
that
the
astute
team
has
to
make
sure
that
you
don't
have
to
care
about
the
underlying
network
and
that
means
being
able
to
span
VPNs.
A
One
of
the
things
I
hear
is
that
you
know
sto
sounds
great,
but
it
also
sounds
like
there's
a
lot
of
stuff.
I
just
have
to
onboard
this.
To
you
is
actually
a
suite
of
tools
and
you
can
actually
install
pieces
of
it
to
meet
your
requirements
independently.
You
know
have
to
eat
the
whole
meal
at
once.
A
So
the
last
slide
is
you
know
it's
just
a
kind
of
statement
of
what
we're
hoping
to
target
for
our
100
release.
I'm,
not
gonna,
throw
dates
out
there,
because
this
is
software,
but
I
think
now
is
pretty
good
time
to
transition
over
to
QA
and
I.
Think
we
have
no
time
for
that.
So
if
you
want
to
talk
sure,
erm
and
I
will
be
outside
and
you
can
also
find
people
wearing
an
unlicensed
with
boats
on
them.
Very
not
logically,
oriented
conference
and
they'll
be
more
than
happy
to
answer.
Uris
to
your
questions.