What is a service mesh?

What is a service mesh?

https://www.techtarget.com/searchitoperations/definition/service-mesh

A service mesh is a dedicated infrastructure layer that controls service-to-service communication within a distributed application. This method enables separate parts of an application to communicate with each other. Service meshes appear commonly in concert with cloud-native applications, containers and microservices.

A service mesh controls the delivery of service requests in an application. Common functions provided by a service mesh include service discovery, load balancing, encryption and failure recovery. High availability is also common through the use of software controlled by application programming interfaces (APIs) rather than through hardware. Service meshes can make service-to-service communication fast, reliable and secure.

An organization can choose an API gateway that handles protocol transactions instead of a service mesh. However, developers must update the API gateway every time a microservice is added or removed. Service meshes typically offer network management scalability and flexibility that exceed the capabilities of traditional API gateways.

The service mesh market

There are numerous commercial and open source service mesh options available. Some are open source or are based in part on open source technology; others are tied to other service mesh platforms. Many are available as software as a service (SaaS) products. The major cloud providers and Kubernetes platform providers offer packaged and hosted service mesh products. The following is an alphabetical list of several providers of service mesh products and services:

• Amazon Web Services. AWS App Mesh is afully managed service mesh that provides consistent visibility and network traffic controls for services built across multiple types of compute infrastructure.
• Buoyant. Buoyant Cloud is a managed version of Linkerd and is an enterprise-ready distribution of the Linkerd service mesh, which is designed to provide a strong, secure infrastructure for managing microservices in production environments.
• F5. Platform-agnostic Nginx Service Mesh offers flexible traffic management and emphasizes security by ensuring mutual Transport Layer Security-encrypted communication for containerized applications.
• Google. Cloud Service Mesh provides a Google-managed control plane and an optional data plane, handling reliability, upgrades, scaling and security for users.
• HashiCorp Inc. Consul offers service discovery and service mesh capabilities to handle network management in distributed environments. It works with AWS and Microsoft Azure and is also available as a SaaS product.
• Istio. The open source Istio service mesh provided by Google, IBM and Lyft is a universal control plane originally targeted for Kubernetes deployments, but architects can use it on multiple platforms. Its data plane relies on proxies called Envoy sidecars.
• Kong. Enterprise-ready Kong Mesh runs on both Kubernetes and VMs on any cloud.
• Kuma. Kuma, which is an open source project supported and maintained by Kong, is a modern control plane for microservices and service mesh, designed to support both Kubernetes and VMs, while providing an easier path to migrating between the two.
• Linkerd. This open source, multiplatform service mesh developed by Buoyant is built on Twitter's Finagle library. This service mesh supports platforms such as Amazon Elastic Container Service, Docker and Kubernetes.
• Red Hat. Red Hat OpenShift Service Mesh helps developers manage, connect, secure and monitor microservices within an OpenShift Container Platform environment, offering operational control, as well as insights.
• Solo.io. Gloo Mesh, which is built on the Istio platform, is designed to simplify the Istio service mesh for Kubernetes clusters and offers features such as dashboards for health checks, operational insights for troubleshooting, advanced traffic management and security.
• Tetrate. Also based on the Istio platform, Tetrate provides an enterprise-ready, fully upstream distribution called Tetrate Istio Subscription. Additionally, Tetrate's advanced API gateway option efficiently manages, secures and monitors APIs, utilizing Istio service mesh capabilities for improved traffic management and secure communication.
• Traefik Labs. TheTraefik Mesh open source service mesh simplifies configuration and offers visibility and management of traffic flows within Kubernetes clusters. It's designed to be nonintrusive and user-friendly, enabling users to identify underutilized resources and overloaded services for optimal resource allocation.
• VMware. Tanzu Service Mesh provides enterprise-grade control and security for microservices, users and data across different clusters and clouds. It supports multiple platforms, public clouds and runtime environments, including Kubernetes.

https://jimmysong.io/en/blog/service-mesh-the-microservices-in-post-kubernetes-era/

https://philcalcado.com/2017/08/03/pattern_service_mesh.html

https://konghq.com/blog/learning-center/what-is-a-service-mesh

