Service meshes provide visibility, resiliency, traffic, and security control of distributed application services. Much value is promised here, particularly to the extent that much is given without the need to change your application code.

Use of Meshery and the Service Mesh Interface specification help avoid switching costs between service meshes.

The goal of Service Mesh Interface specifications are to provide an abstract, unified method of interacting with a service mesh.

See if your service mesh adheres to SMI specifications at the link below.

Three service mesh abstractions have arisen given the high number of service meshes available (see the Service Mesh Landscape)

Servcie Mesh Performance (SMP) - A standard for capturing and characterizing service mesh performance.

Service Mesh Interface (SMI) - A standard interface for using common service mesh functionality on Kubernetes.

Multi-Vendor Service Mesh Interoperation (Hamlet) - A set of API standards for enabling service mesh federation.

Operators don’t necessarily need to involve Developers to change how many times a service should retry before timing out or to run experiments (known as chaos engineering). They are empowered to affect service behavior independently.

Customer Success (support) teams can handle the revocation of client access without involving Operators.

Product Owners can use quota management to enforce price plan limitations for quantity-based consumption of particular services.

Developers can redirect their internal stakeholders to a canary with beta functionality without involving Operators.

Security Engineers can declaratively define authentication and authorization policies, enforced by the service mesh.

Network Engineers are empowered with an extraordinarily high degree of application-level control formerly simply unavailable to them.

Service meshes provide intent-based networking for microservices describing desired behavior of the network in the face of constantly changing conditions and network topology. At their core, service meshes provide:

A services-first network; A developer-driven network;

A network that is primarily concerned with alleviating application developers from building infrastructure concerns into their application code; A network that empowers operators with the ability to declaratively define network behavior, node identity, and traffic flow through policy;

A network that enables service owners to control application logic without engaging developers to change its code.

Value derived from the layer of tooling that service meshes provide is most evident in the land of microservices. The more services, the more value derived from the mesh. In subsequent chapters, I show how service meshes provide value outside of the use of microservices and containers and help modernize existing services (running on virtual or bare metal servers) as well.

There are many service meshes to choose from as well as a variety of deployment models. Which is right for you and your organization depends on where you are in your maturity curve (Cloud Native skill set), number of services, underlying infrastructure, and how centric technology is to your business.

So, should you deploy a service mesh? More and more the answer is “yes”. Service meshes are quickly becoming a ubiquitous layer in modern infrastructures.