See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
4 MIN READ
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.
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.
While the details of a specific implementation may vary, at a high level, all service meshes consist of two basic components:
Figure 1: A generic service mesh architecture
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.
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.
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.
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!
Share Post
Learn how to make your API strategy a competitive advantage.