Service Mesh
The service mesh is usually implemented by providing a proxy instance, called a sidecar, for each service instance. Sidecars handle interservice communications, monitoring, and security‑related concerns – anything that can be abstracted away from the individual services. This way, developers can handle development, support, and maintenance for the application code in the services; operations teams can maintain the service mesh and run the app.
Istio, backed by Google, IBM, and Lyft, is currently the best‑known service mesh architecture. Kubernetes, which was originally designed by Google, is currently the only container orchestration framework supported by Istio.
Video on Service Mesh
What Is a Service Mesh in a Microservices Architecture?
A service mesh addresses some of the key challenges to realizing a microservices architecture. A service mesh allows more leeway in selecting a diverse set of microservices implementation technologies, while focusing more on business logic, instead of investing more time on network functions between services.
Service Mesh and Service Discovery
A service mesh works with a service discovery protocol to detect services as they come up. Then, the mesh ages them gracefully when they disappear. Service discovery is a container management framework that keeps a list of instances that are ready to receive requests – or be discovered – by other services. Together, they create resilience in service‑to‑service communication.