Summary: In 2022, KubeVela has officially entered its fourth phase, adding a series of out-of-the-box features in the form of plug-ins to the core controller API that was basically stable. Developers can connect the complete CI/CD process through the UI console, release multiple cluster applications end-to-end, and further improve the developer experience.
Author: KubeVela Community
As cloud native continues to evolve and mature, more and more infrastructure capabilities are being standardized into PaaS platforms or SaaS offerings. The birth of a product no longer needs to establish a team as in the past, from development, testing to operation and maintenance, infrastructure, all parts of the multi-role system. Today, agile organization culture and cloud native technology-driven, makes the job is more of the “left” to developers, test left, monitoring left, security shift to the left, and the conversation, and a series of ideas are stressed, through open source projects or cloud products and services will be testing, monitoring, safety, operations and a series of transaction in advance into the development phase is complete. This seemingly beautiful vision brings great challenges to developers. Developers 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, so as to meet the rapid development and iteration requirements of the upper business.
This complexity and uncertainty significantly reduces the developer experience, reduces the delivery efficiency of business systems, and increases operational and maintenance risks. The core of the developer experience is “simplicity” and “efficiency”, and both developers and enterprises need better developer tools or platforms to achieve this. The core goal of KubeVela’s evolution has been to build an integrated platform to help developers from development, delivery and continuous operation on top of modern cloud native technology. As shown in Figure 1, in V1.2, we added UI console component (VelaUX) to focus on developer experience, simplified the complexity of programming YAML, improved plug-in system construction, enriched the expansion ability of cloud resources, and increased a large number of ecological docking capabilities such as CI/CD. Further improve the developers end-to-end use experience.
Review of development History
Let’s briefly review the development stages and process 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. Ali Cloud and Microsoft jointly launched the OAM model, innovatively proposing the concept of “separation of concerns”, with developers focusing on business itself and operation and maintenance focusing on modularity. OAM model around the idea of “all services, comprehensive modularization”, for major manufacturers and cloud native platform builders to implement their own application management platform to provide easy to use and highly extensible standard practice. Within one year after the model was put forward, it received responses from major manufacturers at home and abroad, including AWS, Oracle, Tencent and Huawei, and was approved by the National Information and Communications Institute as an industry standard. There is a common goal to lower the barriers to cloud native adoption and make application delivery and management easier.
- 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 of advanced players also began to create their own tools to practice, including Alibaba, Microsoft, Oracle, Upbond, Tencent and a series of companies have built their business platforms based on THE OAM guidance. However, for the wider community of developers and small and medium enterprises, who could not directly benefit from the benefits of the model, KubeVela was born as the official implementation engine for the OAM community. It was built from scratch by seven OAM community members from different organizations. The implementation of KubeVela has absorbed the practical experience of many companies for OAM, and combined with the ecological advantages of Kubernetes community, it has realized the automation, convergences, idempotence and stable application distribution controller, and constructed a user-friendly abstraction layer around IaC (Infrastructure as Configuration). Help developers to realize the OAM implementation engine based on open box.
- KubeVela V1.1 release, implementation of application delivery workflow, native support mixed environment multi-cluster application delivery
With the advancement of cloud in enterprises, diversified infrastructures such as hybrid cloud and distributed cloud have gradually become the norm. As a modern application management system, KubeVela also conforms to the trend. The overall architecture is upgraded to the control plane for application delivery and management in a mixed environment, and all functions are built on the multi-cluster technology naturally. We believe that due to high availability, cost performance, data security, and many other factors, the future of most enterprise applications will be heterogeneous and diverse. KubeVela V1.1 version of the release, but also to achieve a highly extensible application release workflow, it naturally presented in a mixed environment architecture, innovative implementation of the delivery workflow and application abstraction combined with the working mode, the realization of the final state of application delivery workflow, greatly simplifies the complexity of the process layout.
By 2022, KubeVela was officially in its fourth phase, adding a series of out-of-the-box features in the form of plug-ins to the core controller API that was basically stable. Developers can connect the complete CI/CD process through the UI console, release multiple cluster applications end-to-end, and further improve the developer experience.
Core capabilities in V1.2
Graphical Operation Console (VelaUX)
Providing a good graphical interface is the number one way to lower the barriers to use, and the community has been clamoring for the UI console since KubeVela was born. With v1.2, it’s officially here. The purpose of the UI console is to help developers assemble and manage heterogeneous business applications in a more standardized way, and help them analyze and find business failures and obstacles faster.
VelaUX**[1]** is the front-end project of KubeVela, and it fully considers the core point of KubeVela’s scalability when it is designed and implemented. Introducing the concept of a low-code platform to build the front end, our goal was to create a platform that could be used to customize the application delivery input parameters with a drag and drop approach and make the operational data observable. Therefore, we design a front-end description specification (UISchema**[2]), and with KubeVela’s modular X-definition [3], rich front-end interaction elements can be rendered through configuration. At the same time, we designed multidimensional data custom query language (VelaQL[4]**) in order to configure the front-end data query, which forms the basis for KubeVela to deliver and manage heterogeneous applications.
With VelaUX, users can now manage extensions, connect to Kubernetes clusters, assign delivery goals, plan environments and deliver various types of applications, and observe application performance to achieve a complete loop of application delivery.
As shown in Figure 2, some new terms appear in VelaUX, please refer to the core concept **[5]** document for learning and understanding.
Unified management of multiple environments
KubeVela consolidates N Kubernetes clusters, N cloud vendor services or other private cloud services into a large infrastructure resource pool. From there, our developers can divide the environment according to business needs, process needs, team needs, and many other business dimensions. The environment space is formed on the basis of large resource pool. The same application can be published to different environments, which are completely isolated from each other from management to running state.
As shown in Figure 3, applications can be published to production, test, and default environments, and each environment can contain multiple delivery goals, each with a separate Kubernetes cluster behind it.
Standardized delivery of heterogeneous applications
In cloud native, we have a lot of options for how we can deliver 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 mirroring, and management edge applications through OpenYurt. Based on the open capabilities of cloud service providers, we can deliver middleware such as database, message and cache, as well as operation and maintenance capabilities such as logging and application monitoring.
With so many options, KubeVela uses the standard OAM specification for unified delivery and management of heterogeneous applications. KubeVela implements a highly extensible delivery system that helps users extend the platform through built-in, community sharing and other forms to handle heterogeneous applications with a consistent delivery and management experience. On Top of KubeVela, developers see a modular, service-oriented management model.
As shown in Figure 4, we can see that users can easily obtain cloud service applications from the same application management page. Developers can view the delivery process of heterogeneous applications by reading the following documents:
- Deliver Docker image **[6]**
- Delivery of Helm Chart package **[7]**
- Deliver Kubernetes resources **[8]**
- Delivering cloud services **[9]**
Extended Architecture (Addon)
KubeVela has been designed as a microkernel system with high scalability from the very beginning. As mentioned above, when it comes to heterogeneous applications, KubeVela can extend the system to a standardized form to expand unlimited application delivery capabilities. 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, operations capabilities, workflow types, application delivery strategies, and more. In the current release, we have released the Addon extension architecture. Addon is the carrier of the organization’s extensibility capabilities, which are easy to distribute and manage.
Currently, the available Addon as shown in Figure 5 already exists in the official warehouse. At the same time in the pilot warehouse we are actively working with the community to create more extended capabilities. Of course, this requires the active participation of every community developer.
So far, KubeVela has grown into an application delivery platform that can be directly used by developers. What scenarios can companies use KubeVela for? We’ve rounded up the following common scenarios:
Enterprise development scenario solutions
Multiple cluster application DevOps
In the past community communication, we found that the mainstream R&D systems of enterprises are similar to the structure shown in FIG. 6. They use computing resources provided by cloud service manufacturers as the production and demonstration environment. Build the development and test environment with the servers purchased or left over from the past. If the service has multiple regions or Dr Requirements, the production environment may need to be deployed in multiple regions or cloudy.
The basic DevOps process includes code hosting and CI/CD. KubeVela currently provides you with CD support. The steps for enterprise practice are as follows:
-
Prepare local or cloud service resources as required. At least one network can be connected to local and cloud resources for centralized resource management.
-
Set up the KubeVela system in a production environment for continuous availability.
-
Deploy Gitlab, Jenkins, Sonar and other DevOps tools via KubeVela and get through the tool chain. In general, the availability of code hosting and development tools is critical, and we need to deploy them in production (if you have production availability in your local machine room and want code data to flow in your local environment, you can deploy them in your local machine room).
-
Use KubeVela to plan the local development environment, deploy the local test middleware, plan the production environment and deploy the cloud service middleware.
-
Jenkins built the CI pipeline of business code, and the output Docker image was sent to KubeVela for multi-environment deployment, forming a complete application delivery workflow.
The multi-cluster application DevOps scheme combined with KubeVela has the following advantages:
(1) Developers do not need to master too much Kubernetes ecological knowledge, and can realize the cloud native deployment of heterogeneous applications.
(2) Multi-cluster, multi-environment unified management, native deployment of cross-cluster applications.
(3) Unified application management mode, no matter business application or development tool chain.
(4) Flexible workflow, to help enterprises get through a variety of development specifications process.
Integrated management of mixed environment
Different companies often have different infrastructure and business needs. On the infrastructure side: The enterprise may have built a private cloud, may have purchased a public cloud, and may have edge computing resources. On the business side: Different businesses have different scales and resource requirements. There may be multi-cloud and multi-active applications or 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 service teams need to be isolated from each other and may need to communicate with each other.
With the accumulation of time, different business teams will gradually become independent or even separated from each other due to the influence of responsibility boundaries and different division of labor. Such separation includes: separation of development tools, separation of technical architecture and separation of business management form. KubeVela adheres to the principle of “respecting reality and actively innovating”, bringing solutions that are compatible with differences with high expansion capabilities in the process of pursuing unity.
- In the face of infrastructure differences, we support adequate modeling of infrastructure in the form of Kubernetes apis, cloud service apis, or other custom apis. Finally, consistent concepts are exposed upward through a unified OAM model.
- Application models are open to business architecture differences and have no architectural requirements. What KubeVela does is connect and empower, connect existing systems, and support new ecological technologies through extension mechanisms.
- Faced with the differences of development tool chains, there may already be different development tool chains in the enterprise, producing different business products. KubeVela implements standardized delivery of artifacts through extensions and standard models. Of course, its standards are gradually derived from the front step, to help enterprises gradually realize the consistency of the tool chain. So, you don’t have to worry about whether you’re using a Gitlab or a Jenkins, it’s docked.
- In the face of the differences in operation and maintenance capabilities, the operation and maintenance capabilities and tool solutions of different teams in the enterprise can be gradually accumulated under KubeVela’s specifications, and the capabilities can be interconnected. More operations and maintenance capabilities are also shared and reused at the community level.
Therefore, using KubeVela as the basic platform for enterprises to get through business and carry out unified capacity building is a practical and promising solution.
Custom enterprise publishing platform
There have been different PaaS platforms since the days of Heroku and Cloud Foundry, and we all know that a fixed distribution platform is not suitable for every enterprise. For example, some highly standardized enterprises can release applications based on the characteristics of the business and only need to update the image name, while using common PaaS they have to understand a lot of concepts and parameters. Another example is that an enterprise produces AI applications, and the release of AI applications is quite different from that of ordinary applications. In this case, it needs to customize PaaS for AI scenarios, and the enterprise has to pay more fees and learn more concepts.
When general products do not meet the needs of enterprises, self-research is a real demand. However, for the research platform from scratch, it is necessary to invest a lot of manpower and material resources, even more than the investment of the core business of the enterprise, which seems to outweigh the gain and loss. KubeVela also takes into account the unique appeal of enterprises with self-development capabilities. They can build their own easy-to-use business platform based on the KubeVela microkernel and highly extensible design, according to their own business scenarios and domain knowledge.
KubeVela’s microkernel is a PaaS platform development framework for enterprises that need to develop their own publishing platforms. On the one hand, enterprises can develop or install various functional plug-ins of the community according to their own needs; On the other hand, enterprises can modify the modular configuration based on the OAM model, adding or tailoring 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, more advanced technology into their own productivity at any time.
Participate in the community
With all this introduction, have you gained some new insight into the development of KubeVela? No product is an absolute silver bullet, and no one solution can solve all problems. But our vision is to create a standardised model that allows more enterprise and developer users to participate in the battle for an “easy” and “efficient” developer experience. KubeVela is still young and we want you to join us. We would like to thank the 100 + developers [10] who have contributed to KubeVela in the past for making our community more prosperous.
Jointly build OAM application specification
For the OAM application specification, model updates and upgrades are based on the KubeVela practice driver, but it is not bound to the KubeVela implementation. It is the summary and abstraction of KubeVela’s practical experience in cloud native application delivery and management, and is the best practice and core concept of creating a standardized application management system. We welcome cloud manufacturers, platform manufacturers and end users to participate in the process, and we are also pleased to see the attention and support of many domestic manufacturers, including Tencent, on OAM application specifications. Anyone and any organization can post your thoughts, suggestions and thoughts.
Participate in OAM model discussion:
Github.com/oam-dev/spe…
Co-build Addon to expand ecology
As mentioned above, we have started the Addon extension system, and we welcome community creators and developers to contribute more extension capabilities.
How to extend and contribute to Addon Reference documentation:
Kubevela.net/zh/docs/pla…
Contribute cloud service capabilities
KubeVela extends cloud service integration capabilities by integrating Terraform Module. We already support common cloud resources **[11]**. We welcome community friends to refer to and contribute more cloud service vendors and products.
How to extend and contribute cloud resources Reference documentation:
Kubevela.net/zh/docs/pla…
Feedback your needs or pain points
Maybe you’re a casual developer, maybe you’re in the cloud native space, and if you believe in where we’re going and what we’re doing, we welcome you to participate in the KubeVela community discussion.
Community discussion:
Github.com/oam-dev/kub…
KubeVela website to speed up access
KubeVela’s official documentation is hosted on GitHub (
Github.com/oam-dev/kub…
), if you find any mistakes or want to contribute to 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 added the domain name kubevela.net, which can facilitate the faster access of domestic users. The content is completely consistent with the domain name kubevela.io, real-time synchronization.
KubeVela is the CNCF sandbox project. For more information, please click here for the official documentation.
A link to the
[1] VelaUX:
Github.com/oam-dev/vel…
[2] UISchema:
Kubevela. IO/useful/docs/ref…
[3] X – Definition:
Kubevela.net/zh/docs/pla…
[4] VelaQL:
Kubevela. IO/useful/docs/PLA…
[5] Core Concepts:
Kubevela.net/zh/docs/get…
[6] Docker image delivery:
Kubevela.net/zh/docs/tut…
[7] Delivery of Helm Chart package:
Kubevela.net/zh/docs/tut…
[8] Delivery of Kubernetes resources:
Kubevela.net/zh/docs/tut…
[9] Delivering cloud services:
Kubevela.net/zh/docs/tut…
[10] Over 100 developers:
Github.com/oam-dev/kub…
[11] Common cloud resources:
Kubevela. IO/useful/docs/end…
The original link
This article is the original content of Aliyun and shall not be reproduced without permission.