A service mesh addresses challenges associated with a microservices architecture. However, the service mesh itself introduces new challenges.

Challenges a Service Mesh Addresses

A service mesh is an abstraction layer on top of a microservices application that provides the following capabilities:

  • Service-to-service communication (including service discovery and encryption)

  • Observability (monitoring and tracing)

  • Resiliency (circuit breaking and retries)

  • Traffic management (routing, load balancing)

  • Security (authorization, encryption)

Before service mesh, client libraries and application programming interface (API) gateways were used to address some of the issues introduced by a microservices architecture. These solutions, however, have challenges of their own.

A service mesh solves some of the challenges introduced by distributed microservices by abstracting necessary functions (service discovery, connection encryption, error and failure handling, and latency detection and response) to a separate entity called proxy.

The proxy sits in front of each microservice, and all inbound and outbound communications flow through it. The proxy provides the functions noted above and metrics for observability purposes.

Challenges a Basic Service Mesh Does Not Address

Although most service mesh implementations prove effective in connecting services and securing service-to-service communication, because of inherent limitations, they don't address these challenges:

  • Limited scope. Service meshes focus on services alone. They do not extend the scope from service-to-service communication to users-to-service-to-data communication. However, application flows are not limited to interservice communications. Basic service meshes do not process the full end-to-end requests because they flow from end users through the services, and on to the data.

  • Challenges related to highly distributed heterogeneous platforms. In a multicloud, multiplatform environment, each cloud or platform has its own service mesh technology and uses different operational and security models. Basic service meshes do not provide the same capabilities (traffic management, security, and observability) across applications deployed in multiple clouds or platforms.

  • Federation challenges. Basic service meshes do not deliver security, control, and observability across different administrative boundaries, technologies, and service meshes. Basic service meshes do not provide connectivity, control, observability, and security outside the service mesh.

  • Autoscaling. Basic service meshes do not provide automatic scaling of services based on the resources usage or measured metrics on the system. However, Tanzu Service Mesh enriches standard service mesh functionality by offering service autoscaling. For more information about service autoscaling, see the Service Autoscaling with Tanzu Service Mesh User's Guide.

  • Gauging performance quality. Basic service meshes do not come with an effective way of measuring how well an application is doing. Industry practice is now embracing service level objectives as an essential measure of performance quality of applications. For more information, see the Service Level Objectives with Tanzu Service Mesh documentation.

Tanzu Service Mesh is not a basic service mesh. As an enterprise-class service mesh, it solves these challenges and more.