The IBM Cloud CTO describes the origins, roles, and goals of the Istio project

The original title of this article was: Istio aims to be a network pipe for containerized microservices

In the wonderful world of software containers, there is a sense of trance as new solutions to problems that have already been solved. In many cases these issues were resolved long ago, but the emergence of modern cloud native architectures drives the deployment of larger scale applications, which requires new tools and approaches to manage these services.

Microservices are a good example. Under this model, a typical application or service is decomposed into independently deployable functional modules that can be extended and maintained separately from each other and linked together to provide the full functionality of the entire application or service.

The latter can be the trickier part when developing microservices using containers. How do you wire all components together when they might be distributed in a cluster of server nodes and their instances are constantly coming online and being replaced by newer versions? In a service-oriented architecture (SOA), microservices can be viewed as evolutionary successors, similar to the tasks handled by an enterprise Service Bus (ESB). So what we need is a cloud-native version of the ESB.

This is a job that Istio, a relatively new open source project, aims to fill. It is formally described as a service grid, as part of it is distributed alongside the infrastructure alongside the containers it manages, and it sets out to meet the requirements of service discovery, load balancing, message routing, telemetry and monitoring, and of course security.

Istio, which grew out of a partnership between IBM and Google, actually includes some existing components, notably ones developed by ride-hailing company Lyft. It existed in some form for at least a year, but finally reached the 1.0 milestone at the end of July, meaning it is now finally considered mature enough to operate as part of a production infrastructure.

Jason McGee, IBM researcher and CHIEF technology officer of IBM Cloud Computing, told The Next Platform that The cloud native ecosystem has basically identified The container as The core packaging and runtime construction, and Kubernetes as The orchestration system that manages The container. But McGee explains that there is a third piece of the puzzle still in the air, and Istio aims to fulfill that requirement.

“How do you manage interactions between applications or services running on a container platform?” McGee said. “If you’re building microservices, or if you have a set of applications, there are a lot of interesting issues with communication between applications. How do you know what is the service in the interaction, and how to collect performance data communication between applications, how to protect the communication control which services can communicate with each other, and how to ensure the safety of the application, especially in the more dynamic and distributed architecture we use today, you may have on public clouds and private clouds have component at a time. “

McGee says his team at IBM started working on this issue A few years ago, when he met his counterparts at Google and found they were on the same path, but IBM focused on traffic routing, version control, and A/B testing, while Google focused on security and telemetry. The two decided to merge their efforts, and Istio was born.

Istio consists of the following components:

• Envoy, described as a Sidecar proxy because it is deployed as a proxy next to each microservice instance.
• Mixer, which is a core component for executing policies through Envoy proxies and collecting telemetry metrics from them.
• Pilot is responsible for configuring the agent;
• Citadel is the centralized component responsible for issuing certificates and also has its own per-node agent.

Envoy is a component developed by Lyft and described by McGee as a “very small footprint, layer 4 through 7 smart router” that captures all incoming and outgoing traffic, controls traffic, applies policies, and collects telemetry information for the microservices it pairs with. Pilot is a major component provided by IBM as the control plane for all Envoy agents deployed in the infrastructure.

“If you imagine in a service grid, you might have a hundred microservices, if you have multiple instances of each service, you might have hundreds or thousands of smart routes, and you need a way to program them, so Istio introduced this thing called Pilot. Think of it as the programmer, the control plane of all these routers. So you have a place where you can program this service network and then telemetry around data collection, certificate management around security, but essentially you have this intelligent routing layer and this control plane to manage it, “McGee explained.

Istio also has its own API that allows users to plug it into existing back-end systems, for example for logging and telemetry.

According to Google, Istio’s monitoring capabilities enable users to measure actual traffic between services, such as requests per second, error rates and latency, and can also generate dependency diagrams so users can see how services affect each other.

Istio can also use two-way TLS authentication (mTLS) on each service call through the Envoy Sidecar proxy, encrypting and enabling users to authorize each call within the scope of the infrastructure.

Istio aims to eliminate many of the issues that developers need to worry about: Security issues for communication between instances, control which instances can communicate with which instances, and provide for performing operations such as canary deployment, and if a new version of a particular microservice code is released, only a subset of instances is updated until you are satisfied that the new code is running reliably

It should be noted that other Service Mesh platforms already exist, such as Linkerd or Conduit on the open source side, while Microsoft has a Service called Azure Service Fabric Mesh that is currently serving as a technical preview for its cloud platform. In addition, the service grid represents an abstraction layer above the network pipes, so it is assumed that network interfaces, IP addresses, and other network properties have been configured for each container instance. This typically means that deploying microservices will also require a separate tool to automate network configuration whenever a new container instance is created.

However, IBM hopes Istio will become a standard part of the cloud native toolkit, as has happened with Kubernetes, which is based on Borg and Omega technologies that were developed for Google’s own internal clusters and container layers that run on top of them.

“From a community perspective, my expectation is that Istio will become the default part of the architecture, just as containers and Kubernetes have become the default part of cloud native architecture,” McGee said. To this end, IBM wants to integrate Istio with its managed Kubernetes service provided by the public Cloud and its IBM Cloud Private stack deployed internally.

“So, you can run Istio today, and we support running Istio on both platforms today, but the expectation should be that in the near future, we will have Istio built in, so every time you use our platform, Istio components are integrated into it, and you can leverage it and not be responsible for deploying and managing Istio itself, Just use it in your application, “McGee says.

Google has added Istio support, although it only marks it as an alpha version, as part of a hosted service that is automatically installed and maintained in customers’ Google Kubernetes Engine (GKE) clusters on its cloud platform.

Istio also has support from other players in the industry, notably Red Hat, which redesigned its OpenShift application platform a few years ago based on the Docker container and Kubernetes.

Brian Harrington, Red Hat’s Istio product manager, also known as Red Beard, says that Red Hat intends to integrate the service grid into OpenShift, but Red Hat wants to see some sketchy improvements, such as multi-tenant support, before committing.

“Istio is now targeting what they call soft multi-tenancy, which means we want it to be available within the organization so that two different teams within the organization can use it and trust it, as long as no one on the team is acting so maliciously that they are not prepared to affect the services of others. “The way we ran OpenShift Online, we had customers running code we’d never seen before, and we had to eventually accommodate both customers, which was a very different multi-tenant challenge,” Harrington explained.

“We need to have more confidence in this multi-tenant feature; We need to have more confidence in performance and stability. In these areas have yet to see a perfect solution, but in the scale and some automated regression testing, we see the places we think we can provide a lot of value, we also at the community level contributed a project called Kiali, gives the Istio visualization of the process of operation, this is just a part of our products, “He added.

In other words, Istio is just another open source tool to add to the menu of options for those who want to build a cloud native application infrastructure. Vendors like Red Hat will incorporate it into their tested and supported enterprise platform offerings, such as OpenShift, while others will want to mix and match and build it themselves.