Istio’s Complexity Demystified
For a very long time, Istio has been criticized as notoriously complex and hard to use. As someone who worked on the project for over four years, I agreed with this statement in the first two years of Istio. However, since Istio 1.3, the Istio community focused on simplifying and Istio is now a lot more streamlined and easier to use, especially with Istio 1.6 or newer. I personally observed improved simplicity and ease of use myself, and many of our users are reporting similar experiences.
Essentially, today’s Istio is much more straightforward. Anyone who avoided Istio because earlier versions were harder to use should consider taking a second look.
Simple Things Are Easy with Istio
With tremendous focus from the Istio community on simplicity, I’m proud to say that simple things are now easy with Istio. Let me start with three concrete examples:
1. One Command to Install
In the earlier days of Istio, I remember I always had to look up the installation instructions in istio.io. It just was not a simple command to remember. Today, users can install Istio easily using the istioctl install command, which sets up the default profile for them. Furthermore, users can specify --profile to indicate a different profile. Very easy to remember, right?
Istio install takes about one minute, with only a dozen or so custom resource definitions (CRDs) installed:
2. Analyze Your Istio Resources
Back in earlier days with Istio, I recall spending hours debugging what was wrong with my Istio resources when onboarding a simple guestbook application from Kubernetes to Istio service mesh. Not anymore! istioctl analyze can immediately tell me what’s wrong with my Istio resource(s) with consideration of other Istio resources in my cluster.
3. Simple Security Policies
Most of our users are adopting service mesh because their security or architecture team requires them to secure microservice communications. Istio made this very easy: A mesh platform team can just apply authentication policy and enable mutual TLS on any services with the matching label. I love this because it means the service owner doesn’t need to do anything other than label their deployment to require all communications to their services with mTLS. You may be thinking you could manage all these yourself without service mesh, but it would be a lot harder to modify your application code and create a homegrown framework to manage the certificate distribution and rotations.
Complexity with Service Mesh
The service mesh data plane is a critical component of your infrastructure, which by nature is complex when you need to deal with cloud native workloads along with legacy workloads on VMs or bare metals. Plus, you may run your workloads across different zones, regions and clouds. A service mesh like Istio is straightforward for pure Kubernetes workloads, but the reality of our users is that they all have different requirements, and many of them still have most of their workloads in non-Kubernetes environments. It is critical for them to have these legacy workloads participating in service mesh as they progress through their cloud native journey. Our users even told us that some of these workloads likely will always stay outside of Kubernetes.
This is where many of the challenges with keeping a service mesh simple come into play. With Istio, we need to make scenarios simple, but also enable complex scenarios.
Using the install process as an example, the Istio project has been criticized for providing too many choices. While installing Istio using istioctl is extremely simple, we have users who don’t want to run istioctl in production as it requires updates to their delivery pipeline, and they have to seek additional approval for it. Some common tools like Helm are already supported in their organization, and it would be much easier for them to leverage these pre-approved tools. Furthermore, some of our users want the control plane to run outside of their clusters so it can be managed separately by a different team, thus the external control plane is another installation method we offer. Because there are so many different use cases and requirements for each company or team, I believe it is better to provide choices and flexibility based on various requirements from users than just offering one simple method of installation using istioctl install.
Istio has also been criticized for its complexity with networking APIs. Complexity was partly caused by the rich features available while providing consistent API for north-south traffic and east-west traffic. Interestingly enough, over the past years, I have found that all these features were requested by users working to solve various challenges. Application-layer networking is complicated, and many scenarios have to be considered from the edge to the east-west traffic, for example:
- What is your host name? Are you terminating or using passthrough for your traffic at the edge?
- What protocols and ports are you using?
- How are you securing your edge?
- How do you want to route traffic to your service?
- How do you increase the resiliency of your service?
- Do you need a failover policy, perhaps based on locality?
What’s Next for Istio?
With a large number of users in production, the Istio project is committed to focus on Day 2 operation of Istio, as we want to ensure our users are successful in running service mesh globally at scale. I am excited to work with our Istio and Gloo Mesh users at Solo.io to help them adopt Istio on a large scale while bringing their requirements to upstream Istio as well.
As part of the effort that focuses on Day 2 operation, we are also standardizing our APIs as they become more mature and provide clear separation of our APIs based on personas. For example, MeshConfig has been a home for many APIs when experimenting with the feature, but as the feature matures, the community is standardizing these APIs into its own custom resources so users can easily configure telemetry or extension or proxy configuration without asking the platform team to modify the global mesh config.
We will continue to graduate our features from less mature stages (experimental or alpha) to mature stages (beta or stable). As every other successful project, we want to keep the house clean and remove features that are not interesting to our users. This is especially true for features that are stuck at experimental or alpha for a very long time. We will continue to make simple scenarios simple, but enable complex scenarios possible for our users.
Experience Istio’s Simplicity Yourself!
If you would like to learn more about Istio or still need to be convinced that it is easy to use, get started with our Istio workshop to experience Istio hands on. (Note: That link is good till end of November and for 500 uses). In this workshop, you can learn how to incrementally adopt Istio from Istio’s ingress gateway to securely expose your services, as well as how to observe the interactions among your services along with various traffic-control scenarios. If you prefer to attend a live workshop, just sign up for one of our upcoming “Get Started with Istio” workshops.
