Skip links

What is the Service Mesh?

Recently you may have heard the term ‘service mesh’ crop up more frequently around containers and Kubernetes – this isn’t because it’s a brand-new technology, but rather because Google & IBM backed the release of Istio version 1.0 in July 2018.

I’m Garreth Davies, a cloud consultant at Mobilise Cloud, and I have a keen interest in all things containerised. In this short blog, I’d like to talk to you about the next big thing in the container world; the service mesh.

A bit of history…

Not too long ago, the traditional approach to designing and building applications was to build big and deploy tightly coupled services to large pieces of infrastructure. Developers would have to write extensive sets of code to handle the communication across networks to allow applications to talk to each other. This didn’t make a lot of sense since an application shouldn’t have to worry about retries and routing mechanisms, developers shouldn’t have to write lines of code that would be duplicated over and over again. So, this network layer was abstracted out into a common set of libraries and principles that we use today (APIs, protocols etc.).

The present…

Move forward to the containerised era where an application may consist of hundreds of services; each service having a large number of instances – where instances may be in a constantly-changing state as they’re scheduled by the likes of Kubernetes. Implementing networking between these services is incredibly complex and we are now starting to see the same patterns of code creep back into application code; retries of requests, load balancing, flow control and all those classic problems.

The Future…

 

So, what ‘The Service Mesh’ promises to do is to abstract these problems away from developers writing code for distributed systems utilising microservices. Moving this logic away from applications and implementing a controlled stack allows for a uniform set of protocols that can be utilised across all of your applications. This enables developers to focus on the critical parts of the application rather than getting bogged down on communication challenges.

Is there more than one service mesh?

There are four main open-source service mesh products available, listed in order of release date, these are:

  • Linkered (pronounced ‘linker-dee’) – written in scala and un on the JVM was released in February 2016.
  • Envoy – High performance C++ application proxy.
  • Istio – Written in GO and backed by IBM & Google, first released in May 2017 and later version 1.0 (production ready) released in July 2018.
  • Conduit – Written in Go and released in December 2017.

Who is driving the service mesh movement?

It’s still a relatively new principle of working with microservices, but the service mesh offers so many benefits that it’s hard to ignore. Recently Google Cloud CTO Urs Hölzle stated:

“My expectation would be, 90% of Kubernetes users use Istio two years from now. It’s such a natural fit to what Kubernetes provides, it almost feels like the next iteration of Kubernetes. It’s done by the same team, the two work well together.”

Google & IBM believe there will be a sharp increase in the use of Istio as more companies look to move their services to the cloud. Rather than perform lift and shifts of applications to public cloud platforms the belief is that companies will transform their applications as part of the migration journey. It requires relatively small amounts of reprogramming in order to implement Istio into existing microservice architectures – opening up a wealth of benefits.

Istio benefits

  • Automatic zone-aware load balancing and failover
  • Secure service to service authentication with strong identity assertions
  • Fine grained control of traffic behaviour; routing rules, fault tolerance and fault injection.
  • Pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
  • Migrating from VMs to Kubernetes is challenging but Istio can significantly de-risk and accelerate this work by easing the implementation of capabilities such as mutual TLS.
  • Minimal overhead added to your system while providing increased developer efficiency and speed.

It’s still early days for the service mesh, but with the likes of Google and IBM weighing into the picture – it must only be a matter of time before more companies start picking services like Istio as part of their Kubernetes offering.

Leave a comment

Name*

Website

Comment