Introduction: In 2022, KubeVela has officially entered the fourth stage, and on the basis of the basic stability of the original core controller API, we have added a series of out-of-the-box functions in the form of plug-ins. Allows developers to connect to the complete CI/CD process through the UI console and publish multi-cluster applications end-to-end, further improving the developer experience.

Author: KubeVela Community

As cloud-natives continue to evolve and mature, more and more infrastructure capabilities are being standardized into PaaS platforms or SaaS-based offerings. The birth of a product no longer requires the establishment of a team as in the past, from development and testing to operation and maintenance, infrastructure and other parts of the system to complete. Today, agile organizational culture and cloud-native technology drive these responsibilities more "left" to developers, testing left, monitoring left, security left shift, devOps and a series of concepts are emphasized, through open source projects or cloud products and services to test, monitoring, security, operation and maintenance and a series of transactions ahead of the development stage. This seemingly beautiful vision brings great challenges to developers, who lack control over the various products and complex APIs at the bottom, they are not only making choices, but also need to understand and coordinate the complex and heterogeneous infrastructure capabilities at the bottom to meet the rapid development and iteration needs of the upper business.

This complexity and uncertainty undoubtedly greatly reduces the developer experience, reduces the delivery efficiency of business systems, and increases operational risks. The core of the developer experience is "simple" and "efficient", and both developers and enterprises need better developer tools or platforms to achieve. Building an all-in-one platform that helps developers develop, deliver, and continue to operate on top of modern cloud-native technologies has been a core goal of KubeVela's evolution. As shown in Figure 1, in the v1.2 version, we have added a UI console component (VelaUX) around the developer experience, simplifying the complexity of arranging YAML, improving the construction of the plug-in system, enriching the scalability of cloud resources, adding a large number of CI/CD and other ecological docking capabilities, and further improving the end-to-end user experience of developers.

KubeVela v1.2 released: The graphical operations console velaUX you want is finally here

Figure 1: KubeVela architecture design

History review

Let's briefly review the development stages and history of OAM and KubeVela:

OAM (Open Application Model) was born and grew

To create simplicity in a complex world, the first problem we need to solve is abstraction and standardization. Alibaba Cloud and Microsoft jointly launched the OAM model, innovatively proposing the concept of "separation of concerns", with developers focusing on the business itself and O&M focusing on modular capabilities. The OAM model revolves around the idea of "everything is service, full modularity", providing a standard practice that combines ease of use and high scalability for major vendors and cloud-native platform builders to implement their own application management platforms. In just one year after the model was proposed, it was responded to by major manufacturers at home and abroad, including AWS, Oracle, Tencent, and Huawei, and was approved by the National Academy of Information and Communications Technology as an industry standard. Because we all share a common goal, we will lower the threshold for cloud-native use and make application delivery and management easier.

The KubeVela open source project v1.0 was released, bringing a standard implementation of OAM to the community

With the OAM model as a practical guide, the community advanced players have also begun to create their own tools to practice, including Ali, Microsoft, Oracle, Upbond, Tencent and a series of other companies have built their own business platforms based on OAM guidance. But for the wider group of developers and SMEs, they couldn't directly enjoy the dividends of the model, so KubeVela was born as the official implementation engine of the OAM community. It was built from scratch to one from the beginning by 7 members of the OAM community from different organizations. The kubeVela implementation draws on the practical experience of OAM from many companies, and combines the advantages of the Kubernetes community ecosystem to achieve an automated, convergible, idempotent, and stable application release controller, constructing a user-friendly abstraction layer around IaC (Infrastructure is Configuration), helping developers implement an OAM implementation engine based out of the box.

KubeVela v1.1 was released to implement application delivery workflows and natively support multi-cluster application delivery in hybrid environments

