A Beginner's Guide to Service Mesh and Its Implementations

Sep 30, 2022ยท

3 min read

Play this article

Why do we need a Service Mesh?

Imagine that your app contains hundreds of microservices and all of them need to communicate with each other. Your application is broken down into multiple microservices like "frontend", "backend" and "payments" which need to communicate with each other to function correctly. We need to rewrite the communication logic baked into the microservices whenever there is an update. This can become tedious over time if we decide to add more microservices ๐Ÿ˜”.

Enter Service Mesh !! ๐Ÿš€

Service Mesh is a paradigm/concept where we separate the communication between the microservices into a separate Sidecar policy. This implementation separates the communication logic in the microservices into its own (service mesh) deployment. Now let's look at one of its implementations.

The Istio Service Mesh

Istio is one of many implementations of a service mesh. Istio comes with its own control plane and injects envoy proxies to communicate between the internal network of the microservices.

How Istio works

You can install Istio and deploy a sample application here.

istioctl install --set profile=demo -y

When you run the above command, a namespace named istio-system will be created in your cluster.


For Istio to inject the Envoy proxies into your Pods, you should set the label of your application's namespace to istio-injection=enabled. Labels are key/value pairs that are attached to objects, such as pods. You can learn more about labels here. You can change the label of a namespace using this command.

// kubectl label namespace <namespace> <label>
kubectl label namespace default istio-injection=enabled

Without istio-service mesh, notice that there is one container running inside that pod 1/1 image.png

Now that you've used the above command to change the label, istio-system will look for that label which is istio-injection=enabled and inject the envoy proxy into each of the application's pods. As you can see there are two containers 2/2 running, one of which is an envoy proxy and the other one is the application's container.


What's the use of this?

Well to put it simply, you won't have to worry about the communication logic that had to be changed/ rewritten, Whenever you deploy a new service into your application, the Istio-system will automatically inject the envoy proxy into your pod. And everything works like magic ๐Ÿช„. Also, you can add "add-ons" to the istio service mesh. One of which is Kiali. Kali helps to visualize and troubleshoot your service mesh.

All of this is too much work. But Is there an easier way to deploy a service mesh?

Introducing Meshery

Meshery is a Cloud-Native Management tool that lets you install popular service meshes with a click of a button. There are multiple ways to get started with Meshery. One of the easiest ways is to use the Docker extension. You don't have to install any of the service mesh into your pc. All of that capability is provided by Meshery.

Did you find this article valuable?

Support Collabnix by becoming a sponsor. Any amount is appreciated!