The Istio project today hit its 1.0 release nearly 14 months after its public unveiling. However, the service mesh management platform still lacks official support from cloud giants Amazon Web Services (AWS) and Microsoft, and supporting vendors are working through testing and education challenges.
Istio was established last year to provide developers with visibility into microservices without the need to change application code. The platform sits at the network level and uses a substrate for microservices development and maintenance. This allows for the decoupling of management from application development.
The 1.0 release builds on recent work up to the 0.8 release level (it skipped 0.9) and includes improved handling of role based access controls (RBACs), improved transport layer security handling, component stabilization, increased test suites, and broader community testing.
“We really wanted the release to knock the socks off of the community and we feel we have done that,” said Brian Harrington, product manager for Istio at Red Hat.
Harrington noted that one area of focus has been in reducing the performance impact of injecting Istio into a running system. This is important as containers provide for their greatest efficiency when unencumbered by running dependencies.
“That has been something we have really doubled-down on over the past few months,” he explained, adding that he “absolutely” thinks it has hit those targets.
Istio was initially launched with backing by Google, IBM, and Lyft, which donated its Envoy proxy that makes the network transparent to applications. A number of other vendors have since jumped on board to support the project, including Red Hat and Cisco.
AWS and Microsoft have so far not officially tied Istio into their cloud platforms, but both companies were also slow to jump on the Google-led Kubernetes bandwagon.
“I think service mesh is still in its early stages of widespread enterprise adoption but it would be great if those major cloud services adopted it,” said IT analyst and consultant Daniel Conde.
Edwin Yuen, senior analyst for cloud at Enterprise Strategy Group, added that he thinks that additional support would help but is not necessary.
“I think that having Google backing it and the strength in the existing partnerships will be enough to sustain Istio going forward,” Yuen said via email. “It certainly would benefit the community at large if AWS and Microsoft officially support it, especially in their managed offerings, but I don’t think it’s essential for Istio adoption in the future.”
While Istio is now ready for upstream work, Harrington said Red Hat is likely to continue with testing in order to make sure it integrates smoothly with its customer base. “That’s just something we typically do with all projects,” he explained.
Google last week launched a managed version of Istio in an attempt to further ease adoption of the platform.
Where Does It Fit?
Harrington admitted that there still remains some confusion over where Istio fits into the broader cloud native picture. He cited the current Cloud Native Computing Foundation (CNCF) projects page that lists Linkerd and Envoy as “service mesh” platforms that would appear to be similar to Istio.
Harrington explained that both of those provide the “functions of a service mesh, but the application developer and cluster administrator still need to orchestrate the configuration of the individual proxy instances.”
This is where Istio helps as it acts as the control plane for management of a service mesh. It can handle the deployment of Envoy sidecars – where Envoy sits next to a running container pod – and coordinate that deployment through the container orchestration layer working with platforms like Kubernetes or Apache Mesos.
“It’s through this process of traffic interception that Istio is able perform its ‘magic’ of automatically connecting components of a service together,” Harrington added.
The Linkerd community has added support that allows users to run both. This involves using Istio as a control plane across Linkerd instances.
Istio is also being used as a building block for the recently unveiled Knative project. Google announced Knative last week at its Next event in San Francisco. It’s an open source set of components that allows for the building and deployment of container-based serverless applications that can be transported between cloud providers.
Knative runs as an abstraction layer on top of Istio and Kubernetes. It uses parts of Istio for secure socket layer (SSL) and transport layer security (TSL), though due to current Istio limitations that support is limited to a single certificate per cluster.
Craig Box, a lead on Kubernetes and Istio at Google, said Knative is currently dependent on Istio, but that the group was looking for comments from developers as to whether it should loosen that dependency.
“We can half implement Istio or make it a hard dependency on Istio,” Box explained during a presentation this week at Google’s offices in Boulder, Colorado. “We are looking for feedback on that.”