The Evolution of DevOps: From Separation by Technology to Separation by Concerns

Apr 2, 2026

The current state of DevOps feels eerily similar to the dark ages of Frontend development before the React revolution.

In the early days of the web, we practiced Separation by Technology. We kept our CSS in one folder, our HTML in another, and our JavaScript in a third. We were told this was clean, but in reality, it was a nightmare to maintain. To change a single button, you had to hunt through three different files in three different directories.

React changed the game by introducing Separation by Concerns. It recognized that a Component is the natural unit of work. A component encapsulates its logic, structure, and styling into a single, cohesive module.

The Modern DevOps Bottleneck

Today, DevOps is still stuck in the Separation by Technology phase. We segregate our logic by the tools we use:

Terraform/OpenTofu for infrastructure.
Ansible for configuration.
Kubernetes for orchestration.

While Kubernetes has moved us toward immutability, it has also introduced the YAML trap . Furthermore, the real world isn’t always immutable. We don’t discard a developer’s machine every time we need a minor package upgrade, and stateful services (like databases) require delicate, mutable handling that pure-container strategies struggle to manage.

Enter BigConfig: The Component-Based Approach

BigConfig applies the React philosophy to DevOps. Instead of managing a Terraform repo and an Ansible repo you manage Packages.

For example, the BigConfig Package once utilize four Terraform projects and two Ansible projects under the hood, but to the user, it is a single, functional unit.

The Coupling Problem: A Practical Example

Consider a simple task: checking if the the server can send emails. Ansible needs to create a .mailrc file so the operator can use s-nail CLI to test the SMTP connection during an incident.

The Traditional Way: The infrastructure (SMTP infrastructure) is defined in OpenTofu, but the .mailrc configuration lives in an Ansible folder. This creates strong coupling. If you change your SMTP provider or port, you must manually update two different repositories.
The BigConfig Way: Responsibility is delegated, not segregated. The Tofu SMTP component is responsible for generating the configuration data, while Ansible is simply the delivery mechanism that places the file on the server. The file source path acts as a clean interface. One change in the SMTP component automatically flows through the system.

Modularity and Referential Transparency

The power of a Separation of Concerns architecture lies in its modularity. In the BigConfig Package once, we categorize providers into functional types: Compute, DNS, and SMTP.

Interchangeability: Our Compute component has three implementations: OCI, Hetzner, and DigitalOcean. Because these are built as components, you can swap one for another without touching your DNS or SMTP logic.
Referential Transparency: We utilize “no-infra” components as placeholders. This allows you to bring your own pre-existing infrastructure into the system. You can replace a live resource with its values without changing the behavior of the rest of the stack. In programming, this is called referential transparency; in DevOps, it makes brownfields easier to support.
No Degradation of Experience: Usually, abstractions make debugging harder. BigConfig is designed so that the composition of components doesn’t hide the underlying tools. You can manage the entire Composition as one, or drop down to debug a single component (like a specific Tofu component) without any additional configuration overhead.

Conclusion

We are moving past the era of “Tool-First” DevOps. By adopting a component-based mindset, we can stop managing scripts and start building systems that are as modular, testable, and maintainable as our modern frontend applications.

Would you like to have a follow-up on this topic? What are your thoughts? I’d love to hear your experiences.