Overview

Application

Represents an application model used to define the components of an application and declare the required deployment and maintenance needs. If an “application” exists in file form, it is usually represented in YAML or JSON format. An “application” is a collection of “components,” serving merely as the delivery unit for related components, but the components themselves are the deployable units. This means that components can be deployed independently to designated clusters, and thus, components of the same application can be deployed to different clusters.

This platform allows DevOps engineers and platform engineers to collaborate on the automated deployment and maintenance of applications. To ensure the portability of applications, DevOps engineers need a universal and abstract way to describe how to deploy and manage application components. For this purpose, platform engineers define a set of abstract, extensible application component description languages, allowing DevOps engineers to describe the intent of application deployment without overexposing infrastructure details.

Component Elements

Components are mainly divided into “workloads,” “backing services,” and “configuration settings” based on their characteristics.

Workload components need to provide application business logic code to implement functions such as microservices and background tasks. Backing service components represent external services or storage that other components depend on, such as databases, object storage, message queues, etc. “Backing services” can be provided by cloud providers or other applications. Configuration setting components provide shareable configuration information for other components to use.

Backing service components usually have more than one implementation, and the same implementation can support different specifications or capacities. For example, a PostgreSQL database service can offer different service plans. Different specifications of the same component implementation are represented by ComponentClass. In some cases, limited customization parameters can be supported during the component implementation process.

There are dependencies between components; the dependent components need to be delivered before the dependending components can be deployed.

The type of components can be extended, and each component’s type definition is described by a ComponentDefinition object.

Trait Elements

”Traits” elements provide declarations on how to implement components, affecting the results produced during the component composition process.

Each “trait” has a type that distinguishes its schema and semantics. Depending on the type, each “trait” element has different properties. The type of “traits” can be extended, and each trait’s type is described by a TraitDefinition object.

Here are some rules for “traits”:

• The order of “trait” elements in the “component” declaration determines the processing order of the “traits.”
• Only one of the same type of “trait” can exist in a single component declaration.
• Traits can limit the component types they can act on.
• There may be conflicts between traits, meaning some traits cannot be applied to the same component simultaneously.
• There are dependencies between traits; the dependent traits need to be present in the component declaration simultaneously.
• The first trait in the list of traits in the component declaration (index 0) is the primary or fundamental trait of that component:
  • If it is a backing service component: its type is Service.
  • If it is a workload component: its type is Container (currently, but other workloads will be supported in the future).
  • If it is a configuration setting component: its type is Properties.

Release

”Release” represents an application delivery task that occurs when an “application” object is created or modified in an “environment.” A “release” records the current component configuration of the application and the status during release. Since a new “release” object is generated every time an “application” changes, the component configuration within the “release” object does not change once established.

When a new “release” is generated, it needs to be compared with the previous version of the “release” to determine:

• Which new component instances (Component objects) need to be created.
• Which component instances need to be adjusted.
• Which component instances need to be removed.

The created components are represented by “component” objects indicating the released component instances. Since component instances can be referenced by multiple “release” objects, the naming rule for component instances needs to be deterministic, currently using the “{application name}_{component name}” format.

Environment

Represents the destination for application deployment, also known as the deployment environment. Each application deployment requires specifying (sometimes implicitly) an environment. An “environment” represents the logical boundary of a software system, which can consist of multiple applications. On the other hand, an application and its components can only be deployed in the same environment.

Target

”Target,” or deployment target, represents the deployment destination of application components. In this platform, only “clusters” can serve as deployment targets. A “target” object defines the binding rules and relationships between application components and clusters within an environment, so a “target” is a different concept from a cluster.

• The scope of a “target” is limited by its environment, and “targets” in different environments can have the same name. When the associated environment is deleted, the “target” object is also deleted.
• The specification of a “target” defines the binding rules between different deployment targets and clusters in the environment. When first established, the “target” is not yet bound to a cluster.
• When a “target” object is actually configured and assigned a cluster, it enters a bound state.
• When a cluster is bound, that cluster object cannot be deleted.
• When the cluster bound to a “target” changes, the components deployed on the previously bound cluster must be redeployed to the newly bound cluster (if any).
• ”Target” objects are usually created by the Application Operator to meet the deployment needs specified by the components.

Cluster

”Cluster” represents a network service that can be accessed via API. Clusters that can serve as deployment targets for “components” are called “Target Clusters,” while “Management Clusters” are the “Application Delivery Engine” services provided by the platform to tenants.

”Clusters” can be provided by different “cloud collections,” which means that “cloud collections” include various cluster services. When a cluster needs to be dynamically prepared by this platform, the “cloud collection” to be used must be specified. “Cluster” objects can also be manually created by administrators to represent existing cluster services.