With the advancement of enterprises to the cloud, diversified infrastructure such as hybrid cloud and distributed cloud has gradually become the norm. KubeVela, as a modern application management system, also conforms to the trend, and the overall architecture is upgraded to a control plane for application delivery and management in a hybrid environment, and all functions are naturally built on the multi-cluster technology. We believe that due to high availability, cost performance, data security and other factors, most of the future enterprise application forms will be heterogeneous and diverse. The release of KubeVela v1.1 also implements a highly scalable application release workflow, which is naturally presented in a hybrid environment architecture, innovatively implements a working mode that combines delivery workflow and application abstraction, realizes a final-state application delivery workflow, and greatly simplifies the complexity of process orchestration.

Fast forward to 2022, KubeVela has officially entered the fourth phase, on the basis of the original core controller API is basically stable, we have added a series of out-of-the-box functions in the form of plug-ins. Allows developers to connect to the complete CI/CD process through the UI console and publish multi-cluster applications end-to-end, further improving the developer experience.

Core capabilities of version v1.2

Graphical Operations Console (VelaUX)

Providing a user-friendly graphical interface is the preferred way to lower the barrier to entry for developers, and since the birth of KubeVela, the community has been very vocal about the UI console. Starting with the v1.2 release, it's officially here. The UI console was built to help developers assemble and manage heterogeneous business applications in a more standardized way, helping them analyze and identify business failures and obstacles faster.

VelaUX[1] is a front-end project for KubeVela, designed and implemented with KubeVela's scalability in mind. Introducing the concept of a low-code platform to build a front-end, our goal is to build a platform that can customize the input parameters of the application delivery by dragging and dropping, and realize the observability of operational data. To this end, we have designed the front-end description specification (UISchema[2]), which, in conjunction with KubeVela's modular definition (X-Definition[3]), can be configured to render a rich set of front-end interaction elements. In order to configure the front-end data query, we designed a multidimensional data custom query language (VelaQL[4]), which forms the basis for KubeVela to deliver and manage heterogeneous applications.

Currently, with VelaUX, users can manage extensions, connect Kubernetes clusters, assign delivery targets, plan environments and deliver various types of applications, and observe application health to achieve a complete closed loop of application delivery.

Figure 2: VelaUX preview

As shown in Figure 2, some new terms have emerged in VelaUX, please refer to the core concept [5] documentation to learn and understand.

Unified management of multiple environments

KubeVela unifies N Kubernetes clusters, N cloud vendor services, or other private cloud services into large pools of infrastructure resources. On this basis, our developers can divide the environment according to various business dimensions such as business requirements, process requirements, and team needs. Form an environmental space on the basis of a large resource pool. The same app can be published to different environments, which are completely isolated from management to runtime.

Figure 3: Multi-environment/multi-cluster application management page

As figure 3 shows, applications can be published to three environments: production, test, and default, each of which can include multiple delivery targets, each of which can be a separate Kubernetes cluster.

Standardized delivery of heterogeneous applications

In a cloud-native architecture, we have a lot of options for delivering applications. Based on the Kubernetes infrastructure, we can deliver middleware and third-party open source applications through the mature Helm Chart package, enterprise business applications through images, and management edge applications through OpenYurt. Based on the open capabilities of cloud service providers, we can deliver middleware such as databases, messages, and caches, as well as O&M capabilities such as logs and application monitoring.

For so many options, KubeVela uses standard OAM specifications for unified delivery and management of heterogeneous applications. KubeVela implements a highly scalable delivery system that helps users scale the platform with built-in, community sharing, and more to handle heterogeneous applications with a consistent delivery and management experience. On top of KubeVela, developers see a modular, all-in-service management.

Figure 4: The Cloud Service Application Management page

As shown in Figure 4, we can see that the same application management page makes it very convenient for users to get to cloud service applications. Developers can view the delivery process of heterogeneous applications by reading the following documents:

Delivering Docker images[6]
Delivery of the Helm Chart package[7]
Delivering Kubernetes resources[8]
Delivery Cloud Services[9]

Extended System (Addon)

KubeVela was designed from the beginning as a microkernel highly scalable system, and as we said above for heterogeneous applications, KubeVela can expand unlimited application delivery capabilities by extending the system in a standardized form. It not only matches the different demands of enterprises, but also does not bring too much cognitive burden. Extensible points in KubeVela include component types, operational capabilities, workflow types, application delivery strategies, and more. In the current release, we released the Addon extension system. Addon is the bearer of an organization's various scaling capabilities, which is easy to distribute and manage.

Figure 5: KubeVela plugin administration page

Addon is currently available in the official repository, as shown in Figure 5. At the same time, in the experimental warehouse, we are actively creating more scalable capabilities with community users. Of course, this requires the active participation of every community developer.

Up to now, KubeVela has grown into an application delivery platform that can directly serve the majority of developers, so which scenarios can enterprises directly take advantage of KubeVela? We've put together a few common scenarios:

Enterprise development scenario solutions

Multi-cluster application DevOps

In past community exchanges, we found that the mainstream R&D system of enterprises is similar to the structure shown in Figure 6, and they use the computing resources provided by cloud service providers as production and demonstration environments. Use a server you purchased or left over from your history to build a development and test environment. If your business has multiple regions or disaster recovery needs, your production environment may need to be deployed to multiple regions or multiple clouds.

Figure 6: Multi-cluster application practice architecture

For the basic DevOps process, both code hosting and CI/CD are included. KubeVela currently provides you with CD support. The steps for enterprise practice are as follows:

Prepare on-premises or cloud service resources according to the actual situation. At least a single item opens up the network of local and cloud resources, which is convenient for centralized management of resources.
Build your KubeVela system into production for continuous availability.
Deploy DevOps tools like Gitlab, Jenkins, Sonar, and more with KubeVela and connect toolchains. Typically, the availability of code hosting and development tools is critical, and we need to deploy them in a production environment (if you have production availability in your on-premises machine room and you want code data to flow around in your on-premises environment, you can deploy it in your on-premises machine room).
Plan your on-premises development environment, deploy on-premises test middleware, plan your production environment and deploy cloud service middleware with KubeVela.
Through Jenkins, the business code CI pipeline is built, and the Output Docker image is distributed to KubeVela for multi-environment deployment, forming a complete application delivery workflow.

Combining KubeVela's multi-cluster application DevOps solution has the following advantages:

(1) Developers do not need to master too much Knowledge of Kubernetes ecology to achieve cloud-native deployment of heterogeneous applications.

(2) Multi-cluster, multi-environment unified management, native can deploy cross-cluster applications.

(3) Unified application management model, whether it is business applications or development toolchains.

(4) Flexible workflow to help enterprises open up various development specification processes.

Integrated management of hybrid environments

Different enterprises often have different infrastructure and business requirements. On the infrastructure side: Enterprises may have built private clouds, may have purchased public clouds, and may also have edge computing resources. On the business side: different business scales, different resource requirements, there may be multi-cloud multi-activity applications, there are also enterprise legacy systems. On the R&D side: Business R&D often requires development, testing, pre-release, and production environments. On the management side: Different business teams need to be isolated from each other, and may need to communicate with each other.

With the accumulation of time, due to the influence of responsibility boundaries and different divisions of labor, enterprises will gradually form a state in which different business teams are independent or even separated from each other, which includes: the separation of development tools, the separation of technical architecture, and the separation of business management forms. KubeVela adheres to the principle of "respecting reality and actively innovating", and brings a solution that is to use highly scalable capabilities to accommodate differences in the pursuit of unity.

In the face of infrastructure differences, we support full modeling of infrastructure in the form of Kubernetes APIs, cloud service APIs, or other custom APIs. The final exposure of consistent concepts is upwards through a unified OAM model.
In the face of business architecture differences, the application model is open and there is no requirement for the architecture. What KubeVela does is connect and empower, connect existing systems, and add new ecological technologies through expansion mechanisms.
In the face of differences in development tool chains, there may already be different development tool chains in enterprises, producing different business products. KubeVela supports a wide range of artifacts through extensions and standard models to standardize their delivery. Of course, its standards are gradually derived to the pre-link, helping enterprises to gradually achieve tool chain consistency. So you don't have to worry about whether you're using Gitlab or Jenkins, it can dock.
In the face of differences in O&M capabilities, the O&M capabilities and tool solutions of different teams in the enterprise can be gradually accumulated under the specifications of KubeVela, and the capabilities can be interconnected. More operational capabilities are also shared and reused in the context of the community.

