A fairly recent technology, the service mesh came about as pressures mounted in the industry from the increasing use of Kubernetes and microservices in general. Applications were broken down into smaller containerized services, which all had to communicate with one another, and the outside world, both securely and safely.
The problem with this approach is that it required application developers to add to their apps an entire networking stack to deal with issues like service discovery, routing, circuit breaking, load-balancing, and security authorization. The answer didn’t come in the form of a library that a developer could use because even smaller shops used multiple languages to build their apps.
The service mesh provided an answer to all these by abstracting all of these components into a sidecar, which could be attached to the application and could communicate with all the other sidecars on a network.
A typical service mesh can be divided into two parts, a data plane and a control plane. The data plane deals with the actual traffic from one application to another. Any networking aspects regarding the actual service requests, such as routing, forwarding, load balancing, even authentication and authorization are part of the service mesh data plane. The control plane is the entity that connects the various data planes into a distributed network. This is the policy and management layer of the service mesh.
One of the most popular service mesh packages, Istio is, in itself a control plane, though it uses Envoy as a data plane.
The Cloud Native Computing Foundation’s Linkerd, managed by Buoyant, is another popular service mesh. It was recently rewritten to move the codebase off the chunky Java language to the most nimble combination of Go and Rust. Linkerd 2.0 was also designed to work more smoothly with the Kubernetes container orchestration engine (though contrary to popular belief, a service mesh does not require Kubernetes to run).
In addition to new service mesh packages popping up, a number of network management software stacks have been extended to become full-fledged service meshes, notable the Nginx application server, the Kong API gateway and HashiCorp’s Consul. And because of the early success of the service mesh, there is a growing movement towards creating tools to manage multiple service meshes, including the Service Mesh Interface standardization effort and the Gloo software for service mesh federation.
Because the service mesh is a cloud native technology, we will be following its progress very closely. So bookmark this page for the latest news and views on the service mesh.
