►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Bringing the Envoy Service Mesh to Mobile - Jose Nino & Michael Schore, Lyft
99.999% reliability on the server is meaningless if mobile apps are only able to complete the desired product flows a fraction of the time. Learn how Lyft built, and deployed Envoy Mobile (envoy-mobile.github.io) in their Swift/Kotlin apps and is benefitting from a single, consistent Envoy-based network stack across every platform. Envoy Mobile was created to provide apps with the same network configurability, observability, and transport technologies that Envoy Proxy enables for the server - as if apps are simply another node on a service mesh. This unlocked a new tier of reliability on mobile and paved the way for many enhancements such as QUIC, request prioritization, and low connectivity handling. This talk will cover how this library was built, how Lyft tested it in their mobile apps, and what benefits they’ve already started to see.
https://sched.co/UaWW
A
All
right,
hi
everyone,
thank
you
for
coming
to
our
session.
This
is
the
first
talk
that
our
team
has
done
about
the
work
that
we
have
been
focusing
at
lift
for
the
past
few
months,
so
Mike
and
I
are
really
excited
to
be
here
and
sharing
this
progress
with
you.
In
this
talk,
we
want
to
introduce
you
to
envoy
Mobile,
which
is
a
child
project
of
the
Envoy
ecosystem,
and
it
is
building
envoy
as
a
multi-platform,
mobile
networking
library,
with
ongoing
mobile.
A
So
we
want
to
take
you
through
this
story
in
in
four
parts.
The
first
part
is
sharing
with
you,
the
motivation
for
why
we
want
to
bring
Android
to
mobile
as
any
other
project.
It's
a
it's
a
big
engineering
effort,
and
so
we
want
to
justify
to
justify
the
effort
with
all
of
you.
Next,
we
will
dive
deep
into
the
internals
of
Android
mobile
and
what
it
took
to
bring
envoy
into
our
mobile
clients.
A
A
A
All
the
way
through
and
through
from
the
edge
of
the
infrastructure
into
the
service
mesh
and
even
fronting
third-party
services
and
data
sort
of
storage,
primitives
envoy
has
done
a
great
deal
in
May
in
making
the
network
more
reliable
server-side
by
having
this
Universal
network
primitive,
that
is,
that
is
configurable,
extensible,
reliable
and
observable.
We
have
really
made
made
the
network
transparent
to
our
server
engineers
and,
more
importantly,
because
Han
boy
has
best-in-class
observability
when
problems
actually
happening
in
the
network,
we
have
made
it
increasingly
easy
to
debug.
A
However,
our
premise
with
this
project
is
that
3:9
server-side
are
actually
meaningless.
If,
then,
the
the
application
flows
that
the
users
interact
with
in
in
mobile
applications
are
actually
only
successful
a
fraction
of
the
time.
So
we
believe
that
with
Android
mobile,
we
can
extend
all
the
benefits
that
we
have
broad
server-side
with
Android
to
our
mobile
clients,
but
that
vision
requires
a
paradigm
shift,
because
traditionally
we
thought
of
mobile
clients
as
independent
from
the
backend
mesh,
and
we've
build
a
unique
solution
for
what
we
think
what
we
have
thought.
It's
a
unique
space.
A
So
we
really
can
say
that
envoy
has
become
this
true,
Universal
Network
primitive.
If
all
the
network
flows
for
our
four
mobile
platforms
start
and
end
in
the
mobile
client,
which
is
the
only
hope
that
our
voice
not
running
in
so
we
are
proposing
that
we
don't
need
to
treat
the
mobile
care
in
any
differently.
We
can
have
our
our
clients
become
another
node
in
the
network.
Another
part
of
this
homogeneous
mesh.
A
The
problem
is
that
that
current
solutions
are
platform-specific
both
for
ios
and
android.
So
we
really
can
have
this
true
networking
substrate.
That
is,
that
is
all
homogenized,
in
other
words,
there's
no
open
source
solution
that
is
giving
us
this
Universal
network
primitive,
and
this
is
where
we
believe
that
unblameable
fits
because
with
an
boy
in
the
class
and
with
mobile
in
the
client
and
envoy
server
side.
A
So
why
do
we
believe
that
standardization
is
important
between
the
mobile
client
and
the
back-end
infrastructure?
Well,
we
think
it's
important
by
largely
similar
reasons
of
why
standardization
in
the
backend
was
useful.
So,
first
of
all,
we
have
this
tenant
of
right
once
and
deploy
everywhere
by
having
this
universal
network
substrate,
we
can
embark
on
projects
that
would
have
otherwise
been
prohibitive.
Due
to
the
engineering
effort
of
trying
of
implementing
the
solutions
in
three
different
platforms:
iOS
Android
and
the
back
end
with
a
true
Universal,
Network
primitive.
A
Second,
we
can
share
common
tooling
for
common
problems,
so,
for
example,
by
emitting
the
same
metrics
everywhere
in
our
in
our
network,
topology
all
the
way
from
the
clients
to
the
edge
to
the
mesh.
We
can
share
the
same
infrastructure
and
the
same
visualization
tools
to
give
a
clear,
a
clear,
a
clear
flow
of
how
our
network
traffic
is
is
flowing.
B
All
of
this
sounded
really
compelling
to
us.
We
were
still
struggling
to
solve
a
set
of
problems
on
our
mobile
devices,
which
we
had
solved
elegantly
and
consistently
across
our
back-end
infrastructure,
but
we
were
still
left
with
the
question:
was
this
even
going
to
be
possible?
Envoy
runs
in
the
backend,
of
course,
as
a
server
in
a
dedicated
multi-threaded
process,
and
you
can't
do
that
on
a
client
there's
no
such
thing
as
a
sidecar
proxy
that
can
run
an
iOS
or
on
Android.
B
We
needed
some
way
to
actually
run
envoy
inside
an
app
the
only
kind
of
process
that's
allowed
to
run
on
mobile
devices.
A
lot
of
our
initial
effort
was
simply
invested
in
answering
this
question.
We
worked
to
actually
build
envoy
within
an
application
as
a
harness
and
just
get
the
server
started,
just
get
it
running
and
see
that
we
could
run
it
on
iOS
on
Android,
with
the
different
platforms,
OSS
and
architectures.
We
knew
we
wanted
envoy,
Mobile's
core
to
be
Envoy
and
once
we'd
answer
that
question.
B
We
used
Basil's
our
build
system,
not
only
because
its
envoys
build
system
and
offers
numerous
advantages
in
terms
of
incremental
builds
and
parallelizable
builds,
but
also
because
it
has
great
multi-platform
support.
We
knew
this
project
was
going
to
require
us
to
build
code
in
Swift,
Kotlin,
Java,
objective-c
C,
because
we
wanted
the
actual
core
the
library
to
be
platform
agnostic
and
share
as
much
code
as
possible
and
C.
B
We
actually
have
Envoy
itself
as
one
of
our
basil
targets
and
really
forms
the
core
of
the
library
it
does
all
the
heavy
lifting.
Then
we
have
code
that
interacts
with
envoy
and
then
the
blue
layer
in
the
middle
is
actually
our
bridge
code.
It's
the
code
would
actually
allows
the
platform's
to
call
down
to
envoy
envoy
to
call
back
to
the
up
to
the
platforms
without
is
actually
trying
to
embed
any
sort
of
platform,
specific
logic
in
the
code
that
works
directly
with
Envoy.
B
It
also
allows
us
to
potentially
support
other
line,
which
is
in
the
future
as
well
other
environments,
and
finally,
we
knew
we
wanted
application
developers
not
to
need
to
know
a
lot
about
envoy
in
order
to
realize
the
benefits
of
this
library.
We
want
them
interacting
with
interfaces
with
which
they're
comfortable
using
mechanisms
with
which
they're
comfortable,
and
so
we
have
platform
specific
code
to
provide
flexible
bindings
into
the
library
and
that
allows
platform
developers
to
use
the
patterns
are
familiar
with
again.
This
sort
of
forms
three
different
layers.
In
our
library.
B
B
B
To
start
to
answer
this,
it's
helpful
also
to
look
at
the
actual
context
under
which
code
can
run.
First,
we
have
application
threads.
The
application
threads
are
threads
that
are
owned
by
the
actual
app
they're
started
by
the
app
that
the
threads
or
other
application
recode
runs,
and
ultimately
it's
the
code,
which
will
eventually
need
to
call
down
into
envoy
to
issue
requests
in
order
to
library
to
be
usable.
B
We
made
the
decision
to
have
our
library
be
single
threaded,
just
to
allow
it
to
be
more
streamlined
and
operate
with
more
predictable
patterns
on
the
device
itself.
Fortunately,
for
us,
Envoy
itself
actually
is
largely
single
threaded
code.
Despite
the
fact
that
Envoy
is
a
multi-threaded
vibrant,
a
multi-threaded
server,
most
code
has
been
written
to
assume
it
runs
under
a
single
threaded
context,
there's
very
little
synchronization
very
little
shared
state.
Instead,
explicit
mechanisms
are
used
to
actually
communicate
across
threads
and
finally,
we
have
callback
threads.
B
B
When
a
client
goes
to
actually
use
envoy
mobile
first,
they
create
a
client
which
will
prefer
which
will
form
their
primary
interface
into
the
library
under
the
hood.
The
client
creates
an
envoy
engine
that
engine
is
then
actually
responsible
for
starting
envoy
Runner
thread.
The
Fed
will
become
envoy
his
main
thread
and
is,
in
fact
very
similar
to
envoys
main
thread.
They
are
the
same
as
far
as
envoy
is
concerned.
B
The
one
notable
difference
is
that
the
event
loop,
which
drives
envoy,
runs
under
a
very
different
pattern
in
envoy
mobile,
instead
of
running
almost
constantly
doing
bookkeeping
and
management
of
the
server.
Instead,
it's
primarily
reactive,
it
wakes
up
in
response
to
Iowa
vents
and
platform
calls,
and
that's
about
it
only
rarely
for
other
work.
B
Now,
in
server
side
envoy,
in
addition
to
ombos
main
thread,
we
have
worker
threads
when
envoy
is
functioning
as
a
proxy
when
a
request
comes
in
a
listener,
will
take
a
request
and
assign
it
a
dedicated
thread
which
will
stay
on
for
the
entire
lifetime
of
that
request.
When
that
worker
thread
needs
to
communicate
with
the
envoys
main
thread,
it
will
use
an
event.
Dispatcher,
that's
dedicated
to
the
main
thread
net
event.
Dispatcher
is
backed
by
a
low-level
event.
Library
like
live
event.
B
Additionally,
worker
threads
will
sometimes
need
to
perform
asynchronous
work
like
issuing
a
request
out
to
the
internet.
That's
a
side
channel
from
the
actual
main
proxying
pipeline.
This
could
be
to
perform
off
with
a
different
server
or
do
rate
limiting
it
uses
a
construct
called
an
async
client.
To
do
this,
we
took
an
event
dispatcher
and
an
async
client
and
use
these
to
form
the
core
of
our
alpha
release
direct
API
into
envoy.
Basically,
these
are
the
code
paths
that
we
use
to
actually
get
code
into
envoy
running
through
it.
Once
it's
been
initialized.
B
Now,
when
it's
time
for
a
client
to
actually
issue
a
request,
it
will
do
so
by
means
of
creating
an
HTTP
stream
at
the
bridge
layer.
We
have
these
platform
high-level
types.
We
have
NS
data
representing
buffers
or
potentially
byte
buffers
from
Java,
and
we
need
to
convert
them
into
something
that
envoy
can
understand.
This
is
the
work
that
our
bridge
layer
does
it
converts
them
into
C
types
that
can
be
mapped
directly
into
envoy
native
types.
B
We
have
another
issue
here,
however,
and
that's
at
the
memory
we're
getting
from
the
platform
which
is
essential
for
both
the
headers
and
the
actual
bodies
of
requests
is
owned
by
the
application.
It's
being
managed
on
iOS
by
AR
C,
by
automatic
reference,
counting,
it's
being
managed
on
Android
by
the
JVM
and
the
garbage.
Collector
and
Envoy
knows
nothing
about
this,
and
we
didn't
want
envoy,
didn't
know
anything
about
this.
B
B
This
is
an
elegant
pattern,
which
we've
been
able
to
extend
and
actually
avoids
a
lot
of
complexity
in
passing
this
memory,
notably,
it
also
avoids
us
needing
to
copy
buffers
unnecessarily.
We
can
use
the
same
memory
that
was
passed
to
us
from
the
platform
and
pass
it
all
the
way
down
to
the
socket,
that's
being
written
an
envoy
here.
B
You
can
actually
see
just
briefly
what
that
struct
looks
like
so
the
bridge
layer,
including
the
callback
that
on
will
uses
to
release
that
memory
in
a
forum
where
it's
entirely
agnostic
of
the
platform,
once
we've
converted
the
types
we're
ready
to
actually
pass
them
into
Envoy,
we
use
the
event
dispatcher
to
get
it
onto
the
main
thread.
The
async
line
issues
the
request
and
it
goes
out
into
the
Internet.
Importantly,
this
is
actually
the
same
code
past
that
Envoy
is
using
on
the
server
to
send
requests
the
Internet.
B
B
Once
we
get
a
response
or
get
an
error,
as
the
case
may
be
it's
time
to
actually
surface
that
information
back
up
to
the
platform.
Again.
First,
we
need
to
traverse
the
bridge
layer.
We
need
to
send
this
up
from
envoy
without
needing
to
tie
platform
specific
notions
in
the
code
that
works
with
Envoy.
We
want
this
to
be
portable,
so
these
callbacks
are,
at
this
point,
simply
function
pointers.
B
We
also
don't
want
platform
code
actually
blocking
envoys
main
thread,
since
it
does
have
important
work
to
do
in
a
wake
us
up.
So
we
also
need
to
get
things
on
the
cut
on
the
callback
threads.
We
achieve
this
by
means
of
dispatchers
that
are
provided
by
the
platform
and
unique
to
the
platform.
So
in
iOS
we
are
talking
about
Grand,
Central,
Dispatch
and
dispatch
queues
and
Android
we're
talking
about
executor
and
runner
bowls.
B
Now
we
still
have
a
problem
because
we
don't
want
envoy
or
even
the
bridge
layer,
to
really
understand
anything
that
the
platforms
are
calling
into,
and
so
we've
used
an
old
C
pattern
to
allow
the
platform
to
pass
in
state
which
neither
Envoy
nor
the
bridge
layer
knows
about
via
a
type
arrest
type
erased
context
parameter.
This
context
parameter
is
specified
by
the
platform.
B
B
Similarly,
we
knew
that
code
in
the
application
where
the
request
is
issued
might
be
very
far
remote
from
where
the
actual
response
is
being
handled,
so
to
avoid
a
lot
of
bookkeeping
and
tracking
that
would
be
necessary.
Instead,
we
provide
contracts
around
when
functions
are
called
and
when
callbacks
are
issued,
so
that
the
estate
can
be
largely
and
synchronized
really.
The
only
exception
to
this
is
cancellation.
B
We
dispatched
this
as
an
interrupt
in
both
directions
again
providing
strong
contractual
guarantees
and
so
forms
the
only
actual
atomic
shared
state
and
that's
a
high-level
step
through
of
what
the
architecture
of
envoy
Mobile
looks
like
today,
and
how
we're
able
to
actually
work
directly
with
high-level
platform
code,
but
still
call
into
envoys
internals
for
all
the
important
work.
That's
done
with
HTTP.
A
Well,
thank
you
for
that
excellent,
deep
dive
Mike.
So
with
all
that
built
out.
Let's
take
a
look
at
where
the
library
is
today,
both
as
an
open
source
project
but
also
in
its
integration
was
left.
A
few
weeks
ago,
we
released
version
0.2
of
the
library
which
we
consider
to
be
in
office,
state
ready
for
people
to
experiment
with,
while
the
API
might
change
very
slightly.
We
believe
that
the
design
decisions
that
we
made
are
our
sound
and
foundational
to
the
to
the
library.
A
Additionally,
and
perhaps
more
importantly,
for
a
little
over
a
month
now
we
actually
have
integrated
ongoing
mobile
into
the
lift
up
and
we
have
released
it
to
to
our
alpha
release.
This
actually
is
a
picture
of
our
team,
taking
the
first
lift
right
in
history,
where
all
the
network
requests
were
dispatched
through
envoy
mobile,
we
actually
went
and
grabbed
some
doughnuts.
So
let's
take
a
look
at
how
we
integrated
envoy
mobile
into
the
lift
up-
and
this
starts
with
how
lift
does
public
API
is
a
lift?
A
We
have
taken
a
model-based
approach
to
our
API,
so
what
this
means
is
that,
when
an
engineer
wants
to
create
a
new
public
facing
API,
all
they
have
to
care
about
is
writing
the
model,
and
we
have
chosen
part
of
both
to
do
that.
After
that,
our
generation
pipelines
actually
generate
clients
in
all
the
supported
languages
at
lift
both
for
mobile
clients,
but
also
for
our
back-end
services.
A
If
you're
interested
in
learning
more
about
our
mobile
or
model-based
API,
so
I'd
encourage
you
to
check
out
a
blog
post
and
a
talk
that
my
coworker
Michael
Roberto
will
put
up
and
they
lift
engineering
blog
data
this
year
after
our
after
the
the
generator
has
generated
this.
This
clients
for
us
we've
actually
gone
a
step
further
in
our
in
our
mobile
clients,
and
we
pre
compiled
this
files
into
into
modules
for
iOS
and
for
and
for
Android.
A
We
do
this
in
order
to
reduce
compilation
time
for
our
mobile
clients,
but
also
to
better
organize
our
API
and
manage
our
dependencies,
and
what
this
abstraction
really
has
done
for
us
is.
It
has
given
us
a
way
to
transparently
shift
implementation
details
about
this
kinds
without
interrupting
or
having
to
ask
our
client
engineers
to
upgrade
their
their
libraries.
A
More
specifically,
what
this
means
for
ongoing
mobile
is
that,
by
having
this
abstraction
layer,
we
can
transparently
remove
classic
networking
libraries
like
nsurl
session
for
iOS
and
ok
HTTP
for
Android
and
instead
put
in
Android
mobile
in
in
in
that
in
those
generated
clients.
So
replacing
those
API
calls
for
API
calls
that
we
exposed
in
the
platform
layer
that
Mike
was
talking
about.
So
let's
take
a
look
at
that
at
those
platform.
Api
s
and
something
that
I
want
to
highlight
here
is
that
we
have
made
it
a
goal.
A
The
project
to
actually
have
nearly
identical
priority
between
the
the
ergonomics
of
using
the
platform
API
in
iOS
and
in
Android.
So
while
here
up
top,
you
see
swift
and
Kotlin
moving
for
and
we're
just
going
to
show
the
swift
code,
but
you
can
assume
that
the
code
link
code
looks
nearly
identical.
A
A
Then
you
can
build
a
request
with
the
request
builder
and
the
API
paths.
Are
you
that
you
want
to
hit
at
this
point?
We
have
also
exposed
ways
to
custom,
headers
and
also,
and
more
importantly,
to
change
the
behavior
that
this
week,
the
network
behavior
that
this
request
will
have
so,
for
example,
here
you
can
see
that
we
can
attach
retry
policies
to
this
request.
A
So,
lastly,
you
build
a
response
handler
and
this
is
the
object
that
is
going
to
receive
those
callbacks
back
from
the
engine
that
that
Mike
was
describing
so,
for
example,
when
headers
come
back
on
the
stream
or
when
data
come
back
that
comes
back
on
the
stream.
These
are
the
handlers
that
are
gonna
deal
with
that
to
wrap
it
all
up.
You
submit
the
request
and
response
handler
into
the
engine,
and
then
the
engine
gives
us
a
way
to
interact
with
the
open
stream,
for
example
by
sending
data,
and
and
until
you
close
it.
A
So
what
we
have
integrated
on
going
mobile
at
lyft
based
on
this
model
based
API
is
we
actually
want
to
make
the
library
an
easy,
drop-in
replacement
for
all
sorts
of
patterns
in
in
mobile
in
mobile
clients?
So,
for
example,
we
want
to
expose
bindings
for
the
classic
networking
libraries
like
NS
euro
session
in
iOS
and
ok
HTTP
in
Android,
so
we
started
this
project
with
the
premise
that
mobile
clients
were
really
primed
to
to
receive
the
benefits
of
envoy
that
we
have
seen
in
back-end
services
with
the
alpha
release
of
Android
mobile
at
lyft.
A
We
embarked
on
this
journey
and
we
started
with
observability
so
as
as
you
may
know,
envoy
has
best-in-class
observability,
for
example,
it
flushes
nearly
hundreds
of
time-series
metrics
that
have
become
really
essential
for
lyft
engineers
to
monitor
the
network.
Well,
now
that
Android
mobile
is
running
in
our
mobile
clients,
we
have
access
to
those
same
metrics
coming
from
the
mobile
clients.
So
here
the
goal
is
that
engineers
are
able
to
really
monitor
and
observe
the
network
and
to
end
using
the
same
tooling
and
the
same
concepts.
A
Metrics
is
one
of
the
places
where
we
have
already
started
to
receive
dividends
from
building
Android
mobile
on
top
of
the
Android
core,
because
envoy
on
voice
is
a
high.
Extensibility
has
given
us
access
to
different
stat
sinks,
and
specifically,
it
gave
us
access
to
the
metrics
service,
which
is
a
way
to
get
envoy
metrics
out
of
of
Android
mobile
using
protobuf
and
G
RPC.
So
we
build
a
very
small
G
RPC
server
that
just
receives
those
metrics
and
then
emits
them
to
our
already
existing
observability
infrastructure.
A
And
what
this
really
allows-
and
this
is
a
very
powerful
part-
is
it-
allows-
allows
us
to
build
dashboards
like
this,
where
up
at
the
top,
you
see
metrics
coming
from
our
mobile
clients,
in
this
case
the
total
number
of
upstream
request
and
then
complimentary
at
the
bottom.
You
see
the
same
metrics
at
the
edge
of
our
infrastructure.
I
really
want
to
highlight
how
powerful
this
is.
A
It's
giving
us
insight
that
we
didn't
have
before
coming
out
of
the
mobile
clients
and
it's
giving
us
a
way
to
really
monitor
the
network
all
the
way
and
to
end
using
the
same
constructs.
This
is
really
the
first
of
many
examples
of
the
possibilities
that
we're
unlocking
by
having
ongoing
Mobile
in
our
mobile
clients.
B
B
Additionally,
working
on
next-gen
protocols
was
previously
something
that
was
really
out
of
the
reach
of
most
organizations.
Someone
like
Google
or
Apple
could
do
it
sure
they
have
huge
resources
in
terms
of
engineering.
But
again
you
have
to
build
this
for
different
platforms
and
ensure
interoperate
with
envoy
mobile.
You
can
build
the
single
stack,
a
single
stack
and
run
that
single
stack
reason
about
that
single
stack
and
actually
be
able
to
deploy
something.
That's
consistent
envoy
is
also
an
incredibly
extensible
platform
by
means
of
its
filter
chain.
B
B
That
aren't
we
see
this
as
something
we
can
extend
to
clients,
selecting
cellular
or
Wi-Fi
connections
based
on
network
conditions,
falling
back
from
ipv6
to
ipv4
for
networks
that
don't
support
it
or
similarly,
from
quick
and
UDP
based
proto
calls
the
TCB
based
protocols
when
needed,
Jose
shared
the
model
based
API
that
we
use
a
lift.
We
actually
plan
to
expose
support
for
this
directly,
an
envoy
mobile,
despite
also
supporting
standard
HTTP
with
the
model
based
API.
B
B
When
you
need
to
failover,
you
could
do
it
by
virtue
of
envoy
configuration
that's
distributed
via
XDS,
as
opposed
to
actually
needing
to
use
server-side
controls
for
it
or
when
it
comes
time
to
roll
out
a
new
pop,
rather
than
need
to
roll
out
new
clients
with
new
dns
configuration.
Instead,
you
could
do
it
via
Envoy
configuration
and
even
beyond
mobile
phones.
Envoy
Mobile
is
truly
a
cross-platform
library
we're
already
exploring
integration
with
lifts
fleet
of
rentable
transportation
devices.
We've
considered
IOT.
B
We've
also
had
interest
from
folks,
even
just
looking
to
use
it
as
a
replacement
Python
networking
library,
because
at
the
end
of
the
day
it
is
a
high
performance,
C++
library,
under
the
hood,
the
C
bindings
there
make
this
all
possible
envoys
success
is
a
platform
is
largely
because
of
its
vibrant
community
that
has
contributed
from
open
source
across
different
disciplines
and
across
different
organizations.
Envoy
mobile
is
also
being
developed
completely
in
the
open.
B
D
B
We
definitely
it's
something
you
have
to
be
concerned
about
right,
so
if
you're
talking
about
sending
down
dynamic
configuration
or
even
potentially
in
the
future,
dynamically
executed
code
like
via
web
assembly
or
Lua,
which
are
supported
by
on
boy
filters,
that's
something
you
have
to
be
concerned
about
envoy,
of
course,
does
have
mechanisms
already
in
place
for
doing
both
encryption.
You
know
via
TLS,
and
also
authentication,
whether
that
be
certs
or
another
mechanism
like
oh,
so,
you'd
have
to
be
careful
about
what
you
built
and
what
you
accepted
in
terms
of
configuration.
B
Security
is
definitely
something
we're
thinking
about.
We
wouldn't
actually
include
functionality
in
library
that
could
introduce
arbitrary
configurations
or
run
arbitrary
code
without
putting
a
lot
of
thought
into
it.
That
said,
there
are
cases
where
envoy
mobile
can
actually
potentially
make
things
even
more
secure.
Just
today,
envoy
already
has
support
for
client-side
certificates
for
TLS
for
certificate.
Pinning
you
can
do
a
great
deal
more
configuration
around
what
kinds
of
TLS
connections
you're
willing
to
make
under
what
circumstances
with
Envoy.
Then
you
can
out-of-the-box
with
pretty
much
anything
else
out
there.
B
A
B
Actually,
we
already
have
binary
sighs
in
CI,
so
we're
already
tracking
that,
because
of
this,
an
item
of
concern
for
mobile
applications-
and
we
did
early
on
see
performance
issues,
that's
part
of
why
we
retuned
envoys
main
event
loop.
So
it's
much
more
relaxed
now
envoy
is
basically
not
doing
work
now,
unless
there's
networking
happening
at
this
point,
there
you'll
see
very
little
impact
outside
of
maybe
degenerate
conditions.
F
A
So
we
had
to
to
layer
answer
I
think
the
first
answer
is
right:
now
we
we
expose
the
ability
to
continue
no
configure
the
the
frequency
at
which
you're
actually
emitting
metrics
later
on.
We
actually
want
to
create
interfaces
where
we
can
actually
batch
metrics
and
only
flush
them,
for
example,
when
the
app
is
getting
background
there
or
gonna
be
killed,
so
we're
only
actually
getting
you
know
emitting
metrics
when
that's
happening
and.
B
It's
configurable,
as
the
other
part
of
that
answer
right.
So,
no
matter
what,
if
you
want
increased
insight
and
what's
happening,
you're
not
to
send
something,
and
the
best
answer
to
that
is
I
think
we
can
try
to
send
it
as
efficiently
as
possible
and
let
whoever's
using
the
library,
decide
what
they
want
to
send
and
how
often
they
want
to
send
it.
G
You
know
awesome
project
I,
like
the
initial
announcement
from
Matt
Klein
on
this
I'm,
just
wondering
you
have
on
my
mobile
and
Envoy
are
in
the
server
side.
Let's
say
I'm
a
you
know
my
company
decides
to
adopt
this.
What
is
the
advantage
that
you
guys,
you
know
not
right
now,
if
not
right
now
or
in
future
as
well
in
terms
of
connectivity,
we
use.
Seo
also
would
like
to
say
stick
to
you
steer
for
being
having
envoy
as
a
sidecar.
So
what
is
yeah?
That's
the
question.
G
Basically,
if
I
want
to
bring
on
my
mobile,
just
like
left
word
for
their
app
for
any
app
in
general
or
even
IOT
going
forward.
What
is
the
advantage?
I
see?
You
know
library
and
functionality
and
algorithm
being
similar
and
being
shared,
and
maybe
being
more
slim
slim
doubt
for
smaller.
You
know
resources.
But
what
is
what
is
the
benefits?
I
would
obtain
being
equal
on
either
side
or
having
similar
functionality
on
equal,
equal
side,
both
sides.
So
what
are
intellect.
B
So
we
actually
try
to
unpack
that
a
little
bit,
that's
okay,
there
is
I
mean.
Of
course,
we
see
a
lot
of
potential
benefit
to
running
envoy
you're,
asking
about
benefit
to
running
envoy
mobile
as
opposed
to
running
envoy
as
a
sidecar
in
certain
cases.
Are
you
just
asking
about
the
benefit
of
running
Envoy
mobiles
in
network
library
in
general,
regardless
potential?
Even
what
you're
running
on
the
back
end.
G
B
What's
the
benefits
to
using
both
and
we're
gonna
have
to
do
a
brief
answer
and
cut
this
off.
I
think
we're
out
of
time,
but
let's
talk
about
it
more
after
briefly,
though
again,
it's
just
you
getting.
If
you're
already
used
to
running
envoy,
you
realizing
those
same
benefits.
If
you've
dashboards
driven
by
envoy,
you
can
drive
them
from
your
clients.
B
Now,
if
you
have
configuration
you're
used
to
running
for
envoy,
you
can
configure
your
clients
now
extensions
that
you
build
for
your
back-end
can
work
in
the
clients
where
they
make
sense,
so
it's
actually
having
that
common
layer
everywhere.
It's
kind
of
why
envoy
is
great
for
the
backend
in
the
first
place.
Thank.