The Data Plane

The data plane is made up of services running alongside sidecar proxies. The services handle business logic, while proxies sit between them and other services. All traffic, ingress, and egress occur through the proxies, which are responsible for routing (proxying) traffic to other services.

Fig. 1: Service mesh data plane

Many features provided by the service mesh work at the request level, making sidecars Layer 7 proxies. By operating at this layer, service meshes provide capabilities like intelligent load balancing based on observed latency, or provide sensible and consistent timeouts for requests.

Sidecars also provide functionality at the connection level. For example, sidecars can provide functionality like Mutual Transport Layer Security (mTLS), allowing each party in the communication to validate the certificate of the other.

The Control Plane

Proxies need to be configured. This is done through the control plane, which consists of several services that provide administrative functionality over the service mesh and provides an interface to configure the behavior of the data plane and for the proxies to coordinate their actions.

Fig. 2: Service mesh architecture

Operators interact with the service mesh through the control plane by using a CLI or API. For example, operators work through the control plane to define routing rules, create circuit breakers, or enforce access control.

Depending on the implementation, you can use the control plane to export observability data such as metrics, logs, and traces.

Fig. 3: How a service mesh works

To learn more about how a service mesh works, see Understanding a Service Mesh Architecture.

https://learn.microsoft.com/en-us/dotnet/architecture/cloud-native/service-mesh-communication-infrastructure

Throughout this chapter, we've explored the challenges of microservice communication. We said that development teams need to be sensitive to how back-end services communicate with each other. Ideally, the less inter-service communication, the better. However, avoidance isn't always possible as back-end services often rely on one another to complete operations.

We explored different approaches for implementing synchronous HTTP communication and asynchronous messaging. In each of the cases, the developer is burdened with implementing communication code. Communication code is complex and time intensive. Incorrect decisions can lead to significant performance issues.

A more modern approach to microservice communication centers around a new and rapidly evolving technology entitled Service Mesh. A service mesh is a configurable infrastructure layer with built-in capabilities to handle service-to-service communication, resiliency, and many cross-cutting concerns. It moves the responsibility for these concerns out of the microservices and into service mesh layer. Communication is abstracted away from your microservices.

A key component of a service mesh is a proxy. In a cloud-native application, an instance of a proxy is typically colocated with each microservice. While they execute in separate processes, the two are closely linked and share the same lifecycle. This pattern, known as the Sidecar pattern, and is shown in Figure 4-24.

Figure 4-24. Service mesh with a side car

Note in the previous figure how messages are intercepted by a proxy that runs alongside each microservice. Each proxy can be configured with traffic rules specific to the microservice. It understands messages and can route them across your services and the outside world.

https://www.tigera.io/learn/guides/service-mesh/service-mesh-architecture/

Example of a Service Mesh: Istio Architecture Diagram

Istio is a popular, open source service mesh solution. The following diagram shows the architecture of the Istio service mesh.

Image source: Istio

Data plane
In Istio, the data plane is made up of Envoy proxies, which are deployed as sidecars alongside each service. These proxies manage all inbound and outbound traffic for the services, handling tasks such as load balancing, dynamic service discovery, TLS termination, and health checks. Envoy proxies also collect telemetry data, enabling detailed monitoring and analysis of traffic within the mesh.

Control plane
In the diagram above, the control plane is represented by Istiod. This component manages the configuration and operation of the data plane. Istiod handles service discovery, configuration, and certificate management. It converts high-level routing rules into configurations that Envoy proxies can enforce.

Istiod also enables strong security practices by managing service-to-service and end-user authentication and acting as a Certificate Authority for secure mTLS communication within the data plane.

Read our guide: What Is Service Mesh in Kubernetes? 4 Tools to Get Started

consul -- service mesh

https://www.consul.io/

https://github.com/nicholasjackson/demo-consul-service-mesh/blob/master/traffic_routing/docker-compose.yml

https://github.com/nicholasjackson/demo-consul-service-mesh/blob/master/gateways/docker-compose.yml

consul -- service discovery

https://github.com/santteegt/docker-consul-demo

https://github.com/aevri/hello-consul-docker/tree/master