Image for post
Image for post

Reducing Microservices Architecture Complexity with Istio

Nowadays microservices are a huge trend used by companies. Developers use microservices to architect for portability, while operators manage extremely large hybrid and multi-cloud deployments.

In a microservice world, things become more complex. Platforms such as Kubernetes address a lot of the complexity; they handle resource isolation and utilization, networking, and deployments nicely. But a lot of the involved complexity such as load balancing, rollout scenarios, circuit breaking, retries, rate limiting, observability, tracing, and transport security is still left up to the development teams.

Of course, you can address all of these challenges in your microservices programmatically using popular open-source components such as Hystrix, Ribbon, Eureka, the EFK Stack, Prometheus, or Jaeger. But unfortunately, this approach can quickly lead to excessive library bloat, and suddenly your microservices are not quite so micro anymore.

Istio is one of the latest technologies that is used by developers to reduce the complexity of their deployments. It is a so-called service mesh that addresses many of the cross-cutting communication concerns in a microservice architecture. Think of Istio as AOP (aspect-oriented programming) for microservice communication. Instead of implementing everything directly within your services, Istio transparently injects and decorates the desired concerns into the individual communication channels.

Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality, which includes:

  • Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
  • Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
  • A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
  • Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
  • Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.

Istio is designed for extensibility and meets diverse deployment needs. It does this by intercepting and configuring mesh traffic as shown in the following diagram:

Image for post
Image for post
Conceptual Istio Architecture and Components.

An Istio service mesh is logically split into a data plane and a control plane.

  • 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. They also collect and report telemetry on all mesh traffic.
  • The control plane manages and configures the proxies to route traffic.
Image for post
Image for post
Istio Glossary

Gateway configures a load balancer for HTTP/TCP traffic, enables ingress traffic into the service mesh

Virtual Service defines the rules that control how requests for a service are routed within the service mesh

Destination Rule configures the set of policies to be applied to a request after VirtualService routing has occurred

Service Version aka Subset allows to select a subset of pods based on labels

Service Entry enables requests to services outside of the service mesh

Istio provides an ingenious solution by being completely separated from the services and act only by intercepting all network communication. And doing so it can implement:

· Fault Tolerance: Using response status codes it understands when a request failed and retries.

· Canary Rollouts: Forward only the specified percentage of requests to a new version of the service.

· Monitoring and Metrics: The time it took for a service to respond.

· Tracing and Observability: It adds special headers in every request and traces them in the cluster.

· Security: Extracts the JWT Token and Authenticates and Authorizes users.

Architecture Istio

Image for post
Image for post

· Pilot — Responsible for configuring the Envoy and Mixer at runtime.

· Proxy / Envoy — It runs as a container inside each pods. Sidecar proxies per microservice to handle ingress/egress traffic between services in the cluster and from a service to external services. The proxies form a secure microservice mesh providing a rich set of functions like discovery, rich layer-7 routing, circuit breakers, policy enforcement, and telemetry recording/reporting functions.

· Mixer — Create a portability layer on top of infrastructure backends. Enforce policies such as ACLs, rate limits, quotas, authentication, request tracing and telemetry collection at an infrastructure level.

· Citadel / Istio CA — Secures service to service communication over TLS. Providing a key management system to automate key and certificate generation, distribution, rotation, and revocation.

· Ingress/Egress — Configure path-based routing for inbound and outbound external traffic.

· Control Plane API — Underlying Orchestrator such as Kubernetes or Hashicorp Nomad.

Different release patterns can easily be applied

Istio affords the following benefits:

  • Improved availability: If a control plane becomes unavailable, the scope of the outage is limited to only workloads in clusters managed by that control plane.
  • Configuration isolation: You can make configuration changes in one cluster, zone, or region without impacting others.
  • Controlled rollout: You have more fine-grained control over configuration rollout (e.g., one cluster at a time). You can also canary configuration changes in a sub-section of the mesh controlled by a given primary cluster.
  • Selective service visibility: You can restrict service visibility to part of the mesh, helping to establish service-level isolation. For example, an administrator may choose to deploy the HelloWorld service to Cluster A, but not Cluster B. Any attempt to call HelloWorld from Cluster B will fail the DNS lookup.
Image for post
Image for post
Different release patterns can easily be applied.

You have to know that Not all Istio features are marked Stable yet, but Beta can already be used in Production and Istio has built-in support for service mesh diagnosability.

Written by

Apache Solr Contributor | Slack Contributor | Speaker | Chief Technology Officer at OpenSooq | Technical Reviewer for Big Data Books

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store