►
From YouTube: Envoy Mobile in Depth: From Server to Multi-platform Library - Jose Nino & Michael Schore, Lyft
Description
Join us for Kubernetes Forums 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
Envoy Mobile in Depth: From Server to Multi-platform Library - 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 the motivation behind deploying 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 were simply another node on the service mesh. This talk will dive deep into the technical aspects of using the Envoy codebase as the core foundation of a mobile networking library. We will cover the challenges we encountered and solutions we built in packaging Envoy and developing a direct HTTP API into its core, supporting an ergonomic interface for both iOS and Android.
A
Ready,
okay,
great
everyone
ready,
hi
everyone.
Thank
you
for
coming
to
envoy
con
2019.
This
is
the
first
thought
that
our
team
has
done
about
the
work
that
we
have
been
focusing
for
the
past
few
months,
so
Mike
and
I
are
really
excited
to
be
here
to
share
the
progress
that
we've
made
over
the
past
few
months.
We
just
heard
a
great
talk
from
Spotify
about
the
value
of
running
envoy
at
the
edge
of
your
infrastructure.
A
In
this
talk,
we
want
to
introduce
unblameable,
which
is
a
child
project
of
the
Android
ecosystem,
and
in
it
we
want
to
extend
the
concept
of
the
edge
to
our
mobile
clients.
We
want
the
mobile
clients
to
be
another
node
in
the
network,
part
of
the
mesh,
so
our
talk
will
guide
you
through
the
story
of
Android
mobile
in
four
parts.
First,
we
want
to
discuss
the
justification
for
bringing
Android
to
mobile
as
any
engineering
project.
It's
a
big
investment
of
time
and
resources,
and
we
want
to
to
show
you
why
we
think
it's
valuable.
A
It's
a
valuable
project
to
embark
on.
After
that,
we
will
dive
deep
into
what
it
took
to
bring
envoy
to
mobile
after
that
I'd
like
to
discuss
where
we
are
now,
both
as
an
open-source
project
and
also
in
its
integration
with
the
lyft
app.
And
lastly,
we
want
to
share
some
of
the
exciting
roadmap
items
that
we
have
planned
moving
forward.
A
By
having
this
Universal
network
primitive
that
is
performant,
reliable,
configurable
and
extensible,
we
have
largely
made
the
network
transparent
to
our
back-end
engineers
and
importantly,
when
problems
actually
do
arise.
Envoys
best-in-class
observer
has
made
it
increasingly
easy
to
debug
network
problems.
A
However,
our
premise,
the
premise
of
my
team,
is
that
not
three
9s
server
side
is
actually
meaningless.
If
the
users
of
mobile
applicable
allocations
can
actually
complete
the
network
flows
only
a
fraction
of
the
time
without
going
mobile,
we
propose
that
we
can
extend
all
the
benefits
of
Envoy
at
the
at
the
back-end
infrastructure,
all
the
way
to
our
mobile
kinds,
but
this
vision
requires
a
paradigm
shift,
because
traditionally,
we've
treated
our
clients
as
separate
from
our
back-end
infrastructure,
we've
treated
them
as
a
unique
problem
that
requires
unique
solutions
that
are
platform-specific.
A
So
really
we
can't
say
that
Android
has
become
a
true
Universal,
Network
primitive.
If
all
the
network
flows
that
our
mobile
platforms
that
we
use
day
in
and
day
out,
start
and
end
with
the
mobile
clients.
The
one
hardware
envoy
is
not
running,
so
we
are
proposing
with
Android
mobile
that
we
don't
need
to
treat
the
mobile
clients
any
differently.
Like
I
said
we
want
them
on
their
mobile
clients
to
become
part
of
the
network
to
become
another
node
in
this
mesh.
A
So,
with
this
project
and
by
extending
the
last
smile
of
our
of
our
network
topology,
we
want
that.
We
want
true
standardization
of
the
network,
similar
to
what
kubernetes
has
done
for
standardizing
container
orchestration.
We
want
envoy
to
do
for
the
network
and
we
believe
that
Android
mobile
is
that
next
logical
step
in
the
standardization
process.
A
A
We
can
write
one
write
code
once
and
deploy
it
everywhere
by
having
the
same
universal
network
primitive
end
to
end,
we
can
embark
on
projects
that
would
be
otherwise
prohibitive
due
to
the
engineering
costs
of
having
three
implementations
in
iOS
and
Android,
and
then
in
our
back-end
services
with
envoy,
mobile
and
Envoy
in
the
backend,
we
can
implement
things
one
and
deploying
them
deploy
them
everywhere.
For
instance,
we
can
experiment
with
protocols
like
quick.
A
Second,
we
can
share
common
tooling
for
common
problems
by
having
the
same
metrics,
for
example,
be
emitted
by
our
mobile
clients
and
our
back-end
infrastructure.
We
can
use
the
same
touring
and
the
same
monitoring
infrastructure
in
order
to
really
see
the
network
end-to-end.
We
can
allow
our
our
engineers
to
operate
with
the
same
with
the
same
metrics,
all
the
way
from
a
mobile
clients
into
the
edge
and
into
a
back-end
infrastructure
and
lastly,
and
related
by
having
the
same
network
stack
everywhere.
B
Today,
envoy
Mobile
is
running
in
the
alpha
version
of
the
lyft
app,
but
before
we
got
there,
we
had
to
really
realize
that
this
was
even
something
that
was
going
to
be
possible.
Envoy
itself
is
back-end
server
software.
It
runs
in
a
dedicated
process
with
multiple
threads
in
order
to
run
on
Android
and
iOS
in
a
sandboxed
environment
as
something
that
the
applications
could
use,
it
would
need
to
run
in
a
thread
in
the
app
which
required
rethinking
assumptions
about
how
ombo
is
run,
how
it
was
even
built.
B
Fortunately,
for
us
envoy
is
built
with
basil,
which
is
a
powerful
build
system
which
offers
parallelized,
builds
and
incremental
builds.
Basil
also
has
strong
cross-platform
support
and
across
architecture
support.
This
allowed
us
to
solve
one
of
the
initial
problems
with
actually
targeting
multiple
architectures
and
targeting
multiple
platforms.
Our
first
proof
of
concept
was
simply
getting
envoy
up
and
running
on
mobile
clients,
running
it
on
iOS
running
it
on
Android,
wrapped
in
a
thin
layer
of
an
application.
B
B
This
naturally
led
us
to
something
of
a
layered
architecture.
You
can
see
on
the
right.
We
have
actually
envoy
itself
as
one
of
our
Basel
targets.
Envoy
is
the
core
of
envoy
mobile
and
actually
performs
all
the
heavy
lifting.
It
is
the
same
software
path
that
envoy
uses
to
carry
requests
in
the
backend.
B
Additionally,
we
have
code
which
maps
directly
to
envoy
which
uses
envoys
native
types
and
interfaces,
and
this
perform.
This
is
the
core
layer
of
our
library.
Above
this,
we
have
our
common
bindings,
which
allows
us
to
be
cross-platform.
These
were
decided
to
be
C
bindings
for
maximal
support
across
different
languages
and
platforms,
and
then,
finally,
we
actually
have
code,
that's
written
for
Android
and
for
iOS
platform
code
that
exposes
high-level
interfaces
to
which
client
developers,
application
developers
are
familiar
using
common
patterns
and
common
types.
B
B
Envoy
itself
is
designed
to
such
a
way
again
something
that
we've
been
able
to
leverage
that
most
of
the
code
in
Envoy
is
actually
written.
As
if
it's
running
in
a
single
threaded
context,
most
code
doesn't
deal
with
synchronization
or
crossing
thread
boundaries.
This
was
really
useful
to
us.
We
knew
we
were
going
to
be
run
in
a
thread
which
was
not
the
roots
out
of
the
process,
and
one
we'd
have
to
actually
have
external
control
over
how
things
are
run.
B
We
were
able
to
leverage
the
starting
a
model
in
envoy
to
actually
move
things
all
to
a
single
thread,
two
envoys
main
thread.
Additionally,
of
course,
we
have
application
threads,
which
are
going
to
need
to
call
in
to
envoy
in
order
to
manage
its
lifecycle
and
actually
issue
requests.
This
is
a
networking
library
at
the
end
of
the
day,
and
finally,
we
have
callback.
Threads
envoy
needs
some
way
to
actually
signal
back
to
the
application
that
something
has
happened.
A
response
has
been
received
or
an
error.
These
callback
threads,
of
course,
might
be
application
threads.
B
In
fact,
they're
provided
by
the
application
again
using
native
mechanisms
to
their
respective
platforms,
so
on
iOS
you
have
grants
until
dispatch
and
dispatch
queues
on
Android.
You
have
executor
x'
and
runner
Boles,
but
the
importance
is
the
flexibility
here
that
the
speed
another
unique
contacts
wreaking
dispatch
work.
B
For
starters,
when
the
client
developer
goes
to
create
an
envoy
client,
what
they're
going
to
use
ultimately
to
manage
the
engines,
lifecycle
and
issue
requests,
the
engine
is
now
responsible
for
starting
up
the
Envoy
runner
thread.
This
is
the
thread
upon
which
on
will
run
again
in
this
context,
envoy
is
actually
single
threaded.
It's
not
multi-threaded
like
it
is
when
it's
running
on
the
server
back-end.
B
However,
this
envoy
main
thread
is
these
same
main
thread
from
Omelas
perspective,
as
its
main
thread
is
running
the
background
again,
we're
leveraging
the
same
code
path,
the
same
initialization
path
to
run
this
now
envoy
on
the
backend
is
multi-threaded.
There's
the
main
thread
and
there's
worker
threads
when
a
request
comes
in
a
listener,
assigns
a
request
to
a
worker
thread
and
that
work.
B
Additionally,
on
occasion,
a
work,
a
thread,
that's
handling,
a
request
will
need
to
actually
dispatch
work,
that's
asynchronous
and
out
of
band,
maybe
that's
for
authorization,
a
call
out
to
an
authorization
service,
or
maybe
it's
for
rate,
limiting
an
envoy
and
a
sync
client
construct
is
used
for
this
to
issue
these
side
requests
for
envoy
mobile
we've
leveraged.
These
two
constructs:
we've
used
an
event.
Dispatcher
and
an
async
client
actually
formed
the
core
of
our
direct
API
into
envoy,
not
an
API.
That's
mitigated
by
a
socket,
but
actually
one,
that's
mediated
by
direct
function.
B
And,
conversely,
these
platforms
don't
know
anything
about
how
envoy
manages
memory
either,
fortunately,
for
us,
oddly,
actually
has
a
fairly
powerful
buffer
abstraction
that
it
uses
already
in
Envoy.
Buffers
are
an
abstract
wrapper
around
individual
fragments,
and
these
fragments
are
what
actually
knows
where
the
physical
memory
is.
Each
of
these
fragments
has
a
done
callback
once
Envoy
is
done
with
the
fragment,
it
can
call
done
it's
done,
IO
or
whatever,
and
the
buffer
can
be
released
by
whatever
mechanism
is
used.
With
that
fragment
implementation.
We've
extended
this
concept
at
our
intermediary
layer,
our
bridge
layer.
B
B
They
have
their
own
unique
characteristics,
but
the
important
thing
is
that
we
wanted
to
avoid
actually
leading
to
Thai
logic
that
was
bridged
closely
to
envoy
to
how
memories
can
be
managed
in
the
platform.
Instead,
what
happens?
Is
these
unique
buffer
fragment
implementations
map
that
done
callback
back
to
the
actual
platform
memory
management
schemes?
This
allows
envoy
to
signal
when
it's
done
with
a
buffer
and
the
buffer
can
be
potentially
free,
but
that's
really
up
to
the
platform,
maybe
the
platform's
keeping
the
buffer
around
for
longer.
B
B
This
is
actually
an
area
where
we've
contributed
to
upstream
envoy
to
allow
for
further
support
in
this
library.
We
see
this
as
an
ongoing
opportunity
running
on
voice.
A
library
means
we
can
generalize
concepts
envoy
and
create
new
abstractions
as
well
as
potentially
degree
factors
that
provide
overall
benefits
to
envoy
both
when
it's
running
in
the
backend
as
a
server
and
when
it's
running
as
a
library.
B
Once
we've
issued
a
request,
we'll
eventually
hopefully
receive
a
response.
We
need
to
surface
these
responses
back
up
to
the
application.
Somehow
we
do
this
with
callbacks.
Again,
though,
we
have
this
common
binding
layer,
which
is
something
that
allows
us
to
be
cross-platform
and
portable,
but
it's
not
something
that
the
application
understands.
We
knew
we
wanted
this
library
to
be
easy
to
use.
We
didn't
want
client
developers
needing
to
understand
the
various
characteristics
of
function,
pointers
in
C
to
actually
be
able
to
leverage
the
library.
Our
own
callbacks
are
necessarily
see
function.
B
Pointers
our
bindings
are
see,
however,
we
want
to
client
developers,
people
use
their
own
dispatch
mechanisms
and
their
own
concurrency
concepts
for
actually
passing
callbacks
down
to
the
library.
This
means
we
needed
platform,
specific
dispatchers
and
it's
with
our
C
bindings,
where
the
platform
provides
its
own
dispatch
mechanism,
as
well
as
its
own
callback
mechanism
that
can
be
mapped
to
pot
the
platform's
own
concept.
Lambda
is
on
iOS.
B
You
have
Grand
Central,
Dispatch
firt
for
actual
dispatch,
and
then
you
have
blocks
commonly
used
for
that
for
concurrency
on
Android
we've
elected
to
use
the
executor
pattern,
which
has
been
around
forever
as
well
as
rentals,
to
allow
for
a
maximally
flexible
interface
to
support
a
variety
of
different
concurrency
mechanisms
now
to
actually
make
this
work
with
C
callback.
So
we
need
a
way
for
Envoy.
We
will
call
this
code,
which
has
no
way
of
actually
understanding.
B
This
code
path
is,
of
course,
coming
out
of
envoy
through
our
bridge
layer
back
up
to
the
platform.
In
order
to
accomplish
this,
we
leaned
on
an
old
C
pattern,
wherein,
when
the
platform
provides
callbacks
bridge
callbacks
to
Envoy,
they
actually
contain
a
type
erased
context
in
addition
to
a
static,
see,
function
pointer,
both
of
which
the
platform
provides
for
its
own
unique
use
case.
That's
the
function
pointer,
can't
capture
state,
it's
just
C,
but
because
it
has
this
void
star
context.
The
platform
can
attach
whatever
it
wants.
B
B
We've
deliberately
made
the
design
decision
with
our
library
to
actually
have
our
request
path
and
response
path
be
almost
entirely
unsynchronized.
This
is
important
not
only
because
of
simplicity
and
it's
a
pattern
that
envoy
already
follows,
but
it
also
allows
us
to
handle
the
case
that
in
mobile
applications,
the
place
where
request
is
called
may
actually
be
remote
from
where
the
response
is
handled.
Reducing
shared
state
means
that
we
can
reduce
complexity
in
support
in
these
use
cases
and
instead
provide
strong
contracts
or
on
the
timing
and
the
handling
of
requests
and
responses.
B
A
Thanks
for
an
accident,
deep
dive
into
internals
of
the
library
Mike,
so
with
all
that
built,
I
want
to
proceed
into
where
we
now,
both
as
an
open
source
library
and
also
in
its
integration,
into
the
lift
app
a
few
weeks
ago,
we
released
version
0.2
of
the
library
which
we
consider
to
be
alpha
ready
for
everyone
to
experiment
with
it.
While
the
API
might
change
a
little
bit,
we
we
think
that
the
design
decisions
that
are
foundational
to
a
library
are
very
sound.
A
Additionally,
for
a
little
over
a
month
ago,
now
we
integrated
Android
mobile
into
the
lift
app
for
the
alpha
release.
This
is
actually
a
picture
of
our
team,
taking
the
first
lift
write
ever
where
all
Network
calls
were
dispatched
via
Android
mobile.
We
of
course
went
to
grab
some
donuts,
so
let's
take
a
look
at
how
we
actually
integrated
unblameable
into
the
lift
app
at
lift.
We
have
taken
a
model-based
approach
to
designing
our
API
s.
A
A
Getting
to
this
state
of
model-based
api's
was
a
gradual
process
and,
if
you're
interested
in
this
aspect,
please
look
out
for
a
blog
post
and
a
talk
from
my
colleague,
Michael
rabello,
which
is
actually
going
to
come
to
the
lift
engineering
blog
sometime
later
this
year.
So
on
mobile,
we
go
a
step
further
and
we
actually
pre
compile
the
their
files
into
into
package
modules.
This
allows
us
to
reduce
compile
times
for
our
mobile
clients,
and
it
also
allows
us
to
better
organize
the
api's
and
their
dependencies.
A
What
this
means
is
that
we
can
really
experiment
with
the
implementation
details
underneath
this
packages
for,
for
a
variety
of
reasons,
explicitly
for
Android
mobile.
What
this
means
is
that
we
can
swap
transparent
the
classic
networking
libraries
like
URL
session
in
iOS
and
okay
HTTP
in
Android
for
onboard
mobile
and
that's
what
we
did.
So,
let's
take
a
look
at
the
actual
API
calls
that
are
done
by
our
app
now.
A
One
of
the
one
of
the
things
that
I
want
to
highlight
here
is
that
we
have
made
it
our
goal
to
make
our
high-level
economic
API
is
pretty
identical
between
iOS
and
Android.
So
here
you
see
up
top
a
swift
example
and
below
a
cut
an
example
for
the
rest
of
the
slides
I'm
going
to
only
show
Swift
code,
but
you
can
assume
that
a
continent
that
the
continent
code
is
pretty
identical.
A
So
the
first
thing
that
the
application
does
is
create
an
android
client
and
what
this
does
underneath
the
hood
is
actually
instantiate
and
create
the
Envoy
engine
that
mike
was
talking
about.
At
this
point,
we
have
exposed
some
configuration
elements
so,
for
example,
we
allow
you
to
change
the
log
level
of
the
engine
or
even
the
stats
versioning
interval.
A
Then
you
can
build
a
request
with
that
to
use
with
the
engine
here.
You
can
add,
for
example,
the
API
path
that
you
want
to
hit
on
the
remote
host
and
we
have
exposed
the
ability
to
attach
custom,
headers
or
even
Network
constructs
like
a
retry
policy
and
I
want
to
emphasize
here
that
the
retry
policy
that
we
expose
actually
maps
to
an
voice,
retry
behavior,
because
at
the
core,
its
envoy,
that
is
running
that
Network
logic.
A
Lastly,
you
build
a
response
handler
that
will
receive
the
callbacks
back
from
Envoy,
like
Mike
was
describing
so,
for
example,
you
might
have
an
on
headers
fallback
or
an
on
data
callback
that
will
be
mapped
up
to
two
application
code
to
wrap
it
all
up.
You
submit
the
request
and
the
response
handler
with
two
to
the
engine
and
the
engine
allows
you
to
interact
with
this
open
stream,
for
example
by
sending
data
and
then
subsequently
closing
the
string
so
well
lift
us
integrated
with
ongoing
mobile.
A
A
So
we
started
this
project
with
the
premise
that
3:9
server-side
was
was
not
enough
and
that
mobile
clients
were
really
prime
candidates
to
benefit
from
the
same
standardization
that
the
back-end
infrastructure
has
received
by
deploying
envoy
at
lift
one.
We
once
we
integrated
with
the
lift
with
with
the
app
we
took.
This
is
our
first
opportunity
to
start
experimenting
with
the
benefits
that
we
could,
that
we
could
actually
see
and
stats
were
actually
the
first,
the
first
step
there.
A
So
we
all
know
that
envoy
has
best-in-class
observability,
for
example,
it
flushes
hundreds
of
time
serious,
metrics,
every
stats,
versioning
interval.
These
stats
have
become
invaluable
to
operate
the
network
at
lyft
and
I'm
sure,
at
a
lot
of
your
companies.
Now
that
Android
mobile
is
running
on
the
lift
clients,
we
actually
had
access
to
the
same
metric
stream
as
we
had
in
our
back-end
infrastructure.
So
really
the
goal
that
we're
trying
to
achieve
here
is
for
an
engineer
to
be
able
to
observe
the
network
and
to
end
from
the
mobile
client
into
the
back-end
infrastructure.
A
A
The
metric
service
allows
us
to
get
time-series
metrics
via
G
RPC,
so
we
built
a
very
simple
G
RPC
service
that
could
receive
those
metrics
and
then
emit
them
to
our
already
existing
metrics
infrastructure,
and
just
like
that,
we
can
start
plotting
the
same
metrics
that
we
see
in
our
back-end
services
for
our
mobile
clients.
So,
for
example,
here
you
can
see
the
request
count
up
top
coming
from
the
mobile
clients
and
below
coming
from
edge
infrastructure.
A
I
really
want
to
emphasize
how
powerful
this
construct
is,
because
it
really
is
giving
us
insight
into
parts
of
our
infrastructure
that
we
did
not
have
before.
This
is
just
the
first
of
many
examples
of
how
Android
mobile
can
really
start,
unlocking
a
whole
new
wave
of
potential
in
our
mobile
kinds.
B
Stats
are
a
super
big
deal
for
us
actually
having
that
level
of
insight
into
mobile
clients
is
something
you've
struggled
with
for
a
long
time,
even
when
we
instrumented
them
ad
hoc,
we
dealt
with
discrepancies
between
the
implementations
and
inconsistencies
between
client
versions
in
between
platforms.
Having
stats
turned
on
opened
the
floodgates
having
the
same
visibility
into
our
clients
in
our
back-end
is
really
remarkable
for
us.
That
said,
we
are
very
early
on
in
the
project
for
Envoy
mobile,
and
we
see
immense
opportunity
here
in
the
near
future.
B
We're
gonna
be
experimenting
with
a
quick
protocol,
rolling
it
out
to
our
mobile
clients
with
envoy
mobile,
rather
needing
to
work
with
quick
implementations
that
are
unique
to
both
Android
and
iOS,
as
well
as
our
back-end.
We
can
roll
out
a
single
stack
and
have
a
lot
of
the
work
done
for
us
by
Google
who's
already
working
on
it
in
in
Envoy.
B
Secondly,
envoy
has
extensible
filter
chain,
something
which
Spotify
mentioned
actually
leveraging
this
on
the
mobile
client
so
well
as
well,
will
allow
us
to
develop
single
solutions
for
multiple
patterns,
for
instance.
Auth
is
something
we
can
solve
in
a
universal
way,
not
only
in
the
backend,
but
we
can
also
solve
off
in
a
filter
on
a
mobile
client
as
well.
Compression
is
another
example
rather
needing
to
roll
out
compression
with
unique
gzip
implementations.
We
can
do
the
same
thing
in
a
filter
across
all
our
nodes
in
our
network.
B
It
even
opens
up
the
opportunity
to
explore
explore
things
like
Google's
own
new
compression
algorithm
broadly.
We
would
ordinarily
never
consider
implementing
this
on
our
mobile
clients
and
back-end,
simply
because
the
resources
required
would
be
too
much.
Instead
with
a
single
implementation,
we
can
try
it
deploy
it
everywhere
and
see
how
it
works.
B
Envoy
itself
already
has
intelligent
behavior
and
how
it
selects
connections
with
health
checking
and
with
various
load,
bowing
load,
balancing
configurations.
We
see
this
as
a
concept.
We
can
extend
further
to
actually
allow
envoy
to
intelligently
select
connections
over
different
interfaces,
be
it
Wi-Fi
or
cellular
or
fallback
between
different
protocols,
quick
or
fall
back
to
HTTP,
ipv6
or
ipv4.
To
have
a
rich
set
of
possible
technologies.
The
mobile
client
can
be
using
to
communicate
with
us,
but
be
intelligently.
Selecting
the
one
that's
actually
working
in
any
given
time.
B
Jose
mentioned
the
model
based
API,
we
use
a
lift,
and
while
we
want
to
expose
a
variety
of
bindings
to
envoy
mobile,
to
allow
to
be
used
in
in
use
cases
as
simple
as
HTTP
up
to
actual
model
based
DPI's,
we
see
a
huge
opportunity
with
mobile
api's
or
at
model-based
api's,
and
actually
plan
on
supporting
them
first
class
in
envoy
mobile.
By
doing
this,
we
think
we
can
actually
expose
the
ability
to
annotate
these
models
as
well
with
how
they
should
be
communicated
with
the
server
in
varying
in
our
conditions.
B
Actually
using
this
configuration
would
allow
us,
in
theory,
to
change
the
network
topology
all
the
way
out
to
our
mobile
clients
on
the
fly
without
needing
to
deploy
new
out
versions.
This
could
range
or
something
like
incident
response
or
failover
scenarios
down
to
actually
doing
something
like
rolling
out
a
new
pop
which
are
traditionally
require
things
like
changing
dns.
B
Finally,
we're
already
exploring
opportunities
to
extend
envoy
mobile
beyond
our
actual
phones,
lyft
has
its
fleet
of
rentable
transportation
devices,
which
are
prime
candidates
running
envoy
mobile.
They
face
many
of
the
same
networking
challenges
that
our
phones
do
when
they're
out
in
the
wild.
We've
also
had
interest
from
people
thinking
about
IOT
and
or
even
have
people
who
are
interested
in
the
project
from
their
perspective
of
using
envoy
simply
as
AC
networking
library
to
replace
libraries
that
are
written
in
other,
which
is.
B
One
of
the
most
amazing
aspects
of
envoy
is
its
vibrant
community,
and
this
is
a
big
part
of
what's
made
the
project
successful.
We've
made
the
deliberate
decision
to
develop
envoy
mobile
in
the
open.
It
is
already
open
source
and
though
it's
a
small
project,
still
very
early
on
we're,
making
rapid
progress,
and
we
welcome
both
input
from
the
community
and
what
your
needs
are,
as
well
as
contributions
to
the
project,
we're
very
excited
for
the
road
ahead
and
we
look
forward
to
working
with
you
all.
Thank
you.
B
B
B
I'm,
sorry,
yes,
okay
yeah,
so
the
question
was-
and
let
me
know
if
I
got
this
right,
do
we
see
tension
between
the
server
oriented
design
of
envoy
and
the
SDK
oriented
use
case
that
yes,
I
mean?
Potentially
there
could
be,
but
I
think
that
whether
or
not
we
encounter
that
and
whether
that
actually
is
you
know,
inherent
complexity
or
incidental
depends
on
some
of
the
design
decisions
that
we
make
as
well.
B
B
At
the
end
of
the
day,
we're
trying
to
send
requests
over
a
network
we'd
like
visibility
to
those
requests,
we'd
like
to
control
what
happens
to
them
when
they're
in
flight
at
different
hops,
and
we
think
that
those
core
levels
are
really
the
most
important
shared
aspect
of
this.
And
that's
really.
What
we're
driving
for
I.