Interview with Christian Posta: istio 1.7 will be the most stable version available for production


Interview with Christian Posta: istio 1.7 will be the most stable version available for production

By Tian Xiaoxu and Christian Posta

In 2017, after istio released version 0.1, its elegant architecture design was recognized by everyone. With version iteration, developers make complaints about Istio too complicated. Therefore, istio version 1.5 overturned the previous architecture design and proposed the architecture design of “return to monomer”. The release note of version 1.6 even indicated that minimalism should be carried out to the end at the beginning.

The architecture design changes of istio version 1.5 and 1.6 have caused a lot of discussion among developers. Everyone is very concerned about where the simplification of istio architecture will go? What are the surprises of the upcoming version 1.7? What is the progress of the integration of envoy and webassembly In order to answer the above questions, we interviewed Christian Posta, former chief architect of red hat, author of istio in action and field CTO, at the opening of cloud native microservices conference.

Istio is moving towards simplification

Since version 1.5, istio has embarked on the road of simplified architecture. This is because its control surface components have encountered many difficulties in operation and maintenance, such as the division of management responsibilities. The original intention of splitting control components is to separate functional responsibilities, which are managed by different operation and maintenance or developers separately. However, in practical application, the control components are separated, Operation and maintenance is often managed by one person or team, and does not play a role of independent management; Deployment is complex. After component splitting, the difficulty of system operation and maintenance rises sharply, and the increased configuration and parameters increase the complexity of deployment.

Because of these complexities, there are various deployment related issues in GitHub, such as lstio operator, istioctl and so on. Unfortunately, no breakthrough has been made. Istio 1.5 boldly carries out a “self revolution”, which combines all the components of the control plane into a single structure istiod.

Istiod’s original design intention is “how I learned to stop worrying and love the monolith”, and clearly put forward the design objectives at the beginning: reduce the installation complexity, reduce the configuration complexity, increase the operability of control surface, improve the ability of problem diagnosis, improve the efficiency and response speed, and eliminate unnecessary coupling. Istiod is a monomer, which supports all the functions of previous versions. The services that used to form the control plane are still implemented as sub modules (including boundaries and contracts) in the project, but the operation experience is improved.

Istio version 1.6 is actually the end of the unfinished work of version 1.5. The biggest simplification is to fully integrate the functions of the original components into istiod to make istiod more complete, and completely remove citadel, sidecar injector and galley. In addition, istioctl install command is added to replace the installation process of manifest apply, which improves the experience of the installation process with more intuitive and concise commands.

The future development trend of istio

After the iteration of versions 1.5 and 1.6, the architecture simplification of istio has gradually taken shape, but there are still some functions and requirements that have not been realized. For example, after the end of mixer, the centralized current limiting, black and white list and other functions have not yet appeared corresponding compensation measures. Therefore, everyone is full of expectation and curiosity about the 1.7 version of istio. Next, let’s see how Christian Posta interprets the future development trend of istio.

Q: Istio version 1.5 proposes to “return to monomer”, and then version 1.6 proposes to carry out minimalism to the end. How does the community consider the simplification of istio architecture?

Christian Posta: before the release of istio 1.5, I wrote a detailed blog “istio as an example of when not to do microservices” to discuss this issue. In my blog, I discussed the motivation and some shortcomings of building distributed components (microservices) and the motivation of reconstructing istio project. One of the obvious reasons is that the technology dividend of distributed components has not been realized. We need to be very honest about the tradeoffs in the process of system architecture, especially when these tradeoffs can’t make the system get the technical dividend in the end. At this time, it is better to “revise the route”, which is exactly what istio has done.

Q: The release cycle of istio is changed to quarterly release. What new features can be revealed in the new version?

Christian Posta: istio 1.7 will be released soon (beta 2)   Some of the main features of this version are the central istiod controller for multiple clusters, the continuous enhancement of VM support, and the most important improvement in stability.

Q: Many technical personnel in China are very concerned about the strong cooperation between envoy and webassembly. They don’t know what actions and plans the community has now?

Christian PostaYes! Web assembly (wasm) is getting closer and closer to integration into upstream envoy proxy projects, and we have been working hard to improve the development experience using wasm and wasm + envoy. We announced the webassembly hub in December 2019, and made significant improvements to istio 1.5 in March 2020, especially using wasme (webassembly hub CLI) as the official method to extend istio with webassembly. Generally speaking, both wasm and wasm + envoy are cooperating with the community, and there is still a lot to do. Please look forward to it!

Q: Kubernetes was basically stable in version 1.8. Now istio has reached version 1.6. Which version do you expect istio to achieve stability?

Christian Posta: I’ve always been honest about which versions to avoid and which to use. It can be said that in the 1. X series before 1.5, 1.4. X is the most stable. Now, after 1.5, I think the upcoming 1.7 will be a stable version available for production.

Q: How do you see the current global market structure of service mesh? What role does istio play in this pattern?

Christian Posta: the global market of service mesh is still developing rapidly! As early as in November 2018, we predicted that there would be multiple grid implementations, and there would be no obvious winner. This prediction has been realized. There are not only several service grid options on the market, but also cloud vendors are beginning to provide their own service grid implementation. For example, AWS appmesh, Google traffic director and alicloud ASM. Recently, Microsoft introduced open service mesh, which we believe will become a part of Microsoft cloud. We set up a service mesh hub in to help reduce this volatility and diversity and unify various workloads deployed across multiple service grids. In general, we are now seeing more and more organizations adopt open source or vendor provided service grid technology instead of self built. I personally believe that istio will continue to be the leading service grid technology used by organizations for “self-management” service grid, and will continue to develop with the service grid of cloud vendors for a long time.

Introduction of guests

Christian Posta  Former chief architect of red hat, author of istio in action, field CTO. He has been engaged in the development of distributed system in traditional industries such as finance, insurance and retail for nearly 20 years. K8s has been used since kubernetes version 1.0, and has been involved in community work; Before the public release of istio, it was very active in the community. At present, he works as field CTO in, and is fully committed to building the next generation API infrastructure, including API gateway, service grid, web assembly and so on.

The first cloud based micro Service Conference

The first cloud native microservice conference is in a hot live broadcast. Click the PC address to watch:

Alibaba cloud nativeFocus on micro service, Serverless, container, Service Mesh and other technology areas, focusing on cloud native technology trends, cloud native large-scale landing practice, do the best understanding of the official account of cloud developers.

Recommended Today

Implementation example of go operation etcd

etcdIt is an open-source, distributed key value pair data storage system, which provides shared configuration, service registration and discovery. This paper mainly introduces the installation and use of etcd. Etcdetcd introduction etcdIt is an open source and highly available distributed key value storage system developed with go language, which can be used to configure sharing […]