Maybe you’ve heard of Infrastructure as Code (IaC), which is the process of managing and provisioning computer data center resources (mostly but not entirely in the cloud) through version-controlled, machine-readable definition files (or configurations), rather than via manual hardware configuration or web consoles at the source. But what is Infrastructure from Code (IfC)? Throughout this post, we’ll talk through what IfC means, how different implementations of it work, and how it differs from IaC.
Infrastructure from code is a new way of thinking about and working with infrastructure provisioning, one that puts the application code at the heart of everything. Rather than creating configuration for infrastructure from scratch, based on your thoughts (or your company’s) on how best to structure infrastructure, you generate the infrastructure your application needs based on the particular version of your application code.
IfC has the benefit of fitting the infrastructure to the changing needs of the application, rather than making your application fit your infrastructure and then trying to treat the infrastructure like software. The Infrastructure from Code approach significantly improves the developer experience, helping streamline processes and accelerating delivery, without anyone having to pick up an entirely new domain of expertise. Depending on the approach to IfC that you choose, you can potentially also use IfC to apply necessary architecture and security standards, all while keeping the benefits of version control.
Infrastructure from Code hasn’t been around all that long, and so new ways to implement it are being discovered and developed all the time. At present, there are four main ways to use IfC:
There’s a good, quick overview of the first three approaches over at InfoQ that is worth checking out. The basic idea is that, presently, you can either try to build your app in a way that accounts for IfC (SDKs and programming languages), or you can use your existing code to come up with IfC (code annotation and code scanning).
Which approach works best for you will depend on your team’s time constraints, experience, interests, and the needs of your company and application. Each has their own pros and cons, with the SDK and programming language approaches ensuring IfC is integrated from the very beginning of the application being built, and the code annotation and code scanning approaches building infrastructure tailored to the app from the code without the need to switch languages or tools. And maybe IaC is working just fine for your whole organization and you don’t see a need for IfC.
IaC really came into being throughout the 2010s. There are a lot of ways to use IaC, from Helm to Terraform to CloudFormation and beyond. And there are a lot of tools offering adjacent IaC solutions that have sprung up to help users, like Spacelift, Rancher, Pulumi and AWS CDK.
As time has gone on and the industry has grown and changed, drawbacks have begun to show in the IaC approach, and questions have arisen about how better to merge application code and infrastructure code. IfC is one answer that’s beginning to gain traction. But how do they compare?
| Infrastructure as Code | Infrastructure from Code |
|
|
|
|
|
|
|
|
|
If you’re interested in trying out the Infrastructure from Code approach, StackGen offers IfC in the newest most low-effort way with a static code scan that reduces intervention and speeds delivery. Try us out by connecting StackGen to your project’s repo, statically scanning your code, reviewing the visualization of the proposed infrastructure, and then generating IaC files for deployment.