VP Marketing & Product (UX)
29 December, 2022
5 min read
It’s time to address the elephant in the room.
Do we need a service mesh? Is there a cheaper, easier alternative? What’s the ideal solution that’s best for my applications? These questions come up all the time and today I’d like to go over them with you.
In this digital transformation world, application microservices are constantly communicating with each other. Requests(traffic) coming into these microservices need to be load balanced and there’s a need for visibility into these microservices. When microservices are distributed(as they often are for best app performance or for resiliency) getting microservices to communicate across geographic distances becomes challenging. The networking is complex.
A service mesh is a network architecture that abstracts all of the following from the application logic- enable mTLS, service discovery, load balancing and monitoring. Thus service meshes provide an efficient way for service to service communications, making your applications more scalable and resilient.
Service meshes enable service to service communications by enabling mTLS for secure zero trust communication. With mTLS every microservice in governance of service mesh will have guaranteed a) Authenticity (both server and client) b) Confidentiality c) Integrity. Although mTLS solves securing application service to application service in service mesh, it does not solve unauthorized access to a node in Kubernetes cluster.
A service mesh puts a sidecar or proxy alongside every microservice in the system, hence implementing one gets more complex with an increasing number of microservices. Also getting services to communicate across networks, across regions, via firewalls and gateways -i.e service mesh to service mesh networking is a whole different ball game - because again, networking is complex.
Implementing a service mesh is both time and resource consuming. It requires specialized skills in IT and DevOps. You got it, networking is complex.
KubeSlice is a Kubernetes based multi-cluster, multi-cloud application networking platform with support for multi-tenancy. KubeSlice creates a network of namespaces across clusters which may be in a single or in distributed locations. KubeSlice - is like a service mesh in some sense, because it offers the service discovery and communication, but it has a host of other application centric capabilities, which goes beyond communication and networking - we will get to that at another time. The microservices in a Slice workspace discover and communicate with each other across the KubeSlice overlay network created across clusters.
Let’s see how they both compare in service to service communication
|Service to service communication in Single Cluster||Optional||yes|
|Service to service communication across Multi-Cluster||Yes||Yes but complex to set up|
|Service to service communication across Multi- Cloud||Yes (Base)||Complex|
|Performance||Lightweight, hence fast||Resource intensive|
|Secure Communication||Via OpenVPN||Via mTLS|
|Time to setup||Minutes||Days|
|Skills required to setup||No IT/networking knowledge needed||Specialized Skills Needed|
|Supports All Traffic||Yes||No (only HTTP)|
|Monitoring||Single pane for all clusters||Multiple panes - one for each cluster|
|Load Balancing||Can be added with Avesha SmartGLB||Yes|
The case for BOTH: Service meshes do an excellent job of making it easy for services to communicate within a cluster. For multi-cluster tho’, the setup and maintenance of a service mesh can be challenging. The best networking architecture is where a service mesh rides over the KubeSlice connectivity. You get the best of both worlds.
The case for KubeSlice alone: If you’re looking for a network where services communicate with each other within your own private ecosystem, yet geographically distributed, KubeSlice is your platform of choice. That is, if they are one company’s applications talking to each other across network domains because they are geographically spread out- there’s no need for a service mesh or firewalls and gateways to facilitate that. KubeSlice will serve as a cheaper, faster and secure connectivity fabric for your microservice communications.
The case for Service mesh alone: For inside-a-cluster communication, service mesh abstracts away a lot of the networking logic, so that makes it simpler. For multi-cluster, If you have services communicating across providers, different apps from different companies taking to each other across network domains and if that communication is only HTTP based - service mesh may be the network of choice - it’ll still be complex to set up - but will serve the needs of a disparate app communication across the internet.
IMO, the case for BOTH is the winner. Your pick?