Nice article.

Industry norms are getting rich and richer in terms of application architecture because of the wide variety of tools available. One of such areas that have gotten traction is configuration management.

Configurations require some form of a versioning technique. For example, if you want to revert back to a different version of your application, you can roll back along with the config version. These kinds of "rolling back" techniques are very popular, and are commonly used along with some Infrastructure-as-Code (IaC) tool. Another use case is the concept of environments. Different environments (dev, QA, STG, PROD, LIVE) require different versions of configs.

Out came different tools to achieve these functionalities. Configuration management has gotten some real reputation; the idea is to maintain a distributed, redundant, persistent and fault-tolerant configuration store with a well-defined interface that can maintain different versions of configurations with different environments.

To access these configuration stores, various adapters were also developed that could easily be plugged in to your existing applications. MicroProfile Config (Primarily for JavaEE) is one such adapter that I've used and it's almost perfect.

In my opinion, the applications.properties used in Spring and JavaEE is used mostly to configure framework-specific details. When it comes to configurations like database credentials, URIs, secrets and such, industries tend to go for stand-alone configuration stores and secret managers that are specifically tailored to manage configurations and secrets. These applications do have well defined interfaces and provide adapters for downstream applications to interface with themselves.