Infrastructure in 2035: Anton Babenko on Moving Beyond 'As-Code'

Terraform taught us that "infrastructure-as-code" is a very good idea compared to not having it in any scriptable and reproducible format. I personally like that HCL is limited by design, so that it's very hard to do things you normally shouldn't be doing with infrastructure, compared to generic programming languages.

I often see how developers try to jump over these limitations and, using CDK, come up with overengineered and messy solutions. I like that if Terraform is used properly, the final solution will be easier to manage and work on later. Terraform is more restricted – it's a good thing when you want to manage infrastructure reliably, not "vibeform"-ing your way to production.

Part of the reconciliation process is already doable and highly recommended if you run "terraform plan" regularly and automatically. Applying such changes is a significantly harder part, but using policies and guardrails, it should be possible. I have not met companies that apply the step automatically.

The deliberate nature of infrastructure changes is important – most infrastructure changes are high-stakes and require careful consideration. While automation can help with detection and planning, the application of changes still needs human oversight in most organizations.

Absolutely, I believe that the "infrastructure-as-code" term coined by current set of tools will be phased out in a few years. There will still be a long tail of companies using current tools and established "as-code" approaches.

Currently, some new set of tools are more revolutionary and harder to comprehend than their potential customers expect them to be. I think that the winner in the next generation of infrastructure management tools will have a more responsive interface, and it's not necessarily going to be "as-code."

Most progressive users (it's hard to predict 10 years) will not write HCL or manage configurations as complex code – bye-bye CDK. In the coming few years, the demand will be coming more from higher-level stakeholders, and the implementation will happen mostly with the help of a variety of canned solutions (e.g., Terraform modules) governed by policies, controls, and guardrails.

The shift isn't just about tools – it's about who's making infrastructure decisions. As infrastructure becomes more abstracted, business stakeholders will have more direct input, with implementation happening through pre-built, policy-governed components rather than hand-written code.