►
From YouTube: Istio Adoption Planning for Success & Problem Solving
Description
#IstioCon2021
Presented at IstioCon 2021 by Geoff Flarity, Jan Zantinge, & Liam White.
As service mesh gains wider adoption, more and more companies are looking to bring Istio to their organization. Istio will impact many teams, from operations to developers, and it’s important that they are well equipped. First you’ll hear a success story from the Square Cash team, who decided to move to Istio from Square’s homegrown Envoy service mesh. They’ll discuss why it was the right move for them, how they executed the move, and what they’d do differently if they were to do it a second time. Then we’ll generalize their learnings by exploring patterns we’ve seen firsthand for successfully bringing Istio into organizations.
A
Sure
so,
right
now
we're
living
in
two
worlds.
We
have
an
a
large
monolith
living
in
on-premise
data
center
and
we're
also
breaking
up
that
monolith
and
moving
into
the
cloud
there's
quite
a
number
of
things
now
running
in
the
cloud.
The
cloud
is
built
on
top
of
aws
using
eks
to
manage
it.
Nothing
too
unusual.
I
don't
think
about
the
our
deployment
but
running
kubernetes
and
we've
have
now
had
istio
running
in
between
services
in
the
cloud
and
also
helping
with
traffic
from
the
dc
to
the
cloud.
B
So
you
know
our
our
architecture
is
a
little
bit.
It's
it's
a
bit
strange.
We
have
two
service
meshes,
one
is
managed
by
square
and
one
is
managed
by
us
which
is
istio,
and
so
we
have
had
to
like
work
around
managing
the
transition
between
the
two
service
meshes.
So,
like
that's
one
of
the
main
interesting
problems
and
interesting
quirks
of
our
architecture,.
C
A
A
But
more
and
more
the
cloud
platform
team
is
looking
to
leverage
open
source
stuff
and
moving
away
from
our
own
kind
of
custom
made
stuff
it
just
it
isn't
scalable
we
just
it's
hard
to
get
enough
eyes
and
enough
coders
in
to
make
that
product
better
and
so
we've
kind
of
gone
all
in
on
kubernetes
in
general,
and
so
we
were
really
looking
for
a
kubernetes
first
cloud
native
service
mesh
to
deploy
and
moving
away
from.
You
know
our
own
custom-built
stuff.
B
And
I
have
nothing
to
add
there
yeah
that
are
basically
agreeing
with
what
jeff
said.
You
know
our
square
envoy
service
meshes.
You
know
it's
very
proprietary
and,
like
it
uses
a
lot
of
stuff.
That
square
has
developed
for
other
purposes
like
for
dns
and
stuff,
like
that,
and
you
know
kubernetes
we'd
like
to
have
something
that's
needed
for
that,
so
you
still
was
like
a
natural
fit
for
us.
C
A
B
Yeah
I
mean
like
when
we
started
this
whole
project.
We
had
a
few
objectives
like
jeff
said
and
like
we
had
a
few
features
we
wanted
to
maintain
and
then
a
few
features
we
wanted
to
like
to
make
use
of
right,
and
so
we
had
a
problem
with
long-lived
connections
going
from
the
dc
to
the
cloud,
and
so
that's
the
thing
we
wanted
to
resolve
immediately
with
the
deployment
of
istio.
We
also
wanted
to
simplify
certificate
management.
B
It
was
a
bit
of
a
manual
process
to
get
square
certs
like
square
square
sign
certificates
from
square,
and
so
we
wanted
to
sort
of
automate
that
a
bit
with
you
know,
istio's
ability
to
issue
search
to
workloads
and
those
would
like
the
immediate
benefits
and
then
yeah.
Like
jeff
said
we
had
a
bunch
of
ideas
for
things
we
wanted
to
do
in
the
future
as
well.
C
Okay,
so
that's
mostly
why
let's
discuss
a
bit
about
how
and
a
reminder
if
you
have
any
questions,
ask
in
the
sdo
construct
channel
and
I'll
and
I'll
ask
them
on
your
behalf.
So
can
you
talk
through
kind
of
the
adoption
strategy
you
took
so
obviously
jeff
more
from
an
organizational
perspective
and
yeah
from
a
technical
perspective.
A
Yeah
I
mean,
I
don't
think
I'll
have
too
much
to
say
here
other
than
from
my
perspective.
What
was
most
important
is
that
we
had
a
clear,
just
role
plan
in
terms
of
like
how
we
were
going
to
phase
in
the
istio
service
mesh
and
that
we
could
do
it
incrementally
and
that's
what
that's.
What
ended
up
happening
and
went
pretty
well
and
seemed
easy
from
my
perspective
as
the
pointy
headed
boss,
but
I'll,
let
jan
go
into
actual
details
there.
I
know
it
was
a
lot
of
work.
B
Yeah
for
sure
so
like
I
think
our
strategy
started
off
with
just
simply
trying
to
understand
what
istio
was
and
how
we
could
use
it
and
like
understand
the
concepts
behind
it
and,
like
you
know,
istio
can
be
kind
of
overwhelming
at
first,
but
want
to
get
the
hang
of
it.
It's
actually.
It
becomes
very
intuitive
and
easy
to
understand.
B
The
next
thing
we
wanted
to
do.
You
know
me,
and
my
colleague
is
we
wanted
to
outline
the
goals,
as
I
mentioned
before,
so
we
wanted
to
simplify
certificate
management.
We
wanted
to
like
handle
long-lived
connections,
to
enable
http2
and
grpc
and
that
kind
of
stuff,
and
we
wanted
to
maintain
a
few
things
we
already
had,
which
is
like
mtls
connection,
encryption
for
all
connections
and
so
on
and
so
forth.
Right.
B
So
then,
the
next
thing
that
we
did
was
we
wanted
to
set
up
a
poc
like
a
proof
of
concept
right,
and
so
we
created
an
environment
for
ourselves
that
was
connected
to
our
dc
and
would
allow
us
to
like
set
up
all
these
different
routes.
That
traffic
would
take
in
our
situation
specifically
going
from
the
dc
to
the
cloud
and
then
from
the
cloud
to
the
dc
and
then
within
a
cluster
itself,
and
then
between
two
clusters,
because
we
have
we're
done,
is
redundancy
across
regions.
B
So
we
have
a
cluster
in
east
and
a
cluster
in
west,
and
we
just
want
to
make
sure
that
we
can
still
send
traffic
across
across
those
boundaries
right
and
then
the
next
thing
we
wanted
to
do
after
we
set
up
that
pocs.
We
wanted
to
design.
You
know
exactly
how
we
wanted
these
things
to
flow,
and
there
were
a
few
quirks
that
we
had
to
work
around.
As
I
mentioned
earlier,
there
is
a
square
managed
surface
mesh
and
that
actually
was
already
kind
of
deployed
in
our
cloud
clusters.
B
Whoops
hold
on
so
we're
gonna
go
over
here
this
guy
here
yeah.
So
this
is
the
design
we
just
we
decided
on
to
handle
traffic
going
to
legacy
endpoints,
and
so
this
one
involves
the
square
gc
specifically,
but
it
actually
holds
true
for
our
in-mesh
stuff
too,
and
so
we
set
up
an
ingress
gateway,
an
istio
ingress
gateway
per
service.
B
That
would
then
use
the
certs
that
we
previously
provisioned
for
the
square
service
mess
and
four
square
in
general.
The
square
sets
I
mentioned
earlier,
and
it
would,
it
would
basically
open
a
port
that
would
listen
for
mtls
connections
using
those
square
certs
and
then
translate
the
the
mtls
at
the
square.
Mtls
requests
into
the
istio
surface,
mesh
requests
and
then
forward
them
on.
This
did
a
couple
things
for
us.
B
I
guess
in
a
in
a
cli
application
that
we
we
deployed
to
everybody
and
that
allowed
us
to
simply
run
a
command
that
would
bring
a
service
onto
the
mesh
in
an
automated
way.
We
could
then
watch
for
any
issues
that
came
along
with
it
and
then,
if
there
was
something
wrong,
we
could
quickly
take
it
back
off
the
mesh
and
like
leave
it
as
it
was,
and
so
at
a
as
a
at
a
high
level.
That
was
basically
our
strategy
and
I
think
it
worked
fairly
well
for
us.
C
Yeah,
I'm
familiar
with
that.
Typically,
what
happens
when
something
breaks
is
the
first
thing
that
gets
blamed.
Is
the
service
match?
The
second
thing
that
gets
blamed
is
kubernetes.
The
first
thing
is
the
service
mesh,
so
okay,
so
I
generally
think
of
this
in
kind
of
two
dimensions
right,
so
you
have
one
dimension.
You
mentioned
of
you
know
individual
incrementally
adopting
services
into
the
mesh
and
the
other
dimension.
I
kind
of
think
of
is
features.
So
did
you
have
like
a
certain
subset
of
minimum
features
that
you
adopted
everyone
on?
C
A
C
A
Yeah
yeah,
I
mean
from
my
perspective
I
think,
since
we
were
already
kind
of
like
running
our
own
in-house
service
mesh
in
the
dc,
there
was
that
that
subset
of
features
that
we
wanted
to
maintain
and
take
advantage
of
with
istio,
and
I
think
that
we've
been
more
looking
at
expanding
the
set
after
we
kind
of
came
on
with
that.
Like
parody,
if
you
will
but
jen
did
you
say
that's
accurate
or.
B
Yeah
for
sure,
like
I
did
kind
of
mention
this
a
little
bit
earlier,
we
did
have
some
things
we
wanted
to
maintain
like
just
mtls
between
services,
but
mostly
with
this
initial
migration.
We
wanted
to
make
sure
that
everything
was
working,
the
way
it
did
before
the
service
mesh,
so
that
we
could
start
making
use
of
newer
features
later,
and
we
would,
like
you
know,
drop
designs
for
some
of
the
things
we
want
to
do
in
the
future.
So
yeah.
I
think
that
was
really.
B
A
I
will
say,
though,
that,
like
once,
we
had
it
up
and
running
features
that
we
maybe
had
on
our
roadmap
got
put
to
the
forefront
based
on
different
production
issues
that
we
saw.
I
know
circuit
breaking's,
one
of
the
ones
we
were
like
always
planning
to
like
roll
out,
but
suddenly
that
became
very
urgent
and
it
got
moved
up
and
that
went
incredibly
well
all
things
considering
so
yeah.
I
think
that
kind
of
summarizes
things
pretty
well.
C
A
We
try
to
at
least
raise
awareness
about
the
existence
of
istio
and
like
the
features
that
it's
providing
the
product
engineers
who
we
consider
our
customers.
That
being
said,
I
think
that
the
product
engineers
are
very
focused
on
building
their
product
and
shipping,
their
features
and
they're
really
just
kind
of
looking
to
us
to
provide
them
with
guidance
and
consultancy
and
like
tooling,
more
specifically,
tooling,
self-service
tooling.
A
That
just
kind
of
like
makes
it
all
work
and
they
don't
have
to
think
too
much
about
so
it's
fairly
abstracted
away
from
our
customers,
but
the
glass
we
can
break
the
glass.
If
we
have
a
particular
customer.
That's
you
know
very
cloud
native
aware:
that's
an
option,
but
for
the
most
part,
people
are
content
to
just
kind
of
use.
Our
abstractions.
B
B
You
know
we
have
a
currently
like
an
in-house
thing
for
translating
an
hcl
manifest
into
like
a
helm
chart
or
something
like
that,
and
so
we
are
already
in
the
process
of
creating
for
our
service
owners
a
few
like
a
subset
of
configuration
for
traffic
that
they
can
use.
You
know
things
like
circuit
breaking,
providing
values
for
them
so
that
they
can,
you
know,
have
a
destination
rule
created
for
their
service
so
that
their
pods
don't
get
overloaded.
B
If
that
happens
right
and
then
on
top
of
that
to
be
able
to
handle
something
like
internet
ingress
and
allowing
them
to
specify
which
of
the
endpoints,
they
want
in
their
service
to
be
accessible
to
the
public
internet.
So,
like
that's
the
kind
of
stuff
that
we're
going
to
move
towards
over
the
next
few
months,
I'd
say
and
that's
the
kind
of
control
we
want
to
give
them
just
like
an
abstracted
level
of
control.
B
A
A
There
was
never
an
issue
and
it
was
just
part
of
like
the
iterative
rollout
process
and
it
felt
very
positive.
So
I
think
that's
that's
the
main
thing.
From
my
perspective,
I
think
in
terms
of
gotchas,
I
think
I'll.
Let
jan
talk
a
little
bit
about
the
fun
with
unix
domain
sockets.
I
think
that
the
high
level
there
is
that
unix
domain
socket
support,
isn't
always
amazing.
Depending
on
what
platform
you're
you're
trying
to
incorporate
and
thinking
java
in
particular
or
jvm
jen,
did
you
want
to
go
into
some
issues?
A
B
I
think,
once
we
got
past
that
it
was
pretty
easy
to
understand,
but
yeah
more
specifically,
the
technical
issues
surrounding
unix
domain
socket
support
like
we
ran
into
a
few
issues.
You
know
not
just
with
java
and
like
a
few
of
the
platform
specific
things,
but
we
did
have
a
few
issues
with
istu
as
well.
B
We
ran
into
some
issues
with
jetty
and
some
like
weird
headers
that
had
some
strange
contain
some
strange
characters
in
it
and
that
could
cause
jetty
to
have
some
issues
too,
and
so
we've
had
to
work
around
a
few
of
these
things
here
and
there,
but
like
otherwise.
I
think
the
unix
zoom
in
socket
support
and
in
istio
specifically,
is
vastly
improved
over
the
last
year
and,
like
I
haven't,
seen
any
real
issues
with
it.
B
We
did
recently
have
an
issue
upgrading
from
istio
one
seven
to
issue
one
eight,
but
that
did
eventually
get
fixed,
and
so
that's
very
it's
very
encouraging
that
this
is
getting
better.
But,
like
I
said,
the
java
stuff
is
not
necessarily
getting
better.
So
sometimes
you'll
have
to
find
a
find
ways
to
work
around
these
things
and
like
istu,
does
provide
that
kind
of
stuff.
B
So
maybe
the
best
piece
of
advice
around
unix
domain
sockets
is
maybe
just
to
avoid
them
for
now,
depending
on
your
your
platform,
but
like
yeah,
I
didn't
really
mention
why
we
use
them.
We
kind
of
consider
them
a
security
boom
and
then
also
you
know
there
is
the
the
the
assumed
performance
benefit
that
you
get
from
it
as
well.
B
A
Yeah
yeah,
I
think
one
last
thing
I'd
add
in
the
gotchas
that
we
encountered
was
the
love
of
long-lived
connections,
was
kind
of
like
a
reoccurring
theme,
and
I
don't
think
that
was
necessarily
istio
centric,
because
I
think
any
load
balancer
that
auto
scales
would
kind
of
cause
a
problem.
But
one
thing
to
be
aware
of
is:
if
you
have
clients
in
your,
I
forget,
if
it's
downstream
or
upstream,
but
you
have
clients
calling
into
the
mesh
and
they
like
long
live
connections.
A
C
A
Yeah
I
mean
so.
I
think
that
we
were
coming
from
a
place
where
on-prem
we
were
all
using
already
using
envoy
and
so
like
when
you
think
about
istio.
You
should
think
about.
You
know
it's
using
envoy
and
it's
a
control
plane
for
envoy,
that's
kubernetes
and
cloud
native
and
so
like
we
were
already
sold
on
the
cloud
native
part
and
we
were
already
sold
on
the
envoy
part
completely
separate
separately
of
this
project.
A
So
for
us
it
was
more
about
just
like
coming
out
with
a
roll
out
strategy
that
we
could
have
confidence
in
and
then
testing
it
so
like
testing
it
in
staging
environments,
testing
it,
and
we
have
our
own
platform
testing
environment
that
we
rolled
it
out
on
ahead
of
time.
I'm
taking
the
time
to
do
it
right
from
then
on.
Like
you
know,
we
don't
have
anything.
Particular
we
have
all
the
probably
common
alerts
around
rpc
connections,
dropping
unexpectedly
and
stuff
like
that
too
many
five,
five
or
whatevers.
A
But
there
isn't
there
isn't
a
ton
of
like
chaos,
testing
or
anything,
because
we
already
had
a
lot
of
confidence
in
envoy's
ability
and
yeah
istio
aco
impressed
us
from
the
start.
So
jan
do
you
have
anything
to
add?
There
did
anything
like?
Were
you
concerned
about
rolling
out
istio,
and
is
there
something
you
needed
to
do
to
build
confidence.
B
And
on
top
of
that,
while
we
were
like
rolling
this
out
or
getting
ready
to
roll
this
out,
we
did
some
some
stress
testing,
just
with
some
like
test
services
within
the
mesh
and
like
across
clusters,
as
well.
Just
to
verify
that,
like
you
know,
the
performance
was
what
we
expected,
that
we
had
the
proper
resource
requests
for
envoy
and
for
sdod
and
that
kind
of
stuff,
and
that
that's
what
allowed
us
to
build
confidence
that
this
would
actually
properly
scale
up
and
handle
like
increased
load.
C
Yeah,
okay,
so
that
is
time.
If
ever,
if
anyone
has
any
more
questions,
we'll
be
in
the
this
dukong
slack
channel
answering,
I
will
mention
that
both
square
and
tetra
hiring,
so
if
you're
interested
in
jobs
paying
either
jeff
john
or
myself,
depending
on
which
company
you're
interested
in
and
yeah
thanks
for
your
time,
guys.