In this article, we will be discussing the Microservice Mesh which includes:
What is a Service Mesh?
Advantages of Service Mesh
Disadvantages of Service Mesh
How does a Service Mesh Work?
How to Secure Service Mesh?
What is a service mesh?
A service mesh is an architectural pattern for microservices deployments. Its primary goal is to make service-to-service communications secure, fast, and reliable.
In a service mesh architecture, microservices within a given deployment or cluster interact with each other through sidecar proxies. The security and communication rules behind these interactions are directed through a control plane. The developer can configure and add policies at the control plane level, and abstract the governance considerations behind microservices, regardless of the technology used to build. Popular Service Mesh frameworks, such as Istio, have emerged to help organizations implement these architectural patterns.
Advantages of Service Mesh
Increase release flexibility. Organizations can exercise greater control over both their testing procedures and deployments.
Ensure high availability and fault tolerance. Businesses can deploy a service mesh to enable setup retries and failover and to test code paths through fault injections.
Maintain secure communications. Chief information security officers and IT teams can authenticate, authorize and encrypt service-to-service communications. For example, service meshes are useful to manage service encryption via mutual Transport Layer Security and ensure secure connections.
Gain greater visibility. Service mesh deployments ensure observability and monitoring in the form of latency metrics, distributed tracing support, and real-time service-to-service monitoring.
Disadvantages of Service Mesh
Added Complexity: The introduction of proxies, sidecars, and other components into an already sophisticated environment dramatically increases the complexity of development and operations.
Required Expertise: Adding a service mesh such as Istio on top of an orchestrator such as Kubernetes often requires operators to become experts in both technologies.
Slowness: Service meshes are an invasive and intricate technology that can add significant slowness to an architecture.
Adoption of a Platform: The invasiveness of service meshes force both developers and operators to adapt to a highly opinionated platform and conform to its rules.
How does a Service Mesh work?
It has two components:
Data Plane
Control Plane.
1. Data Plane
The data plane consists of proxies deployed to each microservice instance as a Sidecar.
A Sidecar is a design pattern that helps separate specific operations from a microservice, thus reducing its internal complexity. So, the networking operations get isolated to the Sidecar. Hence it acts as a proxy and manages all incoming and outgoing communications in each microservice.
Additionally, the Sidecar is responsible for more features such as:
Security (with mTLS)
Service discovery
Load balancing
Circuit breaking to avoid unnecessary invocations of failing microservices until it is back online
Observability through logs
2. Control Plane
The control plane offers a GUI or a CLI that the operations team can use to generate and deploy the configuration information needed to manage the behavior of the proxies in the data plane. It’s important to note that the data plane must connect and register using an API to obtain the configuration information for the control plane.
The diagram below illustrates an architectural diagram of a Service Mesh highlighting the discussed components:
It provides more reliable intra-service communication, thus increasing the user experience for client applications. That’s why Netflix, Twitter, and Lyft leverage the Service Mesh Architecture. For example, Netflix uses microservices that communicate with other microservices to serve millions of client requests.
Hence, Netflix requires:
Load balancing to manage the load for these requests
Secure communication to avoid data breaches when communicating between services
Comprehensive monitoring to ensure everything works as expected. And if not, prevent microservices from invoking the failing services until they get fixed (Circuit breaking)
The Sidecar deployed with each microservice enforces these requirements. Furthermore, Netflix and other companies with large-scale applications require the ability to deploy new versions of microservices with minimized downtime using Blue/Green deployments. They can use the load balancer of the Service Mesh to implement “Traffic Routing” to help route a certain number of user requests to the new version while the remaining requests get routed to the old version. This helps them to test the new version without affecting a large customer base. Once tested, they can fully route all traffic to the new version, thus enabling seamless Blue/Green deployments.
How to Secure Service Mesh?
Securing the microservices mesh is important to protect your data. And the best way to secure the microservices mesh is to use an API gateway. This ensures you can prevent unauthorized data access, loss of data integrity, or degradation of the quality of service.
A monolithic application executes all function-to-function calls within the monolith and is secure. However, a microservice application uses HTTP to communicate with other services and generally has a higher need for authentication and authorization in order to secure the communication between these distributed services. Moreover, if it is not secure, a hacker may intercept the request and get access to sensitive data. That’s why microservices have a higher need for security. With a Service Mesh, the Sidecar proxy deployed with each microservice helps to satisfy authentication and authorization needs to control the traffic flow.
By default, it offers four forms of authentication:
JWT validation in applications
JWT validation at the ingress
Istio Ingress TLS passthrough + JWT Validation at Sidecars
Istio mTLS + JWT Validation
Besides, it allows requests to get authorized in the principle of least privilege using a Role/Attribute-based Access Control. These security measures get enforced at the Sidecar and the Service Mesh and, as a result, the request gets validated in the Sidecar proxy and is forwarded to the microservice only if authorized to access it, ensuring high security.
Resource: spectralops.io
The Tech Platform