Five Exciting Things About Istio v1.0
5 min read
Get excited about Istio v1.0
Istio, an open platform to connect, secure, control, and observe microservices, was launched on May 24, 2017, as a joint force by IBM, Google, and Lyft.
In the video below, JJ Asghar, an IBM Cloud Developer Advocate, explains the basics of this new, open-platform, independent service mesh and looks at how Istio runs on Kubernetes:
Istio v1.0 features and improvements
Over the last year, numerous new features and improvements have been made to get to the current production-ready version 1.0.
Below are the top five reasons why I’m an advocate for Istio:
1. Incrementally adopt Istio
The new Istio installation and upgrade via Helm made it possible to start with only the feature you need—such as traffic management—and gradually upgrade to adopt more features from Istio. As a user, if I started with the network feature, I could easily run `helm upgrade` to add the Jaeger distributed tracing or Grafana dashboard feature without causing any disruption to the Istio control plane or my applications that were already deployed. This is powerful because I can adopt Istio features at my own pace as I get ready to explore some of the new improvements.
2. Traffic management improvement
Starting with Istio 0.8, a new traffic management API (e.g., v1alpha3) has been introduced to address some of the pain points from the older API, such as managing very large applications containing thousands of services, working with some protocols, and configuring external traffic with Kubernetes Ingress resources. The new traffic management enables fine-grained control over the flow of traffic through a mesh and pushes configuration from the Istio control plane to the Envoy sidecar via gRPC to improve performance and scalability. With traffic management, you could easily configure your service to talk to one of the IBM Watson services in IBM Cloud, empowering your service with machine learning capabilities. I recently modernized the Kubernetes guestbook example to automatically generate an emoji based on machine learning and experienced that traffic management really helped me to test and roll out the new version. I highly recommend you to explore traffic management so you are confident about what you are testing.
3. Improved telemetry
As an Istio user, I don’t have to do anything to enable various metrics or tracing, which gives me valuable time back. I can deploy my microservice application and let Istio manage it without having to change any part of my application or my deployment .yaml file. The Jaeger tracing provides detailed tracing information for each of the requests that come into my application and allows me to drill into each request to view how traffic flows end-to-end within the service mesh. If you want your trace spans tied together for each given request, you’ll need to update your code to propagate a few headers. I highly recommend you consider telemetry as the first Istio feature to roll into your production environment.
4. Multi-environment and multicluster support
One of the initial goals for Istio was to enable multi-environment support because you can’t require all of your workload to run in Kubernetes in a microservice architecture. Some of your applications may run in Kubernetes, while some may run in Docker Swarm or VMs. Istio has provided early support for VMs, allowed for integration with some of the more popular service discovery systems such as Consul, and expanded to support other runtime environments. Multicluster allows users to deploy one single Istio mesh across multiple Kubernetes clusters where users can easily access service across clusters. I’m excited to see Istio expanded to multiclusters and multiple vendor clouds!
5. Mutual TLS (mTLS) and its flexible configuration
This one is my personal favorite: Istio enhances the microservices to communicate securely via mTLS without the need for you to make any code change to your microservices. What is most interesting is the community really made this flexible and easy to use by introducing the new authentication policy where you can gradually adopt mTLS per namespace or per service. Further, users can plug in any existing CA certificate and key or configure role-based access control (RBAC) for each service. As much as I love these security features, I would recommend you to adopt Istio without mTLS enabled first, then gradually enable mTLS. It can be much harder to troubleshoot problems when mTLS is enabled, so you want to make sure your microservices can work with Istio without mTLS enabled first.
In closing, I hope these five highlights get you excited about Istio. The community is thriving and we eat our own dog food. The Istio control plane itself runs on Istio so that the communication is secured and operators can see nice Grafana dashboard around the control plane. I recommend installing the newest version on IBM Cloud Kubernetes Service and giving it a try!
