1. Why We Need to Define the Application Runtime

There are more runtime choices. Traditional application runtimes include physical machines, virtual machines, and cloud hosts. In the container era, the common runtimes are Docker and Kubernetes. These runtimes no longer present us with a single runtime choice.

Application topologies are more complex. If a CMDB stored application topologies uniformly, that would of course be ideal — other systems would have a single source of data. The reality is that such foresight is hard to come by: when a topology like this is urgently needed, developing the feature, entering the data, and keeping it consistent are all extremely difficult.

When different operations systems use these runtime environments, the topology they present may differ. As shown below:

There are two ops systems here:

• A’s view is that under an application there is first an environment, then a data center, and only then can you locate a specific application.
• B’s view is that under an application you first pick a region, then an environment, then a cluster, and only after that a namespace, before you can locate an application.

The problem with a missing unified application topology is that every ops system has to describe a topology of its own. The resulting problems are self-evident: the cost of onboarding new business is high, system-to-system integration is not easy, and each ops system is difficult to use. This creates overhead for development, ops development, and ops alike.

The proposal of having the CMDB store application topologies uniformly is out of scope here. What we need to think about is how to define the application runtime in a way that solves the current problem: the topology of an application differs across the views of different ops systems, yet the experience presented to users is consistent.

2. Defining the Application Runtime

Our servers may be spread across different regions, belong to different vendors, and be of different types. Defining the application runtime is about establishing a link between these runtime providers and the application. When an application is created, a suitable runtime can then be found and a workload created on it.

Recall how, in the usual case, an ops system selects a runtime. As shown below:

What is first presented to the user is the region — Northeast, Central China, South China, Asia-Pacific, Singapore, and so on — and then the choice of virtual machine, container, or Kubernetes. After a while, we found that what users cared about was not the region but the runtime type, so we adjusted the ops system. As shown below:

We set the first-level menu to virtual machines, containers, and Kubernetes, and the second-level menu to regions — Northeast, Central China, South China, Asia-Pacific, Singapore, and so on. After a while, we found that under the region we had to add another level, the data center, and the ops system had to be adapted again.

When you browse my website, you will find that it has no categories, only tags. That is because choosing a category for an article is actually not an easy thing — it is unique, whereas an article can have many tags.

This is the main difference between categories and tags. A category builds a linear, single network, while tags build a mesh-like, interconnected network. A tagging system contains a categorization system within it.

With the help of a tagging system, we can describe the application runtime well while also remaining compatible with a single CMDB topology source. As shown below:

No matter how an ops system presents an application’s topology, a tagging system can accommodate it. Using a set of tags to define the application runtime mainly costs you this: developing an efficient tag-filtering system and maintaining the tags well. This is similar to Labels in Kubernetes and can be used as a reference.

3. System-to-System Integration

Ops systems are not singular; they cooperate with and act on one another.

As shown above, when two ops systems define the runtime differently, a mapping must be made through agreed-upon conventions. Each system only needs to care about its own runtime and need not leave behind unmaintained redundant fields just for the sake of compatibility. Absence is better than error.

Here DATACENTER maps to REGION, CLUSTER, and NAMESPACE. But system A does not care about NAMESPACE. Therefore, we can persist the correspondence between DATACENTER and REGION/CLUSTER, or map it through a convention — for example, naming DATACENTER in the form REGION-CLUSTER.

Another point is that when managing these runtimes, each ops system should inject the runtime description into environment variables as much as possible, for example ENV=DEV, REGION=HW-BJ, and so on. Developers can use these variables to adapt, which helps with debugging and locating problems.