Configuration

Definition

Very generally, “configuration” are quantitative values supplied to an application which are incorporated into its processing and execution.

As we’ll discuss, what is and is not “configuration” can be very vague.

Configuration often defines how an application runs at a very base level. A user’s experience can be deeply affected by configuration, and it can be unchangeable by them, effectively making it “instance-specific source code.”

Example Use Cases

Configuration vs. Managed Data

Configuration are not data that the application manages. They are data that the application uses to execute.

For example, a classic library manages books. However, there might also be a manual for library procedures which is also a book. However, the procedures book is not something the library manages; it’s a book the library uses to manage other books.

Managed data is “inert,” in the sense that the application can process it without ever evaluating it. Configuration data will be actively evaluated by the application.

Configuration vs. Settings

Configuration values are mostly assumed to be static. They will be established by some usage requirement during implementation or application onboarding, and will rarely change once the application has been deployed.

Static configuration in the classic sense is not related to any dynamic entity – it is global to the application. Meaning, there is no configuration for specific entities – those are considered managed, transactional data.

If configuration is meant to be dynamic – it’s meant to change after the application is running, or it’s specific to some entity, like a user account – then we often call it “settings.”

Startup Values

Many applications use configuration values that are read once during startup.

These startup values are usually always stored in files, because they need to be available before the application has fully started up. Files are the “lowest common denominator” of storage mechanisms.

For example, a database connection string cannot be stored in the database, for the simple fact that without it, the application can’t connect to the database to retrieve it.

Configuration files usually use some established format, like the *.config files of a .NET application (XML), or the *.ini files of a PHP application.

When one of these values is changed, the application often much be restarted in order to reload the new values.

Of course, this requires that an application even has a “startup” process, and that it can be restarted without externality. SaaS and multi-tenant applications are never “started,” and can therefore not be restarted for a single customer to change their configuration values.

File-Based Configuration

Configuration from files requires text to be entered in a specific format – XML, JSON, informal “ini” formats, etc. This means that configuration files:

Formatting error handling might manifest in three ways:

Because of this, file-based configuration – regardless of the format – is not user extensible. Besides requiring environment access, the potential for errors makes configuration basically the same as source code.

Additionally, most file-based configuration is read on start-up, much like source code, meaning changes require an application restart.

Some systems have deep subsystems for file-based configuration management, allowing for configuration to be spread across multiple files, and for values to be selectively overridden from base/default values.

A lot of these systems operate on an “overlay/overwrite” metaphor. Base configuration values are read first, then additional configuration values are read that might overwrite (“overlay on”) the base values. This occurs multiple times, in progressively more specific configuration values.

UI-Based Configuration

Occasionally, configuration values can be changed via a UI, then re-persisted. However, the application has to be designed that these values can be re-read, without requiring a full application restart (which is usually not possible – thankfully – from a UI).

A danger is in “configuration diffusion,” where different parts of the application are configured in different ways. This is often the case with add-ons and plug-ins. Developers of those tools will often bring their own configuration methods and conventions, meaning each part of the application has to be configured in a different way.

UI-based configuration is often presented as “settings” control panels, where a configuration-specific UI is presented, with editorial controls for all values, along with contextual help and instructions.

UIs usually persist configuration to their own storage system.

Occasionally, an application will formalize a “configuration management system,” which will allow disparate tools to store values in a common repository.

For example: Drupal calls “persistent variables,” and provides methods to read and write them, and even mass-persist an entire form’s worth them

However, this can be uncommon for the simple fact that plug-in/add-on developers don’t want to invest much time into configuration UIs. As discussed above, configuration is often considered static and unchanging, and the establishment of values will usually coincide with the deployment of source code, so there’s no harm in doing at the file level.

The Danger of Non-File Storage

A value of file-based configuration is that it provides rock-solid access – a text file is the most simple computing asset, and it can always be read and written outside of the application context.

Here’s the nightmare scenario –

An invalid configuration value prevents the application from starting, and that value can only be changed from a UI…which is not available because the application won’t start.

Files provide the ability to change configuration values independent of the status of the application, and that has significant benefit.

Reconciliation of UI and File-Based Approaches

One way to support both file- and UI-based models might be to have a UI write files. Use files as the backing storage model for UI changes.

Thus, the UI simply becomes a “configuration file editor.”

However, this can be problematic for a couple reasons:

  1. Many developers are wary about writing files with values that are used for future logical processing. This opens up some threat vectors.

  2. Systems that run on cloud or grid computing environments might not have a file system to write to.

Storing Configuration as Managed Assets

Since a data management system – like a content management system – is specifically designed to persist data, there’s often a temptation to use it to store configuration.

Some examples:

There are several advantages:

There are also some drawbacks:

Practices for User Extensibility: Configuration