Consul: Up and Running

Chapter 1. Service Mesh 101

To get started on your service mesh journey, you need to know three things: what a service mesh is, how it works, and why you should use it (and when you should not).

There is no universally accepted definition for a service mesh, but I define it as follows:

A service mesh is an infrastructure layer that enables you to control the network communication of your workloads from a single control plane.

We can break that definition down into parts to better understand it:

By infrastructure layer, I mean that a service mesh is not part of your services; it is deployed and operated independently. Since it is not aware of service-specific business logic, but it affects every service, it is considered infrastructure or middleware.

Figure 1-1 shows a typical software stack. Services and applications run on top of infrastructure. Service mesh is at the first infrastructure layer with storage, metrics, and other higher-level infrastructure requirements. Under that is VMs, Kubernetes, or any compute provider or orchestrator where everything runs. At the bottom is actual hardware (bare metal).

By control the network communication of your workloads, I mean that a service mesh controls the traffic entering and leaving a microservice, database, or anything else that does network communication. For example, a service mesh might disallow incoming traffic based on a rule (such as it’s missing a required header), or it might encrypt outgoing traffic. A service mesh has ...