What is Service Mesh? — An Introduction to Envoy Proxy

Service Mesh is the communication layer in your micro-service setup. All the requests to and from each one of your services will go through the mesh.

What is Service Mesh?

Service Mesh is the communication layer in your micro-service setup. All the requests to and from each one of your services will go through the mesh. Each service will have its own proxy service and all these proxy services together form the “Service Mesh”. So if a service wants to call another service, it doesn’t call the destination service directly, it routes the request first to the local proxy and the proxy routes it to the destination service. Essentially your service instance doesn’t have any idea about the outside world and is only aware about the local proxy.

Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.

Services with local proxies

Why Service Mesh?

Container orchestration framework:

As more and more containers are added to an application’s infrastructure, a separate tool for monitoring and managing the set of containers — a container orchestration framework — becomes essential. Kubernetes seems to have cornered this market, with even its main competitors, Docker Storm and Mesosphere DC/OS, offering integration with Kubernetes as an alternative.

Services and instances (Kubernetes pods):

An instance is a single running copy of a micro-service. Sometimes the instance is a single container; in Kubernetes, an instance is made up of a small group of interdependent containers (called a pod). Clients rarely access an instance or pod directly; rather they access a service, which is a set of identical instances or pods (replicas) that is scalable and fault-tolerant.

Sidecar proxy:

A sidecar proxy runs alongside a single instance or pod. The purpose of the sidecar proxy is to route, or proxy, traffic to and from the container it runs alongside. The sidecar communicates with other sidecar proxies and is managed by the orchestration framework. Many service mesh implementations use a sidecar proxy to intercept and manage all ingress and egress traffic to the instance or pod.

service-mesh kuberne envoy-proxy nodejs microservices

In this article, take a look at the service mesh in the microservices world. The software industry has come a long journey and throughout this journey, Software Architecture has evolved a lot. Starting with 1-tier (Single-node), 2-tier (Client/ Server), 3-tier, and Distributed are some of the Software Architectural patterns we saw in this journey.

For teams to monitor, support, and to maintain these services is becoming a challenge so most enterprises have invested in some kind of microservices management tool.

Microsoft has released open service mesh (OSM), an alpha service mesh implementation compliant with the SMI specification. OSM covers standard features of a service mesh like canary releases, secure communication, and application insights, similar to other service mesh implementations like Istio, Linkerd, or Consul. Additionally, the OSM team is in the process of donating the project to the CNCF.

Reading Time: 3 minutes Service mesh is a dedicated infrastructure layer for handling service to service communication. Basically, it's a way to control how different micro services deployed on kubernetes will manage secure communication and traffic between them with lot's of cross-cutting concerns like logging, security, etc.

Microsoft’s Open Service Mesh is an SMI-compliant, lightweight service mesh being run as an open source project. Backed by service-mesh…