The Microservices.com Practitioners Summit, is a practitioner-driven microservices conference, that focuses on real-world applications of adopting microservices at scale. The Summit will be held in San Francisco on January 31, 2017. Speakers include microservices practitioners from Uber, New Relic, Lyft, PayPal, and Google.
Matt Klein is a senior software engineer at Lyft, and will be speaking at the Summit. Klein works on Envoy, a Layer 7 communications bus, used throughout Lyft's service-oriented architecture.
Prior to the summit, InfoQ met with Klein to discuss the benefits of creating a custom tool for Lyft’s networking needs, and how it could benefit other microservices architectures.
InfoQ: Modern service-oriented architectures rely heavily on network communication and RPC calls, instead of inline processing within a monolith. How does Envoy help to improve the dependency on a complex network infrastructure?
Matt Klein: Over the last 5-10 years we have seen a couple of major shifts in SoA. Primarily, lots more folks are building SoA, and doing it earlier in an infrastructure's lifecycle. More importantly, we see a lot of companies with "polyglot" language deployments (3+ languages in use at all times).
Historically, most of the complexity around sophisticated SoA networking has been accomplished via very complicated libraries. This includes load balancing, routing, service discovery, retry, rate limiting, circuit breaking, stats, logging, tracing, etc. Unless an organization uses very few languages or has a lot of resources, it becomes nearly impossible to have sophisticated networking libraries for every production language.
Envoy is an out of process high performance proxy that solves common SoA networking problems in one place. It is designed to run alongside every application (in any language) and abstract most of the complexities of networking from the application developer. Application developers focus on business logic, and just talk to the local Envoy, which then proceeds to handle service discovery, load balancing, routing, etc. Possibly most importantly the existence of Envoy produces consistent observability across every hop of the SoA which is critical from a debugging perspective.
InfoQ: At Lyft, how much of the network stack do developers of microservices need to understand? Does Envoy help reduce this mental overhead?
Klein: Very little! With the full Envoy deployment at Lyft, we have created a world in which developers interact with an extremely thin library we call "EnvoyClient." Whether the code is running in dev, staging, or production, they instantiate an EnvoyClient and use it to talk to a remote service. Under the hood, all this library does is set some headers and talk to the local Envoy which does all of the hard work. We encourage developers to set proper retry policies, timeouts, etc. via the library, and that's about it. They just make a call and get an answer and don't need to worry about much else.
Because Envoy runs everywhere, we are also able to produce copious amounts of consistent data to help developers debug (stats, logging, tracing, dashboards, etc.).
InfoQ: Before Envoy was in place, what components were involved in L7 routing? Why were these not sufficient, and what justified the effort in creating a custom solution?
Klein: Like most modern companies, Lyft is "polyglot." We currently run PHP, Python, and Go services in production. We had a mishmash of different solutions prior to Envoy including different libraries in each language, different stats, etc. We relied heavily on the AWS ELB product with all of its inherent issues (instability, poor observability, etc.). In short, it was total chaos. Developers did not trust the network, could not debug complicated issues, and were resistant to creating high performance network services in the critical path.
It was clear that a common substrate was needed, and lots of prior experience and observation led us to build Envoy.
InfoQ: Do see Envoy as a benefit for any organization making a transition to a microservice architecture? What’s the best way to get started?
Klein: Ultimately, I think the use of Envoy will help any company with a moderately complex SoA. A common substrate is invaluable for providing a consistent environment, easing developer burden, and debugging complex problems.
I would encourage everyone to check out our website where we have put a lot of effort into the docs. We also have some example docker containers to play with. Furthermore, there are efforts underway to build Envoy more directly into k8s which I think will make adoption even easier for smaller companies.
