Istio Service Mesh

Linux containers

Red Hat Openshift recently announced a Technology Preview program for Istio on Red Hat OpenShift. This preview works with Red Hat OpenShift Platform 3.10.

This annoucement was very timely given the recent release of Istio 1.0 and the Istio London meetup held on 1 October which I popped along to:

One thing is for certain, Istio and the Service Mesh is a hot technology right now!

What is a service mesh?

In microservices, an application is reduced into a set of smaller services.  These smaller services perform customised tasks which make them easier to understand and develop.   However, as an application grows in complexity so do the number of such services.  Rather than one big monolith where a developer knows everything around a single application, instead you have many smaller services (which can each use different technologies if needed) which can all be independent of each other.  So, how do we manage this large number of services?  This is where the service mesh comes in.  In simple terms, a service mesh is a dedicated infrastructure layer for handling communication between services within the microservices architecture. With Istio, the most important concept to understand are the two data planes:

  • The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices along with Mixer, a general-purpose policy and telemetry hub.
  • The control plane manages and configures the proxies to route traffic. Additionally, the control plane configures Mixers to enforce policies and collect telemetry.



Istio Components

Envoy – A proxy in the data plane that is deployed as a ‘sidecar’.  One proxy is deployed per service and they manage all inbound and outbound traffic for all services in the service mesh

Mixer – Sits in the control plane and receives metrics from envoy

Pilot – Sits in the control plane and provides service discovery and manages traffic and routing rules (example – send 99% of traffic to Service A but 1% of traffic to a new service B, so A/B testing can be performed)

Citadel – Sits in the control plane and provided service-to-service and end-user authentication with built-in identity and credential management.  This feature allows mTLS (Mutual TLS authentication) communication to occur in the data plane between services.

Fortio – Not really a core Istio component, but worth a mention.  started as, and is, Istio‘s load testing tool and now graduated to be its own project.


The Istio London Meetup Group

Some links from the 1 October 2018 Istio London Meetup group:

Observability tools and patterns with Istio – Nick Joyce (Realkinetic)


Nick Joyce on Twitter

Video to follow.

Service Mesh Network Security – Andrew Martin (Control Plane)

Video to follow

Andrew Martin on Twitter

Mutli-cluster routing: a mutli-mesh approach – Matt Turner (Tetrate)

Video to follow

Matt Turner on Twitter