What Is a Service Mesh?
A Service mesh is a dedicated infrastructure layer that enables service-to-service communication between microservices, often within a cloud-based application. It manages how different parts of an application share data with one another, ensuring reliable data transfer, service discovery, load balancing, and encryption.
Using a service mesh can enhance the network’s security, reliability, and observability. Unlike traditional monolithic architectures where inter-service communication is hard-coded into the application logic, a service mesh abstracts this complexity into a separate layer.
This allows developers to focus on developing business logic rather than worrying about the intricacies of network and communication protocols. A service mesh operates at a high level of abstraction, enabling granular control over how services in a microservices architecture communicate with each other.
In this article:
- Service Mesh Architecture: Key Components
- Example of a Service Mesh: Istio Architecture Diagram
- Service Mesh Architecture: Key Design Considerations
- Do you really need a service mesh? Calico offers an operationally simpler approach
Service Mesh Architecture: Key Components
A service mesh typically consists of two main components, the data plane and the control plane, as illustrated in the diagram below.
Data Plane
The data plane handles the actual traffic between services. It comprises a collection of intelligent proxies, deployed as sidecars alongside service instances. These proxies intercept and manage all network communication between microservices. They apply various policies such as routing, load balancing, and authentication, ensuring that data packets reach their intended destinations.
The proxies within the data plane are responsible for executing detailed instructions provided by the control plane. They perform tasks like encrypting and decrypting requests for secure transmission, implementing rate limiting to prevent service overload, and recording telemetry data for monitoring purposes.
Because these proxies sit directly in the path of inter-service traffic, they also play an important role in broader container security strategies by enforcing encryption, authentication, and policy at runtime.
The Control Plane
The control plane acts as the brain of the service mesh architecture, orchestrating the configuration and management of the network’s communication rules. It centralizes policy decisions and distributes these policies to the data plane’s proxies for enforcement. This enables dynamic updates and communication management without direct code changes or redeployments.
The control plane provides a unified interface for administrators to define, apply, and monitor policies across all services. Through this interface, operators can implement security measures like authentication and authorization, manage traffic flow via routing rules, and observe system behavior through logging and monitoring tools.
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.
While Istio is widely adopted, several other service meshes offer different trade-offs in complexity, performance, and feature scope—see our overview of Istio alternatives for a comparison.
Read our guide: What Is Service Mesh in Kubernetes? 4 Tools to Get Started
Service Mesh Architecture: Key Design Considerations
Here are some important considerations when designing a service mesh architecture.
1. Plan for Observability
Integrate comprehensive monitoring and logging tools that can provide insights into both the infrastructure and application levels. This involves collecting metrics, traces, and logs from the proxies in the data plane as well as the components of the control plane. Such a setup enables developers and operators to gain visibility into the performance of services, understand dependencies, and quickly identify issues or bottlenecks within the system.
Observability practices leverage the capabilities of the service mesh to automatically gather detailed telemetry data without adding overhead to application code. Built-in features for tracing requests across services and monitoring network latency, errors, and throughput allow teams to proactively manage service health and optimize performance. They also support root cause analysis with a granular view of interactions between microservices.
2. Implement Strong Security Practices
Ensuring security in a service mesh involves leveraging its inherent features to enforce security at various levels. By default, the service mesh should ensure encrypted communication between services using mutual TLS (mTLS), providing a baseline for secure data transfer. This encrypts all traffic within the network, mitigating risks associated with data breaches and eavesdropping.
Additionally, fine-grained access control policies allow administrators to specify which services can communicate with each other, further enhancing the security posture. Regularly rotating service credentials and automating certificate management also help maintain a strong security framework. The service mesh’s control plane should automate these processes, ensuring certificates are up-to-date without manual intervention.
3. Decouple Configuration
Decoupling configuration from application code enables dynamic management of network behavior without redeploying services. This involves externalizing configuration into the control plane, which then propagates updates to the data plane’s proxies. It allows operators to modify routing rules, security policies, and load-balancing strategies on the fly.
By keeping configuration separate, service meshes enable easier version control and rollback of settings. In the event of problematic updates or unforeseen issues with new configurations, administrators can quickly revert to previous states without impacting the application’s core functionality.
4. Automate with Policies
The service mesh architecture should define rules that govern the behavior of services and their communication without manual intervention. Policies can dictate traffic routing, security measures like authentication and authorization, and service discovery mechanisms. Automating these aspects ensures consistent enforcement of best practices across all services.
Automated policies also allow for dynamic adaptation to changing operational conditions. For example, a policy could automatically divert traffic away from an overloaded service or enforce stricter security checks in response to an identified threat.
5. Enable Gradual Rollouts
Gradual rollouts in a service mesh environment make deployment safer by allowing new versions of services to be introduced to a subset of traffic. They minimize the risk associated with deploying updates and new features. Operators can use the service mesh’s control plane to incrementally shift traffic from older versions to new ones, closely monitoring the impact on system stability and performance.
A/B testing and canary releases provide an opportunity to detect issues early and adjust configurations or rollback without affecting the entire user base. Operators can direct a small percentage of traffic to new service versions, analyze behavior and performance, and then gradually increase exposure based on success criteria.
Do you really need a service mesh? Calico offers an operationally simpler approach
A service mesh adds operational complexity and introduces an additional control plane for teams to manage. Platform owners, DevOps teams, and SREs have limited resources, so adopting a service mesh is a significant undertaking due to the resources required for configuration and operation.
Calico enables a single-pane-of-glass unified control to address the three most popular service mesh use cases—security, observability, and control—with an operationally simpler approach, while avoiding the complexities associated with deploying a separate, standalone service mesh. With Calico, you can easily achieve full-stack observability and security, deploy highly performant encryption, and tightly integrate with existing security infrastructure like firewalls.
- Encryption for data in transit – Calico leverages the latest in crypto technology, using open-source WireGuard. As a result, Calico’s encryption is highly performant while still allowing visibility into all traffic flows.
- Dynamic Service and Threat Graph – Kubernetes-native visualization of all collected data that allows the user to visualize communication flows across services and team spaces, to facilitate troubleshooting.
- Operational simplicity with Envoy integrated into the data plane – Calico provides observability, traffic flow management, and control by deploying a single instance of Envoy as a daemon set on each node of your cluster, instead of a sidecar approach, thus making it more resource efficient and cost effective.
- Zero-trust workload access controls – Integrate with firewalls or other kinds of controls where you might want to understand the origin of egress traffic. Identify the origin of egress traffic, to the point where you have visibility into the specific application or namespace from which egress traffic seen outside the cluster came.
Next steps:
