Service Mesh Pattern in Software Architecture
Application of different Service Mesh Tactics
Performance concerns are driving forces for software architects to come up with new techniques for more efficient software performance. The performance is also hot topic for teams applying microservices. The extreme popularity of microservices has led to evaluation of service mesh pattern/architecture (whatever you want to call this…).
In software architecture, a service mesh is a dedicated infrastructure layer for facilitating service-to-service communications between services or microservices, using a proxy.
The main idea is to isolate application-independent cross-cutting concerns such as communication, monitoring, security, authentication/authorization etc. from core business logic. This kind of dedicated infrastructure layer adds value to low latency, configurability.
Service Mesh is implemented typically through array of proxies, and sidecar pattern. Sidecar/Sidekick pattern uses a same languages and libraries and service is needed that shares the lifecycle but can be independently deployed. The functionalities like logging, configuration etc. can be abstracted away to another microservice, as shown in example below. This pattern has 1:1 relation with Primary Service.
