Application

    OAM allows end users to work with a simple artifact to capture the complete application deployment workflow with easier primitives. This provides a simpler path for on-boarding end users to the platform without leaking low level details in runtime infrastructure and allows users to fully focus on the application delivery itself.

    Every application deployment plan can be composed by multiple components with attachable operational behaviors (traits), deployment policy and workflow. It works in the following format:

    This entity will reference component, , policy and types which are essentially programmable modules that are maintained by platform team. Hence, this abstraction is highly extensible and can be customized in-place at ease.

    • Policy: Policy defines a strategy of certain aspect for application as to multi-cluster topology, configuration overrides, security/firewall rules, SLO and etc. It’s a bit similar with traits but take affects to the whole application instead of one component.

    • Workflow Step: Workflow step allows you to define every steps in the delivery process, typical steps are manual approval, partial deploy, notification.

    The modules that make up the application are all extensible, they are defined by a bunch of programmable configurations called . Under the hood, KubeVela will glue and leverage Kubernetes API to drive the infrastructure capabilities. You can check the following picture to see their relationships:

    A package of OAM Definitions and is called an Addon. KubeVela has a large and growing catalog of addons to support modern application delivery, such as for cloud resource provisioning, OCM for multi-cluster management, for gitops, and etc.

    With these addons, KubeVela provides a unified and good experience for developers to deliver modern application in a multi-cloud/hybrid-cloud environment.

    Despite the efficiency and extensibility in abstracting application deployment, programmable (Infrastructure-as-Code) approach may lead to an issue called Infrastructure/Configuration Drift, i.e. the rendered component instances are not in line with the expected configuration. This could be caused by incomplete coverage, less-than-perfect processes or emergency changes. This makes them can be barely used as a platform level building block.

    Hence, KubeVela is designed to maintain all these programmable capabilities with and leverage Kubernetes control plane to eliminate the issue of configuration drifting, while still keeps the flexibly and velocity enabled by IaC.

    • View to learn the overall architecture of KubeVela.