Istio 1.0 was released recently. Many significant features have progressed, from alpha to beta stage or from beta to stable, and is already in deployment at various phases at AutoTrader, Ebay, IBM and Namely, to name a few.
InfoQ caught up with Lin Sun, a senior technical member at IBM and also a participant in the open source Istio project release team, regarding Istio in general and the 1.0 release in particular.
Sun covers a number of topics around Istio including microservices, the features in 1.0, service mesh, the sidecar proxy, roadmap for the Istio platform, and its ability to work not just with Kubernetes, but also with other platforms.
InfoQ: Istio is built around Service Mesh. Can you explain to developers and architects what this really means?
Lin Sun: Istio is essentially our viewpoint of how a service mesh should connect, secure, control and observe microservices. Microservices have brought a great amount of benefits to new cloud architectures, such as agility, speed, and flexibility. However, one of their pitfalls is complexity.
As users move monolithic applications to architectures that are built on containers and microservices, what they're doing is breaking these large apps into many different moving parts. This same concept also applies to new cloud apps built with microservices, with the only difference being that all of these different pieces are created from scratch. However, the challenges with this model remains the same.
Managing all of these different parts at once can be difficult, and can wreak havoc on security. Istio is a way to give control back to developers, and ensure that microservices are connecting to each other in a prescribed way while handling failures. This makes it easier to observe what is happening across an entire network of microservices, as well as to secure communication between services and ensure that policies are enforced.
This isn't just IBM's viewpoint. Istio is an open service mesh platform, with over 200 contributors at this point in time. Istio was founded by IBM, Google and Lyft, and a thriving community has grown around it to include other partners such as Cisco, Redhat, Pivotal, Tigera and countless others. Istio's open architecture and ecosystem is one of the components which makes it so effective; there is no vendor lock-in limiting the types of services you can use with it, and it can run in any cloud model – whether that means public, private, on-premises or a combination.
The other benefit of Istio is that it requires few to no code change to the application. It doesn't matter whether your services are programmed in Javscript, Go, Java, Python or another language. Once you implement it, the only change needed is minimal code change required to properly forward request headers to leverage distributed tracing. Common tasks such as load balancing, routing, retries and mTLS are abstracted away and solved by Istio in a consistent way across all microservices, regardless of the language in which they're written.
InfoQ: Can you summarize the differences between Istio 0.8 and Istio 1.0, and if and how Istio 1.0 is more production ready?
Sun: Many significant features across Istio have been promoted from Alpha to Beta, and from Beta to Stable between Istio 0.8 and 1.0. Together, these capabilities form the latest and most stable version yet of Istio, and are the result of strong community collaboration to test and harden how Istio can scale and manage an increasing large and complex network of microservices.
For example, HTTP1.1 / HTTP2 / gRPC / TCP protocols in traffic management have been moved to Stable. WebSockets and MongoDB have been moved to Beta, along with traffic control, resilience, gateway, TLS termination and SNI support in the gateway. Filter support is newly added to 1.0, thus we kept it at Alpha. IBM has driven the development of many of these features by contributing knowledge we've learned from working with complex enterprises as they journey to the cloud. Together with the community, we've rallied to deliver what developer teams want when they move Istio into production, including stability, security and control.
You've probably noticed a trend where we declare a new feature as Alpha first, then if it is relatively stable from our testing, experience and feedback from users, we promote it to Beta, then promote it to Stable across multiple Long Term Supported (LTS) releases. Once a feature reaches Beta, we start to recommend users to use it in production but with caution.
With many of the core features of Istio now in Stable and Beta status, Istio 1.0 is ready for production. Some of our users are already using Istio in this way, including AutoTrader, Ebay, and Namely, to name a few. At IBM, we use Istio internally and a number of our customers are using Istio in pre-production.
A few other strong features of Istio 1.0 include:
- SNI routing support in virtual service to enable users to configure traffic routes based on the SNI host values.
- The out-of-process mixer adapter allows developers to write mixer adapters without needing to submit a pull request (PR) to the core Istio mixer component. Developers can build and release their own mixer adapters at their own pace.
- Many of the policy checks are now done in the envoy sidecar proxy, which improves both performance and reliability. For example, you don't need a mixer when applying RBAC rules on your microservices.
- In addition to the authentication policy, there is a new 'permissive' mode to allow transition to mutual TLS more easily. This allows you to be in 'permissive' mode during the transition and then enforce the security once the transition is fully done.
InfoQ: The sidecar proxy pattern is a central tenet in Istio. Is this primarily for gathering telemetry on the pods or is there a larger purpose for this?
Sun: Collecting telemetry data is just one of the many things done by the sidecar proxy. Envoy is our default proxy implementation, and it handles common tasks such as load balancing, routing, and retries consistently across all languages.
Envoy captures all inbound traffic based on the target ports and all outbound traffic, and sends telemetry data to Istio, which is a sub-component of Mixer. It also performs policy checks such as rate limiting, RBAC or other attribute-based policy checks, either locally or with the Istio-policy component. Finally, Envoy also handles secure communication among microservices within the mesh by checking identity, certification and keys when mutual TLS is enabled.
InfoQ: Istio is not meant just for Kubernetes, is it? Does it work with other platforms such as Cloud Foundry, OpenShift and so on?
Sun: This is the beauty of Istio being created and run in the open. You can run Istio virtually anywhere – whether that is on Kubernetes clusters, on virtual machines, or within Cloud Foundry environments. Istio can run in any environment which has passed the Kubernetes v1.9 or newer conformance certification issued by CNCF. You can run Istio on any Kubernetes 1.9 cluster, including within the IBM Cloud Kubernetes Service, or on top of another cloud platform.
If you look at our installation document, we have instructions for how to set up Istio across different environments. Services from virtual machines can also participate as part of the Istio mesh.
Istio is also embedded within Cloud Foundry, and the Cloud Foundry team has been contributing actively to Istio as well.
InfoQ: Can you point developers and architects to learning resources for Istio apart from the bookinfo example?
Sun: Bookinfo is a great learning example that is written for cloud-native microservices, and it is used throughout istio.io to showcase various features of Istio. There are many other good resources as well, including:
- Various Istio Blogs, tasks and examples on Istio.io
- Get Started with Istio and Kubernetes by Katacoda
- IBM extended the Kubernetes Guestbook example, including how to integrate it with machine learning and other services
- IBM Cloud also maintains an Istio resource page
A number of other community members have also published various other blogs, tasks and examples that can help you get started with Istio, such as Redhat and Google.
InfoQ: Can you provide a roadmap beyond Istio 1.0 and the plan for working with the Kubernetes, Knative and other communities going forward?
Sun: From IBM's perspective, we have been focused on ensuring that Istio is easy to set up and use with IBM Cloud. Istio is a key component of the IBM Cloud strategy. Among other things, we're focused on providing federated Istio service mesh capabilities across clusters spanning the public IBM Cloud Kubernetes Service and on-premises IBM Cloud Private environments to provide a unified microservices experience.
From a broader community outlook, IBM and Istio contributors are focused on releasing fixes for 1.0 and 1.1, with the goal of broadening adoption by making Istio easier to use. This includes building the ability to adopt parts of Istio on an as-needed basis, continuing to improve its performance and scale, and actively building out key features such as routing API improvements, ability to run mixer per node, and the ability to span Istio across multiple environments. We're also focused on growing multicluster support for non-flat networks, which are networks in which pods cannot be routed across multiple Kubernetes clusters.
Istio works closely with the Kubernetes community and the community continues to choose Kubernetes as its preferred platform. We are excited that other open projects such as Knative and Fission are using Istio, and the potential that they hold to make Istio even easier to consume and use in the future.
Istio 1.0 technical details are available in the release notes.