This year, the Service Meshes are of all conferences: istio, linkerd, kubeflix, even zuul?.... Many tools are surfing on this wave. What exactly is this about?

By comparing our different visions we have the feeling at each new tool of a déjà-vu or a superposition with the precedent ones. As if we were once told: in a world of microservices we need security, traceability, and intelligent routing. We have an HTTP reverse-proxy solution to meet these challenges - with the photo (one-wheeled wheelbarrow) at the top as an illustration. Then a few days later: in a container world where orchestration is more and more dynamic we need intelligent routing, traceability and security inside the orchestrator. And for that we have the solution that fits into our container orchestrator - by showing us the photo at the bottom (two-wheeled wheelbarrow).

Let us try to see more clearly through this series of articles. The first will attempt to position the issues that lead to considering the Service Mesh in the ecosystem of microservices. The second will provide an X-ray of the functionalities offered by the tools claiming to be a Service Mesh and the related functionalities of the microservices and containers ecosystem. Then, we will discuss different solutions that implement these features, for example an application implementation in Java.

Microservices, containers and platforms

Today, the challenge is to design modular and scalable architectures to meet the stakes of the digital world. The principle of single responsibility has now become widely established as the state of the art to meet these challenges. It consists in breaking down an application into a set of components and services, each of which meets a specific need.

Microservices are the most common implementation of this principle.  If we use Sam Newman's definition in "Building Microservices", "microservices are small autonomous services that work together". As a target, the developer focuses only on the implementation of a basic business functionality, with maximum freedom (choice of technology, weak coupling to other services, etc.) and possible responsibility (continuous deployment, you build it you run it).

Inseparably, DevOps principles have imposed themselves to provide developers with a foundation - a platform, we will come back to it - that offers freedom and responsibility right through to production. The implementation of this principle is based in particular on the infrastructure as code and on cloud solutions characterised by instantiation and payment on demand of various IT resources. Containers and container orchestrators are one of the most prominent solutions today to implement these principles. They package the applications - and therefore the services - in the form of stackable and immutable images, which makes them portable and relatively independent of the platform.

As a developer, I will focus on writing business features. These will be exposed as an API, then packaged in containers and deployed in the cloud. But is that enough to make an application? No, because many other features are required to transform a set of software components into an application. How can they be coordinated to interact with each other? How to ensure security? How to make the API usable by front-end applications (JavaScript screens running in the browser)? How to monitor they are properly running?

For a long time now, these transversal problems have been the domain of platforms. In English, a platform means a dock, something flat, homogeneous, in order to allow standardisation, to promote industrial activity. A port platform will thus be built around container standards and the Bill of Lading. Thus all the complexity of the transport is transparent for the sender and the recipient.

Figuratively speaking, in the world of microservices and containers, the platform serves as a foundation to promote reuse and to free the developer from the implementation of non-differentiating transversal functionalities for the implemented business.

What platforms are we talking about?

In the world of the cloud, the term Platform As A Service appeared very early. These platforms - from which docker technology is indirectly derived - aim to transparently manage the infrastructure and deployment of an application.  In the application world, application servers have in the past been the platform offering software frameworks, security and exposure of these components. More recently, API management tools have provided reusable solutions for managing the API lifecycle and self-service security.

Today, the increasingly evolving nature of microservice architectures makes the centralised vision of these different approaches obsolete. New platforms are therefore emerging to propose a foundation that embraces the decentralised principle of microservices. Where PaaS focuses on deployment, API Management on API, Service Mesh focuses on communication between microservices.

Our definition will therefore be as follows:

Different implementations exist as Thoughworks indicates in their radar. But the implementation of the best known solutions tend to hide other possible solutions.

So is it simply an improvement of an existing tool like this two-wheeled wheelbarrow? Or is it a truly differentiating approach such as switching from axe to chainsaw that requires using the new tool in a completely different way? The next articles will try to give you the keys to compare Service Meshes to your context and your needs.

Sources of illustrations: https://pixabay.com/