Envoy project cross-post by Michael Schore
Just over a year ago, we announced Envoy Mobile’s initial OSS preview. Today, we have some exciting news to share: Envoy Mobile is officially joining its parent project Envoy as part of the Cloud Native Computing Foundation (CNCF)! From the outset, we made the commitment to develop Envoy Mobile as an open source project. Our belief in its potential to break new ground as a model for mobile networking and recognition of the vibrant community that has grown around Envoy made open source the clear choice for us. In the past year, it has been immensely rewarding to interact with the community as we’ve moved from the earliest proof of concept stages to an experimental and then production solution, fully in the open. Today is an important milestone, as we are privileged to join projects like Envoy, Kubernetes, gRPC, and more under CNCF stewardship.
A Brief History
The success of the Envoy project came about because it provided a common foundation to a network of diverse and polyglot systems. Deploying Envoy means one achieves consistent observability, configurability, and extensibility across the fleet, regardless of any unique characteristics of the individual services. Envoy’s model of active/passive health-checking and eventually-consistent routing configuration provides stability and reliability in the face of unpredictable network and software faults.
The Envoy Mobile project began with a question: Why do we treat mobile devices differently from the nodes in our backend infrastructure? Even though businesses run critical software on both, one is treated as core infrastructure, and the other is treated as a discrete, external client. The default assumption has historically been that the two components are fundamentally different. While there surely are differences, many of the challenges experienced by mobile clients resemble problems we had previously solved on the server with Envoy.
Achieving visibility into the health and performance of mobile applications is an ongoing struggle for many organizations. Similarly, custom runtime/dynamic configuration solutions are the norm for apps deployed at scale. And given that both Android and iOS must generally both be supported, sharing code is difficult. Moreover, the network conditions faced by mobile clients are even more unpredictable and fault-prone than those in backend infrastructure. We had leveraged Envoy as a common solution to these problems on the backend. Could Envoy become the solution for mobile clients as well? Envoy Mobile came about when we decided, “Absolutely.”
A Mobile Networking Library
“Envoy has become the universal programmable data plane for application networking. We are excited to see Envoy Mobile bring the benefits of Envoy to the mobile ecosystem. We now have the ability to deliver programmability to client applications such as mobile apps enabling true end-to-end cloud-native services.”
—Anna Berenberg, Distinguished Engineer, Google Cloud
Before we embarked on this journey, we spent some time evaluating other possibilities. There are a number of capable mobile networking libraries with a strong following. But a key differentiator Envoy delivers is that it provides a common layer for all networking within a distributed application. Ultimately, we came to the conclusion that the only way we could achieve that same advantage on our mobile clients would be to use Envoy itself.
Envoy, of course, wasn’t designed to be an in-process library, let alone one run within a mobile application. But a number of its design decisions made it remarkably adaptable to this new purpose—from its largely single-threaded codebase, to its buffer management model. We’ll share more on this in a future post, but for an in-depth look at how we adapted Envoy to run as a library instead of a server, see this talk we gave at KubeCon and EnvoyCon last year. Envoy’s modern architecture and design gave us a notable head start on proving out the viability of our idea.
Open Source
When we first published the Envoy Mobile repository, the library was little more than a working prototype. Envoy ran and could serve requests on both iOS and Android. We had an ambitious roadmap, but rather than execute on the project behind closed doors and share it only once we had a production-ready solution, we made the deliberate decision to open source not only our incipient project, but also the roadmap itself. Our belief is that the ideas behind Envoy Mobile have the potential to fundamentally change how organizations view and interact with mobile clients and IoT devices. Sharing that vision and the earliest version of the project was in part our commitment to that belief, and in part a pledge to the community that we wanted to work to realize these benefits for everyone.
A year on, and Envoy Mobile is compiled into the Lyft apps and dispatches our production traffic. The library has first-class bindings and support for Swift, Kotlin, Objective-C, and Java (with Python in the works!). We’ve reached the point where we now have a real foundation in place to build the future of mobile networking.
Onwards
“Envoy’s community growth and myriad use cases continues to exceed my wildest expectations. While Envoy has had a profound effect on how server-side cloud-native distributed systems are built, mobile clients and IoT devices have all of the same problems as their server-side counterparts including observability, fault tolerance, load balancing, and configuration. Envoy Mobile moving into the CNCF will accelerate the adoption of Envoy as an end-to-end cloud-native networking platform, enabling more robust deployments of complex distributed applications. I couldn’t be more excited.”
— Matt Klein, creator of Envoy
With a unified foundation and a common network abstraction in place across clients and backend services, features can be created once and used everywhere. We have big plans for the next chapter of Envoy Mobile’s development. A very abbreviated selection includes:
Strongly-typed API generation — allowing APIs to be defined with IDLs such as protocol buffers and leveraging code generation to eliminate boilerplate and abstract away transport.
Policy-based support of networking features selected via API/IDL annotations — including caching, retries, deferred APIs, streaming, push, and prioritization.
Advanced protocol support and network optimization — support for QUIC, HTTP/3, DNS alternatives, and custom protocol extensions, with intelligent connection weighting and selection.
xDS — leveraging Envoy’s configuration discovery APIs to dynamically configure via the same control plane as the traditional mesh.
To see more about what we have planned or see opportunities to contribute, our roadmap is open source as well!
The timing is right for Envoy Mobile to move to join the CNCF. This new, neutral home will make it easier for us to collaborate with and accept contributions from other organizations. It will also align us more closely with Envoy’s development cycle, allowing us to execute shared CI test coverage, and upstream features with tighter integration between the two projects. With this step, we look forward to working with the CNCF—and all of you—on redefining how we think about client-server communications.