As you know on microservice architecture, each service is now built and deployed independently, by small teams, that are flexible to choose their own tools and coding languages.
How Microservices already communicates ?
One of the most advantage that makes microservices possible is service-to-service communication that let each service can individually fail without escalating into an application-wide outage.
However, everything is not green in a Microservice architecture, As the number of services increase, you have to deal with the interactions between them, monitor the overall system health, be fault tolerant, have logging and telemetry in place, handle multiple points of failure, and more.
Cause the logic governing communication must have these common functionalities coded in each service, a service mesh becomes more valuable, especially communication becomes more complex on large disturbed systems.
So, what is a service mesh?
A service mesh can be defined as an infrastructure layer which handles the inter-service communication in a microservice architecture. Service mesh decouples the complexity from your application and puts it in a service proxy and lets it handle on a separate process or container to provide isolation and encapsulation. This is also known as “sidecars”.
The communication between sidecars form a mesh network. that sits alongside a microservice and routes requests to between the different proxies.
These service proxies can provide you with a bunch of functionalities like traffic management, circuit breaking, service discovery, authentication, monitoring, security, and much more. Hence from an application standpoint, all it contains is the implementation of business functionalities.
How Is Service Mesh Implemented?
A service mesh consists of two high-level components: a data plane and a control plane.
Broadly speaking, the data plane "does the work" and is responsible for conditionally translating, forwarding, and observing every network packet that flows to and from a [network endpoint].
A control plane "supervises the work," and takes all the individual instances of the data plane — a set of isolated stateless sidecar proxies—and turns them into a distributed system.
Without a Service Mesh:
Each Microservice implements Business Logic and Cross Cutting Concerns (CCC) by itself.
With a Service Mesh:
Many CCCs like traffic metrics, routing, and encryption are moved out of the Microservice and into a proxy. Business logic and business metrics stay in the Microservices.
Incoming and outgoing requests are transparently routed through the proxies.
In addition to a layer of proxies (Data Plane), a Service Mesh adds a so-called Control Plane. If distributes configuration updates to all proxies and receives metrics collected by the proxies for further processing, e.g. by a monitoring infrastructure such as Prometheus.
Advantages of using a sidecar pattern include:
• A sidecar is independent from its primary application in terms of runtime environment and programming language, so you don't need to develop one sidecar per language.
• The sidecar can access the same resources as the primary application. For example, a sidecar can monitor system resources used by both the sidecar and the primary application.
• Because of its proximity to the primary application, there’s no significant latency when communicating between them.
• Even for applications that don’t provide an extensibility mechanism, you can use a sidecar to extend functionality by attaching it as its own process in the same host or sub-container as the primary application.
The sidecar pattern is often used with containers and referred to as a sidecar container or sidekick container.
Service Mesh Implementations and Products
The following is a non-exhaustive list of current service mesh implementations:
• Istio
If you have heard about service mesh, you have probably heard about Istio too. Istio is by far the most popular service mesh because it has the most features and it is backed by Google and IBM.
• Linkerd
While Istio made the service mesh popular, Linkerd was the first service mesh and quite successful. Still, the developers decided to build a new version - Linkerd 2 - committed to usability, performance, and Kubernetes as the underlying platform.
• Consul
Consul is well known as a service discovery solution. They decided to implement the service mesh pattern into their architecture to provide even more advanced features.
• Maesh
As the name already reveals, Maesh is the service mesh based on Traefik, a cloud-native API gateway.
• Kuma
Similar to Maesh, Kuma is also a very new service mesh made by developers of an API gateway - Kong.
• AWS App Mesh
Not long after the service mesh hype, AWS added its own service mesh for applications on AWS.
References:
- https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
- https://dzone.com/articles/the-rise-of-service-mesh-architecture
- https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar
- https://servicemesh.es/
- https://www.infoq.com/articles/service-mesh-ultimate-guide/
More Info:
