Runtime configurations and environments

Deprecation notice

This feature might be removed in the future. We recommend using platform settings to manage and configure your organization’s infrastructure and operations. Check our Providers article for more information.

Scopes vs Runtime Configurations

Scopes might not be enough for every use case. The simplest way to create environments for your applications is to create different scopes for each environment. This is usually a good choice for relatively simple scenarios where the environment might affect the application behavior but not the infrastructure. For example, if I want to create a production and a staging environment, it would be sufficient to create one scope for each one with specialized parameters to change its behavior. But what if I want every production environment in the company to run in a different cloud account than staging or development environments? This is where runtime configurations come to the rescue.

Why runtime configurations? Runtime configurations allows you to provision environments that can be reused across different scopes, decoupling work done by teams who provision infrastructure / environments (typically DevOps teams) from teams that operate applications (typically Developers). The decoupling happens because, once the runtime configuration is made available, developers just pick the right one for their scope, abstracting themselves from the underlying configuration and infrastructure details.

You can think of runtime configurations as (search engine) facets for scopes. This is, you define certain attributes that define the runtime configuration (eg: country = US ; environment = testing) and developers use your runtime configurations by selecting those attributes for their scope.

The infrastructure side of this process is about provisioning using any tool, and creating the runtime configuration on nullplatform:

The developer side is just about selecting the runtime configuration, which becomes an attribute of the scopes:

info

If you're interested in learning more about this topic, please check the article Make environments that work on medium.

To create a runtime configuration, you first have to create the dimensions and dimensions values for it. Please read the next section to learn more about this.

Dimensions and Dimension Values

Runtime configurations are selected based on the attributes (eg: country = US ; environment = testing) and those attributes are dimensions and dimension values. In the example country=US, you have country as a dimension and US as a dimension value for this dimension.

Before creating a runtime configuration, you have to create a dimensions and values, otherwise your runtime configurations cannot be selected.

Please refer to the Dimensions and Values section for further reference.

Runtime Configuration Values

When you create a runtime configuration, you normally want to alter behavior for a scope. For this to happen, you have to send a values object with the keys and values that alter this scope behavior. These keys are not arbitrary since internally are stored as NRN (please check the docs to learn which keys you are entitled to read / modify).

Putting it all together

This is a diagram that shows the actual properties and relations between scopes, runtime configurations, dimensions, dimension values, and the actual values that the runtime configuration holds.

1. Configure Dimensions and Dimension Values

2. Create Runtime Configurations

3. Assign runtime configurations to scopes, yielding a final configuration for the scope

Runtime Configurations and NRN

Runtime configurations have specific interactions with NRN that you have to know to avoid errors and mistakes:

Runtime Configurations are created at a specific NRN. Every scope under this level will have the runtime configuration applied. Dimensions that are defined for this runtime configuration have to be available at the NRN for which the runtime configuration is being created.

Values for the runtime configuration are stored on NRN API. Whenever you create values for your runtime configuration, those values will be stored on NRN API as profiles. This implies that your runtime conifgurations can only hold values that you can write on NRN API (check the list here)

Examples

Creating a runtime configuration

POST /runtime_configuration
{
  "nrn": "organization=1",
  "dimensions": {
    "environment": "development"
  },
  "values": {
    "some": "thing"
  }
}

Assign /remove a runtime configurations to / from a scope

POST /scope/1/runtime_configuration
{
  "id": 1234
}

DELETE /scope/1/runtime_configuration/1234