Wilson Mar bio photo

Wilson Mar

Hello. Hire me!

Email me Calendar Skype call 310 320-7878

LinkedIn Twitter Gitter Instagram Youtube

Github Stackoverflow Pinterest

The sidecar proxy separates cross-cutting operational concerns from business logic, handing off to a control pane to do the rest

US (English)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Cyrillic Russian   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean


“Service mesh” architecture is about microservices applications working within a “control plane” a standard way to hand-off service-to-service access control authentication, encrypted communications, monitoring, logging, timeout handling, load balancing, health checks, and other operational cross-cutting concerns to a sidecar proxy within its pod, which works with a control plane common to all services. The control plane aggregates telemetry data for display on dashboards such as the hero image above.

The implementations:

  • Istio, backed by Google, IBM, and Lyft (which contributed its Envoy proxy which works within Kubernetes as a sidecar proxy instance)

  • NGINX proxy


Individual apps interact with a proxy (Kubernetes sidecar) running on each service instance. The sidecars communicate with a Control Tower. This out-of-process architecture puts hard stuff in one place and allows app developers to focus on business logic. And a separate library in each language for operational concerns is not needed.

The control plane is a traffic controller that handles tracing, monitoring, logging, alerting, A/B testing, rolling deploys, canary deploys, rate limiting, and retry / circuit-breaker activities that include creation of new instances based on application-wide policies during authentication, and authorization;

The control plane includes an application programming interface, a command‑line interface, and a graphical user interface for managing the app.

Cloud Foundry Spring Cloud?

Within a Service Mesh, apps create service instances from service definitions (templates) for service instances. Thus, the term service refers to both instance definitions and the instances themselves.



https://istio.io/ aims to provide a a uniform way to secure, connect, and monitor microservices. It provides rich automatic tracing, monitoring, and logging of all services to a “service mesh” – the network of microservices.


Istio provides APIs that let it integrate into any logging platform, or telemetry or policy system.

Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more.

“Without any changes in service code” applies only if the app has not implemented its own mechanism duplicative of Istio, like retry logic (which can bring a system down without attenuation mechanisms).



gRPC is a high-performance, open-source universal RPC framework built on top of HTTP/2 to allow for streaming between client and server. It originated as project “stubby” within Google and is now a F/OSS project with open specs.

  • A new HTTP/2 stream for each RPC call
  • Clients open one long-lived connection to a grpc server.

gRPC avoids mistakes of SOAP WSDL:

  • Protobuf vs. XML

https://www.youtube.com/watch?v=RoXT_Rkg8LA by Twilio


Lyft Envoy uses gRPC bridge to unlock Python gevent clients.

https://www.youtube.com/watch?v=hNFM2pDGwKI Introduction to gRPC: A general RPC framework that puts mobile and HTTP/2 first (M.Atamel, R.Tsang)

Envoy from Lyft



VIDEO: Lyft’s Envoy: From Monolith to Service Mesh Feb 14, 2017 by Matt Klein, Lyft explains from a developer’s viewpoint why SoA and its issues.

Envoy is written in C++11. H2 on both sides, supports gRPC. Does shadowing (fork traffic to a test cluster for live perf testing) It’s container-aware of Docker

Lyft uses LightStep for tracing, WaveFront for stats (via statsd)

L7 reverse proxy at edge (replacement for NGINX).

Envoy provides robust APIs for dynamically managing its configuration.



NGINX built the equivalent of Istio Envoy.




Linkerd (https://linkerd.io) is a Cloud Native Foundation (CNF) incubating project that also includes graduates Kubernetes and Prometheus, plus Helm, OpenTracing, gRPC, etc.. Linkerd provides Grafana dashboards and CLI debugging tools for Kubernetes service with no cluster-wide installation. It was built in the Rust programming language. Its customers include Salesforce, Walmart, PayPal, Expedia, Comcast.

https://linkerd.io/2/getting-started/ for installation, etc.

Provides Grafana dashboards:



Circuit breaker

The circuit breaker pattern isolates unhealthy instances, then gradually brings them back into the healthy instance pool if warranted.


There is a quite thorough hands-on workshop using GKE (Google Kubernetes Engine).

  • https://github.com/retroryan/istio-workshop is the original worked on by Ryan, etc. contains exercises.

  • https://github.com/srinandan/istio-workshop

In this workshop, you’ll learn how to install and configure Istio, an open source framework for connecting, securing, and managing microservices, on Google Kubernetes Engine, Google’s hosted Kubernetes product. You will also deploy an Istio-enabled multi-service application

Rock Stars

Ray Tsang (@saturnism, saturnism.me), Google Cloud Platform Developer Advocate in NYC:

Kelsey Hightower:


BOOK: Istio Succinctly 2020

What is a service mesh? May 27, 2018 by Defog Tech

What is a service mesh? May 27, 2018 by Defog Tech

Microservices in the Cloud with Kubernetes and Istio (Google I/O ‘18) May 9, 2018 by Sandeep Dinesh

APIs, Microservices, and the Service Mesh (Cloud Next ‘19) by Dino Chiesa