Guest post originally published on Kong’s blog by Scott Lowe

If you’ve done any reading about service meshes, you’ve probably come across mentions of an open source project named Envoy. And if you’ve done any reading about Envoy, you’ve probably seen references to service meshes. How are these two technologies related? How are they different? Do they work together? I’ll attempt to answer all those questions in this blog post’s first and second parts, plus possibly a few more.

What Is a Service Mesh?

As companies are increasingly re-architecting their applications and embracing a microservices-based approach, the need for solutions to traffic management, observability, security and reliability features increases. A service mesh is one approach to adding these features to the underlying platform instead of individual applications or services.

What kinds of traffic management, observability, security and reliability features are we talking about here? A few examples include:

A service mesh can do these things without modifications to the underlying applications or services. This is an important point—offloading this functionality to the service mesh means that organizations can focus on their applications instead.

What Makes Up a Service Mesh?

While the details of a specific implementation may vary, at a high level, all service meshes consist of two basic components:

The data planes sit in front of services or workloads that communicate through those data planes with other services or workloads. It’s the responsibility of the data planes to enforce the policies defined on and passed down by the control plane.

The control plane and data plane together make up a service mesh.

Figure 1: A generic service mesh architecture

More About the Control Plane

A service mesh’s control plane is responsible for “command and control” functions. Some typical functions of the control plane include:

It’s important to note that the control plane is out-of-band, so it doesn’t sit in-line between two communicating workloads. This ensures that the control plane isn’t a bottleneck and that an outage of the control plane doesn’t disrupt traffic.

The service mesh doesn’t redirect all the traffic up through the control plane. Instead, data planes are distributed across the mesh and placed close to each of the workloads. They’re only responsible for managing the traffic moving in and out of that particular workload and directly scale with the number of workloads deployed in the environment.

Digging into Data Planes

Unlike the control plane, a data plane is in-band; it is responsible for actually passing traffic into or out of a workload. This is the piece that actually moves packets to and from the workloads. Because it is in-band, it must be lightweight (not consume a lot of computing resources) and be very performant (not introduce significant latency or delays in the traffic it processes).

The data plane’s in-band position allows it to expose more detailed metrics about a workload’s network traffic; the data planes see all the traffic moving into or out of a workload. This enables observability functionality that might otherwise be difficult to achieve.

As an aside, some folks use “the data plane” (singular) to refer to the entity where traffic passes back and forth between and among services or workloads. Here we use the term “data planes” (plural) to refer to the collection of smaller entities responsible for managing the traffic in and out of a single workload only.

Where Does Envoy Fit In?

Originally created at Lyft, Envoy is a high-performance data plane designed for service mesh architectures. Lyft open sourced it and donated it to the CNCF, where it is now one of the CNCF’s graduated open source projects. 

What makes Envoy so well-suited for service mesh use cases? It offers several features that are very useful as a service mesh data plane.

Many different service meshes use Envoy. For example, Kong’s open source project Kuma—and its enterprise counterpart Kong Mesh—use Envoy for the data planes.

More Resources

Now that you understand the basics, look at these helpful resources for implementing an Envoy-based service mesh. And look check out part 2 of the series here!