How We Evolved from IaC to Environments as Code

In the years I’ve spent building our platform — and working with other DevOps and platform engineers that our product supports — I’ve seen firsthand how the evolution of application infrastructure is breaking the automation it is intended to deliver.

Infrastructure as Code (IaC) tools are invaluable for defining and automating the delivery of cloud services. When a dev team’s needs expand beyond that scope, the automation often breaks down.

This happens for two reasons:

• IaC tools were designed for velocity and automation, not as the source of truth for environments. Large teams can struggle to leverage infrastructure at scale and understand how code changes might disrupt application performance.
• IaC tools don’t play nicely together. Applications increasingly rely on complex infrastructure defined in various technologies, necessitating manual orchestration to reconcile the nuances of the tools.

Developers face a gap between infrastructure automation capabilities and the realities of an application’s needs. The result is diminishing velocity and increased risk of unmanaged or misconfigured infrastructure.

We asked what we could do to bridge that gap, and that led us to a simple question:

What if you could simply launch all environments as code, regardless of the scope of the infrastructure or the IaC tools used to define it?

Defining Environments as Code in Git

To define environments as code, we first needed to define everything a developer needs to launch an environment, in a format that is simultaneously easy for DevOps to understand and machine-readable for automation.

Using our Torque platform, we connected to a Git repository, discovered the IaC modules defined within it and wrapped the resource configurations in a new YAML that was autogenerated by the platform.

From there, we could modify any YAML code to include the infrastructure components, parameters, dependencies, metadata, authentication and outputs the environment will generate upon launch.

This YAML snippet is an example:

This contains a single definition of all the essential metadata for an environment in a structured format.

Put simply, we leveraged our existing infrastructure code to define an environment as code.

Using GitOps to Launch App Environments

To answer our customers’ needs, we needed to operationalize this definition.

Our initial answer was to rely on our self-service portal. When administrators in our platform create one of these YAML files, which we call a “blueprint” for an environment, they can choose to “publish” it. This adds the environment to a self-service catalog in the platform, where those with end-user permissions can launch the environment on demand. For those who integrate environments into developer tools, CI/CD or internal developer portals, publishing a new blueprint makes it accessible through those tools as well.

In order to support teams that embrace GitOps, we needed to integrate published blueprints into the day-to-day workflow.

By storing this new YAML file in the original repository where we discovered the IaC modules, we made the environment definition accessible in a GitOps motion. In effect, we “published” the environment definition for the users with access to that repository.

Now developers can launch the complete environment with a single command.

This approach provides several additional advantages:

• Version control: Just like application code, environments can be versioned, ensuring that every change is tracked and can be rolled back if necessary.
• Consistency: Leveraging this definition provisions environments consistently every time, eliminating the “it works on my machine” problem.
• Speed: Developers can provision environments by simply committing code — a motion they are familiar with — so they can respond to development, testing or production needs quickly and without requiring help from other teams.
• Collaboration and governance: Creating a shared definition of an environment establishes a basis for collaboration that isn’t as easy with IaC alone.
• Operational efficiency: Automating the provisioning process means less redundant manual work (and burnout) for DevOps engineers and more capacity to take on more valuable tasks.

In platform engineering, every second counts and every resource matters. As infrastructure becomes more complex, managing environments as code is the next step in maturity for modern DevOps organizations.