Modeling application delivery using AppConfiguration

Cloud-native technologies have emerged as the de facto standard for the delivery of modern applications in the cloud. At Ant Group, we have adopted them extensively. As we moved to the cloud-native infrastructure, we saw a dramatic increase in the complexity of configurations and consequently, developer’s overall cognitive burden.

Therefore we’ve decided a new approach is needed to keep up the pace with the growing scale and the variety of configurations involved. As a response, we’ve introduced an application-centric, declarative specification. One of the core ideas behind it is a declarative configuration model — AppConfiguration, which captures the application intent in an intuitive and developer-friendly way.

Design Principles

1. Developer First: The AppConfiguration model serves as the interface for application developers. The goal is to reduce the cognitive overhead by hiding the complexity of the underlying infrastructure, by describing applications with concepts and semantics that are intuitive and easy to understand. Developers should be able to describe an application as simple as “I want a database of type X and version Y to go along with my application”.
2. Application Centric: Shipping a working application involves more than just bootstrapping the compute workload. It also includes setting up the variety of resources the workload depends on, e.g. networking, storage, database, monitoring. The AppConfiguration model serves as a comprehensive abstraction layer of the application, capturing everything it needs inside a single, declarative source of truth.
3. Platform Agnostic: The AppConfiguration model is designed to be environment-agnostic and should not be locked into any specific tooling, technology stack or infrastructure providers. In the context of using the public clouds, the AppConfiguration model should support multi-cloud deployment out-of-the-box and enable “Write Once Deploy Everywhere”.

Model Architecture

Based on the principles above, we hereby present the design of AppConfiguration model:

AppConfiguration consists of four core concepts, namely Workload, Accessory, Pipeline, and Dependency. We will walk through each of these concepts one by one.

Workload

Workload is a representation of the business logic that runs in the cluster. Common workload types include long-running services that should “never” go down and batch jobs that take from a few seconds to a few days to complete. A valid AppConfiguration instance must include at least one Workload, which is made of one or more containers, along with their configurations, such as the container image, environment variables, and resource requirements.

In most cases, a Workload is a backend service or the frontend of an Application. For example, in a micro-service architecture, each service would be represented by a distinct Workload. This allows developers to manage and deploy their code in a more organized and efficient manner.

Accessory

Using the analogy of a car, workload is the core engine of application, but only having the engine isn’t enough for the application to function properly. In most cases there must be other supporting parts for the workload to operate as intended. For those supporting parts we call them Accessory. Accessory refers to various runtime capabilities and operational requirements provided by the underlying infrastructure, such as database, network load-balancer, storage and so on.

From the perspective of team collaboration, the platform team should be responsible for creating and maintaining various accessory definitions, providing reusable building blocks out-of-the-box. Application developers just need to leverage the existing accessories to cover the evolving application needs. This helps software organizations achieve separation of concern, so that different roles can focus on the subject matter they are an expert of.

Pipeline

Running reliable applications requires reliable delivery pipelines. By default, the automated release system is capable of providing a relatively fixed built-in application delivery pipeline, which should be sufficient for most use cases. However, as the application scale and complexity grows, so does the need for a customizable delivery pipeline. Developers wish for more fine-tuned control and customization over the workflow to delivery their applications. That’s why we introduced the Pipeline section in AppConfiguration model.

A customized delivery pipeline is made of several steps, each corresponds to an operation that needs to be executed, such as running certain tests after a deployment, scanning artifacts for vulnerabilities prior to a deployment, and so on. Implementation-wise, the execution of each step should be carried out in the form of a plugin, developed and managed by the platform owners.

Dependency

Application dependencies refer to the external services or other software that an application relies on in order to function properly. These dependencies may be required in order to provide certain functionality or to use certain features in the application.

Similar to declaring a dependency from an application to an accessory, AppConfiguration lets you declare the dependencies between different applications in the same way.

Codification

Taking a closer look into the diagram above, you will notice that the AppConfiguration model is not defined using raw YAML or JSON, but rather a domain-specific language(DSL). The truth is we are big fans of codification, and have been practicing Everything as Code for a while. You can find the reference implementation of AppConfiguration in the catalog repo.