Service meshes are an essential building block for modern enterprise applications - here's why

Cloud native applications are loosely coupled collection of services – and someone needs to keep communication channels open. Enter the service mesh

A service mesh is increasingly viewed as an essential building block for organisations keen to monitor, manage and control their service-to-service communications. A critical component of the cloud native stack, this networking model (also described as an infrastructure layer) enhances online responsiveness, performance and reliability. It enables, among others capabilities, communication among complex services that support modern, cloud native applications.

In such applications, there may be hundreds of services with thousands of variations that constantly change when orchestrated on a platform like Kubernetes. A service mesh uses dynamic routing tools to connect to the correct service and find the source of information that historically has provided the fastest response. If that source is unresponsive, the service mesh finds another source; if an error is returned, it removes the source from the balancing pool. If the request deadline is missed, it registers a ‘failed request' rather than loading the system with more retries, preventing it from crashing.

By automating communications between the different parts of the application, a service mesh improves uptime, performance and resilience of the application as a whole.

Evolution of service meshes

So how did this tool, which uses web applications to manage service-to-service communications, evolve?

In 1992, one of the first software architecture models (still widely used today), was the Model View Controller (MVC) pattern. Changes in distribution patterns resulted in Service Oriented Architecture (SOA) in 2000 and event-driven architecture in 2003. Ten years later, when software development required more robust and scalable solutions, microservices arrived, followed by serverless platforms in 2015.

There was, however, still a tendency to develop process-driven applications that mirrored organisations' existing silo-based communication structures. Granted, the software was broken up into smaller pieces (the individual microservices), but there was also more of it distributed across more systems. These smaller pieces of software and the communications between them are more complex to handle, which is where service meshes come in.

A service mesh works by supporting the inter-process communication (IPC) - the mechanism an operating system uses to manage and share data.

It addresses all the network issues developers normally have to consider when implementing a microservice, for example, load balancing, circuit breakers, retries, time-outs and smart routing, and enables advanced deployment techniques, such as canary releases and dark launches. In doing so, a service mesh negates the need for infrastructure application coding, giving developers more time to focus on the business logic.

Telemetry is another feature of service meshes; activity is observed and recorded via metrics and loaded onto a central database. Some service mesh solutions integrate with software monitoring tools, and they can also replace the communication libraries typically used to handle load balancing, latency, fault tolerance and failover network issues.

North, South, East, West

While service meshes are perfect for handling the often complex and varied service-to-service communication (also known as east-west traffic), requests originating from external networks, by consumers of exposed APIs (north-south traffic), should be managed by an API gateway. The latter provides the necessary security, access control and governance capabilities to protect the internal infrastructure.

There is no silver bullet to address all organisations' technology issues, but software architects and developers now have access to new tools to support the software development life cycle.

And as more businesses migrate to a microservices architecture, organising their software around their capabilities rather than process-driven silos, service meshes will be increasingly needed to help applications evolve in line with business growth.

Gibson Pasquini Nascimento is head of solutions, EMEA, at Sensedia