
Envoy Mobile - jparise
https://eng.lyft.com/announcing-envoy-mobile-5c2067d9ade0
======
simonw
I really like how they're releasing this as effectively the first working
proof of concept and committing to developing the rest entirely in the open -
it's a great opportunity to see how a project of this scale plays out in real-
time on GitHub.

~~~
goawaypls
Thanks, we're excited to be able to do this in the open and welcome community
involvement!

~~~
trifarious
But your username is “go away please”?

~~~
goawaypls
My username predates this account and this project. On Twitter and GitHub,
it's just "goaway", so this is arguably more polite. ;)

It stems from the spdy/h2 GOAWAY frame, from prior work I did with these
protocols.

Please don't take it personally.

------
polskibus
So envoy will now provide a client-side library? Is there a particular reason
why such client-side enhancements should not be applied to all Api clients,
not just on mobile?

What is the ultimate goal here? Reduce the amount of boilerplate required to
handle all possible edge cases when communicating with a remote service, like
need to retry, etc?

I'd like to understand the value prop from a perspective of a generic api
client, that does not now if there is Envoy, or any other load balancer on the
other end.

~~~
SriniK
You can think it as a cross platform networking library.

From the post.

"Low-level networking improvements like HTTP/2, QUIC, QUIC to TCP failover,
gRPC, DNS replacements, push/streaming, observability, analytics, state of the
art TLS, retry and timeout policies, etc. take a tremendous amount of effort
both to implement robustly as well as to make consistent across all of the
Android and iOS versions in common use. Envoy Mobile will provide all of this
functionality in a consistent cross-platform manner, especially when paired
with Envoy running at the edge, similar to how server-side Envoy provides
consistency to polyglot distributed application architectures."

~~~
blaisio
Yeah I think the idea is, envoy helps a lot on the server side, but the client
side uses almost the exact same algorithms, so we ought to have something like
envoy on the client side too.

------
orliesaurus
The blog post does explain a lot of the vision and its promises but can
someone from Lyft (preferably) explain the practical use cases?

------
InTheArena
I've been waiting to see this for a while, because this is intrinsically about
extending the service mesh to end devices. Unfortunately it does seem to be
more protobuf / gRPC specific then I would like at the moment, but device
connectivity is absolutely something that should be managed as a separate
concern from core application development.

~~~
goawaypls
While we see a lot of potential in protobuf-based interfaces, rest assured
that this is fully-intended to be a general-use networking library. (Lyft
employee/project contributor here.)

------
zng00
Really interested in cases where people have taken xDS to user-scale.
Presumably you would want to implement the Delta Discovery Service to minimize
the bandwidth used by xDS updates, however, then you're maintaining state on
the xDS server which adds server overhead.

We're adopting xDS as an abstraction for our service discovery. Implementing
it has been relatively straightforward even with the relatively minimal
documentation outside of the hints provided by the Envoy specific
configuration elements.

~~~
ec109685
Are things that complex a delta coding would be needed over sending the whole
thing down if etag changes?

~~~
zng00
As long as the node metadata is static and you're still filtering state-of-
the-world to produce the same resources. If clients are only subscribing to
static resources then yes, however, if you want to perform dynamic traffic
shaping across a subset of resources then you have some state to manage.

------
jensneuse
What are possible use cases for a proxy in a client?

~~~
jonhohle
I see this more as a "smart" client, where you can push routing, load
balancing, retry policy, etc. out to the clients instead of enforcing those at
your infrastructure edge… which seems great for controlled clients, but not-
feasible for public facing use-cases:

    
    
        * routing rules potentially sensitive architectural 
          information and expose many different nodes to the
          public internet
        * a mobile client doesn't generate enough "load" that the 
          typical use case for load balancing would be used for
        * retry & timeout policies seem useful
    

However, I'm a curmudgeon that doesn't see a huge benefit to a service mesh
over a traditional load balancer in the vast majority of applications. Load
balancers can offer a lot of the same functionality at scale (thousands of
requests per second) and abstract these ideas away from the client, which has
more benefit, in my opinion.

I have used smart clients in the past to interface with, what is now being
called, a service mesh. For low latency operations that could possibly hit one
of thousands of hosts, it worked well… until network fabric changed and hosts
were no longer directly accessible. Then operations became increasingly
difficult since you had to be on the appropriate network to communicate.

------
adamfeldman
Is there anything similar to Envoy Mobile for browser-based apps?

~~~
__float
Unfortunately, browsers don't give very much (if any) control over the
networking components -- so you lose out on possibilities for much
observability, you can't do things like implement HTTP/2 if your browser
doesn't already give it to you, you can't tune DNS stuff at all, etc.
Especially as, right now, it only supports gRPC, which requires a proxy on the
server side if you want to use gRPC from the browser.

What benefits would you like to see for a browser-based app?

------
edgetech
The hello-world example (At least in Objective-C) shows a 'run-envoy' call
followed by the client code making requests to envoy in the same process over
HTTP on a dedicated port. Will there be a client API or is the model that one
uses a local HTTP client to speak to your in-process envoy?

~~~
goawaypls
Yes, we are immediately starting work on a direct, client API. Getting this
linked as a library and functional in iOS and Android apps was merely our
proof-of-concept and first step.

------
nullwasamistake
Shout out to Lyft for Envoy. I haven't used it all that much, but it's been
very set and forget. The other "API gateways" like Linkerd and Kong are either
a bunch of hacky Lua scripts (Kong) or use a lot of ram for the number of
instances you'll probably want (Linkerd)

~~~
fosk
Kong is a fully fledged Lua/C application running on the LuaJIT VM and
leveraging the NIO of Nginx, the same stack that powers the underlying proxy
of companies like Cloudflare by the way.

------
espeed
Would this make WireGuard UDP tunneling over TCP easier?

~~~
kim0
Also hoping obfuscation, censorship evasion...etc!

------
vbs_redlof
I want to like envoy, but honestly the documentation for all areas of the
framework is poor, with no support.

------
zubairq
So does this mean that containers will be able to run on mobile devices?

~~~
wmf
No, this is a library that is linked in to a mobile app.

Although arguably iOS/Android sandboxing is already akin to a container.

~~~
zubairq
Ok, I'll have to dig in to find out why this is important, as all the
explanations I have seen are too technical for me

