Rethinking environment management: How flawed architecture begins with property files

In large organizations, environments go way beyond just dev, test, QA and prod environments; they typically exist as parallel streams of work, as staggered release trains and as complex branching structures. In my experience, maintaining legacy systems while also operating newer transactional platforms requires multi-year, multi-track programs with different business lines. In these architectures, environmental configuration settings are typically stored in property files in source control based on their related branching strategies.

Property files, when first introduced, were thought of as configuration files. They have now become brittle, unscalable artifacts that put teams into what I would call a “configuration hell.” The tight coupling of environmental configuration settings with deployment decisions and branching strategies can become a messy tangle where each small configuration change introduces a chain of risk and liability into lower environments and in-flight projects.

The need to redefine the environment configuration

In today’s cloud-native environments, the expectation of zero downtime directly conflicts with legacy practices centered around property files. This rigid coupling introduces operational overhead and stretches recovery time objectives (RTO), as services must pause for updates. Worse, manual misconfigurations can undermine data integrity and escalate recovery point objectives (RPO), risking incomplete rollbacks or state corruption.

As enterprises pursue resilient architecture, dynamic configuration — externalized, secure and decoupled from deployment — emerges as a non-negotiable strategy to meet continuity benchmarks and business velocity. Additionally, config drift and manual patching often trigger cost spikes in the long run. Centralizing these configurations is just one step towards operational agility — what is truly needed is an API led architecture that can sync environment configurations on the fly to these distributed systems, ensuring consistency and uptime.

Breaking the coupling: Strategies for decoupled configuration management

Strategy 1: Identity provider-based configuration

In many enterprise use cases, IDPs like Okta or Azure AD provide a single source of authentication, but they may also act as a source of propagation of environment configurations. The fundamental way we plan on doing this is to add to the IDP claim — issued per user when they authenticate — the metadata to manage their environment-specific access. The claim contains a hashed pointer that can be used to expediently fetch relevant secrets from the secrets manager, as well as the tags that control access to the environment-specific resources, like data stores or runtime services for a given environment.

This approach has two significant benefits:

• It makes the most of existing identity infrastructure reuse, lessening intricacy and operational overhead.
• It eliminates the need to perform extra API calls to fetch application-specific settings, enabling real-time sync in distributed systems
• It leverages existing IDP features such as audit trail and logs.

For organizations that do not have a cloud IDP, they could consider using an open source provider for this, such as Keycloak.

Strategy 2: Orchestrator-led runtime updates

Another approach, based on a similar idea, uses an orchestrator to trigger the update of config in real time between environments. A central orchestrator fetches config info from a cloud store (based on a defined refresh period), and uses that information to update the runtime config files used by deployed apps. This reproduces the principles of Kubernetes secrets operators, so that environment-specific variable state is kept in sync as required without making direct API calls or effort. This approach has its benefits as well:

• Unlike the previous approach, it separates authentication concerns from configuration delivery, enhancing modularity and fault isolation
• The sync frequency can be customized and paused as needed.

Organizations can build their own lightweight orchestrators that can perform dynamic sync of configurations. This will enable fine-grained control and avoid vendor lock-in.

Conclusion: Toward resilient architecture in a multi-environment world

Two solutions — IDP-embedded claims model to provide secure real-time access provisioning, and orchestrator-driven runtime config synchronization — offer distinctive advantages for distinctive architectural concerns. However, by leveraging some of the strengths of both solutions, organizations can develop a bifurcated configuration ecosystem to balance security with agility and operational simplicity. The IDP-native claims model lends itself to certain controlled access patterns that would allow it to be effective in regulated industries or multi-tenant architectures. Alternatively, the orchestrator approach allows modularity and equivalent runtime capability, providing access to powerful integrations with GitOps, policy engines and other cloud-native tooling.

As systems become more complicated and layered in the cloud-native space, the use of hybrid approaches can facilitate the creation of truly cohesive configuration pipelines that operationalize less effort, deliver better governance and future-proof application environments.

This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?