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!
In this episode of Kongcast , I spoke with Scott Lowe , principal field engineer at Kong , about what a service mesh does and when to use it, among other common mesh-related questions. Check out the transcript and video from our conversation belo
In my Service Mesh 101 article, I talked about some of the basics behind a service mesh: what it is, what it does and where Envoy fits into a service mesh. Having now covered those basics, I'd like to dig into some more in-depth content focused on
The acceleration of microservices and containerized workloads has revolutionized software delivery at scale. However, these distributed architectures also introduce significant complexity around networking, security, and observability. As developmen
What is Service Mesh and Where Did it Come From? Over the past few months, you may have noticed the explosion of industry chatter and articles surrounding service mesh and the future of software architecture. These discussions have been highly polar
A Practical Look at When (and When Not) to Use Ambient Mesh The word on the street is that ambient mesh is the obvious evolution of service mesh technology — leaner, simpler, and less resource-intensive. But while ambient mesh is an exciting develop
Discover how API management and service mesh can go hand in hand toward secured platforms Over the last ten years, Kongers have witnessed hundreds of companies adopting a full lifecycle API management platform and have been working with the peop
