Service Mesh — Are there any alternatives to it?
Every tool works best when applied in an appropriate context. Service mesh is no different.
I’ve written about “out-of-process” design and why service meshes are so desirable in my earlier articles (links at the end). However, it’s important to know the alternatives to make a decision that fits the context and meets the goals, and that's the purpose of this write-up.
The problem it solves & The features it brings
Service mesh does a fantastic job at hiding the complexities of synchronous service-to-service communication at scale and that’s why its adoption is on the rise.
It brings features like
- Security -Encryption and mutual authentication.
- Resilient communication — Retry policies which can overcome network faults.
- Observability — As all the traffic is flowing through the side-car proxies. All traffic is observable.
- Routing/Traffic shaping to enables A/B testing and canary releases.
Considerations
Learning new technology, the technical complexity of more moving parts, and additional memory & CPU utilisation per pod. And an infrastructure that can support service mesh.
Alternatives:
1) SDK Libraries
Unlike the “out-of-process” architecture followed by service mesh proxies, using libraries for infrastructure & cross-cutting concerns (like logging, resilience, configurations) is the traditional approach where an application consists of a single process which has business logic as well as cross-cutting & infrastructure concerns.
Being a single process has its shortcomings because it means that the runtime of the SDK must be compatible with the runtime of the application. And the issues of being a high coupling & low cohesion design.
But this “in-process” design also has its benefits —
- Straightforward implementation & debugging.
- Simple deployment & monitoring.
- Fewer connections/moving parts that can develop a fault.
- Extremely low latency. Depending upon where the other process is running (same machine or remote machine), there shall be some degree of latency.
For more on out-of-process architecture and side-car patterns in my earlier article (link below).
2) Using Asynchronous Communication (messaging) instead of synchronous service-to-service calls.
Service mesh supports synchronous service-to-service communication. Synchronous communication between backend services is considered a deterrent to exploiting the hyper-scaling cloud resources. Because it can form long network chains, depends on the availability of other services and promotes a low cohesion service integration design.
Asynchronous communication between services on the other hand promotes decoupled services (by breaking temporal coupling) which further leads to independent scalability, availability and performance. Asynchronous communication is done over a message broker or event stream which delivers small frequent information packets to consumer services(But it's also possible to model asynchronous communication over HTTP & I’ll leave a link to an article).
Synchronous calls have a place in system integration but it needs to be a conscious decision after having evaluated an event
Summary
A service mesh can solve a lot of challenges. And if there is already an infrastructure built within the organisation for it, it could be an irresistible offer. However, asynchronous messaging for system integration should still be a consideration.
Also, it's important to consider the scale, if we are talking about thousands of pods or tens of pods.
Related Articles
- Out-of-process design & Side Car Proxies — Why do we need multi-container pods?
2. Service Mesh -What is Service Mesh? And why do we need it over Kubernetes?
3. Asynchrounous communication on REST APIs — Asynchronous Communication- Client-Server over REST APIs & WebSockets
