After Istio 0.1 was released in 2017, its elegant architectural design received extensive recognition. However, with the iteration of versions, some developers complained that Istio was too complex. Against this backdrop, Istio 1.5 discarded the previous architectural design and proposed the approach of "returning to the monolithic." The release notes for Istio 1.6 stated that minimalism is and will be a strategic aim for future Istio versions.
The architectural design changes between Istio 1.5 and 1.6 have led to discussions among many developers. Everyone is wondering about the simplification future of Istio architecture. What would surprise us in the upcoming version 1.7? What is the progress of the much-anticipated integration of Envoy and WebAssembly? To find the answers to these questions, we interviewed Christian Posta before the opening of the cloud-native microservice conference. Christian is the Field CTO at Solo.io, the former Chief Architect of Red Hat, and the author of Istio in Action.
Since version 1.5, Istio has embarked on the road of architecture simplification. This is because the control plane components of Istio have encountered many difficulties in operations and maintenance (O&M). The original intention of separating control components from other components was to separate functional responsibilities, so they could be managed by different O&M personnel or developers. However, in practical applications, O&M is often done by one person or team, rendering no need for separate management. In addition, after control components are separated from other components, O&M difficulty soars and additional configurations and parameters increase the complexity of deployment.
For these reasons, various deployment-related issues occurred in GitHub, for example, in lstio operator and Istioctl. Little breakthrough has been made in resolving these issues. In this context, Istio 1.5 carried out a "self-revolution" by combining all components of the control plane into a single Istiod compound.
Istiod was designed to address the issue of "How I Learned to Stop Worrying and Love the Monolith." Its design goals were clear from the very beginning, including reducing installation and configuration complexities, enhancing the O&M of the control plane, improving problem diagnosis, increasing efficiency and responsiveness, and eliminating unnecessary coupling. Istiod is a monolith that supports all functions of previous versions. The services that previously composed the control plane are implemented as submodules in projects (including boundaries and contracts), but the operation experience has improved.
Istio 1.6 is a complement to Istio 1.5. The most prominent simplification is to fully integrate the functions of the original components into Istiod, making Istiod more complete and removing Citadel, Sidecar Injector, and Galley. In addition, the istioctl install command has been added to replace the installation process of manifest apply, which delivers a better installation experience through more intuitive and streamlined commands.
With the emergence of versions 1.5 and 1.6, the architectural simplification of Istio has gradually taken shape, but some functions and requirements are yet to be fulfilled. For example, after the Mixer processing, no compensation measures are in place for centralized throttling, blacklisting and whitelisting, and some other functions. Therefore, everyone is looking at Istio 1.7 to achieve this. Next, let's see what Christian Posta thought about the future development trends of Istio.
Q: Istio 1.5 proposed to "return to the monolithic," and Istio 1.6 proposed to carry out minimalism to the end. What does the community think of the simplification of the Istio architecture?
Christian Posta: Before the release of Istio 1.5, I wrote a long blog named "Istio as an Example of When Not to Do Microservices" to discuss this issue. In my blog, I explained the motivation and some shortcomings of building distributed components (microservices) and explored the intention of re-architecting the Istio project. One of the most obvious reasons is that the technical benefits of distributed components have not been realized. We need to honestly evaluate the tradeoffs during the system architecting process, especially when the tradeoffs fail to benefit the system. In this case, it is best to "correct the route," which is exactly what Istio does.
Q: Now, the Istio release cycle has been changed to a quarterly release. What new features will we see in the latest version?
Christian Posta: Istio 1.7 will be released soon (Beta 2 will be released on August 12, 2020.) The major functions of this version include the central Istiod controller for multiple clusters, the continuous enhancements of VM support, and most importantly, the improvement in stability.
Q: Many technicians in China are concerned about the partnership between Envoy and WebAssembly. What actions and plans have the community put forward?
Christian Posta: Yes! WebAssembly (WASM) is about to be integrated with the upstream Envoy Proxy project. In fact, we have been working hard to improve our development experience with WASM and WASM+Envoy. We announced the WebAssembly Hub in December 2019 and made major improvements to Istio 1.5 in March 2020. We use wasme (the WebAssembly Hub CLI) as the official method of extending Istio with WebAssembly. In general, both WASM and WASM+Envoy are working with the community, and we still have a lot to do, so stay tuned!
Q: Kubernetes became basically stable when it came to version 1.8. Now, Istio 1.6 is available. Which version do you think will be the stable Istio version?
Christian Posta: I have always been honest about which versions to avoid and which versions to adopt. Now, I can say that among the earlier 1.x versions than 1.5, 1.4.x are the most stable ones. After 1.5, I think the upcoming 1.7 will be the most stable version.
Q: What you think about the current global market pattern for Service Mesh? What is the role of Istio in this market pattern?
Christian Posta: The global market for Service Mesh is still growing fast! Way back in November 2018, we predicted that Solo.io would have several service mesh implementations and they would be basically equal in quality. Now, this prediction has come true. In addition to the service mesh options on the market, cloud vendors are rolling out their own service mesh implementations, for example, AWS AppMesh, Google Traffic Director, and Alibaba Cloud ASM. Just recently, Microsoft introduced Open Service Mesh, and we believe it will be part of Microsoft Cloud. We have established Service Mesh Hub at Solo.io to help mitigate this volatility and diversity to unify various workloads deployed across service meshes.
Generally, more and more organizations are adopting open-source or vendor-provided service mesh technologies rather than on their own. In my opinion, Istio will still be the leading service mesh technology for self-managed service meshes and will continue to evolve along with cloud vendors' service meshes.
Christian is the field CTO at Solo.io, the former Chief Architect of Red Hat, and the author of Istio in Action. He has been engaged in the development of distributed systems in traditional industries, such as finance, insurance, and retail for almost 20 years. He has been using Kubernetes since Kubernetes 1.0 and has been participating in the community. Before the public release of Istio, he has been very active in the community. Currently, he works as the Field CTO at Solo.io and is committed to building the next-generation API infrastructure, including API Gateway, Service Mesh, and WebAssembly.
508 posts | 48 followers
FollowAlibaba Cloud Native - May 23, 2022
Alibaba Cloud Community - July 29, 2024
feuyeux - May 8, 2021
Xi Ning Wang - March 7, 2019
Alibaba Container Service - October 12, 2024
Alibaba Cloud Project Hub - November 15, 2021
508 posts | 48 followers
Follow
Cloud-Native Applications Management Solution
Accelerate and secure the development, deployment, and management of containerized applications cost-effectively.
Learn More
Container Service for Kubernetes
Alibaba Cloud Container Service for Kubernetes is a fully managed cloud container management service that supports native Kubernetes and integrates with other Alibaba Cloud products.
Learn More
ACK One
Provides a control plane to allow users to manage Kubernetes clusters that run based on different infrastructure resources
Learn More
Microservices Engine (MSE)
MSE provides a fully managed registration and configuration center, and gateway and microservices governance capabilities.
Learn MoreMore Posts by Alibaba Cloud Native Community
