Modern business applications do not run on a single server any more. They run on dynamic clusters, on virtual servers or in containers, locally or on the cloud. In the 20th century, server-side code would read a configuration file, e.g. the famous Java properties file, and get their configuration information. This has many problems for modern applications:
- Distributed applications do not have a cluster-wide file system for security and scalability reasons
- It is hard to edit the configuration information: dangers of data corruption if the system crashes while files are being written out
- The application does not reload the configuration after a file update
Some applications stored configuration parameters in a database instead of a file, which took care of data protection, but raised problems of bootstrapping (where is the configuration information for the database connection stored?) and increased the weight of the application. And it left unanswered the questions of propagating changes to values, and expected each application designer to design his own configuration management layer.
Rigel solves these problems by providing a small distributed database where a set of configuration values can be stored and accessed from anywhere in the cluster. The application bootstraps its configuration information off Rigel, and can be notified of changes to configuration parameters in real time if required.
Rigel comes with a user interface which may be used by an administrator to change values of configuration variables. The impact of the new value on the application is decided by the application designer.
Offers a facility to store and retrieve a set of scalar configuration variables in a distributed database
Far lighter than solutions based on relational databases, far more robust than file-based configuration
Supports type enforcement of variables, preventing, for instance, a string being assigned to an integer variable. This minimises accidental data corruption or typos.
Changes to variables are propagated across the cluster in near real time. This facilitates distributed operation and horizontal scalability.
Application code cannot change variable values; they may only be edited manually using the UI. This makes the configuration database more secure.
All changes to values and full history are logged in LogHarbour for audit purposes. Access to the administration interface is access controlled.
Application code can register to be notified when configuration values change.
Internally, the data is stored in a distributed etcd database. The number of variables can be in thousands. etcd is a tested and reliable open source data store, used by critical products like Kubernetes.
Client libraries are available for Go and Java Springboot.
Client library implementations minimise access to the distributed database by caching values locally. This improves lookup performance.
It is possible to run Rigel in containers, allowing easy portability between cloud and on-premise data centres, and providing scalability and high availability.