Implementing Dynamic Configuration Management with Score and Humanitec
Static configuration management is the no. 1 killer of developer productivity. Dynamic Configuration Management (DCM) is the newest solution gaining traction among top-performing engineering organizations. This article identifies the characteristics of static setups and their challenges, discusses why popular approaches (like service templates) aren’t effective, and explains why DCM is a core driver of developer productivity.
Why static configuration management sucks
The industry has spent the last decade refining the “git-push update, and the change is rolled out” motion. However, it has neglected to optimize anything more complex than the simple update of a component, like app and infrastructure configurations.
An organization’s approach to configuration management determines how easy it is for a developer to perform actions that go beyond simple updates of an image: onboarding to a service, changing an environment variable to promoting between environments, handling dependencies, adding services or infrastructure components, or rolling back.
Most organizations default to a static approach. With static configuration management, developers need to understand, operate, and maintain the dependencies across all workloads and environments. Developers must define how each workload relates to which resources in the final environment before deployment.
This means that workloads configured using a static approach generate exponentially more configuration files for teams to manage. This is impossible to scale beyond 50 services without hindering developer and Ops productivity, driving change failure rates, and increasing security risk.
Many organizations believe their static setup is fine because any single Helm chart isn’t that complicated. While this is true for a single config file, it is not true at scale. Scaling static setups often creates so much complexity that organizations pay significant overhead costs to understand, operate, and maintain these files.
Static setups must maintain a large number of individual configuration files for each workload in each environment, because the exact relationships between workloads and their dependencies has to be provided prior to deployment.
Let’s demonstrate the problem of scaling static configuration with a quick calculation. Say an app has ten services and dependencies, and is deployed across four environments. Assuming an organization deploys three times a day every 21 working days, the result in a typical cloud native setup would be 300 to 600 configuration files with up to 30,000 versions a month.
Complexity isn’t only driven by the volume of files but also by variations between them in style and structure. Helm charts, for example, allow the user to express the same desired state of an environment in hundreds of different ways.
The resulting config sprawl hurts overall business performance in a number of ways.
Maintenance overhead
The sprawl of config files generated by static setups requires someone to operate and maintain them. Most Ops teams spend a huge amount of time fixing stuff in static config files, including spinning up new environments, services or resources, debugging deployments, and making sense of how parts of the app fit together. Most organizations compensate for their faulty setup by hiring more Ops. However, that Ops expertise is often squandered on repetitive tickets in ServiceNow or Jira.
Cognitive load for developers
Static setups are also incredibly draining for developers, who must understand and operate configurations, workloads, and their dependencies across all environments and services. If a developer in a static setup wants to switch teams, they must first spend time learning which component relates to the other. If they need to tie a service to architecture, add a resource or a new environment, they have to dig through dozens of files and formats… Or submit an Ops ticket to figure it out. An increased reliance on ticket-ops is especially likely in security-heavy environments where any major change to resources or architecture needs to go through security processes.
Reliability
Hundreds of files contribute to hundreds of additional points of vulnerability, both for errors driving change failure rate and for security incidents. My colleagues at Humanitec have observed that 90% of change failure rate and 80% of security incidents are attributed to configuration errors.
Service templates don’t fix the complexity problem
To tame complexity, the most common approach organizations take is to standardize the creation of a new service. They might use GitHub templates, or even a service catalog or developer portal to help developers more easily spin up a well-configured “Spring Boot service”. The assumption is that this will have a long-term impact on standardization, reliability, and maintainability. However, this approach does not ensure continuous standardization between files. It only standardizes day one of a service that has a lifetime of tens to hundreds of days. The effect is that the organization’s complexity problem gets pushed into the future, not solved.
Dynamic configuration management is the solution
The most effective solution to config complexity requires both reducing the number of files and continuous standardization. This is where Dynamic Configuration Management (DCM) has a lot to offer.
Dynamic Configuration Management (DCM) is a newer approach wherein developers instead create a workload specification that describes everything their workload needs to run successfully. The specification is used to create the configuration to deploy the workload in a specific environment. There is no longer a need to define or maintain any environment-specific configuration for workloads.
Instead of being forced to slog through hundreds of config files, developers can use exactly one file per service and trust the final config files are created appropriately for the context of the deployment.
The impact of DCM is huge. Going back to the example of ten services and dependent resources, with static configuration management, the result was 300 to 600 config files. With DCM, the same application can be configured with ten files (plus the necessary base configs and templates). That’s up to 95% fewer files than the static approach.
Unlike a service template, DCM addresses the entire lifecycle of an application, not just day one. A plot of the complexity vs. application lifetime illustrates how continuous standardization keeps complexity growing linearly — instead of exponentially.
How to get started with Dynamic Configuration Management
Dynamic Configuration Management (DCM) is a game-changer for organizations overwhelmed by config file sprawl and complexity. It is the key to driving developer productivity, lowering change failure rate, and reducing security incidents.
DCM is the natural evolution for the platform engineering movement. As more organizations build platforms at scale, they need methods that drive standardization by design and introduce separation of concerns without abstracting context from developers. Top organizations adopt DCM because they understand how essential it is for enterprise-grade platforms.
Want to see DCM in action? Get a demo of the Humanitec Platform Orchestrator, no strings attached. The Platform Orchestrator is the best solution on the market to enable DCM and act as the core of a successful Internal Developer Platform.
