What Is a Service Mesh? - NGINX

Original: https://www.nginx.com/blog/what-is-a-service-mesh/

A service mesh is a configurable infrastructure layer for a microservices application. It makes communication between service instances flexible, reliable, and fast. The mesh provides service discovery, load balancing, encryption, authentication and authorization, support for the circuit breaker pattern, and other capabilities.

The service mesh is usually implemented by providing a proxy instance, called a sidecar, for each service instance. Sidecars handle inter‑service communications, monitoring, security‑related concerns – anything that can be abstracted away from the individual services. This way, developers can handle development, support, and maintenance for the application code in the services; operations can maintain the service mesh and run the app.

Istio, backed by Google, IBM, and Lyft, is currently the best‑known service mesh architecture. Kubernetes, which was originally designed by Google, is currently the only container orchestration framework supported by Istio.

Service mesh comes with its own terminology for component services and functions:

The part of the service mesh where the work is getting done – service instances, sidecar proxies, and the interaction between them – is called the data plane of a service mesh application. (Though it’s not included in the name, the data plane handles processing too.) But a service mesh application also includes a monitoring and management layer, called the control plane.

The control plane handles tasks such as creating new instances, terminating unhealthy or unneeded instances, monitoring, integrating monitoring and management, implementing application‑wide policies, and gracefully shutting down the app as a whole. The control plane typically includes, or is designed to connect to, an application programming interface, a command‑line interface, and a graphical user interface for managing the app.

An Istio control plane, with Pilot, Mixer, and Auth, and data plane, with microservice instances and a sidecar proxy per instance
nginMesh, an Istio service mesh with control plane, data plane, and NGINX as the sidecar proxy

NGINX has an Istio‑compatible service mesh called nginMesh. This diagram of the nginMesh architecture shows NGINX in the sidecar proxy role, along with typical Istio components.

A common use case for service mesh architecture is when you are using containers and microservices to solve very demanding application development problems. Pioneers in microservices include companies like Lyft, Netflix, and Twitter, which each provide robust services to millions of users worldwide, hour in and hour out. (See our in‑depth description of some of the architectural challenges facing Netflix.) For less demanding application needs, simpler architectures are likely to suffice.

Service mesh architectures are not ever likely to be the answer to all application development and delivery problems. Architects and developers have a great many tools, only one of which is a hammer, and must address a great many types of problems, only one of which is a nail. The NGINX Microservices Reference Architecture, for instance, includes several different models that give a continuum of approaches to using microservices to solve problems.

The elements that come together in a service mesh architecture – such as NGINX, containers, Kubernetes, and microservices as an architectural approach – can be, and are, used productively in non‑service mesh implementations. For example, Istio, which was developed as a service mesh architecture, is designed to be modular, so developers can pick and choose what they need from it. With this in mind, it’s worth developing a solid understanding of service mesh concepts, even if you’re not sure if and when you’ll fully implement a service mesh application.

This blog post will be the first in a series. Currently, our planned posts include:

  1. What Is a Service Mesh? This post.
  2. Advantages and Disadvantages of a Service Mesh Architecture. Describes when service mesh is the right answer, and when alternatives might be better.
  3. Service Mesh vs. API Gateway. Shows when an API gateway might solve most of your problems, when to go straight to service mesh, and when to use a blended approach.
  4. Kubernetes and Service Mesh Architectures. Describes how to use Kubernetes with a variety of architectures, including service mesh.
  5. Using NGINX in a Service Mesh Architecture. NGINX can serve several of the key roles in a service mesh architecture – sidecar proxy, Ingress controller, or both – while providing features such as load balancing, service discovery, caching, and more.
Retrieved by Nick Shadrin from nginx.com website.