A service mesh is a software-based infrastructure layer that enables and manages communication between services within a microservices app architecture. It connects multiple small, decoupled services that would otherwise be challenging to effectively integrate, secure, and monitor at scale. Without a service mesh, services would operate in isolation and administrators would have a disjointed (or outright broken) task of finding and updating IPs of various services as they move or scale.
Service mesh emerged as a concept in the 2010s in response to early microservices architectural developments. We often relate service mesh to Kubernetes (K8s) and the containerized deployment model, the former having been released in mid-2015. There are many different service mesh implementations out there as there's no one standard (or versioning) attached.
Containers were a great way to deploy lightweight services quickly, and K8s was created as an orchestration layer for these highly scalable building blocks. Soon after, service mesh gained immense popularity since it largely solved the challenge of uniting that tangled web of unique microservices into something cohesive. The mesh provides abstraction and exists outside of the application code — while greatly reducing the code developers must write to make their services run smoothly.
How does a service mesh work?
Service meshes rely on tight interconnectedness between the data plane, which manages client-server packet delivery, and the control plane — which manages data plane's functions, configurations, security, observability, and more.
The data plane typically includes the network proxies that help connect internal networks to various microservices. These monitor service-to-service communication across the network and usually run as sidecar services themselves. These sidecars are paired with every service instance within a Kubernetes pod, receive two-way traffic from those services, and route requests accordingly. The sidecar acts as a middle man and prevents the services from directly communicating amongst themselves. As a result, service meshes are often considered gateways.
Meanwhile, the control plane helps manage and configure the mesh. Using one or more APIs or a GUI, the control plane lets administrators centrally control how traffic flows and critical routing procedures. It also contains the service registry compiled during automated service discovery. This plane also aggregates runtime metrics, alerts, logs, and other network performance indicators to help administrators address issues.
Here's how a service mesh handles traffic:
Ingress traffic arrives at the mesh boundary and passes through to the data plane, which contains the proxy or proxies supporting the service mesh.
The mesh inspects that traffic, determines its correct destination, then forwards those messages from the proxy to the matching service based on path, IP address, etc.
If one container needs to talk to another in order to service a request messages are sent between individual proxy sidecars.
Any traffic not destined for the mesh moves onward, usually through an egress gateway for security and policy enforcement.
The control plane enforces policies, configurations, and other settings in real-time to ensure smooth and secure traffic management in conjunction with the service mesh.
However, sidecar-less services meshes also exist. These forego the typical proxy-service pairing in favor of centralization — and may also leverage other architectures. It's possible to deploy node-level proxies, eBPF service meshes, and more closely integrate mesh functionalities with routers, gateways, or other networking components.
Sidecar-less service meshes are useful because they're less resource intensive, and thus incur less overhead to operate. The setup is simpler and can help reduce latency by removing links in the communicative chain. Such a setup is great for many organizations, but their centralized nature can increase failure risks and reduce infrastructure flexibility.
What makes a service mesh useful?
By forming a fabric through which services can talk back and forth, service meshes deliver the following capabilities:
Improved observability, by ensuring that all services are reachable and visible, while giving teams the flexibility to incorporate their own metrics scraping, tracing, or logging tools
Automated service discovery, by registering each individual service that leverages the mesh, managing those endpoints, and enabling service-to-service visibility no matter where those services and their data are hosted
Load balancing and routing, by recognizing when high traffic volumes are threatening to overwhelm individual services (circuit breaking) and splitting requests between available servers. This also includes traffic management, which encompasses the policy-level routing policies based on system-wide settings vs. algorithmic weights.
Stronger security, by enabling (or necessitating) the implementation of mTLS for encrypted communications, allowing for granular access control (RBAC), and simplifying security to one consolidated layer vs. per-service implementation. A service mesh can also include a centralized control plane to manage security policies that the proxies enforce.
High reliability, by supporting regular automated health checks, failover, configurable connection timeouts, retries, and rerouting when a service goes down. Service meshes also handle failure gracefully so that any interruptions have minimal impacts on users.
Testing and phased deployment, by supporting canary deployments and traffic mirroring
Despite these service mesh benefits, however, building a service mesh can be difficult. It takes ample knowledge and time to successively establish a secure and maintainable mesh layer within your environment.
While service meshes offer consolidation, they're ultimately an added layer of complexity and overhead within your existing infrastructure. Vendor-managed service meshes have grown increasingly popular due to these concerns, though with the tradeoff of reduced flexibility and often increased cost.
Does HAProxy offer service mesh compatibility?
Yes! HAProxy One includes HAProxy Enterprise — a flexible data plane layer providing high-performance load balancing, an API/Al gateway, Kubernetes application routing, best-in-class SSL/TLS processing, and multi-layered security.
Meanwhile, HAProxy Fusion is a scalable control plane that provides full-lifecycle management, monitoring, and automation of multi-cluster, multi-cloud, and multi-team HAProxy Enterprise deployments. It aggregates over 150 individual metrics to track request throughput, success rate, latency, and security. Automated service discovery boosts visibility across your infrastructure while accounting for tens of thousands of Kubernetes service objects.
With other features such as traffic splitting, dynamic tracing with TAP-like functionality, zero trust security, and mTLS, HAProxy One is ready to help your microservices communicate effectively. To learn more about service mesh support in HAProxy, check out our blog, Building a Service Mesh With HAProxy & Consul.