Service API Patterns, Protocols, Coupling Types, Metrics > Service API Design Patterns > Service Mesh

 

Service Mesh

How can cross-cutting functionality be deferred and abstracted so that it can be processed and managed independently?

With the application of the Service Mesh pattern, service logic is split into business-centric and cross-cutting (or utility-centric) logic each with its own implementation. The cross-cutting logic is placed into a dedicated location, such as a service API proxy. This allows the business-centric service to exist separately and shields it from having to interact with system resources or be involved with external service communication. This separation of logic is consistently implemented in services throughout a particular domain, so as to establish a “mesh” of inter-service and infrastructure-level processing that can be also independently and centrally administered.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The service API proxies across different service implementations form an infrastructure-level mesh that includes the cross-service communication activity. The business-centric logic within each service is shielded from mesh-level activity. A central administration tool can be utilized to manage the mesh.

The service API proxies in a service mesh are commonly implemented as “sidecars” within a container. Containerization and the Container Sidecar pattern are covered in Module 9: Advanced Microservice Architecture & Containerization (as part of the Microservice Architect Certification program) and Module 1: Fundamental Containerization Architecture (as part of the Containerization Architect Certification program).