Service Mesh


Service API Patterns, 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).

Module 12: Fundamental Service API Design & Management

This pattern is covered in Module 13: Advanced Service API Design & Management.

For more information regarding service API design & management courses and accreditation, visit the Service API Specialist program page.