Sergey Nivens - Fotolia
Kubernetes, the open source container orchestration system, offers powerful capabilities to manage and scale containerized applications, but there are things it can't do well. Istio adds additional support and manages traffic flows among microservices.
The Istio service mesh project is platform-agnostic, collaborative and open source, developed by IBM, Google and Lyft, the app-based transport service. It uses a proxy sidecar model to connect, secure, manage and monitor microservices networks on cloud platforms. Istio clearly defines the role of infrastructure, decoupled from the software that runs on it.
Pros and cons of Istio integration
Pairing Istio with an orchestrator such as Kubernetes helps developers and IT administrators work together toward a common goal with applications hosted on containers. "Software developers ... direct their focus toward writing code that creates the most business value," said Karlo Zatylny, principal software architect at SolarWinds, an IT management software provider. They don't have to account for deployment factors, such as the VMs and physical environment underpinning the containers.
With Istio, IT administrators can concentrate on compute and network resources, rather than deal with specific hardware and virtual allocations. Deployed microservices-based applications become more efficient at consuming available resources, rather than underutilizing some parts of the infrastructure while overtaxing others. Istio also uses a configuration-driven communication architecture, which increases the speed of development cycles, so developers can easily approach software redesigns when business needs change, Zatylny said.
The Istio service mesh design comes with complexity and additional management overhead, although the complexity is minimized by code reuse and other design choices.
Istio provides load balancing, authorization, visibility and health checks both up- and downstream to enable admins to find, connect and route the various pieces of the deployment. It puts networking in a microservices delivery context at layer 7 of the Open Systems Interconnection model, rather than at IP's layer 3 or at layer 2 with Ethernet, said Brad Casemore, analyst at IDC.
The concept of segmentation between the control and the data plane in an Istio service mesh can confuse users, but it's actually fairly simple, said Rich Sharples, senior director of product management at Red Hat. The data plane uses a simple proxy architecture to mediate all inbound and outbound traffic for each service in the service mesh. The control plane handles service registration and discovery, authentication, access control, certificate management -- namely, signing, issuance and revocation -- and service mesh configuration, as well as telemetry data from services and service proxies.
The service mesh enables secure, reliable, server-to-server communication behind an API. "When you build microservices, you typically expose an API, which exposes functionality, which is then implemented by a collection of services," said Anne Thomas, analyst at Gartner. Because containers are ephemeral, meaning they do not retain session information, admins must reconnect them periodically, and they need security authorization capability to ensure that the deployment's server-to-server communication is protected and operational, she said.
Istio's service mesh locates a service, ensures communications resiliency and performs retries if a connection fails or finds another instance of the necessary service and makes the connection. Service mesh can also implement bulkheads and circuit breakers, Thomas said. Bulkheads isolate pieces of an application to ensure that any given service failure doesn't affect any other services. A circuit breaker is a monitoring component with a programmed failure threshold for external microservices communications; circuit breakers kill malfunctioning services to regulate resource consumption and request response time.
East-west communication capacity is another critical need with microservices. An API gateway that connects a client to a service is north-south communication; this is normally adequate, but to implement a microservice with additional services behind it, a service mesh creates east-west communication, which is to say communication within the IT environment. Istio is built for this communication path.
There are few drawbacks to Istio, as it provides a standard, multilanguage runtime service mesh to run on a given cloud platform, but as always, there are trade-offs. While Istio enables developers to produce smart microservices design patterns and best practices without obfuscating application logic, that power has performance and latency implications, Sharples said. Istio's proxy sidecar model -- the open source Envoy edge proxy to mediate traffic flow -- introduces additional network calls that might generate unacceptable latency for high-performance, real-time applications, Sharples said.
How to adopt Istio service mesh
Istio is in beta and offers no commercial support, at time of publication. For most organizations, it makes a useful proof-of-concept project, but only if they are adventurous and likely not for a business-critical application, Casemore said.
"It is for people who live on the cutting edge and maybe some teams exploring the technology, but with something that is pure open source, they would have to be very confident," said Gary Chen, analyst at IDC.