As the cloud native technologies grows continuously, more and more infrastructure capabilities are becoming standardized PaaS or SaaS products. To build a product you don't need a whole team to do it nowadays. Because there are so many services that can take roles from software developing, testing to infrastructure operations. As driven the culture of agile development and cloud native technologies, more and more roles can be shifted left to developers, e.g. testing, monitoring, security. As emphasized by the DevOps concepts, it can be done in the development phase for the work of monitoring, security, and operations via open source projects and cloud services. Nonetheless, this also creates huge challenges to developers, as they might lack the control of diverse products and complex APIs. Not only do they have to make choices, but also they need to understand and coordinate the complex, heterogeneous infrastructure capabilities in order to satisfy the fast-changing requirements of the business.
This complexity and uncertainty has exacerbated the developer experience undoubtedly, reducing the delivery efficiency of business system, increasing the operational risks. The tenet of developer experience is simplicity and efficiency. Not only the developers but also the enterprises have to choose the better developer tools and platforms to achieve this goal. This is also the focus of KubeVela v1.2 and upcoming release that to build a modern platform based on cloud native technologies and covering development, delivery, and operations. We can see from the following diagram of KubeVela architecture that developers only need to focus on applications per se, and use differentiated operational and delivery capabilities around the applications.
pic 1. KubeVela Architecture
Let's retrospect the history of OAM and KubeVela to understand how it is formed this way:
- OAM（Open Application Model）birth and growth
To create simplicity in a complex world, the first problem we need to solve is how to make standard abstractions? OAM creatively proposes two ways of separation: separation between applications and resources, and separation between development and operation (in ideal world the operation can be fully automated). It is a cloud native application specification which provides everything-as-a-service, complete modularity design. The spec has been getting tractions among major vendors all over the world since it's been announced. Because we all share a common goal -- To reduce learning curve and provide application lego-style invention for developers.
- v1.0 release of KubeVela, bringing the OAM spec implementation
With the application specification as the guidance, advanced community users can create their own tools to build practical solutions. But it is unaccessible to most developers though. KubeVela was born as the community standard implementation to solve this problem. It absorbs the good parts from latest Kubernetes community development. It provides automated, idempotent, reliable application rollout controllers. With its features, KubeVela can empower developers to quickly deploy OAM-compliant applications.
- v1.1 release of KubeVela, provides delivery workflow, making multi-cluster rollout controlled and simplified
As more and more enterprises adopt the cloud, hybrid and distributed cloud will certainly become the future norm. KubeVela has been designed and built based on hybrid cloud infrastructure as a modern application management system. We anticipate that the architecture of modern enterprise applications will be heterogenous considering factors of availability, performance, data security, etc. In KubeVela 1.1, we adds new feature to achieve programmable delivery workflow. It natively fits the multi-cluster architecture to provide modern multi-cluster application rollout.
By the time of 2022, on the road to serve developers, KubeVela has gone to the fourth phase. It is going to empower developers to do multi-cluster rollout way more easily. In the following we will dissect its changes:
It is the best choice to reduce developer learning curve by providing an easy-to-use UI console. Since the inception, KubeVela community has been asking for UI. With the v1.2 release, it has finally come. Providing GUI will help developers organize and compose heterogeneous aplications in a standard way. This will help them analyze and discover business obstacles quicker.
VelaUX is the frontend project of KubeVela with extensible core design. It introduces low-code experience for users to drag-and-drop form that takes user input based on dynamic components. To achieve this we have designed the frontend description spec UISchema with X-Definition, and multi-dimensional query language VelaQL. This design makes the foundation for the heterogenous application delivery architecture of KubeVela.
From GUI, users can manage addons, connect Kubernetes clusters, distribute delivery targets, set up environments and deploy all kinds of apps, monitor runtime status, achieve full lifecycle management of application delivery.
pic 2. KubeVela Application Dashboard
For the new terms in GUI, please refer to Core Concepts documentation to learn more details.
KubeVela will manage N Kubernetes clusters, N cloud vendor services in a big unified infrastructure pool. From that our developers can set up different environments based on business requirements, workflow policies, team collaboration needs, etc. This will create separate environment workspaces from big infrastructure resource pool. One application can be deployed into multiple environments, and environments are isolated from each other in both management and runtime.
pic 3. KubeVela Application Status
As shown above, an application can be deployed to default environments and other custom environments such as test or prod. Each environment can include multiple delivery targets. Each delivery target indicates an independent, separate Kubernetes cluster.
In terms of cloud native technologies, we have many options to pick for build application delivery solutions. Based on Kubernetes, we can use mature technologies like Helm Chart to delivery middleware and third-party open source softwares. We can deliver enterprise business applications via container images. We can also use OpenYurt to deliver and mange edge applications. Based on the open technologies of cloud services, we can deliver database, message queues, cache, etc. middleware, including operational features like logging, monitoring.
With so many options, KubeVela adopts OAM as the standard application definition to manage heterogeneous application architecture uniformly. KubeVela provides highly extensible delivery core engine. Users can use built-in or install more plugins to extend the platform, and manage application deliveries in a consistent way. On top of KubeVela, what users see is the modular, everything-as-a-service control plane.
pic 4. Cloud Resources Deploy
As shown above, we can tell that in the application management page users can conveniently deliver cloud resources. Developers can read the following docs to understand the full delivery process of heterogeneous application architecture:
KubeVela has been designed as an extensible system from the very beginning. The aforementioned heterogeneous application architecture can be achieved via KubeVela's extension system. It can be extended via standard interfaces and plugin as many capabilities as you want. This will match the differentiated requirements of enterprises while reducing the cognitive burden incurred in learning new things. KubeVela's extension system includes component types, operational traits, workflow types, delivery policies, etc. In current release, we have the addon management system. An addon packages the extension capabilities for easy distribution.
pic 5. KubeVela Addons
Currently we provide an official catalog with pre-packaged addons shown as above. Meanwhile in the experimental catalog repo we can collaborating with community users to create more capabilities.
By now, KubeVela has grown into an application delivery platform that serve developers directly. What enterprise scenarios can we use KubeVela for? In the following we list a couple of common scenarios:
Today many enterprise software delivery looks like the following diagram. They use the compute resources from cloud vendors for both the demo and production environments. But they use their in-house server farm for the development or testing environments. If any business applications have multi-region disaster recovery requirements, then production environments can span multiple regions or even clouds.
pic 6. DevOps Pipeline
For basic DevOps workflow, it includes code hosting, CI/CD process. KubeVela can provide support for CD process. To enterprises the following are the practical steps:
- Prepare local and cloud resources according to real needs. Make sure local and cloud resources are connected in the same network plane for unified resource management.
- Deploy KubeVela into the production environment and ensure its accessibility.
- Install DevOps toolchain like Gitlab, Jenkins, Sonar via KubeVela. Usually the accessability of code hosting and developer toolchain are critical and we must deploy them to production environments. Unless you local clusters can ensure accessibility, can hope the business code to exist in local environment, then you can deploy them to local clusters.
- Setup local development environments via KubeVela, deploy testing middleware in local. Setup cloud middleware in production environments.
- Setup business code CI piplines via Jenkins. Generates Docker image and send it to KubeVela to do multi-environment deployment. This will make up an end-to-end application delivery workflow.
Using KubeVela multi-cluster DevOps solution will provide the following advantages:
- Developers do not need to know any Kubernetes knowledge to achieve heterogeneous cloud-native application delivery.
- Unified multi-cluster, multi-environment management in a single control plane. Natively deploy multi-cluster applications.
- Unified application management mode, regardless of business applications or developer toolchain.
- Flexible workflow to help enterprises to glue various software delivery processes in a single workflow.
Different enterprises face different problems and requirements of infrastructure and business. On the infrastructure side, enterprises could build in-house private cloud, yet buy some public cloud resources, and own some edge devices. On the business side, the variance of scale and requirements will lead to multi-cloud, multi-region application architecture, while keeping some legacy systems. On the developer side, developing software will need various environments such as development, testing, staging, production. On the management side, different business teams need isolation from each other, while opening up connection between some business applications.
In the past, it was very easy to become fragmented between different business teams inside enterprises. This fragmentation exists in: toolchain, technical architecture, business management. We take this into account while being innovative in technologies. KubeVela brings a new solution that pursues unified management and extensible architecture with good compatibility.
- On the infrastructure side, we support different API formats including Kubernetes API, cloud APIs, and custom APIs to model all kinds of the infrastructure.
- On the business architecture side, the application model is open and platform agnostic. KubeVela provides the ability to connect and empower businesses.
- On the Developer toolchain side, there might be different toolchain and artifacts in the enterprises. KubeVela provides the extension mechanism and standard models to combine different kinds of artifacts into a standardized delivery workflow. Surely, its standards are shifting left and empowering enterprises to unify toolchain management. You don't need to concern whether you are using Gitlab or Jenkins because KubeVela can integrate them both.
- On the operations side, the operational capabilities and toolchain solutions can be unified under KubeVela standards in the enterprises. Moreover, the community operational capabilities can be shared and reused easily via KubeVela extensions.
Thus, KubeVela can be used to connect different stages inside the enterprises, and unify all capabilities in a single platform. It is a practical and future-proof solution.
Many enterprises that has enough development power will choose to build internal application platforms. The main reason is that they can customize the platform to make it very easy for their use cases. In the past we can see there are many PaaS platforms born out of Cloud Foundry. We all know the stereotypes of application platforms will not satisfy all enterprises. If the application package format and delivery workflow can standardized inside enterprises, then all users need to do is to fill the image name. However, in traditional PaaS platforms developers have to understand a bunch of so-called general concepts. For example, if an enterprise want to deploy AI applications, and there is some difference for AI application architecture, then we have to create such AI PaaS, and enterprises have to pay more fees and learn more concepts.
Therefore, when general products couldn't satisfy the needs of enterprises, they will consider develop one on their own. But it takes so much resources to build an internal platform from scratch. Sometimes it even surpasses the investment of their core business. This is not a feasible solution.
With above introduction, are you more familiar with the motivations and history of KubeVela? There is no such a product to be the silver bullet. But our goal is to create a standardized model to empower more and more enterprises and developers to participate in the path towards building simple and efficient developer tools. KubeVela is still in early development phase. We still hope you can join us to develop it together. We want to thank the 100+ contributors who contributed to KubeVela.
OAM spec is the cornerstone of modern application platform architecture. Currently, OAM spec is driven by implementation of KubeVela for future improvement while the spec didn't rely on KubeVela. We highly encourage cloud vendors, platform builders, and end users to join us to define OAM spec together. We highly appreciate that vendors like Tencent, China Telecom, China Unicom have supported OAM spec and started collaborative work. Every person and organization are welcome to share your ideas, suggestions, and thoughts.
Go the Community repo.
As mentioned above, we have created the addon extension system, and encourage community developers to contribute your tools, and share your thoughts.
KubeVela integrated Terraform Module with Terraform controller to extend cloud resources. We have supported several cloud resources, and encourage community developers or cloud providers to contribute more.
Go to contribute cloud resource.
We highly welcome everyone to participate in the KubeVela community discussion whether you want to know more or contribute code!
Go to Community repo.
KubeVela is a CNCF sandbox project. Learn more by reading the official documentation