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.
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.
Design your deployments the way you want. Drag-and-drop your cloud native infrastructure using a pallete of thousands of versioned Kubernetes components. Say goodbye to YAML configurations. Have your cloud native deployments automatically diagrammed. Deployments configured and modeled in Designer mode, can be deployed into your environment and managed using Visualizer. Discover a catalog of best practice cloud native patterns