Therefore, using KubeVela as a basic platform for enterprises to open up business and carry out unified capacity building is a solution that can be implemented and has a future.

Customize the enterprise publishing platform

Since the heroku and Cloud Foundry era, different PaaS platforms have been produced on the market, and we all know that fixed-mode publishing platforms are often not suitable for all enterprises. For example, some enterprises with a high degree of normalization, based on the characteristics of the business, only need to update the image name when publishing the application, but using the general PaaS has to understand a large number of concepts and parameters. For example, a company produces AI applications, and the release of AI applications is relatively different from ordinary applications, so it is necessary to customize the PaaS of AI scenarios, and enterprises have to pay more and learn more concepts.

When the general product does not meet the needs of the enterprise, self-research is a real demand. However, for the self-developed platform from scratch, it is inevitable to invest a lot of manpower and material resources, even exceeding the investment in the core business of the enterprise, which is not worth the loss. KubeVela also takes into account the unique requirements of enterprises with self-research capabilities, which can create their own, more simple and easy-to-use business platform based on KubeVela microkernel, highly scalable design, and their own business scenarios and domain knowledge.

For businesses that need to develop their own platform, KubeVela's microkernel is a Framework for Developing a PaaS Platform. On the one hand, enterprises can develop their own or install various functional plug-ins in the community according to their own needs; on the other hand, enterprises can also modify the modular configuration based on the OAM model and add or crop the parameters used by users. This modular design can greatly reduce the input cost of enterprises, while keeping up with the development trend of the community, at any time to transform more advanced technology of the community into its own productivity.

Participate in the community

With so much introduction, do you have some new understanding of the development of KubeVela, no product is an absolute silver bullet, and there is no one solution that can solve all the problems. But our ideal is to create a standardized model that allows more businesses and developer users to participate in this battle for the "simple" and "efficient" developer experience. KubeVela is still very young, and we hope you can get involved in building it together. Many thanks to the more than 100 developers who have contributed to KubeVela in the past,[10] and it is your joint efforts that have made our community ecosystem more prosperous.

Jointly build an OAM application specification

For the OAM application specification, the update and upgrade of the model is based on the KubeVela practice-driven, but it is not tied to the KubeVela implementation. It is a summary and abstraction of KubeVela's practical experience at the cloud-native application delivery and management level, and is the best practice and core concept for creating a standardized application management system. We are very welcome for cloud vendors, platform vendors, and end users to participate, and we are pleased to see the attention and support of many domestic vendors, including Tencent, for OAM application specifications. Anyone or organization can post your thoughts, suggestions, and reflections.

Participate in the OAM Model Discussion:

Build an Addon expansion ecosystem

As mentioned above, we have started Addon's extension system, and we are very welcome to add more extension capabilities from creators and developers in the community.

How to extend and contribute to the Addon reference documentation:

Contribute to cloud service capabilities

KubeVela expands its cloud service integration capabilities by integrating Terraform Module, we have supported commonly used cloud resources[11], and welcome community friends to refer to and contribute more cloud service vendors and products.

How to extend and contribute to cloud resources Reference documentation:

Feedback on your needs or pain points

Maybe you're a regular developer, or maybe you're a cloud-native practitioner, and if you recognize our direction and what we're doing, we'd love to include you in the KubeVela community discussion.

Community Discussion:

Accelerated access to the KubeVela website

KubeVela's official documentation is hosted on GitHub(s), so if you find any mistakes or want to participate in the translation, you are welcome to contribute directly to the project. At the same time, in order to accelerate the access of domestic users, we have added kubevela.net this domain name, which can facilitate faster access by domestic users, and the content is completely consistent with the domain name of the kubevela.io and synchronized in real time.

KubeVela is a CNCF sandbox project, for more information, please click here to view the official documentation.

KubeVela v1.2 released: The graphical operations console velaUX you want is finally here

History review

Core capabilities of version v1.2

Enterprise development scenario solutions

Read on