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.

Modern applications’ needs

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.

And so, the service mesh.

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 are secure

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.

But Service meshes are complex

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.

Service mesh is costly

Implementing a service mesh is both time and resource consuming. It requires specialized skills in IT and DevOps. You got it, networking is complex.

So what’s KubeSlice? Is it a Service Mesh?

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.

• It is a secure network.
• It is an “east-west” network. Traffic flowing through KubeSlice network does not need to go through firewalls and gateways, in and out of a network domain, into the internet and then into another network domain. KubeSlice ensures one constant virtual network for the microservices wherever they are - multi-cloud, across regions, edge or datacenter (or even VMs!). The flow is always east-west- not north-south, as they say in networking parlance.
• It’s an ALL INCLUSIVE network. And there’s an important differentiation with service meshes. Service Meshes cater to HTTP web centric traffic only. KubeSlice is ALL INCLUSIVE. Its virtual network supports video, database, UDP, HTTP, any and all communication protocols.

Let’s see how they both compare in service to service communication

Concluding

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.

• mTLS based microservice communication within a cluster
• KubeSlice network for inter-cluster and inter-cloud microservice communication
• Support for HTTP plus all other traffic type communications between clusters
• A single pane of glass observability for all multi-cluster communication
• Load balancing for optimal performance

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?