Load balancing with Envoy: Using side-car approach

Introduction

Laymen explanation

As on the ground microservice practitioners quickly realize, the majority of operational problems that arise when moving to a distributed architecture are ultimately grounded in two areas: networking and observability. It is simply an orders of magnitude larger problem to network and debug a set of intertwined distributed services versus a single monolithic application.

Technical explanation

Side-car design pattern

Envoy is well-suited for deployment as a sidecar deployment, which means it gets deployed alongside your application (one to one) and your application interacts with the outside world through Envoy Proxy. This means, as an application developer, you can take advantage of the features provided by Envoy through configuration (like service discovery, client-side load balancing, circuit breakers, tracing, etc).

Features

Envoy Proxy is a small, lightweight, native/C++ application that enables the following features (and more!):

• • Service discovery

  • Adaptive routing / client side load balancing

  • Automatic retries

  • Circuit breakers

  • Timeout controls

  • back pressure

  • Rate limiting

  • Metrics/stats collection

  • Tracing

  • request shadowing

  • Service refactoring / request shadowing

  • TLS between services

  • Forced service isolation / outlier detection

Metrics collection

The first thing we get from Istio out-of-the-box is the collection of metrics in Prometheus. These metrics are generated by the Istio filter in Envoy, collected according to default rules (which can be customized), and then sent to Prometheus. The metrics can be visualized in the Istio dashboard in Grafana.

Reference

https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar

http://blog.christianposta.com/microservices/00-microservices-patterns-with-envoy-proxy-series/

http://blog.kubernetes.io/2017/05/managing-microservices-with-istio-service-mesh.html