In its 2020 Cloud Native Survey most recent report, The Cloud Native Computing Foundation (CNCF) found that use of service mesh in production jumped 50% in the last year. Twenty seven percent of those surveyed report using the technology in production. Yet, the question remains, when is the right time to adopt a service mesh and which use cases does it benefit most? In today’s article, we’ll explore who really needs to pay attention to service mesh and why.
What is service mesh?
First, a quick overview for anyone who needs a refresher. A service mesh is a set of components that broker service to service communications via a control plane. In this way the service mesh allows parts of applications to communicate with each other, and as a result is quite popular for containerized microservices. Service meshes usually feature discovery of services in the organization, and can include load balancing, encryption and even failure recovery. Well-known service mesh solutions include Istio, Linkerd, Tetrate, Consul Connect, Kuma and AWS App Mesh. While each of these has its own strengths and weaknesses, we won’t delve into these today.
How does it work?
Within microservice environments, the service mesh solution attaches a sidecar instance to each microservice. Sidecars can manage tasks, like monitoring, abstracted from the microservice. Together the interactions between the microservice instance and the side car create a data plane. Acting like the brain of the data plane, the control plane manages the tasks, like monitoring.
Service mesh use cases
Service mesh is ideal in environments with existing applications that have evolved over time and have dependencies that have become interwoven. The benefit of microservices – that different teams can work independently on services with their own tools and languages – can also become a challenge. As teams release services independently, coordinating communication can become increasingly complex, growing to the point where dependencies can become unmanageable. If one service fails, it can topple the others.
Service mesh helps these organizations much more effectively manage discovery and communication. To this end, the more non-standardized an organization’s microservices are, the more powerful a service mesh solution can be.
Best practice advice
Having worked with a wide variety of microservice environments, we’ve found the following to hold true:
- Only use service mesh if you need it to manage your environment’s complexity. While service mesh is gaining rapidly in word-of-mouth popularity, it’s not a fit for all situations and can in fact be more complicated to deploy than your microservice environment. Make sure you do your due diligence to ensure it’s a solution you need before moving forward. If you are just starting out with microservices, we recommend you focus your efforts instead on mastering an orchestration solution, like Kubernetes.
- If a service mesh solution is a fit for your environmental needs, treat it like it’s part of your platform. Get support for it from your DevOps team and have them help enable development teams to use and consume it.
- When using a service mesh with external customers, it makes sense to add another layer, like Apigee or a cloud native service with AWS API Gateway, to securely expose the end points to external parties. If integrating with external partners, we recommend creating an API product or access token with API management on top of it to ensure secure third-party access. This approach shares common elements with zero trust.
As use of cloud, containers and microservices are growing, not every organization has reached the point where they can truly benefit from a service mesh solution. As your environment’s microservice complexity grows, so too will your need for the benefits service mesh bring – discovery, connectivity, security and observability across complex microservice environments. Need help determining if service mesh is right for you? Reach out to our microservice experts today.
Post Date: 4/20/202104/20/2021