Introduction

In cloud era, many organizations are starting journey towards adopting microservice architecture to enable organizations to grow fast, where & when needed. This article has been divided into multiple parts.

In part 2, focus on what is Service Mesh, why do need to use Istio Service Mesh

In part 3, will be focusing on quick comparison between Spring Cloud and Istio service mesh.

In part 4, will be focusing on key benefits of Istio service mesh like how Istio helps developer, operators, etc.

In part 5, will be focusing on additional features of Istio service mesh

ISTIO Service Mesh

This section covers, what is Istio service mesh, how it helps to resolve complexity in microservice approach.

By implementing a common microservices fabric, Istio addresses many of the challenges faced by developers and operators as monolithic applications transition to a distributed microservices architecture.

Applications are getting decoupled internally as microservices, and the responsibility of maintaining coupling between these microservices is passed to the service mesh.

• PaaS platforms like Cloud Foundry are great for deploying microservices, and they were created with a view of simplifying application deployment across multiple runtimes.
• Kubernetes can handle multiple container-based workloads, including microservices.
• Istio comes with more sophisticated features like traffic management, failure handling and resiliency.

Istio achieves this, by using “proxies” to intercept all incoming and outgoing network traffic. Proxies in a service mesh architecture are implemented using the sidecar pattern: a sidecar is conceptually attached to the main (or parent) application and complements that parent by providing platform features.

For more information, refer here.

What is Istio

Istio an open platform to connect, secure, manage and monitor microservices. It provides an easy way to create network of deployed services with load balancing, service-to-service communication, authentication, monitoring, and more, without requiring any changes in service code. By deploying a special sidecar proxy to intercept and act on traffic between microservices throughout the environment, Istio provides a straightforward way to create a network of deployed services, often referred to as a “service mesh.”

Also, Istio automatically collects service metrics, logs and call traces for all traffic within a cluster, including cluster ingress and egress. The use of sidecar proxies enables a gradual and transparent introduction without architectural or application code changes. So, developers can focus on business logic and quickly integrate new features.

Note: Istio is not targeted at any specific deployment environment. During the initial stages of development, and as it currently stands, Istio supports Kubernetes-based deployments. However, it is being built to enable rapid and easy adaptation to other environments, such as VMs and Cloud Foundry.

Why should we use Istio

Imagine an application that is broken down into multiple microservices; each microservice has multiple instances, and each deployed instance has multiple versions. Typically, even a simple application deployment with this kind of model can span with multiple microservices.

When number of services grows, it become harder to manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring, and often more complex operational requirements such as A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.

Istio provides a complete solution to satisfy the diverse requirements of microservice applications by providing behavioral insights and operational control over the service mesh as a whole. It provides a number of key capabilities uniformly across a network of services:

Connect and Communicate

• Dynamic routing based on weights and HTTP headers
• Fault Injection like inject delays, useful to test the resiliency
• Set Timeouts

Monitoring

• Collects metrics and logs
• Tracing using Zipkin
• Traffic monitoring using Grafana
• Service Graph – shows service’s runtime relationship

Security

• Basic access control using Kubernetes label
• Apply/Enforce operational policy
• Local TCP connections between the service and Envoy
• Mutual TCP connections between proxies

Manage

• Enable users to rate limit traffic to a service (ensure user is not crossing usage/quota)
• Migrate traffic from old to new version of a service

In summary,

• For Application developers: With Istio managing how traffic flows across their services, developers can focus exclusively on business logic and iterate quickly on new features.
• For Service operators: Istio enables policy enforcement and mesh monitoring from a single centralized control point, independent of application evolution. As a result, operators can ensure continuous policy compliance through a simplified management plane.

How Istio works
Istio consists of,
A control plane that manages the overall network infrastructure and enforces the policy and traffic rules

A data plane which includes sidecars implemented using Envoy, an open source edge proxy

Istio Pilot (for traffic management):

• Pilot is responsible for the lifecycle of Envoy instances deployed across the Istio service mesh.
• Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (e.g., A/B tests, canary deployments, etc.), and resiliency (timeouts, retries, circuit breakers, etc.). It converts a high level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime.
• Istio Pilot provides content and policy-based load balancing and routing, also maintains a canonical representation of services in the mesh.
• Pilot exposes APIs for service discovery, dynamic updates to load balancing pools and routing tables.
• Users can specify high-level traffic management rules through Pilot’s Rules API. These rules are translated into low-level configurations and distributed to Envoy instances via the discovery API.

Istio Auth (for access control):

• Providing each service with a strong identity that represents its role to enable interoperability across clusters and clouds
• Securing service to service communication and end-user to service communication
• Providing a key management system to automate key and certificate generation, distribution, rotation, and revocation

Istio Mixer (for monitoring, reporting, and quota management):

• Istio Mixer provides in-depth monitoring and logs data collection for microservices, as well as collection of request traces. It uses Prometheus, Grafana, and Zipkin to provide some of these in-depth metrics.
• Precondition checking – enables callers to verify a number of preconditions before responding to incoming request from a service consumer.
• Quota management – enables services to allocate and free quota on a number of dimensions. Rate limits are examples of quotas.
• Telemetry reporting – enables services to be reporting and logging

Envoy

• Istio uses an extended version of the Envoy proxy, a high-performance proxy developed in C++, to mediate all inbound and outbound traffic for all services in the service mesh. Istio leverages Envoy’s many built-in features such as dynamic service discovery, load balancing, TLS termination, HTTP/2 & gRPC proxying, circuit breakers, health checks, staged rollouts with %-based traffic split, fault injection, and rich metrics.
• Envoy is deployed as a sidecar to the relevant service in the same Kubernetes pod. This allows Istio to extract a wealth of signals about traffic behavior as attributes, which in turn used in Mixer to enforce policy decisions, and be sent to monitoring systems to provide information about the behavior of the entire mesh.

References