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
An application allows a specific user group named “Remote Access Users” access to the web service. The name of this group is stored in a configuration file, and is read on app startup.
An approval workflow is defined that specifies the sequence of users or user groups by which a data change must be approved.
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:
- Require environment access to establish or change
- Must be parsable to their specific format
Formatting error handling might manifest in three ways:
- Refusal to read the value with the error (the “value does not parse”)
- Refusal to read the entire file with the error (the “file does not parse”)
- A fatal error and refusal of the application to start
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.
- Sitecore’s Configuration Layers
- The entire .NET configuration system including configuration transforms
- The eZ Publish configuration system
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:
Many developers are wary about writing files with values that are used for future logical processing. This opens up some threat vectors.
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:
Many CMSs use a specially modeling content object to store settings. In Optimize Content Cloud, for example, it’s very common to store settings on the Start Page, since that’s guaranteed to be a singleton for a site.
Sitecore and some other systems operate on a “global tree” concept, where all managed data is stored as content in a tree. The managed content – the things people use to make a website – is just one “branch” on that tree.
There are several advantages:
- Automatic UI creation
- Versioning, which allows for rollback
- Built-in permissions management
- Built-in storage architecture
There are also some drawbacks:
- A lot of content services don’t apply to settings – things like URL management and templating/preview. Some systems provide these to all content by default, settings included.
- Configuration stored as content require the application to be instantiated for access. Some configuration might be necessary for application startup.
- Configuration values can often drastically affect application functioning, and are therefore dangerous to intermingle with content.
Practices for User Extensibility: Configuration
Provide a configuration framework and common conventions and drive the add-on and plug-in community to accept and use them. Discourage bespoke configuration system development. Ensure all vendor tools use the provided configuration system.
Provide the ability for developers to specify default values in files which can only be changed with root or environment access.
Provide a generic configuration UI to authorized users that can override root values.
Provide “dynamic refresh” where new configuration values can be read into the application process without an application restart
For each “root value,” provide a method to “lock” that value, preventing overriding from the configuration UI (effectively saying, “this value is final”). In the configuration UI, clearly display locked values as read-only so the user (1) knows what they are, and (2) knows they are intentionally locked.
When refreshing or reading dynamic configuration values those provided from the UI, handle fatal value errors – if a value does not parse or fit the necessary format, fall back to the “root value” and write a message to the log file. (If a root value fails, then this is a acceptably fatal error, because root configuration is basically source code.)