A service mesh is a technology used to control the way various parts of an application share data with one another. Other microservices systems perform similar tasks. However, a service mesh is a layer built directly into an app to perform this task where other methods are often external integrations. A service mesh layer is useful in documenting how effectively parts of an app are interacting, allowing developers to optimize and address issues more effectively.
Each piece of an application is known as a “service.” Each service is responsible for a specific function that relies on another service to perform the task requested by the end-user. An example of this is a user is on an e-commerce application finding an item they want to purchase in a particular size or color. The app has to communicate that the item is available by interacting with inventory systems that can communicate with product pages. Product pages then need to display the information to the end-user.
Most modern applications utilize service mesh to break down services into containers to form a network of services, each performing its specific business function. Sometimes for one service to perform, it has to refer to various other services first; this is where service mesh layers assist in not overloading systems with requests by optimizing the routing of requests and how the request moves from one service to another.
Service mesh does not bring new functions to an application’s environment as an application, regardless of the architecture type, needs specific rules that specify how requests are handled from the point of origin to destination. The primary difference between microservices and service mesh is that the logic governing component of service-to-service communication is removed from the individual services and is instead applied as a full layer of infrastructure by being built into the application through an array of network proxies. The proxies are used to route requests between microservices in the service mesh layer. The individual decoupled proxies form the layer and run alongside one another in a process known as “sidecar” proxies.
Service mesh flow chart
The microservice architecture differs from service mesh in that it allows developers to make changes to an application’s services without a full redeployment of an application. Additionally, microservices are more siloed in nature. Individual teams develop app segments with their specific tools and languages and are built independently to communicate with other elements and independently fail without causing a full application outage. Microservices are powered by service-to-service communication through logic governing coded into each service. However, as communication gets more complicated, service mesh becomes more valuable to an application due to its ability to compromise a larger number of services into one functional application.
Microservices flow chart
According to Industry Today, the global market for service mesh between 2021-2026 is expected to grow at a CARG of 39.5% year-over-year. Additionally, according to the source, the service mesh industry is estimated at $227.8 million by 2025. Companies already competing in the service mesh industry include:
- A10 Networks
- Vamp
- HashiCorp
- Buoyant
- Solo IO
- F5
- Red Hot
- IBM
Various companies and communities have launched open-source or community-driven service mesh codes for use in developer built applications, where others have developed service mesh produced built around the available open-source proxies such as Envoy, Traefik, and others.
Istio is an example of an extensible open-sourced service mesh built on the Envoy proxy, which allows teams to secure, control, observe, and connect services. Istio remains an ongoing collaboration between IBM and Google.
Linkerd is a service mesh for Kubernetes, and according to the company, it takes only 60 seconds to install to a Kubernetes cluster. Unlike its competitor Istio, Linkerd uses a Rust proxy called linkerd2-proxy, a proprietary build for Linkerd.
Consul Connect is the service mesh developed by HashiCorp, which focuses on segmentation and providing service-to-service networking features through application-level sidecar proxy. Consul is offered through two different proxy options: its proprietary built-in layer for proxy testing and the other being Envoy. HashiCorp has an open-sourced option for Consul Connect but also offers an enterprise-level version of the product.
Maesh is another open-sourced container-native service mesh that markets itself as “lightweight and straightforward.” Its largest difference from similar products is that it’s built on Traefik, an open-source reverse proxy, and load balancer. Maesh also does not utilize the sidecar method and instead uses proxy endpoints for each node, allowing the mesh to be less invasive than sidecar enabled service mesh. The prerequisite for Maesh to be implemented in an application is Kubernetes 1.11+ and a CoreDNS/KubeDNS installation.
Network Service Mesh (NSM) is a service mesh developed by Cloud Native Computing Foundation, as a sandbox project, specifically for telcos and ISPs, providing a layer for adding low-level networking capability Kubernetes. NSM was built on “exotic” protocols and heterogeneous configurations, making it optimal for edge computing, 5G networks, and IoT devices industries.
OpenShift Service Mesh is the service mesh product developed by Red Hat. The company describes it as a hybrid cloud enterprise Kubernetes platform with numerous abilities for enterprise adaptation from its open-sourced code. OpenShift was built atop the open-sourced Istio, which allowed for an integration between the two platforms. OpenShift additionally uses Jaeger for distributed tracing for better tracking of how requests are handled between application services.
ServiceComb-mesher is the service mesh developed by The Apache Software Foundation. It is described by the company as a high-performance mesh written in Go, based on Go Chassis, a microservices development framework, and runs on the sidecar design methods. ServiceComb supports HTTP and gRPC and has application in various infrastructure types, including Docker, Kubernetes, virtual machines, and bare-metal environments.
Kuma, developed by Kong, is a service mesh. Kong defines the product as a “service mesh alternative called platform-agnostic control plane.” Kuma is built on the open-sourced Envoy proxy and provides networking features for security, routing, and communications observation. Kuma is natively compatible with Kong, which allows for simple implementation for enterprises using the Kong API.
Amazon Web Services developed the AWS App Mesh for application-level networking. App Mesh uses the open-source Envoy proxy to control traffic in and out of service containers, and it supports HTTP/2 gRPC services. App Mesh integrates into numerous pre-existing infrastructures, including AWF Fargate, Amazon Elastic Compute Cloud (ECS), and Kubernetes on EC2, which includes App Mesh at no additional cost.
