Hello again!.. As we approach the start of the course we have prepared another useful translation.
Service Mesh is a configurable infrastructure layer with low latency, necessary for handling a large volume of network inter-process communications between application programming interfaces (APIs). Service Mesh ensures fast, reliable, and secure communication between containerized and often ephemeral services in application infrastructure. Service Mesh provides capabilities such as service discovery, load balancing, encryption, transparency, tracing, authentication, and authorization, as well as supporting the circuit breaker pattern (circuit breaker).
Service Mesh is usually implemented by providing each service instance with a proxy instance, called Sidecar. Sidecar handles communication between services, performs monitoring, and addresses security issues, meaning everything that can be abstracted from individual services. Thus, developers can write, maintain, and service application code in services, while system administrators can manage the Service Mesh and run the application.
Istio from Google, IBM, and Lyft is currently the most well-known Service Mesh architecture. Kubernetes, originally developed at Google, is now the only container orchestration framework that is supported by Istio. Vendors are trying to create commercially supported versions of Istio. It's interesting to see what new contributions they can bring to the open-source project.
However, Istio is not the only option, as other implementations of Service Mesh are also being developed. The pattern sidecar proxy is the most popular implementation, as can be judged by projects like Buoyant, HashiCorp, Solo.io, and others. There are also alternative architectures: Netflix's tech stack is one approach where the functionality of Service Mesh is realized through libraries like Ribbon, Hysterix, Eureka, Archaius, as well as platforms like Azure Service Fabric.
Service Mesh also has its own terminology for service components and functions:
- Container orchestration framework. As more and more containers are added to the application infrastructure, there arises a need for a separate tool for monitoring and managing containers — a container orchestration framework. Kubernetes has firmly established itself in this niche, to the extent that even its main competitors, Docker Swarm and Mesosphere DC/OS, offer integration with Kubernetes as an alternative.
- Services and instances (Kubernetes pods). An instance is a single running copy of a microservice. Sometimes one instance is one container. In Kubernetes, an instance consists of a small group of independent containers known as a pod. Clients rarely interact directly with an instance or pod; they more often interact with a service that represents a set of identical, scalable, and fault-tolerant instances or pods (replicas).
- Sidecar Proxy. The Sidecar Proxy works with a single instance or pod. The purpose of the Sidecar Proxy is to route or proxy traffic coming from the container it operates with, as well as the return traffic. A Sidecar interacts with other Sidecar Proxies and is managed by the orchestration framework. Many Service Mesh implementations use the Sidecar Proxy to intercept and manage all incoming and outgoing traffic of the instance or pod.
- Service Discovery. When an instance needs to interact with another service, it must find (discover) a healthy and available instance of the other service. Typically, an instance performs a lookup via DNS. The container orchestration framework keeps a list of instances that are ready to receive requests and provides an interface for DNS queries.
- Load balancing. Most container orchestration frameworks provide load balancing at Layer 4 (transport layer). A Service Mesh implements more sophisticated load balancing at Layer 7 (application layer), rich in algorithms and more effective in traffic management. Load balancing parameters can be altered using APIs, allowing for orchestration of blue-green or canary deployments.
- EncryptionService Mesh can encrypt and decrypt requests and responses, lifting this burden from services. Service Mesh can also enhance performance by prioritizing or reusing existing persistent connections, which reduces the need for costly computations to establish new connections. The most common implementation of traffic encryption is mutual TLS (mTLS), where a public key infrastructure (PKI) generates and distributes certificates and keys for use in the Sidecar Proxy.
- Authentication and Authorization. Service Mesh can authorize and authenticate requests made externally or internally to the application, directing instances only validated requests.
- Support for the Circuit Breaker pattern. Service Mesh supports , which isolates unhealthy instances and then gradually brings them back into the pool of healthy instances as needed.
The part of the Service Mesh application that manages network traffic between instances is called Data Plane. The creation and deployment of configuration that controls the behavior Data Plane, is done using a separate Control Plane. Control Plane which usually includes or is designed to connect to an API, CLI, or GUI for application management.
The Control Plane in Service Mesh distributes configuration between Sidecar Proxy and Data Plane.
Often, the Service Mesh architecture is applied to tackle complex operational issues using containers and microservices. Pioneers in this field include companies like Lyft, Netflix, and Twitter, which provide reliably functioning services to millions of users worldwide. ( Here you can find a detailed description of some architectural challenges faced by NetflixThe Service Mesh architecture is unlikely to ever be a catch-all solution to all application operation and delivery questions. Architects and developers have a vast arsenal of tools, and only one of them is a hammer, which among many tasks is meant to serve just one purpose – to drive in nails.
Microservices Reference Architecture by NGINX , for example, includes several different models that provide a continuous spectrum of approaches to problem-solving using microservices.
Elements that are integrated into the Service Mesh architecture, such as NGINX, containers, Kubernetes, and microservices as an architectural approach, can also be effectively utilized in implementations without a Service Mesh. For instance, Istio was designed as a complete Service Mesh architecture, but its modularity suggests that developers can choose and apply only the components they need. Keeping this in mind, it's essential to develop a clear understanding of the Service Mesh concept, even if you're unsure whether you will ever fully implement it in an application.
Source: habr.com
