Author | Zhang Lei
Source | Alibaba Cloud Native Official Account
2020 is destined to be extraordinary. It begins in the haze and ends in awe, making the future even more confusing. So, what about container and cloud native 2020? Do you remember how it started? Where will it go?
Kubernetes: The standard abstraction for enterprise infrastructure
In 2020, no one will question the rationality of a platform team adopting Kubernetes as their infrastructure. In fact, the 2020 Kubernetes project has been very close to completing its most important mission, which is to bring a layer of platform abstraction to the cloud computing infrastructure that allows the platform team to construct "everything" based on this .
We have been able to see that today's cloud native community has begun to widely recognize the positioning and value of the Kubernetes project as "The platform for platform", and more and more platform teams are building various upper-level platforms based on Kubernetes, such as PaaS / Serverless / AI Platform / Database PaaS and so on. The final state-oriented declarative API and the "hard-working" controller behind it provide a solution that can strike a balance between complexity and usability for the challenging technical problem of "building infrastructure layer abstraction". It is based on this that the Kubernetes project has a huge integrated ecology, making this "standard abstraction of enterprise infrastructure" gradually become a recognized fact in the industry.
And more importantly, the real success of Kubernetes is that it is really betting on the construction of abstract methods rather than the abstractions themselves. In most cases, companies build upper-layer platforms based on Kubernetes, and will introduce various other abstractions as supplements, and even replace or hide some of the built-in abstractions of Kubernetes : Alibaba's open source CloneSet , Tencent's GameStatefulSet practice and other extended types Workloads and so on are the best examples of this trend.
With the gradual improvement of Kubernetes ecosystem capabilities from the bottom to the application layer, in 2020, more large Internet terminal companies will begin to join the cloud native echelon. We saw that Apple, the original Mesos ecological benchmark, became the absolute protagonist of KubeCon 2020 in North America, and financial giant MasterCard shared their internal landing case of building a cross-cloud and cross-runtime application delivery platform based on OAM, Kubernetes and Crossplane projects. And is particularly worth mentioning is that, in the past, these underlying technology gives a large non-cloud enterprises "conservative" impression, in 2020, they have resorted to many emerging technologies such as Virtual Cluster and standard application of modeling techniques landing on And thinking. The profound impact of the cloud native wave on the entire technology industry is evident.
In addition, it is not difficult to observe that the huge popularity of Kubernetes and the upper-layer ecology based on it are becoming more and more convergent with the development path of Android . Android can abstract and integrate different hardware devices such as mobile phones, TVs, and even cars in a unified way for the next, and expose a unified development interface for programmers to enable them to use this unified abstraction. Access or enjoy these infrastructure capabilities. This positioning is very similar to Kubernetes. The only difference here is that the programmer of the Android service is the APP developer, while the "programmer" of the Kubernetes service is the platform builder. In this context, news such as "Kubernetes abandons Docker" will be easy to understand: Android itself does not need to focus on which brand of mobile phone battery is.
This path may also be a "play" that Google is better at: to promote an "operating system" for free, and the way to truly obtain commercial value is to "harvest" the ecological value of the upper layer of the operating system, not the operating system itself. After all, users will not spend money to buy Android. So Google Cloud is currently all-in, it is through Anthos such as Kubernetes hybrid cloud base, Google Cloud services are delivered to any data center in the world.
Cloud computing "three-tier architecture" being broken
For a long time, the industry's cognition of cloud computing has been around the classic three-tier architecture model of "SaaS + PaaS + IaaS". However, in 2020, with the tremendous popularity of cloud native technology, we have found that this model seems to be facing challenges.
Today’s cloud native technology originated from the innovative technological revolution of Docker and containers, and benefited from the long-lasting popularization of classic PaaS (such as Cloud Foundry). Finally, under the dual attention of developers and platform builders, Kubernetes Ecology as the carrier finally landed.
In 2020, with the gradual maturity of cloud native technologies, the form of user-oriented application management platforms will gradually shift from the classic PaaS form (ie: enterprise PaaS) with Cloud Foundry/Heroku as the main body to the lightweight App Service For example, Shipa and Kalm are moving closer. However, the lightweight App Service is essentially a replica of the Heroku experience on the Kubernetes base. While providing an excellent developer experience, they also inherit the "closed" and "unscalable" of classic PaaS. Large-scale enterprises will still be unable to do what they want with their own "PaaS" demands based on the cloud-native technology stack "DIY".
In fact, for more and more platform builders, as cloud-native technologies are increasingly implemented, the “interpretation power” of “PaaS” no longer belongs to a certain provider, and more depends on the platform builder’s Business scenarios and actual needs of their end users. In addition, for "SaaS", the containerized software packaging and delivery system and the Kubernetes base brought by cloud native have also greatly changed the distribution and operation and maintenance of cloud software. Therefore, whether it is PaaS or SaaS, it is essentially being quickly "flattened" by the "cloud native" technology wave. In this context, the traditional "horizontal" method of dividing the cloud computing system has actually become It is difficult to be self-consistent . A typical example is: today you can neither call Kubernetes PaaS, nor IaaS. It is a unique infrastructure capability access layer and platform layer abstraction. As a platform builder, you can build any upper-layer platform in your mind based on it, and you call this upper-layer platform PaaS / Serverless / FaaS, or even It is SaaS, but the degree of further abstraction is different and the vertical capability it depends on is different: there is no such division as "who is overwhelmed by whom".
The rise of the next generation cloud native platform construction system
The success of Kubernetes has greatly enabled the "platform builder", an important role that people have forgotten in the enterprise cost center (Cost Center). In fact, the reason why Kubernetes can replace the Docker ecosystem as the protagonist on today's cloud computing platform is largely because this group made the final decision. Otherwise, according to the scale of the user group reached by Docker and its acceptance in the developer ecosystem, Kubernetes has almost no chance of winning. This is often overlooked by everyone. In fact, in the process of landing an enterprise-level platform, although the end users of the platform (such as business R&D and operation and maintenance) are "customers and gods", they can really play a key role and have the final decision in this process. It is often the platform team and bosses behind the business.
But at the same time, the platform construction ecosystem on Kubernetes is still highly concentrated today. A typical observation is that the teams that can build a complete upper-level platform based on Kubernetes today are actually concentrated in large-scale first- and second-tier Internet companies, and their practices are often "for reference only" and are rarely reproducible. Furthermore, the great popularity of cloud native does not seem to enable platform builders to easily build PaaS or other upper-layer platforms. This actually further explains the stagnation of the “PaaS ecology” we have observed earlier in the cloud-native era: the construction of upper-layer platforms (including PaaS) based on Kubernetes will still be the patent of large companies and high-tech teams in 2020.
The high concentration of this platform construction ecology is obviously inconsistent with the "inclusive" future that Cloud Native hopes to build. Of course, since technological development has not kept up with the vision, the cloud native community will not stop.
In fact, the fundamental motivation for platform builders to further build upper-layer platforms based on Kubernetes comes from two demands:
- Higher abstraction dimension : For example, the concepts that users want to operate are "application" and "gray release" instead of "container" and "Pod".
- More expansion capabilities : For example, the application gray release strategy that users hope is based on the "dual Deployment + Istio" canary release instead of the Kubernetes default Pod linear rolling upgrade. These enhancements or extensions are generally implemented in the form of plug-ins of CRD + Controller in Kubernetes.
Therefore, building an upper-layer platform based on Kubernetes today seems to be chaotic and irregular, but in essence it will not leave the two core demands of "abstraction + plug-in capability management". To give another example, the various dashboards you build for Kubernetes today are actually an "abstract" implementation: these dashboards essentially expose a set of fields that allow users to fill in on the basis of Kubernetes API objects. The goal of "simplifying the user's mind and improving user experience" is achieved-this is of course the fundamental goal of all "abstraction".
Based on the continuous practice and thinking of the two demands of "abstraction + plug-in capability management", the cloud native community has born in 2020 an open source project like KubeVela that focuses on enabling platform teams to build upper-level platforms. The positioning of this project is very unique in the entire cloud native ecosystem: it is not a certain vertical capability, but more like a set of "tools" based on Kubernetes to build an upper-level platform, such as:
- The template-based abstraction mechanism, and the automated process of using documents and OpenAPI Schema based on this generation capability (to help the platform team quickly build Dashboard or Appfile).
- The plug-in capability registration, management, and discovery mechanism based on the OAM model is used to modularize and automate the management of plug-in capabilities, and even warn of conflicts between plug-in capabilities in advance.
Coincidentally, shortly after Alibaba Cloud open sourced the KubeVela project, the cloud computing leader AWS also announced the official birth of AWS Proton commercial products at Re:Invent 2020. The idea is very similar to the KubeVela project, except that the base of the platform is replaced The AWS cloud platform is used to define abstract templates using AWS' own Cloud Formation (KubeVela currently supports Google's open source CUELang template language).
It is foreseeable that after the cloud-native and Kubernetes projects have greatly unified and standardized the infrastructure layer abstraction, how to further help the platform team build the upper-layer platform quickly, easily and reproducibly on this is becoming the industry's beginning to actively think A critical path. Once again, it is difficult for you to find a suitable position for these products in the traditional "three-tier architecture" of cloud computing. Whether it is KubeVela or AWS Proton, they are neither PaaS nor IaaS, nor are they competitors of Kubernetes: they are The budding of the gradual rise of a new generation of platform construction system under the background of cloud native.
Explore the next stop in cloud native
Cloud native in 2020 can be said to be the fastest-growing main thread in the entire cloud computing ecosystem, and it is with this kind of development momentum that cloud native is already thinking about its next development in the new year. space. In fact, we have been able to see various manufacturers and teams actively working and exploring in different fields.
1. Local development and testing
Enabling developers to conduct local development and testing for Kubernetes is beginning to become a topic of concern. In this field, the Tilt project from New York is one of the leaders. Alibaba Cloud and Tencent Cloud also have different dimensional solutions on this topic, such as KT Connet and Nocalhost .
2. The technological revolution of cloud native "middleware"
The Sidecar model is sinking the capabilities of the middleware field into Kubernetes, a new generation of application infrastructure with a more rapid momentum. In addition to the already in full swing Istio's subversion of the traffic governance field, Microsoft has not to be outdone and open sourced Open Service Mesh as an open source Response. At the same time, Dapr , OAM's sister project at Microsoft, directly aligns the distance between Kubernetes and middleware on the "service discovery and binding" side. Dubbo, an established project, also announced a technical blueprint for the next generation of cloud native middleware . Of course, the user motivation behind all this is very clear: middleware in the cloud-native era should be language-independent and platform-independent.
3. "Edge" and the Kubernetes release
The "Androidization" trend of Kubernetes is indispensable to the "ambition" of deploying Kubernetes to any data center in the world, which of course also includes "edge" devices. In addition to Huawei's flagship product KubeEdge, Alibaba Cloud's OpenYurt project also entered the CNCF sandbox incubation in 2020, and Tencent Cloud proposed SuperEdge to follow. At the same time, AWS heavily open sourced the Kubernetes release EKS-D behind its EKS service in 2020, which of course implies a strong response to Google Cloud's Anthos and Microsoft Cloud's Arc layout. It is foreseeable that the obsession of cloud vendors to "deploy Kubernetes to any corner" will make Kubernetes "Android" faster than imagined, and it will inevitably be a "fishy storm" on the side of ISVs and service integrators. .
4. Cloud native application management and GitOps
Cloud native application management and delivery has already become an important value focus on Kubernetes, the "new Android". In this field, the OAM + OpenKruise combination of Alibaba Cloud and Microsoft has emerged. At the same time, KubeVela has also appeared in the community, such as an open source framework that further enables platform builders. Hashicorp, the leader in the field of developer tools, is not too late. Released a cross-platform developer interface tool like Waypoint. With the rapid evolution of application layer technology on Kubernetes, the concept of delivering applications based on Git as an application configuration management center (ie: GitOps) is rapidly replacing the CD link in traditional CI/CD and becoming an application distribution on Kubernetes The best choice. At the end of 2020, the CNCF application delivery field team officially announced the formation of the GitOps Working Group, which is likely to gradually push GitOps to the de facto standard for cloud-native CDs. Today, when the "Androidization" of Kubernetes is unstoppable, we are full of expectations for more disruptions and innovations in this field in the new year.
2020: Cloud native without "exact definition"
What exactly is "cloud native"? Is it containers and Kubernetes? Are virtual machines cloud native? ...
These "soul tortures" have always been the confusion raised by many companies and teams that are first exposed to the concept of cloud native. In fact, as a set of best practices and methodology for "using cloud computing technology to reduce costs and increase efficiency for users", the term cloud native has been in a constant self since its birth, its growth, and its huge popularity today. In the process of evolution and innovation. This "never defined" continuous vitality is the source of the attraction of "cloud native" to the cloud computing ecology.
In 2020, the active exploration and experimentation of the entire cloud native community in different fields is replacing mature implementation projects such as Kubernetes and Service Mesh, gradually becoming the unique theme of the cloud native ecology. This is not difficult to understand. The development of cloud native to this day is getting closer and closer to its imaginary "software naturally grows on the cloud and grows on the cloud", but it also exposes the existing cloud native technology chassis too much attention. For infrastructure abstraction and management, it ignores the end-user experience and many problems caused by technology. These problems need to rely on the continuous thinking, precipitation, and re-innovation of the entire cloud native community to supplement and correct them, so that the value of cloud native technology can gradually "float" and generate direct value and sense of body for end users; and also make cloud native The gradual "democratization" of technology makes building a simple and easy-to-use cloud-native platform no longer exclusive to big companies to "show their muscles."
Related open source project portal:
About the Author
Zhang Lei, Alibaba Cloud Senior Technical Expert, CNCF SIG App Delivery Co-chair, CNCF Official Ambassador