Developers should deploy their own code but usually don’t today. But AI might change that.
Infrastructure as code (IaC) won’t be written by humans. Cloud engineers have been trying to find the perfect abstraction for infrastructure-as-code for almost a decade (Terraform was released in 2014). Despite some success, there’s still a rift in adoption. Most teams use higher-level services that specialize in developer experience — Vercel, Railway, Render, Fly, or a host of other PaaS. It’s just easier. Those who adopt infrastructure-as-code must have specialized DevOps or platform teams focusing solely on writing this code. Teams get reproducibility and security of assets but rarely get the speed-ups or developer experience of quickly inferring and deploying applications with infrastructure-as-code. Platform teams often expose non-code interfaces for application teams (even if they use IaC under the covers).
But AI will change that. AI will write the majority of infrastructure-as-code. It might be inferred just in time. It might automatically convert infrastructure between providers, even when one-to-one mappings don’t exist (e.g., AWS to GCP or back again).
Some ideas for IaC + AI:
Automatically inferred infrastructure components for application code. Given a function, a server component, or some “application” to run, generate the necessary infrastructure to deploy the code. This has been tried many times, but it is an insurmountable problem for a rules-based engine. There are too many configurations to automatically infer. It requires knowledge of application frameworks, cloud providers, and deployment patterns.
Convert infrastructure between providers. Convert an AWS Terraform template to Google Cloud Terraform (or vice versa). There’s no one-to-one mapping, so any rules-based automation will fail. Instead, the mapping needs to be fuzzy — something that LLMs can do today. Instead of mapping resources, the AI can map intent (e.g., deploy an autoscaling webserver via a container).
The heart of the problem is that any middleware libraries ultimately are at the mercy of the underlying cloud APIs. (For AWS, that means CloudFormation). Any abstraction over these APIs is inherently leaky. Worse yet, cloud providers have a strong incentive against making their APIs compatible or equivalent to their competitors. So, IaC ends up being provider-specific, which limits how easy it can be.
But AI can solve this (and not just in a hand-wavy way). Cloud APIs must be stable and supported long-term. The EC2 API does not materially change every month or even year. Likewise, the economies of scale that make the cloud so profitable also mean plenty of customers for every API to produce good training data.
Help developers write their own IaC. Many products have promised developers they could “just write their code” and magically provision the infrastructure. So far, these have fallen short. It’s hard to describe infrastructure right next to code, and it’s hard to turn DevOps abstractions into something that application developers can (and want) to learn.
Developers should deploy their own code, but it’s tough today. AI might be able to build over these fuzzy layers. Given some code, what is the best way to deploy it on the cloud? Once the infrastructure is inferred, it should be fairly easy to generate declarative templates that developers can verify before they deploy.
Changesets for complicated templates. It’s easy for providers to dump a Helm chart or a long set of Kubernetes configurations for customers to deploy. And it works — until the user needs to configure anything outside the golden path. That’s when the pain of sifting through thousands of lines of configuration comes in. This is why templates only delay complexity rather than solve it. But AI can look deeply into large swaths of configuration and suggest the correct changesets needed for a configuration change. This still doesn’t entirely mask the complexity, but it kicks it further down the line (possibly enough for developers to get much further.