When I started working with VMware ESX in the early 2000, I knew it was a very cool tech; and not only me, everyone knew there’s something special about it.

However, I haven’t fully grasped the full value of this technology right of the gate, at that point, I only saw “server consolidation” in front of me.

When vMotion came out, and we realized that physics has changed for our servers, we were no longer tied to the hardware the Server was running on. That hardware abstraction allowed us to do things we couldn’t do before. like fixing hardware issues or patch it with no downtime, scale much better and faster by deploying VMs when we need them and monitor the health of the infrastructure much better, even self heal. A new exciting world of agility we never saw before was opened.

 

Due to the above combined with automation, the effort of managing servers has been lowered, and fewer people are needed to manage fleets of servers.

What does that has to do with Service mesh you ask?

Recently I started focusing on Service mesh, mainly Istio, testing it in the lab, learning the technology and feeling that magic again. While the technology is cool, I was trying to understand the business value that is more than buzz words like distributed, load balancing, observability etc. However, at some point, I realized that I was looking at it all wrong. I was looking for the value from a networking operations point of view, it’s only when I looked at it from a developer value when it clicked.

Service mesh is a form of virtualization

When I get excited, I let the world know, that’s why I love twitter

The service mesh abstracts non differentiating code, virtualizes it in a way. Once it's virtualized you can patch it better, scale easier and have more visibility into what's going on. pic.twitter.com/r30D43ndCe

— Niran Even-chen 🤘 (@NiranEC) December 22, 2018

I see much equivalency in Service mesh to virtualization.

In the monolithic app world, many of the different pieces of code that compile the application or service are running on a small set of servers, so making decisions about how that component interacts with other parts of the application are written in the code.

That means that for every piece of meaningful code that differentiates the business the application is servicing, need to have much non-differentiate code along with it.

Things like server and client side communication, service lookups, error detection and response, telemetry, security are taken care of in the code or middleware software.

With the rise of micro-services (and the use of containers for that purpose) each container now runs a piece of differentiating code and is a single purpose server that communicates with other services on the network. The distributed architecture and the proliferation micro-services, bring new challenges to manage, monitor and troubleshoot problems.

We replaced our monolith with micro services so that every outage could be more like a murder mystery.

— Honest Status Page (@honest_update) October 7, 2015

 

What service mesh and Istio does is outsourcing the non-differentiating work to the sidecars with Envoy where each k8s pod now has a proxy that is responsible for communicating with other proxies and out of the mesh. (Envoy can work with more than k8s pods, it can even work with VMs or Pivotal PAS AIs!)

Now we’ve abstracted the non-differentiating code. Similarly to the value we gained by virtualizing the hardware with the hypervisors and adding a control plane, we gain for the operations of the proxy by adding a control plane in the form of Istio (I will not go into the deeper architecture in this post, there are literally hundreds of posts about it out there)

Here is a diagram to illustrate the abstraction layers in one picture

We can apply our desired state as policies to anything that is not the core function of our software, change policies on the fly without changing our code which saves much effort spent by developers, dynamically changing the policies without changing any code, apply security and authentication to transactions and have better visibility into the application health. Self-healing becomes a real thing now.

But just like virtualization brought its own set of challenges, Service mesh is no different,  which I will cover in my next post.

You can read more about the details of Istio features in this blog post: https://blogs.vmware.com/opensource/2018/10/16/service-mesh-architectures-inevitable

I think this analogy explains the subject, and the proliferation of abstraction layers brings a new set of challenges from a management point of view.

Have any thoughts on this? tweet your reply

@niranec

Niran