
By breaking our applications into loosely-coupled microservices that can be developed and released independently of each other, we isolate our failure domains and provide ways for the application to remain functional even if individual components are failing. The adoption of microservices especially allows us to meet those demands – not only at the technological level, but also at the organizational level.
#WHAT IS KUBERNETES SERVICE MASH SOFTWARE#
This is a far cry from the expectations we placed on software a decade ago, when “sorry, we’re down for maintenance” was acceptable! In the modern world, we expect our software applications to be resilient to failures in hardware, software, and network, as well as handle massive scale and maintain a breakneck pace of feature development.

The cloud native approach, in turn, is rapidly gaining popularity because it is uniquely suited to the increasingly strict demands that we place on our software systems. The rise of service meshes, such as Linkerd, is tied to a big shift in the industry: the adoption of cloud native architectures, in which an application is built as microservices, deployed as containers, and run on a container orchestration system, such as Azure Kubernetes Service (AKS). Why are service meshes becoming so popular? This decoupling of responsibility, and ability to provide reliability, visibility, and security globally across the application, are the fundamental value proposition of the service mesh. This shift means the platform itself can provide these features without developer involvement.
#WHAT IS KUBERNETES SERVICE MASH CODE#
The service mesh provides something vital to operators: the ability to shift responsibility for much of the reliability, visibility, and security requirements out of the application code itself, down onto the underlying infrastructure. The reason is more than the individual features. Why introduce this new layer of complexity and latency?

Why use a service mesh?įor an industry that’s focused on speed and performance, the idea of adding user-space proxies in between every inter-service call can seem counterintuitive. And they can accomplish all these things without any involvement from the application itself. They can encrypt communication transparently with TLS. They can handle request retries and timeouts. Because they’re centrally controlled, the service mesh can institute a variety of traffic control techniques globally across the application that provide reliability, observability, security, and more.įor example, the proxies can instrument all calls to a service, and provide “golden metrics,” such as success rates, latency distributions, and request volumes to that service, or even to individual paths. The data plane proxies act as highly instrumented, out-of-process network stacks, and handle all traffic to and from a microservice. Critically, the data plane proxies handle both incoming and outgoing traffic for each microservice, typically without the application code even being aware. Following common network terminology, these proxies are often referred to as the data plane, and are typically coordinated by a centralized component called the control plane. What is a service mesh?Īt its heart, a service mesh is a distributed set of proxies that are deployed alongside microservices. Finally, we’ll provide a vision of where the service mesh is heading. In this article, we’ll define the service mesh and explain the various factors that are enabling the rise of service mesh adoption. (See this video by Azure’s Lachlan Evenson on installing and run Linkerd 2.0 on Azure Kubernetes Service.) Meanwhile, a host of other projects have followed hot on its heels, from cloud providers and startups alike. The first service mesh project, Linkerd, joined the Cloud Native Computing Foundation just last year, and has since grown to power the production infrastructure of companies around the globe, ranging from startups, like Monzo and OfferUp, to well-established companies, such as Comcast and Salesforce.

Over the past few years, the service mesh has risen to become a critical element of the cloud native stack. Led by open source projects such as Linkerd, the service mesh model is increasingly popular because it addresses challenges, both computational and organizational, that occur with the adoption of microservices. The service mesh may sound complex, but at its heart, it’s a very simple idea: a set of network proxies that transparently run alongside microservices, implementing reliability, observability, and security features by measuring and manipulating inter-service (“east-west”) traffic.
