You may have heard the term service mesh but what is it exactly? With this post I try to get an understanding of what a service mesh is and when it is used.

Monolithic vs. microservices

Before we start going to explain what a service-mesh is, let’s get to some basics of software architecture.

Traditionally applications were built using a monolithic architecture, were the application is a single-tiered, self-contained piece of software, independent from other applications. Single-tiered means, there is a single application layer that supports the user interface, the business rules, and the manipulation of the data all in one. This architecture is very common for applications you install on your computer, such as Libre Office, Gimp or Microsoft Word. But, such applications are hard to maintain and are also hard to scale, means it can not easily “grow” to handle increasing workload. This is not an issue for desktop apps, but scalability is essential for e.g. web applications where you may have hundreds or thousands of daily users accessing your application.

To overcome the challenge of maintainability, the multi-tier architecture a client-server architecture has been widely adopted, were the application is broken down in different layers, where each layer fulfills a dedicate function. For example, in a 3-tier architecture there are 3 layers, presentation - providing the user interface -, the application processing - responsible for the business logic - and data management - the intermediary between the application and the data storage. These layer communicate trough an interface. This facilitates the maintenance as you can work on one layer without touching the others - assuming the interfaces stay the same.

service-oriented architecture (SOA) goes even further. This architectural pattern is about service orientation i.e. thinking in terms of services, whereas an application is broken down in self-contained pieces of software (services), with a clear interface, represents a particular unit of (business)functionality. These services are loosely coupled, where each component has little or no knowledge other components, and communicate over a network trough a communication protocol/API. These services are also often called microservices.

Challenges

Microservices have some advantages as they can be independently developed and even be replaced with a different implementations. This allows faster grow of your application. Your system is also much more scalable. But, with the distribution of these loosly coupled services in a network, there also come certain challenges.

Traffic Management (routing and discovery)

Services are distributed over different locations and thus have have different IPs. For a service to communicate with another, it must know how to reach it i.e. knows it’s IP address, so that network traffic ((HTTP, REST, gRPC, Redis, etc.) goes to the right service instance.

Security

Connection between pairs are usually encrypted using Transport Layer Security (TLS) which relies on proper public and private keys to be in place, so key management i.e. generation, exchange, storage and replacement of keys, is essential.

In addition, how to protect the services? Traditionally you may have your monolithic application running on a single server, which a dedicate IP. Incoming and outgoing traffic to the server and the network segment may be protected with a firewall. But how you do that when there are hundreds and thousands of services? Your firewall rules will grow exponentially and it will be a challenge to manage it.

Traceability

Distributed microservices communicate over the network, were the latency may become an issue. But how to you see where this high latency is caused, slowing down your application? How to you know where the traffic flows goes and what your load is?

What is a service mesh?

The term itself refers to both, the software , as well as the the security/network domain that is created when you use that software. Popular software are:

• Istio
• Kong
• Consul
• Linkerd
• HAProxy
• Envoy
• Traefik

Technically, a service-mesh is a dedicated infrastructure layer1,2 which adds additional capabilities to your application and facilitates the communication between your (micro)services, in order to solve the challenges mentioned above. These capabilities are traffic management (routing and service discovery), security and observability.

What are the benefits of a service mesh?

Service-mesh are here to solve the challenges we have seen above, which means a service-mesh offers the following benefits:

• Observability: Automatically gather metrics such as request rate, latency, and bandwidth usage as well as logging and tracing of the traffic. This information helps you to understand the health of your network and debug problems like performance issues.
• Routing: Control incoming and outgoing traffic, shift traffic (route to different versions of a service), do smart load balancing or mirror traffic (same traffic goes to two different destinations).
• service discovery: Automatic detection of devices and services offered by these devices on a computer network using a service discovery protocol (SDP).
• authentication and authorization: Not only will it take care of service-to-service and end-user authentication, to verify the client or user making the connection, but also takes care of workload-to-workload and end-user-to-workload authorization, ensuring traffic only can reach destinations it is allowed to (similar to a firewall).
• key and certificate management: Issuing valid certificates and keys for the services
• Automatic scaling: Scale up services up and down to cope with the respective network traffic

How does it work?

A service mesh consists of two major elements, the Control Plane and the Data Plane.

The Data Plane is the software. which processes the data requests and take care of routing, load balancing, collecting metrics , authentication and authorization. This is usually implemented by providing proxy instances as a sidecar container to the service

The Control Plane, is the software that configures the data plane. The control plane has knowledge of the isolated stateless sidecar proxies and connects them into a distributed system. It is responsible to provide policies and configuration for all of the running data planes in the mesh, so the proxies know what to do. The Control Plane itself does not touch any package.

Further Readings

So this is my little introduction into service-mesh, but there are definitively other posts which might be interesting:

• Book “Mastering Service Mesh”
• nginx: service mesh
• redhat: service mesh
• istio: service mesh
• hashicorp: service mesh