Podcast - Is Envoy a Service Mesh or a Platform?

By bltd2a1894de5aec444
June 09, 2020

Join Matt Klein, Lyft and Cornelia Davis, Weaveworks as they discuss the history of Envoy, how it was originally an API gateway and how it differs from a purpose-built service mesh.

Related posts

Podcast - Carving out a Cloud Native Culture in Established Organizations

Podcast - Is Kubernetes Ready for Specialization?

Kubernetes Security - A Complete Guide to Securing Your Containers

Is Envoy a Service Mesh or a Platform?

Lyft migrated their single monolithic service to 300+ microservices with their internal proxy and API gateway, called Envoy. Knowing that many other organizations will have faced similar problems to Lyft, Envoy was open sourced and later donated the project to the CNCF where it graduated to ‘Production Ready Status’ alongside Kubernetes and Prometheus just last year.

In this episode of the Art of Modern Ops podcast, Matt Klein (@mattklein123), Software Engineer, Lyft and Cornelia Davis (@cdavisafc) CTO, Weaveworks discuss the origins of Envoy and how it differs from a purpose-built service mesh.

What is Envoy?

Envoy is a part of a “service mesh” that provides common utilities such as service discovery, load balancing, rate limiting, circuit breaking, stats, logging, tracing, etc. to polyglot (heterogeneous) application architectures.

The project was created because almost every company with a moderately-sized service-oriented architecture faced many of the same problems that Lyft did prior to the development and deployment of Envoy including:

  • An architecture composed of a variety of languages.
  • Services running implementations of an RPC library, including partial or zero implementations of rate limiting, circuit breaking, timeouts, retries, etc.
  • Differing or partial implementations of metrics, logging, and tracing across both owned services as well as infrastructure components such as Elastic Load Balancers.
  • A desire to move to Service Orientated Architecture for the scaling benefits but knowing that there can be chaos for application developers as they struggle to make sense of an inherently unreliable network substrate.
At its core Envoy is a network proxy. It is not a service mesh on its own. Today we see Envoy used as a network proxy in a large variety of different deployments. We see it used in Edge/API gateway deployments. We see it used in service mesh or client side networking deployments. We see it used as like a middle proxy load balancing tier within architectures and in some organizations, we see it deployed in all of those cases. So Envoy is really a highly extensible tool that does network proxy. It does enhance durability and it has a lot of powerful configuration capabilities. But it's really a building block tool that allows it to be used in a variety of different scenarios from the service mesh perspective." Matt Klein, Software Engineer, Lyft

Matt Klein, Software Engineer, Lyft

Matt_Klein.png

Matt Klein is a software engineer at Lyft and the creator of Envoy. He has been working on operating systems, virtualization, distributed systems, networking, and making systems easy to operate for more than 15 years across a variety of companies. Some highlights include leading the development of Twitter’s L7 edge proxy and working on high-performance computing and networking in Amazon’s EC2.

button_sign-up-now.png

The Art of Modern Ops · Is Envoy a Service Mesh or a Platform?

Listen on your favorite podcast platform:

Apple Podcasts | Spotify | Stitcher | SoundCloud | Pocket Cast | Google Podcast | Overcast


Related posts

Podcast - Carving out a Cloud Native Culture in Established Organizations

Podcast - Is Kubernetes Ready for Specialization?

Kubernetes Security - A Complete Guide to Securing Your Containers

Get notified of new podcast episodes