►
From YouTube: KubeCon EU Office Hour: Why Service Mesh?
Description
Should your organization deploy a service mesh? Why? What problems does it solve? Join this panel discussion with OpenShift Service Mesh leads on how to make best use of a service mesh. Bring your questions!
A
Good
morning,
good
afternoon,
good
evening,
wherever
you're
hailing
from
welcome
to
a
special
edition
kubecon
office
hour
today,
we
are
talking
about
why
service
mesh
and
I'm
joined
by
a
bevy
of
red
hatters
and
let's
just
go
around
the
horn
and
introduce
ourselves
I'll
go
to
langdon.
First,
since
he's
a
usual
suspect
on
this
channel
this
time
of
day.
Sometimes
well,
maybe
not
this
time
of
day
but.
B
This
is
a
little
early.
You
know,
as
I
was
just
saying
in
my
wife.
You
know
these.
If
these
europeans
could
think
about,
you
know
doing
things
on
a
more
reasonable
time,
they'd
be
much
more
useful.
Obviously
it's
a
little
early.
We
did
want
to
kind
of
come
and
be
a
little
bit
more
in.
You
know
the
time
zone
of
the
of
the
actual
conference
you
know,
but
that
means
that
you
know
chris
and
I
are
as
often
as
the
case
suffering
for
coffee.
C
Right
thanks
landing
yeah.
Likewise
just
getting
getting
the
caffeine
flowing
this
morning,
I'm
so
I'm
I'm
jamie
longmir,
I'm
the
product
manager
here
at
red
hat
for
openshift
service
mesh.
I've
been
I've
been
here,
for,
I
guess
six,
six,
eight
months
now,
so
it's
been
kind
of
a
wild
ride
of
talking
to
a
lot
of
customers.
Who've
been
you
know
getting
on
their
service
mesh
journey.
So
I
think
this
is
kind
of
a
good
time
to
start
diving
into
a
little
bit
about.
D
F
Good
morning
everybody,
my
name
is
mauricio,
but
everybody
all
my
friends
is
coming
maltron
and
before
anybody
asked
no,
I'm
not
the
younger
brother
of
megatron
he's
my
uncle.
He
gets
great
chris
mcgriff
to
me.
I'm
the
product
manager
for
service
mesh,
most
particularly
for
kiyali
in
jaeger
and
I've,
been
working
for
redhead
for
almost
eight
years
now
and
it'd
be
quite
a
journey.
A
B
D
A
A
E
D
Actually,
let's
kick
off
with
a
question
here
I
mean
you
know
we're
seeing
a
number
of
scenarios
out
there
in
the
world
also
with
our
conversations
with
customers
on
a
daily
basis
here
around
you
know
what
they
ask.
You
know
why
service
mesh?
Why
would
we
use
service
mesh
in
the
enterprise,
as
we
know,
there's
a
number
of
compelling
reasons
for
that,
but
let's,
let's
use
that
as
a
starting
starting
point
to
kick
things
off.
C
C
I
think
because
I
think
it
was
sort
of
an
overarching
solution
that
solved
a
number
of
different
problems
for
people,
and
it
wasn't
really
you
know,
maybe
it
wasn't
clear
what
what
the
the
one
that
people
would
be
be
looking
to
to
grapple
on.
To
I
mean
when
I
came
in
here
from
a
developer
perspective,
I
was
mostly
thinking
around
the
lines
of
you
know.
It's
gonna
save
me
all
this.
C
It's
gonna
save
me
all
this
code
for
things
like
encryption
and
tls
and
and
instrumentation
and
error
handling
and
whatnot,
and
so
those
are
the
scenarios
that
I
was
thinking
of,
but
I
think,
as
I've
come
in
here,
it's
been
a
little
bit
different
with
regards
to
how
how
enterprises
are
picking
it
up.
It's
you
know
they
may
have
had
it's
kind
of
at
a
stage
and
it's
an
option
where
they
may
have
been
been
playing
with
it
in
a
few
different
teams.
C
So
a
few
teams
might
have
got
started
with
it,
but
now
they're
looking
to
go
more
serious.
So
you
have
like
these
more
centralized
operations
or
infrastructure
teams
they're
trying
to
standardize
how
they
how
they
roll
it
out
across
the
you
know
across
across
multiple
teams,
and
I
guess
if
I
were
to
sort
of
sum
it
up
as
to
I
guess
really
why
why
I
see
them
adopting
it
and
then
we
can
kind
of
expand
on
this.
C
But
it's
trying
to
bring
some
order
to
the
to
the
to
the
chaos
that
you
get
when
you
have
a
lot
of
different
teams
developing
microservices
here
and
there
it's
trying
to
bring
some
standardization
some
high
level
security
policies,
control
some
some
level
of
overarching
control
around.
You
know
things
like
who
can
talk
to
who
and
sort
of
need
need
to
know
and
what
not
around
around
inner
service
communication.
D
So
this
is
well.
This
is
more
important
than
ever.
I
guess
you
know,
with
a
lot
of
companies
out
there
adopting
a
cloud
native
approach
to
things,
and
particularly
you
know:
microservice
architectures,
where
you
have
you're
breaking
these
huge
monoliths
or
legacy
applications
into
smaller
micro
services.
B
Right
yeah,
but
if
we
talk
one
thing,
I'm
just
gonna
say
like
we
talk
about
it
like
it's
new,
though
right
I
mean
you
know.
If
you
go
back
to
like
service
oriented
architectures
people
are
constantly
looking
for.
You
know
mesh
deployments
right
to
be
able
to
keep
track
of
the
services.
You
know
you
look
at
something
like
corba,
you
look
at
something
like
you
know,
a
sun
application,
server
or
sorry
a
java
application
server.
You
know
all
those
they're
all
really
trying
to
accomplish
the
same
goal
right.
B
It's
like
you
have
all
of
these
different
pieces.
You
know
kind
of
happening
in
your
deployment,
whatever.
That
means
right
and
you
need
to
make
sure
that
you're
keeping
track
of
them
all
and
the
the
upside
to
kind
of
microservices
right
is
we're
kind
of
going
grassroots
up.
You
know
the
downside
is
we're
going
grad
streets
up,
and
so
I
think
and
and
what
I
think
is
interesting
about
this
conversation
like
about
service
mesh-
is
in
particular
the
enterprise
aspect
of
it
right.
It's
like
why.
Why
does
the
enter
like?
B
Why
does
an
enterprise
care
in
a
sense
about
why
about
all
these
services
in
perhaps
a
different
way
than
you
know,
a
different
kind
of
environment?
Might
you
know
like
a
startup,
or
you
know,
like
an
academic
environment,
or
I
mean
you
know?
Sometimes
those
are
enterprises
as
well.
I
mean,
but
the
point
is
like
what
are
those
you
know?
F
If
servers
say
talk
to
service
b
and
c
and
c
fails,
you
have
to
be
able
to
pinpoint
where
the
problem
is.
You
have
to
be
able
to
understand
exactly
how
to
cope
with
this
particular
problem,
and
you
want
to
avoid
disruption
at
all
times
in
before.
Even
we
talk
about
this,
this
tech
technologies,
like
you,
have
different
kind
of
libraries
that
trying
to
solve
that
particular
problem
and
also
manage
it
like
changes
over
time
would
be
incredible
challenges.
F
D
So
just
drilling
down
on
that
a
little
bit
more
their
motor
on.
How
would
have
that
worked
in
the
old
days?
You
know,
ie
pre,
pre-service
mesh,
for
example,
would
would
dev.
I
mean
well,
especially
in
large
large
enterprises
right
you're,
going
to
have
these
different
development
teams,
potentially
working
on
different
aspects
of
of
an
application,
whether
that's
a
monolith
or
whether
it's
a
micro
service
based
application,
but
I'd
imagine
they're
going
to
have
their
own
ways
of
wanting
to
communicate
between
each
other
and-
and
you
know,
definitely
with
the
service
mesh.
F
You're
right
on
spot
simon,
I
think
one
thing
is
like
people
really
jump
into
the
bad
way
to
go.
Microservice
and
people
are
already
embracing,
especially
we
have
to
ask
ourselves
exactly
why
microservices
now,
because
distributing
workloads
is
not
something
new
we've
been
talking
about.
Like
landon
said
we
talked
about
corba,
we
talked
about
all
the
other
kinds
of
discipline
workloads
in
the
past.
So
why
is
that
so
important?
F
Now,
and
if
I
have
to
guess,
I
would
say,
like
all
the
mobile
applications
that
out
there
even
apis
that
you
have
to
interconnect
it.
It
poses
like
a
huge
challenge
like
how
to
like
manage
like
a
bottleneck
workload
to
a
single
service,
so
you
have
to
be
able
to
distribute
it.
You
have
to
be
able
to
focus
on
those
single
services
that
address
one
single
customers
or
one
single
applications
or
even
mobile
applications.
F
So
this
this
kind
of
architecture
is,
has
come
to
to
stay
here
in
our
daily
lives,
and
you
have
to
be
able
not
only
to
deliver
those
applications
and
develop
like
applications
like
jamie
just
mentioned,
but
also,
I
think,
one
key
question
that
addressed
to
corporations
and
enterprises.
It's
like
once
we
deploy
it,
how
we
manage
them,
how
we
manage
changes,
how
we
make
more
secure
and
how
you
make
more
resilience
to
anything
that
happens
over
time.
C
I
think
I
think
one
one
thing
you
hit
on
there,
which
changes
in
particular,
is
something
something
I
think
relates
to
where
we
see
this
land
at
large.
Large
enterprises,
because
usually
service
meshes
like
service
mesh,
is
not
coming
in
as
it's
not
new.
As
you
know
his
language,
it's
not
sort
of
a
new
thing,
that's
driving
it.
I
would
say
it's.
C
A
lot
of
these
companies
are
going
through
digital
transformations,
where
they're
trying
to
change
how
you
know
they're
they're
trying
to
become
from
maybe
a
business
that
was
centered
around
being
say,
you
know
a
bank
or
a
retailer
before
and
become
a
primarily
a
technology
company
and
really
have
you
know
technology
first
and
so
they've.
You
know
they've,
you
know
they've,
maybe
re-architected
they
brought
in
new
development
frameworks.
You
know,
they've
had
sort
of
pilot
projects
here
and
there
to
get
started
with
new
microservices.
C
You've
got
someone
who's,
you
know
bringing
in
their
own
security,
libraries
and
and
and
then
those
services
may
have
to
talk
to
each
other,
and
so
there's
sort
of
this
big
mass
of
experimentation
which
they
you
know
they
want
to
encourage.
But
at
the
same
time
they
want
to.
You
know
not
have
teams
be
trying
to
try
to
do
the
same
same
thing
everywhere
and
start
to
bring
some
some
some
order
to
that,
such
that
you
know
as
in
any
company.
C
B
I
was
going
to
say,
like
I
think,
that's
an
important
point
that
gets
lost
a
lot
of
the
time
with
something
like
service
mesh.
Is
you
know
when
you're
you
know
kind
of
doing
development
or
application
deployment
or
whatever
at
like
kind
of
enterprise
level?
You
you
don't
not.
Everyone
is
a
guru
right,
it's
very
hard
to
hire
all
those
you
know
really
high-end
high-level
people.
B
So
what
you
want
to
be
able
to
do
is
kind
of.
Can
you
move
the
complexity
out
of
the
standard
developers
hands
and
into
some
shared
place
right,
so
it
sounds
like
jamie
at
you
know,
at
prior
company
right
prior
life.
They
did
that
with
kind
of
a
centralized
framework
which
is
fine
problem.
Is
it's
not
very
standardized
across
organizations
right?
You
can't
take
advantage
of
that
kind
of
knowledge.
B
In
other
places,
and
one
of
the
things
I
think
that
service
mesh
brings
to
the
table
is
that
you
can
actually
do
some
of
those
cross-cutting
concerns
or
or
what's
also
referred
to
as
like
aspect-oriented
programming.
Things,
like
you
know,
securing
all
the
services
to
be
able
to
talk
to
each
other
at
at
one
place
and
inject
it
into
each
of
your
services.
You
know
with
the
advent
of
like
webass
web
assembly.
I
mean
it's
webassembly,
but
I
can
never
remember.
B
I
can't
remember
what
the
cool
name
is
where
there's
some
wasm
wasm,
that's
it,
but
what
you
can
do
there
right
is.
You
can
actually
create
your
own.
You
know
whatever
you
know,
they
call
them
side,
cars
and
kubernetes,
but
the
idea
is
like
you
can
create
your
own
little
cross-cutting
concern
and
apply
that
across
your
entire
infrastructure
applications
or
services
without
requiring
you
know,
every
single
person
to
be
able
to
write
that
code
and
usually
those
cross-cutting
concerns
are
the
hardest
things
to
write.
B
In
particular,
because
you
can
take
the
take
some
of
that
hard
hard,
complicated
development
out
of
the
hands
of
your
junior
developers
put
it
into
a
couple
of
experts
who
then
write
it
for
kind
of
everyone
right
without
also
having
to
build
your
own.
You
know
software
framework
that
everybody
has
to
use,
and
you
know
when
some
people
like
rust
and
some
people
like
go
and
some
people
like
python
and
some
people
like
php.
You
know
writing
a
framework
is
not
trivial.
D
So
langton,
actually
you
touched
on
a
couple
of
things
there.
So
the
first
thing
that
that
stood
out
for
me-
I
I
mean
the
nice
thing-
is:
if
you
learn
this
skill
set
right
and
then
the
standardized
you
know,
skill
set
around
service
mesh,
it's
something
that
you
can
pick
up
and
apply
to
another
position
or
another
role
somewhere
else
with
another
company,
if
they're,
if
they're,
also
leveraging
the
same
framework
right
services
framework.
So
so
there's
something
in
there.
Personally,
you
know
with
my
developer
or
my
itops
hat
on
it.
B
Well,
it
goes
both
ways
right,
even
even
you
know,
there's
the
selfish
side
right
for
myself.
You
know,
then
I
have
more
transferable
skills
right,
but
also
for
the
enterprise
right.
You
know
if
you're,
if
you're
thinking
about
you,
know
hiring
new
developers
if
everything
that
you're
using
internally
is
standardized
your
your
barrier
to
entry
for
those
new
people
is
much
much
lower.
You
know
which
is
nice
so
yeah.
So
I
think
that's
a
very
good
point
and
I
think
it
goes
up
both
directions
right.
D
D
C
That's,
that's!
That's
a
good
good
question.
I
think
it
actually
plays
to.
I
guess
another
another
big
angle,
where
this
is
a
bit
different
from
the
enterprise
versus
say
a
small
small
start-up
company,
which
is
the
the
people
around
how
they
use
the
service.
The
personas
and
the
individuals
who
might
you
know,
might
support
my
management
versus
people
who
are
going
to
use
it.
We
see
that
this
is
something
that
I've
seen
a
number
of
companies
that
we're
we're
working
with.
C
So
we
have
a
couple
of
couple
of
really
large
banks,
they're
kind
of
rolling
things
up
out
like
this,
where
you
have,
you
might
have
a
centralized
operations
team,
that's
looking
to
roll
out
service
mesh
across
an
organization
and
they
might
be.
You
know
there
might
already
be
some
usage
there,
but
they're
the
ones
who
are
you
know
their
their
role
is
largely
to
enable
development
teams
and
to
to
give
them
the
you
know
the
the
the
tools
that
they
need
to
get
their
job.
C
You
know
done
as
easily
as
possible
without
having
to
worry
about
things
like
you
know,
containers
or
ip
addresses,
or
you
know,
the
kind
of
the
nuts
and
bolts
of
how
an
application
gets
deployed,
and
so,
at
least
with
a
lot
of
the
customers
we
work
with.
It
does
tend
to
be
more
of
a
central
infrastructure,
ops
team
that
is
looking
at
how
to
to
roll
it
out.
C
First,
people
who
are
who
are
going
to
use
it
is
is
something
that
we
and
that
we
see
and
that's
why,
with
openshift
service
mesh,
we
have
a
strong
distinction
between
the
cluster
administrator.
Who
is
a
person
who
might
again
roll
out
and
administer
that
service
mesh
and
they're
the
one
who's
going
to
be
supporting
it?
So
if
you
know,
if
a
development
team
has
an
issue
or
they
even
want
a
service
mesh,
they
might
reach
out
to
this.
You
know
this.
C
This
infrastructure
team
who's
going
to
deploy
a
service
mesh
instance
for
them
that
they
they
can
then
start
to
use
and
so
that
it
might
actually
be
the
team
itself.
That's
administering
that
service
mesh,
and
so
that's
why
one
of
the
unique
features
of
openshift
service
mesh
is
the
fact
that
it
has
this
multi-tenant
model
where
you
can
deploy
multiple
service
meshes
that
are
completely
isolated
within
an
individual,
openshift
cluster.
C
And
so
that's
that's
that's
entirely
for
that
model.
So
the
administrator
is
the
one
who's
gonna
gonna
have
a
view
and
some
level
of
control
over
all
the
mesh
meshes,
but
for
each
individual
mesh,
you've
gotta,
you
might
have
a
team
or
a
group
of
people
who
development
team.
For
example,
that's
responsible
for
a
set
of
services
and
and
they're
gonna
have
full
control
over
their
their
area
of
the
mesh.
F
One
thing
one
thing
is
important
like
most
of
our
customers
is
particularly
in
financial
institutions
like
large
banks
like
insurance
companies,
and
they
want
to
rely
on
on
something
that
really
is
enterprise
grade
level
that
you
can
start
using.
It
is
very
secure-
and
this
is
something
that
we
take
very
seriously,
especially
in
in
our
product-
is
trying
to
offer
something
that
the
customers
can
rely
on,
and
if
they
have
any
facial
problems,
they
can
like
see
red
hat
as
a
partner
to
support
their
in
their
particular
journey.
F
We
also
help
them
out
of
the
customers
trying
to
get
these
solutions,
but
sometimes
one
thing
that
we
see
as
one
big
example
in
2021
is
the
5g
rollout.
That's
happening
all
over
the
world.
So
a
lot
of
partners
is
trying
to
develop
like
solutions
on
top
of
service
service
mesh,
so
they
can
actually
cope
with
the
high
load
and
high
workload
demand
that
comes
from
these
particular
solutions,
and
also
they
have
to
be
able
to
trust
on
whoever
is
providing
the
service
mesh.
To
be
a
good
example
of
that.
Well,.
B
I
think
that
also
goes
back
to
kind
of
my
earlier
point.
A
bit
too
is
one
of
the
other
advantages
of
being
able
to
have
a
place
to
stick
cross-cutting
concerns.
Is
you
can
you
can
then
take
help
from
vendors
right?
You
can
take
help
from
third
parties,
because
somebody
else
who's
an
expert
in
you
know.
You
know
auditing.
B
Let's
say
you
can
you
can
take
a
widget
from
them
and
have
a
place
to
deploy
it
across
your
enterprise
or
across
your
set
of
applications
or
across
your
services,
and
do
that
in
a
really
consistent
way?
Without
the
you
know
the
at
least
for
me,
when
I
played
an
ops
person
on
tv,
as
I
used
to
say
the
I
was
terrified
of
ever
introducing
any
new
software
into
my
actual
environment
right.
You
know,
because
that's
it
puts
the
the
thing
that
I
care
about
at
risk
right.
B
So
even
if
I
need
to
ins,
you
know
in
institute
sorry
something
like
auditing.
Putting
that
actually
on
the
servers
makes
me
very,
very
nervous,
but
if
I
can
put
it
in,
you
know
in
the
concept
of
whether
it's
in
kubernetes
or
something
else,
the
concept
of
the
sidecar,
I
feel
a
lot
better,
because
I
know
that
if
it
goes
down
or
it
breaks
or
it
has
problems,
it's
not
gonna
break
everything
around
it,
at
least
in
in
ways
that
I
can't
quickly
quickly
get
out
of
right.
Yeah.
C
C
C
Well,
okay,
you
know
you
have
one
openshift
cluster
well,
at
least
if
you
know
something
that's
compromised
and
it's
in
it's
in
one
area,
it's
contained
to
one
mesh,
you
know,
even
within
that
one
mesh
you
can
specify
you
know
exactly
who
can
who
can
who
can
talk
to
who?
So
it's
you
can
you
can
really
contain
what
happens?
C
A
lot
of
a
lot
of
our
customers
asked
for
for
zero
trust,
networking
and
that's
a
bit
of
a
buzzword
across
the
across
the
internet,
but
I
think
it
gets
it
gets
lumped
in
with
with
service
mesh.
I
think
the
way
the
way
I
prefer
to
think
about
it
is
less
about
sort
of
zero
trust,
but
more
like
like
need
to
know
networking
where
it's
you
know
it's
not
so
much.
You
know,
let's
be
honest
if
it's
absolutely
zero
trust
nobody's
talking
to
anybody
and
nothing's
happening.
C
B
It's
similar
to
that
you
know
I
hate
to
constantly
quote
it,
but
I
think
it's
a
really
good
example.
You
know
the
famous
bezos
memo
inside
of
amazon
about
you
know.
Every
service
that
you
create
should
be
externally
accessible
right,
and
so
what
does
that
mean?
Well
that
means
that
every
single
service
that
you
have
you
need
to
have
some
sort
of
mechanism
to
do
a
login
to
pro
provide
like
attestation.
B
You
know
all
that
kind
of
stuff
which
is
not
something
you
think
about
when
you
do
things
kind
of
internally
facing,
but
I
think
the
this
advent
of
you
know
the
buzzwords
but
there's
you
know
like
a
lot
of
buzzwords.
There's
some
truth
to
it.
You
know
zero
trust,
networking,
there's
probably
others
that
I
can't
think
of
right
this
minute,
but
basically
the
idea
that
you
know
if
you,
if
you
consider
your
services
self-contained,
you
will
have.
B
B
I
actually
wanted
to
quickly
mention
just
because
there
was
a
question
here
in
the
audience
about,
and
we
have
some
other
questions
teed
up,
but
I
think
this
one's
quick,
which
is
basically
like
what
does
sre
and
service
mesh,
have
to
do
kind
of
with
each
other
and
one
of
the
things
that
I
think
is
really
it's
like
for
me.
It's
like
a
service
mesh
is
an
sre's
dream
right
like
like
that's
where
you
want
to
be
doing,
you
know
being
a
site,
reliability
engineer
if
you're
unfamiliar
with
the
term.
B
There
was
a
couple,
a
famous
book
about
it
a
few
years
ago,
but
basically
the
idea
is
instead
of
you
know.
You
know
basically
putting
out
the
fire
of
a
given
application
in
production.
You
figure
out
you
not
only
do
that,
but
you
also
figure
out
what
you
know,
what
lit
the
fire
and
keep
that
from
happening
in
the
future
with
something
like
a
service
mesh.
You
know,
and
I'm
gonna
definitely
give
it
to
maltron
here,
but
you
know
with
something
like
service
mesh.
F
F
Yeah,
it
was
a
way
to
test
it
out
with
your
microservices
before
going
to
productions,
so
you
want
to
get
as
much
information
you
you
could
doing
development
before
going
into
production.
So
when
something
fails
in
productions,
you
know
exactly
what
to
do
not
only
from
a
development
perspective
not
only
from
a
coding
perspective,
but
also
from
administration
in
operation
capabilities.
F
This
is
also
some
something
that
service
meshes
already
provides
right
there
from
the
start.
Even
when
we
start
the
development
on
top
of
service
mesh,
you
can
simulate
like
failure,
so
you
can
simulate
like
services
breaking.
You
can
understand
exactly
what
happens
when
networking
is
failing
between
each
service
and
with
that
information
you
know
how
to
handle
once
you
go
and
move
that
service
mesh
into
productions
sres
like
can
actually
pinpoint
the
problems.
F
They
are
more
aware
of
the
things
that's
happening,
and
one
thing
that
I
think
we
failed
to
mention
is
framing
works.
Like
you
said,
langdon
is
pretty
much
like
language
specific
right
and
that
that
was
really
good
like
back
in
the
days,
but
today,
like
you,
have
the
freedom
to
to
choose
any
language
you
want.
It
in
with
server
smash,
it
also
doesn't
rely
in
any
particular
language.
You
can't
speak
use
any
particular
language
and
that
boosts
your
innovations
in
your
delivery.
F
So
once
you
have
that
information
like
sres
this
does
they
don't
have
to
be
knowledge
about
any
part,
a
particular
computer
language
they're
using
server
smash
because
of
the
servers
that
are
pretty
much
concise.
How
the
work-
and
you
can
actually
all
you
have
to
do-
is
to
change
configurations
or
monitoring,
capabilities
or
being
able
exactly
to
pinpoint
what
the
the
problems
are
actually
failing.
F
F
B
You
know
the
the
thing
that
we
ship
and
we
call
open
shift
service
mesh-
is
actually
made
up
of
a
few
different
upstream
projects
right,
which
is
fairly
typical.
You
know
look
at
rel,
for
example,
it's
got
a
couple
of
other
things
in
there.
Besides
linux,
you
know
so
in
that
right.
What
we
actually
deliver
is
the
upstream
is
is
similar
to
istio
right
and
then,
but
then
there's
also
kiali
and
jaeger,
and
we
kind
of
we
feel
like
that.
B
D
Actually,
that's
why
it's
nicely
langed
into
a
question
that
we
had
come
through
on
youtube
there
around
exactly
that:
actually
application
profiling
and
performance
monitoring.
You
know
what
what's
on
offer
with
regard
to
service
mesh
with
regard
that,
so
I
think
that
that
answers
that
question
nicely.
F
So
I
think
I
can
answer
that.
Let's
one
thing
is
happen
is
like
based
on
the
architecture
of
the
service
mesh,
there's
one
particular
component
that
goes
together
which
service
we
call
the
sidecar,
and
this
sidecar
is
actually
communicated
between
all
the
meshes
and
also
the
people
actually
control
the
configurations
to
call
the
the
control
plane
and
that
information
is
come
across.
Also,
there
is
a
lot
of
telemetry
and
from
that
telemetry
we
have
tooling
tooling,
especially
in
the
issue
offering
and
also
in
our
products.
F
We
call
the
kiali
and
jager,
and
with
that
information
we
can
actually
see
graphically
in
that,
especially
for
sres
to
be
able
to
see
exactly
what
this,
what
it
is
service
available
to
them.
They
can
actually
track
the
traces
that
goes
from
one
service
to
another
and
trying
to
understand
exactly
if
there's
any
proper,
particular
problem
or
any
bottlenecks,
any
things
that
not
supposed
to
going
through
you,
you
can
act
on
it.
C
Just
to
add
to
that,
I,
I
think
a
key
point
for,
for
all
this
information
with
with
service
mesh.
Is
that
you
get
you
get
all
this
out
of
the
box
without
having
to
instrument
your
your
application
code
or
or
the
way
openshift
service
meshes
is
set
up.
You
know
you,
you
install
it
and
it's
it's
there
automatically
pretty
much.
So
you
just
you
know
once
you
once
you
add
your
sidecars
to
your
application
and
you
deploy
it.
C
You're
gonna,
have
you
know,
metrics
and
and
traces
that
are
going
to
immediately,
allow
you
to
start
debugging
your
or
doing
doing
you
know,
debugging
your
the
performance
of
your
application,
seeing
where
some
bottlenecks
are,
and
so
sometimes
I
mean.
Sometimes
people
have
questions
on.
You
know
what
is
what
is
the
performance
impact
of
of
having
these
proxies
and
that's
a
concern
for
for
some
some
people,
and
sometimes
sometimes
that
is
a
valid
concern
for
most
applications,
the
additional
the
additional
latency
that's
going
to
be
added.
C
There
is
going
to
be
so
small
that
it's
not
going
to
be.
You
know
a
part,
particularly
if
it's
an
end
user
application.
It's
not
going
to
be
so
significant
that
you're
going
to
you
know
that
it's
it's
going
to
have
a
major
impact
there
are.
There
are.
Obviously
there
are
exceptions
that
sometimes
we
we
have.
You
know
we
have
customers
that
are
that
are
using
service
mesh
at
a
very,
very
large
scale
and
are
really
pushing
the
boundaries
of
performance
on
it.
C
You
know
the
little
bit
of
lag
you
might
get
from
some
of
the
proxies,
so
it's
kind
of
like
a
and
that
changes
over
time
as
well.
So
you
might
you
might
profile
it.
Maybe
it's
things
are
things
are
running,
you
know
really
performant
now,
but
then
you
know,
you
know.
A
week
later,
a
developer
pushes
out
a
new,
a
new
patch
to
a
certain
service
and
then
suddenly
the
performance
changes
and
well.
C
You
know
that
this
is
where
service
mesh
is
going
to
help
you
capture
that
or
detect
that
bottleneck
immediately,
even
if,
even
if
the
team
responsible
for
that
service
had
hadn't
done,
any
telemetry
hadn't
really
thought
about
how
the
how
to
instrument
that
service.
So
it's
it's
getting
that
that
uniformity
across
a
system
that
I
think
really
helps
with
not
just
profiling
on
individual
service,
but
for
your
overall
system
of
services,
so
yeah.
D
C
Well,
it's
it's!
It's
all!
It's
all!
It's
all
relative
for
the
most
part
it
for
there's
I
mean
there's,
there's
a
there's,
a
page
on
the
like
we're
based
on
istio,
and
so
if
people
are
curious,
if
you,
if
you
google,
istio
performance,
there's
a
there's
a
page
in
the
upstream
istio
that
that
talks
about
the
relative
performance
based
on
different
low
request,
loads
and
and
obviously
the
you
know,
the
the
proxies
themselves.
C
C
Well,
I
should
say:
maybe
negligible
is
the
wrong
word.
I
mean
not
not
not
impacting.
You
know
like
if
your
overall
response
time
is
100
milliseconds,
then
you're
adding
you
know
two
milliseconds.
That's
not
gonna,
be
a
big,
a
big
impact.
If
it's,
if
you're
expecting
one
millisecond
and
it's
true,
then
it
is
so
it's
it's.
B
Like
this
goes
back
to
the
like,
this
is
this
is
one
of
those
types
of
questions
which
always
you
know
or
often
kind
of
frustrates
me
because,
okay,
you
know
so,
let's
say
there's
a
two
millisecond
overhead
or
whatever
yeah,
but
think
about
it
in
terms
of
a
different
way.
Let's
say
all
of
your
engineers
had
written
that
piece
by
hand.
Well
now
you
have
somewhere
between
you
know.
Maybe
maybe
some
of
them
are
are
really
brilliant,
and
so
they
get
it
down
to
one
millisecond.
B
B
Yes,
it
can't
be
an
unreasonable
amount
of
overhead,
but
at
the
same
time
recognize
the
trade-off
you're
making
right
is
that
it's
not
it's
not
just
about
numbers,
you
know,
and
so
I
think
it's
really
important
to
kind
of
not
don't
gloss
over
the
fact
that
you're
saving
lots
of
development
time
you're,
you
know
lowering
your
risk
of
application
bugs
right.
You
have
all
these
other
advantages
that
you're
getting
that
are
unrelated
to
you
know
a
slight
performance
impact
yeah.
F
D
B
D
Same
thing
here,
you
know
back
into
my
itops
or
it
admin
date.
Honestly,
I
would
have
given
a
left
leg
for
this,
because
I
used
to
work
for
a
a
large
multinational
oil
oil
company
and
I
used
to
be
responsible
for
the
service
in
the
north
sea.
As
administrator,
I
was
assaulted.
Buck
stopped
with
me,
basically
all
the
applications
running
on
there
and
basically
you
know.
B
Yeah
yeah,
I
mean
another.
Another
example
was
actually
regulation.
Side
too
is
I
did
a
lot
of
work
for
pharma
and
there's
a
there's
a
thing.
What
they
do
is
every
time,
there's
a
negative
drug
interaction
that
has
to
be
reported
to
the
feds
right
about.
You
know
the
fact
that
it
happened.
You
drop
one
of
those
on
the
floor
like
just
a
single
transaction
that
you
just
lost
right.
B
That's
a
million
dollar
fine,
you
know
so
so
it's
it's
not
only
the
kind
of
straight
up
kind
of
losing
money,
but
it's
also
there's
whole
regulatory
spaces
where
it's
a
big
deal,
if
you
you
know,
if
you
make
these
kinds
of
mistakes
so
yeah,
I
just
always
like
to
kind
of
give
there's
other
kinds
of
things
that
you
should
also
be
thinking
about
that
isn't
you
know
the
obvious.
You
know
how
many
dollar
transactions
are
you
making
yeah?
Definitely.
D
You
know
one
of
the
topics
we
touched
on
earlier
on
the
piece,
and
I
see
it's
come
up
as
a
question
and
the
chat
there
from
from
a
viewer
is,
you
know,
can
we
provide
sort
of
some
more?
You
know,
let's
delve
into
the
service
mesh
security
side
of
things,
a
little
more,
you
know
what
what
you
know,
what
what
does
service
mesh
come
with?
What's,
what's
the
you
know,
the
value
add
with
implementing
service
machine
security.
C
Yeah,
I
think
this.
This
is
where
a
lot
of
people
start
coming
to
service
mesh,
and
I
think
that
the
topic
on
you
know
talking
about
the
the
impact
of
of
you
know
of
service
being
down
for
a
short
time,
I
think
is.
That
is
a
kind
of
a
good
segue
into
this,
because,
where
we're
seeing
the
biggest
adoption
is
large
financial
institutions,
who
are
you
know,
implementing
workloads
where
they
they
really
care
a
lot
about
this.
C
So
I
think,
certainly
you
know
encryption
and
mutual
mutual
tls
is,
is
probably
the
big
reason
why
people
start
come
to
service
mesh
in
the
first
place.
So
you
know
if
you,
if
you
look
at
a
wide
service,
mess,
there's
sort
of
a
huge
menu
of
features,
while
the
encryption's,
the
biggest
one
that
that
people
jump
on.
C
First-
and
that's
I
mean
that's,
and
with
with
us
it's
something
that
with
openshift
service
russia,
I
should
say
we
think
a
lot
about
it
as
well,
so
like
what's
providing
the
encryption.
In
our
case,
we
we
use
we're
able
to
leverage
openssl,
the
openssl
libraries
that
are
that
are
created
by
the
the
red
hat
enterprise,
linux
team,
for
example,
and
so
we're
able
to
dynamically
link
in
those
open,
ssl
libraries
which
are
dips
which
are
actually
pips
validated.
C
So
they
you
know
they
go
through
the
the
lengthy
nist
process
of
getting
of
getting
getting
validated
and
we're
just
able
to
to
take
advantage
of
those.
So
that
means
without
going
into
the
sort
of
the
more
regular
regulatory
side,
is
that
those
those
those
libraries,
those
cryptographic
libraries
have
been
validated
by
an
independent
government
organization
with
their
their
own
testing,
as
people
know,
they're
getting
a
reliable
cryptographic
library
for
for
all
the
encryption
within
within
service
mesh.
C
I
guess
other
other
ways
that
we
really
consider
security.
A
lot
is
just
again
thinking
in
terms
of
need
to
know
with
regards
to
access
around
our
own
service
mesh,
so
we,
you
know,
make
sure
that
you
know
anything
that
requires
elevated
privileges,
won't
be
handled
by
the
development
teams,
that'll
be
either
a
cluster
administrator
or
in
the
case
of
openshift
services.
C
F
Just
recently,
myself
and
jamie,
we
talked
to
a
customer
who
has
actually
deployed
services
like
in
in
virtual
machines,
and
each
virtual
machine
needs
to
a
a
brand
new
certificate.
So
it's
like
extra
money.
They
have
to
pay
in
in
for
each
certificate
and
they
are
moving
to
service
mesh
exactly
one
of
the
way
exactly
to
get
to
make
sure
you
have
security
in
place,
but
also
for
from
a
cost
perspective
that
you
have
to
add
all
the
certificates,
all
by
yourself
like
manually,
say
so.
B
I
also,
as
anybody
who
watches
my
show
or
knows
me
knows,
being
kind
of
a
hardcore
linux
guy.
You
know
I
like
to
add
to
jamie's
point
is,
like
you
know,
all
these
bits
that
you
see
in
service
mesh.
Most
of
them
came
from
rel
right
rel's
been
doing
this
whole
security
thing
for
a
bit.
Now
you
know
20
years
or
something
so
you
know
we
have
a.
We
have
a
lot
of
the
same
interests
right.
B
We
you
know
the
open
ssl
that
we're
using
is
the
one
that's
coming
from
rel
right.
So
I
think
it's
important
to
remember
that
you
know
a
lot.
You
know.
Obviously
not
everything
that
is
shipped
in
openshift
is
also
shipped
in
rel,
but
a
lot
of
it
is
you
know
it's
like
building
an
application
on
rel.
You
know
we.
We
know
how
to
do
security
pretty
well,
and
we
like
to
make
it
first
enterprise
ready,
but
also
consumable
right.
B
So
you
know,
so
we
want
to
give
you
a
you
know
this
kind
of
product
or
set
of
products.
That
is
something
that
you
can
go
and
use
out
of
the
box
as
an
enterprise.
Without
having
to
you
know,
validate
every
individual
thing
and
we
actually
go
after
the
certifications
that
prove
that
what
we
say
is
true,
like
fibs.
C
So
I
went
yeah.
I
went
super
deep
on
that
question
into
the
into
the
sort
of
the
low
level.
I
guess
the
the
other
angle
on
security,
which
is
maybe
a
little
sort
of
more
general
general
service
mesh
at
a
high
level,
but
I
know
it
just
because
a
lot
a
lot
of
customers
talk
about
this
or
ask
for
this
is
just
having
that
high
level
controller
view
of
of
your
you
know,
of
everything,
but
but
in
terms
of
services.
C
That's
that's!
That's
more!
In
terms
of
services,
which
is
closer
to
business
domain,
which
is
so
you're
you're
kind
of
get,
you
know
you're
you're
being
able
to
apply
security
policies
and
rules
less
less,
so
at
the
level
of
you
know,
ip
addresses
and
infrastructure
and
more
at
the
level
of
business
domains
and
business
business
pieces.
And
so
I
think
this
is
another
sort
of
angle
that
servicemen
brings
to
to
enterprises.
That
might
be
a
little
bit.
B
That's
a:
I
really
want
to
kind
of
hit
that
as
a
use
case
too,
which
is
you
know,
somebody
asked
about
kind
of
what
are
the
use
cases
for
service
mesh.
Besides,
like
blue
green
deployments,
I
mean,
I
think,
that's
a
huge
one
and
I
think
it's
something
where
you
know
kind
of
your
typical
operator
right.
Your
typical
sysadmin
can't
can't
manipulate
their
environment
in
such
a
way
that
they
can
offer
security
at
that
level.
Right
or
you
know,
authentication
authorization
all
those
kinds
of
things.
B
You
know
one
of
my
other
regular
examples
right
is,
you
know
at
a
company.
I
worked
for
that
manage
pensions,
the
person
who
can
change
the
amount
of
the
pension
and
the
person
who
can
change
the
address
of
the
receipt
recipient
of
the
pension
are
two
different
people,
that's
very,
very
difficult
to
opt
to
to
cause
security
around
or
authentication
or
whatever.
B
Whichever
piece
you
want
to
call
it,
when
you
think
about
it
in
terms
of
network
security
right
or
you
think
about
it
in
terms
of
you
know,
moving
bits
around
right,
but
it's
very
easy
right
to
do
when
you
know
something
about
the
business
service,
that's
involved,
but
if
you
have
two
micro
services,
one
that
changes
the
pension
amount
and
one
that
changes
the
address.
Well,
now
it's
with
something
like
a
service
mesh.
It
gets
much
easier.
D
Yeah
definitely
I
mean
we've
touched
on
a
few
areas
here
like
we're.
Talking
about
you
know
security,
particularly.
That's.
That's
that's
one
area
that
we
sort
of
delve
deep
into
on
on
on
the
call
here.
You
know
what
other
areas
you
know
with
with
our
conversations
with
customers,
you
know:
how
are
we
seeing
how
they
adopting
service
mesh
because
there's
obviously
a
lot
of
areas?
You
know
you've
got
the
a
you
know.
The
blue
green
deployments.
You've
got
the
the
security
side
of
things.
The
application
performance
monitoring
do
do
most
enterprises
out
there.
C
Well,
I
guess
I
guess
what
I
see
is
some
some
do
try
and
do
that
yeah.
You
know,
I
call
it
eat
the
whole
elephant
and
I
don't
think
that
tends
to
work
well
for
any
any
technology.
You
know,
be
it
open
shift,
kubernetes
kubernetes
as
well.
I
think
that
that
also
can
be.
You
know
a
problem
which
I
think
is
also
why,
when
we,
by
the
time
we
come
in
oftentimes,
there's
been
a
pilot
here
or
there
of
some
team.
C
Now,
oh
my
god,
you
know,
and
you
know,
authorization
policies
and
a
whole
other
set
of
resources
and
configurations
that
you
have
to
learn.
It
can
be
extremely
overwhelming,
and
so
I
think
I
think,
first
of
all,
it's
key
to
identify.
Why
you're?
Why
you're
adopting
service
mesh
in
the
first
place?
Because
and
quite
honestly
you
not
everyone
needs
a
service
mesh.
You
know.
If
you
have
a
relatively
simple
system,
a
couple
of
services.
C
You
know
you
might,
you
might
not
need
one
and
if
you,
and
if
you
can,
you
know
if
you
don't,
if
all
you
need
is
like
an
api
gateway
or
you
know
or
an
ingress,
then
great
just
just
go
with
that,
but
and
then
once
once
you
once,
you
really
know
why.
I
think
then
it
becomes
easier
to
to
adopt
say
you
know.
If
what
you
want
is
the
again
the
mutual
tls.
C
Well,
then
you
can
you
know
you
can
just
start
with
the
few
policies
that
you
that
you
need
to
adopt
that
and
and
istio
will
even
let
you
do
it
in
an
incremental
fashion.
So
if
you
have
a
couple
of
services
that
you
want
to
bring
in
and
and
start,
you
know
set
up
use
use
sdo
to
to
to
manage
the
mtls
and
certificates
for
those
services
you
can
and
then,
if
you
have
others
that
are,
you
know,
maybe
they're
they're
they're
still
not
you
know
they're
they're
they're,
not
ready
for
that.
F
Yeah
another
scenario
why
we
see
our
customers
is
most
of
the
time
they
want
to
deploy
the
applications
on
top
of
service
mesh,
but
they
also
don't.
They
won't
be
sure
that
these
existing
services
are
able
to
communicate
to
other
existing
services,
so
cross
communications
between
things.
That's
not
necessary
service
mesh,
it's
another
area
of
concern,
and
I
also
maintain
the
security
maintain
this
stability.
F
So
I
think
jamie
is
right
on
the
spot,
you
have
to
be
easy.
You
have
to
be
able
to
learn
all
the
new
concepts,
that's
ever
smashed,
and
I
think
we
we
have
to
be
honest
with
everybody
here
on.
The
call
is
take
it
easy
and
just
bear
in
mind
that
not
necessary
service
mesh
is
the
solutions
for
everything.
F
Sometimes
it's
just
used
like
a
simple
api
management
can
actually
do
for
you
and
it
actually
can
involve
two
more
complex
architectures.
Then
maybe
service
mesh
can
actually
help
you
in
that
particular
service.
Mesh
is
also
something
that
either
developers
and
also
sres
have
to
be
able
to
understand
all
the
concepts
before
they
actually
move
into
production.
B
Well,
before
and
and
kind
of
understanding
kind
of
what
it's
doing
before
it
becomes
beneficial
to
them,
instead
of
just
another
headache,
another
infrastructure
piece
they
have
to
worry
about,
and
I
think
I
think
this
was
kind
of
the
point
of
your
answer
a
little
bit,
but
I
would
also
kind
of
say,
like
you,
don't
necessarily
need
to
adopt
a
service
mesh
as
the
as
your
first
rollout
right.
It
can
be
something
that
gets
incrementally,
not
really
incrementally
added,
but
more
like
something
that
can
be
added
a
little
later.
B
You
know,
as
you
see
how
your
environment
performs,
you
know
one
of
the
things
that
is
a
big
differentiator
of
kind
of
the
microservice
or
you
know,
cloud
native
or
whatever
you
want
to
call
it
architecture
push
is
that
we
can
do
things
that
kind
of
you
know.
I
talked
about
at
the
beginning
about
like
grassroots
level
rather
than
top
down,
but
it
kind
of
means
like
we
don't
have
to
make
every
decision
up
front,
and
this
is
a
huge
change
in
the
software
development
industry.
B
Right,
like
you,
know,
going
from
waterfall
methods
to
agile
methods.
You
know
all
these
concepts
is
about
incremental
change
to
your
environment,
to
actually
do
just
what
you
needed
to
do
a
service
mesh
deployment
in
some
ways
you
kind
of
have
to
do
a
bunch
of
stuff
at
once,
but
you
don't
have
to
do
it
immediately.
You
don't
have
to
have
and
jamie
talks
about
this.
I
know
a
lot
but,
like
you,
don't
have
to
have
one
service
mesh
that
covers
your
entire
environment.
C
Yeah,
I
think
in
general,
I
think,
of
the
service
message
being
better.
If
it's
scoped
to
a
team
or
an
or
an
area,
you
know
not
not
being
too
too
big
or
but
I
guess
it's
another
another
thing
I
just
want
to
quickly
throw
it
there
on.
You
know
how
how
to
adopt
service
mess.
One
thing
that
I
think
is
really
helpful
is
the
key
alley
tool
which,
which
gives
you
a
visual
representation
of
service
mesh
and
the
way
that
the
way
that
operational
service
meshes
is
set
up.
F
B
And
it
it
also
looks
really
cool,
so
there's
that
huge
advantage
that
speaking
especially,
is
like,
if
you're
a
developer
of
services,
one
of
the
things
that's
actually
sometimes
really
difficult
to
visualize
is
like
how
they
actually
all
hook
together,
especially
if
you're
a
more
senior
developer,
where
you
kind
of
just
get
pulled
in
to
kind
of
do
one
little
piece
or
whatever
getting
a
sense
of
how
everything
is
actually
working
is
way
more
challenging
than
you
might
think.
It
is
without
kind
of
graphical
representations.
D
Yeah,
even
in
the
game
with
my
xs
admin
hat
on
you
know,
that's
the
one
one
thing
that
really
stood
out
for
me
with
the
you
know,
with
the
openshift
service
most
offering
was
the
kiali
dashboard.
You
know
again
that
that
was
brilliant.
The
insights
that
provides
and
super
clear
as
well,
and
I
like
the
ability
how
you
can
drill
down
to
troubleshoot
and
everything
again
that
would
have
been
super
useful
about
10
years
ago.
For
me,
a
little.
B
Bit
later,
literally
22
years
ago,
ish,
we
wrote
a
visualizer
and
a
tracer
in
visual
basic
to
work
on
calm
across
the
hdp.
Because
of
this
exact
same
problem,
you
know,
like
we've
been,
you
know,
durandev
who's,
a
common
audience.
Member
on
on
the
channel
asked
earlier
is
like
you
know,
have
we
you
know,
and
I
kind
of
mentioned
at
the
beginning.
B
Have
we
been
looking
at
this
problem
for
a
while
and
I'm
like
yeah
just
me
like
just
me,
myself
have
wanted
an
answer
to
this
problem
for
a
long
time
and
I'm
not
sure
that
you
know
like
openshift,
service,
mesh
or
istio
or
any
of
the
other.
You
know
choices
are
a
complete
answer
yet,
but
it's
definitely
down
the
right
track.
It's
definitely
a
good
step
and
it's
definitely
got
the
ability
to
grow
in
the
right
directions
to
cover
the
any
other
use
cases
that
we
come
up
with.
A
All
right:
well,
we
got
a
minute
left
and
there
was
a
ton
of
questions
and
you
all
answered
a
lot.
So
I'd
like
to
remind
everybody
that
we
are
in
the
cncf
slack,
please
come
join
us.
The
channel
name
is
six
dash
cubecon
redhat,
and
we
can
continue
to
the
discussion
there
and
we
can
all
go
about
our
merry
little
day
and
know
more
about
service
mesh.
But
if
you
have
more,
questions
feel
free
to
join
us.
B
And
definitely
let
us
know
there
or
elsewhere.
You
know
if,
if
this
was
useful
to
you,
we
are
happy
to
do
more.
You
know
we
could
do
it
on
the
level
up
hour.
We
could
do
a
one-off
show,
you
know
and
and
talk
about
this
more.
You
know,
I
think
we
were
all
nervous
that
there
wouldn't
be
any
questions
at
all,
so
we're
pretty
excited
that
there
are
so
many
questions.