Service Mesh: The Super Hero of Cloud Native Realm

Be a Cloud Native! Live and Breath!

Source: Pexel

At the onset of the Service Mesh story, let us baby-step through the basics. And, then quickly cut to see, what Istio is and how it can help satisfy diverse needs in a distributed environment.

Breaking up the Classic Monoliths to make them a set of Microservices or further to Nanoservices makes our app’s architecture fly. On the second thought, it scares us with a host of challenges, too.

Let’s look through the both sides.

Bright side…

• Allows to have focussed development without worrying of designing/coding of Non Functional Requirements(NFR)— naturally adds to SPEED.
• Freedom to become Language Agnostic — this translates to lower Integration cost
• Reduced Engineering cost, as well the Maintenance cost
• Reduced Time to Market(TTM), HA, Scale and so on

Not-so-bright side…

• High network chatter
• Uncontrolled Traffic monitoring/routing
• Needs to implement & manage a custom Service registry/discovery. Same goes for other NFRs in polyglot environment
• Observability hiccups

Not everything is hunky-dory, huh? Do we have anything close to cure-alls solution to address these problems? Yes, we are getting there…

Service Mesh

A Service Mesh is defined as a dedicated Infrastructure Layer for managing Service to Service communication to make it more controlled, manageable and visible.

What does it mean by managing service to service communication and where it lies?

Take any service. It contains Business logic that is core function. And, Service logic/proxy that handles aspects like discovery, load-balancing, metrics, time-outs, retries, traffic routing and so on. Which of these two logics constitutes the FRONT LINE from the user point of view? It’s invariably, the Proxy. Right?

For a moment, if you package the Proxy code in to a shared library and place that as front liner of all services in the distributed system, it works. But, what if the services are implemented in multiple languages? What if you had to use an off-the-shelf service which you don’t own?

Either ways, tweaking the proxy logic and deploying per service would make the system ungovernable. This is exactly why, you would need to move all the proxy logic/configuration into a separate infrastructure layer — that’s called Service Mesh.

Put in simple terms, Service Mesh is Array of Network Proxies. These proxies are also famously called as Sidecars. The role of sidecar is to augment the Service (core function), often to add functionality to Service that might otherwise be difficult to improve.

In a typical Kubernetes cluster environment, ideal scenario would be that you have bunch of pods where each pod running one or more containers, where in, each container represents a service. Therefore, with the sidecar, you have duo of containers forming a Container Group. One for application and another for sidecar. Both containers get co-scheduled on same node with the shared use of Network, Storage and CPU resources.

The Sidecar is much like it is in reality, so to speak!

With the advent of Sidecars, takeaway is: Sidecars talks to Sidecars always. They transparently intercept inbound and outbound requests.

Service Mesh with Services and Sidecars

On the side note, this approach offers us a cultural benefit too. Applications developers focus on the task at hand, that is- core business logic, while Operators/SREs, precisely, focus on configuration of sidecar and pushing them to production in non-intrusive manner with a very few or no changes in Service code. No stepping on someone else’s toe!

Istio Mesh

While Service Mesh being the design pattern, Istio is an open source service mesh implementation to address the challenges posed after monoliths transitioned to a distributed micro service environment.

From a 30,000 foot view, Istio supports following features:

1. Traffic Management: With YAML configuration, enables control the traffic flow between services in distributed system. Allows to easily setup Timeouts or Retries policies and circuit breakers without introducing code changes in Service logic.
2. Security: Makes certificate management easy. Manages the A&A, encryption at proxy level. We can enforce policies across the spectrum with a quick YAML change.
3. Observability: Allows to hold a tight visibility on Services through tracing, monitoring and logging. There are YAML files to integrate the below utilities with Istio distribution in /samples/addons automatically. They are just a command away to start working for you.

kubectl apply -f ../samples/addons/grafana.yaml

• Prometheus for monitoring
• Grafana for visualising the traffic, faults, routes, delays etc
• Kiali for service mesh configuration and cluster visualisation

Folks, That’s all for now. The upcoming story will be a hands-on primer with setup, code, commands of Istio to see how it works with Kubernetes landscape. Stick around.

Happy learning and Stay safe!