Photo by Matt Artz on Unsplash
Externalized Configuration
For all but the simplest applications, it is a generally accepted best practices to externalize all application configuration parameters that may be changed to configure the application for a specific environment. From networking settings, database connections, and shared credentials to user interface look and feel theming the more complex the application, the greater the number of configuration setting the application may require. By externalizing the application's configuration parameters, we allow it to be customized for a specific deployment without having to rebuild the application.Configuration Profiles
Once we have externalized our configuration parameters, it is often useful to segregate portions of the external configuration into Profiles. A profile allows portions of the configuration to be applied only when the application executes in a particular environment. These configurations may override or add additional configuration parameters for each specific environment. (e.g., development, testing, QA, staging, and production). By segregating the environment-specific configurations, we are able to maintain all of the application's configuration settings within a single location and instruct the application at runtime which profile it should apply.Configuring Microservices
As we build, test, deploy, and scale (replicate) microservices, we must inevitably contend with the problem of configuring each of these individual services. In monolithic architectures, the configuration information usually lives in a combination of the process's environment variables, local filesystem and even potentially packaged within the deployable service itself. However, this configuration approach is impractical for microservices. The sheer number of services that may be deployed makes this complex and error-prone. Add to this the need to dynamically reconfigure existing services it becomes apparent that we need a better approach.Centralized Configuration
To avoid configuring each service manually, we invert the problem. Rather than create configuration files for each service, we create a highly-available, centralized, configuration service that contains every service's configuration data within the application.At startup, each service queries the configuration service to obtain its specific configuration parameters. By centralizing the configuration data, we radically simplify the process of managing configuration data as well as the process of configuring each service.
In addition to providing configuration data at startup, The configuration service can also publish events when any configuration setting has changed. Individual services subscribe and are notified when these events occur and can update individual configuration settings or simply restart the local service. This approach allows the application to be dynamically reconfigured and significantly reduces reconfiguration overhead by operating at the process-level rather than requiring the affected service's containers to be redeployed.
Twitter
Facebook
Reddit
LinkedIn
Email