State of Infrastructure from Code 2024

Over the past few years, Infrastructure from Code (IfC) has evolved from an emerging concept to a recognized category in the software development and deployment landscape, gaining recognition from Gartner as part of a new category and being featured in the 2024 Hype Cycles for:

• Software Engineering
• Infrastructure Automation
• Platform Engineering
• I&O Automation

IfC enhances cloud platforms or Infrastructure as Code (IaC) by automating the discovery of infrastructure requirements for applications, resolving the often fragile relationship between application code and the infrastructure it depends on. If IfC is a new concept to you, or you’ve heard of it and want to dive deeper, consider reading this article What is Infrastructure from Code from Nitric's co-founder Jye Cusch.

As the IfC space grows, its adoption promises to reshape how infrastructure is provisioned and managed. Here, we will explore the current state of IfC, examining its maturity, the tools and platforms that have emerged, and the practical implications of its use.

Supporting both development and deployment

There are several distinct approaches emerging to Infrastructure-from-Code.

For developers, the approaches vary by each tool integrates into application code:

• Code analysis tools: Analyze code to infer infrastructure, often using markers like code comments or annotations.
• Language SDKs: Provide SDKs for popular languages, abstracting infrastructure setup while maintaining flexibility.
• New languages: Introduce new languages that unify application and infrastructure logic for deeper integration.

For deployment, the approaches vary significantly, including new hosting platforms, deployment platforms and platform independent tools:

• Platform hosted: Application are deployed to and hosted on new platforms. These platforms are extremely productive and convenient. They're sometimes specialized for a specific application use cases. However, this convenience comes with potential application lock-in.
• Platform assisted: Automation tools assist with deployment to existing cloud providers such as AWS, Google Cloud or Azure. The deployment is supported or enhanced by a new deployment platform. These tools may not always be usable standalone and may be less flexible in terms of target cloud platforms.
• Platform independent: Tools that automate deployment to existing platforms like AWS, Google Cloud and Azure. These tools typically enhance existing IaC tools like Terraform and Pulumi, rather than replace them. The trade-off is that the tools may not enhance the management/monitoring of deployed applications.

The table below maps out various IfC tools based on these development and deployment approaches.

Development experience

Let's explore how the various approaches impact the developer experience.

Code analysis tools

Code analysis tools analyze code to determine runtime requirements and generate Infrastructure as Code (IaC), integrating easily into existing development environments with minimal changes.

Key features:

• Specialized Analysis: Analyzes code within specific programming languages for infrastructure needs, typically via additions such as code annotations.
• Auto-generated IaC: Produces or automates IaC based on code analysis, simplifying infrastructure management.
• Seamless Integration: Integrates easily with existing development environments.

Trade-offs:

• Specific Languages Only: Targets specific languages, requiring an understanding of application code and annotations. This necessitates that operations team members also be familiar with these languages, which can complicate cross-team collaboration and increase the learning curve.
• Annotations: Requires adding annotations to application code to provide adequate context for building specifications. Some solutions use non-standard annotations, which are unfamiliar, even to those with skills in the language.
• Feature Reliance: Dependence on the tool’s roadmap and support. This can limit the team’s ability to innovate or address specific needs independently, potentially slowing down the development process and responsiveness to new requirements.

Example:

Klotho v1 analyzes custom code annotations to detect resources which are led by annotations.

This Go example from the Klotho documentation demonstrates how the platform allows developers to expose a simple HTTP server with routes using the chi router package.

package main

import (
"fmt"
"net/http"

    "github.com/go-chi/chi/v5"
    "github.com/go-chi/chi/v5/middleware"

)

func main() {
    r := chi.NewRouter()
    r.Use(middleware.Logger)

    r.Get("/hello", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello from Klotho!"))
    })

    r.Get("/hello/{name}", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte(fmt.Sprintf("Hello %s!", chi.URLParam(r, "name"))))
    })

    fmt.Println("Listening on :3000")

    /* @klotho::expose {
     *   target = "public"
     *   id = "app"
     * }
     */
    http.ListenAndServe(":3000", r)
}

The key aspect here is the @klotho::expose annotation. Klotho reads this annotation and understands that the application needs to expose the service publicly. Annotations are a non-standard feature in Go, so editors/IDEs typically can’t validate or assist with these annotations without custom extensions.

Once Klotho processes your code, it generates the necessary IaC files, and modifies your application code, substituting the annotation for runtime code, which you can then deploy using Pulumi or Terraform, depending on what was generated. The generated configurations are flexible and can be adjusted or inspected as needed before deployment.

Language SDKs

Language Software Development Kits (SDKs) help developers build and manage Infrastructure as Code (IaC) using the features of existing programming languages. The application code declares resources in a cloud-agnostic way; the IfC tool uses these declarations to automate or generate IaC for the target platform. This approach decouples applications from a 1:1 relationship with IaC projects.

Key features:

• Compatibility: Using standard language features ensures SDK-based approaches automatically work with editors and other tooling. Including auto-complete, type-safety and error highlighting.
• Decoupled Projects: Creates a protocol for applications to communicate their infrastructure needs, decoupled from IaC projects. The IaC still exists and can be maintained, independent from the application.
• Customization and Integration: Enables extensive customization and integration for specific project needs.

Trade-offs:

• Specific Languages Only: Requires separate SDKs for each supported language. This means ongoing updates and potential fragmentation across different language teams.
• Project Structure: While minimal, restrictions may be placed on the structure of projects using these SDKs. This is so tooling can reliably package and deploy the applications. For example, the application may be deployed as Docker containers for consistency.

Example:

Nitric allows developers to define cloud requirements directly in their application code using language-specific SDKs. These requirements are then fulfilled by plugins/engines for each target cloud platform, translating them into the specific resources for that platform.

This Python example illustrates how Nitric can be used to create an API that generates a pre-signed URL for uploading files to a cloud storage bucket.

from nitric.application import Nitric
from nitric.resources import api, bucket

# Create an API and a bucket resource

photo_api = api('main')
photo_bucket = bucket('photos').allow("read")

@photo_api.put('/upload/url/:name')
async def put_upload_url(ctx):
    name = ctx.req.params['name']
    url = await photo_bucket.file(name).upload_url()
    ctx.res.body = {'url': url}

Nitric.run()

The photo_bucket resource is requested with read permissions, and the photo_api defines an endpoint at /upload/url/:name that returns an upload URL for the specified file name. The Nitric SDK uses this information to create a specification of all of the resources and their relationship with each other. During deployment, each resource listed in the specification is mapped to an extensible IaC provider, written in Terraform, Pulumi or another IaC tool, to consistently deploy applications and their required runtime infrastructure.

The application code and deployment code remain separate and highly decoupled, allowing developers and platform engineers to work in isolation.

New languages

A new language that includes native cloud concepts, such as resource declarations, alongside application code. These languages typically require compilers/transpilers to convert the new cloud-specific language to other languages used for application development and Infrastructure as Code (IaC), abstracting away both.

Key features:

• Unified Approach: Combines IfC and IaC, providing a complete solution for managing both application and infrastructure code.
• Enhanced Productivity: Allows application teams to work with abstract, coarse-grained control of cloud APIs, with best practices built in.
• Reduced Boilerplate: Language features directly enable cloud infrastructure management, removing the need for control structures from existing languages that may add boilerplate.

Trade-offs:

• Skillset Overhaul: Existing language and IaC skills are less transferrable, requiring teams to learn a new language and methodology.
• High Transition Cost: Teams may need to rewrite applications and may not be able to leverage existing libraries.
• Reduced Ecosystem: As a new language, tools, libraries, extensions, and community support will be lacking initially, making troubleshooting more challenging.

Example:

Wing is a new programming language designed specifically for cloud applications, with built-in support for both infrastructure and application logic.

In this example from the Wing documentation, you define a cloud storage bucket using Wing's cloud abstraction, which will be compiled to the appropriate cloud provider's equivalent (e.g., an S3 Bucket on AWS).

bring cloud;

let bucket = new cloud.Bucket();

let hello_world = inflight () => {
    bucket.put("hello.txt", "Hello, World!");
};

// Inflights can be deployed as serverless functions
new cloud.Function(hello_world);

The inflight function represents code that will be executed in the cloud (such as a serverless function) and writes a file into a bucket. The cloud.Function creates a serverless function that runs the hello_world inflight code. Wing handles the translation of this high-level code into the specific cloud resources needed to deploy it, much like with language SDKs you can customize IaC providers to take control of the infrastructure that is provisioned.

Deployment experience

Now we will explore the deployment experience of IfC tools and how they balance between control and convenience.

Platform hosted

Platform-hosted IfC approaches abstract away most of the infrastructure management, taking full control of the deployment process and application hosting. These tools and platforms automatically handle resource provisioning, monitoring, scaling, and management. This is typically the most convenient approach. That said, the convenience comes at the cost of portability and flexibility.

Key features:

• Turnkey Experience: Deployment is simplified to a few steps or commands, with most of the infrastructure managed automatically by the platform.
• Full Abstraction: The platform typically manages infrastructure as part of the application lifecycle without user intervention.
• No IaC Interaction: Developers rarely need to interact directly with Infrastructure-as-Code, as the platform abstracts infrastructure as part of the deployment pipeline.

Trade-offs:

• Lack of Control: Developers have minimal ability to customize or modify the infrastructure setup.
• Vendor Lock-In: Platform-managed solutions often rely on specific platforms, creating challenges if migration is needed and limiting pricing options.
• Limited Flexibility: Since the platform controls most of the infrastructure, developers and operations teams are restricted to the features and configurations the platform supports, which may not always fit all use cases.

Platform assisted

Platform-assisted IfC approaches offer tools automate the generation of IaC or replace it entirely, with the assistance of a deployment platform. Use of these platforms can be optional, as an enhancement to the automation tool. Developers can rely on the platform for some parts of the deployment while customizing others.

Key features:

• Deployment Automation: Deployment is automated, with certain parts handled by the platform and others customizable by the user.
• Customizable IaC: Developers typically still have control over infrastructure provisioning and can inject custom IaC into the deployment process.
• Flexibility: Offers a balance between control and convenience, with more flexibility compared to fully managed platforms.

Trade-offs:

• Complexity: Platform-assisted tools can add complexity since users must learn when to rely on automation and when to manually configure certain parts of the deployment.
• Platform lock-in: While the applications being deployed may target a variety of hosts, the platform performing the automation may be fixed. Often these platforms require a subscription to use.
• Maintenance Overhead: The responsibility for certain infrastructure components still falls on the development or operations teams, requiring additional effort for monitoring and management.

Platform independent

Platform independent tools for deployment offer full control to developers and operations teams, using Infrastructure-as-Code (IaC) to specify and manage the entire infrastructure lifecycle. These tools often integrate directly into existing CI/CD pipelines and give developers granular control over every part of the deployment process.

Key features:

• Extensibility: Platform independent tools are easily extensible to IaC components to meet unique infrastructure needs
• Strong Integration: Tools can more seamlessly integrate directly into existing CI/CD pipelines, making them an excellent choice for teams with established automation workflows.

Trade-offs:

• Setup Effort: Platform independent tools require may require more setup and configuration, which can take time, especially for teams new to IaC.
• Runtime Management: These tools typically accelerate development and deployment, but may do little to assist with managing cloud resources once they're deployed.
• Less Intuitive: The ability to customize every aspect of the infrastructure is powerful, but can require expertise in IaC and cloud platforms to manage effectively.

Language support in IfC

Different Infrastructure from Code (IfC) solutions adopt various strategies for language support. By understanding these approaches, organizations can evaluate which IfC solution aligns with their needs and existing development practices.

Specific language

Some IfC solutions focus on a single programming language, streamlining development processes and optimizing performance for that particular language. This can lead to deeper integration and potentially more powerful language-specific features.

Trade-offs:

• Limited Scope: The solution is only available to developers using that specific language.
• Integration Challenges: Organizations may face difficulties integrating such solutions into polyglot environments.

New language

There is also the option of creating a new language designed specifically for defining infrastructure. This language can offer unique features tailored for infrastructure management and can avoid some pitfalls of long-evolved Infrastructure as Code (IaC) tools.

Trade-offs:

• Learning Curve: Developers must invest time in learning the new language.
• High Transition Cost: Teams need to rewrite application code and may not be able to leverage existing libraries for application code or IaC.
• Lack of Community Support: Initial community support may be lacking, making troubleshooting more challenging.

Language annotations

Some IfC solutions use annotations within existing programming languages to define infrastructure. This method provides a seamless development experience by embedding infrastructure definitions directly within application code.

Trade-offs:

• Complexity: Requires developers to learn and apply specific annotations correctly, which can complicate codebases and reduce readability.
• Limited Flexibility: Annotations may not fully leverage the capabilities of the underlying language or infrastructure, potentially limiting control.
• Testing Challenges: By avoiding typical programming constructs such as function calls, mocking and other test strategies can be more challenging.
• Non-standard Annotations: Some solutions opt for non-standard annotations in the form of code comments, instead of using existing annotation features of the specific language. This greatly reduces the effectiveness of existing language tools and IDEs in detecting errors.

Language-agnostic

Language-agnostic approaches do not tie themselves to any specific programming language. This flexibility allows developers to use their preferred languages, leveraging existing skills and codebases.

Trade-offs:

• Maintenance Burden: The team managing the framework must maintain support for multiple languages.
• Less idiomatic: Supporting multiple languages with a consistent experience may mean avoiding unique features in any specific language.

Will IfC eventually replace IaC?

Two of the most common questions we are asked when introducing IfC are:

• Does IfC replace Infrastructure as Code (IaC)?
• Can I use IfC without discarding years of investment in IaC tools like Terraform or Pulumi?

The short answer is that many, but not all, IfC solutions aim to replace IaC and this is a key differentiator between the available options.

Replacing IaC with IfC

Replacing Infrastructure as Code (IaC) with Infrastructure from Code (IfC) offers the potential for a more streamlined and integrated approach to cloud infrastructure management. By moving away from traditional IaC, development teams can reduce the complexity and specialized knowledge required, making infrastructure management more accessible.

This approach can simplify workflows, allowing teams to focus more on coding and delivering features rather than dealing with the intricacies of infrastructure management. IfC solutions can also provide a higher level of abstraction, which can lead to faster iteration cycles for teams who do not want a deeper understanding of how their runtime is provisioned, just that it works.

Trade-offs

• Limited Versatility: May not replicate the flexibility and broad support of mature IaC tools like Terraform, especially for complex or multi-cloud environments.
• Transition Effort: Requires significant retooling and retraining, particularly for teams deeply embedded in existing IaC practices.
• Reduced Flexibility: Replacing IaC may limit the ability to manage diverse cloud environments effectively

Solutions that replace IaC

Complementing IaC with IfC

Complementing Infrastructure as Code (IaC) with Infrastructure from Code (IfC) allows organizations to enhance their existing infrastructure management practices without abandoning their current investments.

By integrating IfC alongside IaC, teams can bring automation to their current workflow to eliminate some of the manual and error-prone processes allowing their developers to focus on application code and their operations to focus on infrastructure code. Basically, teams can maintain their familiar workflows and tools, while benefiting from the added automation and capabilities that IfC brings.

This strategy supports gradual adoption, enabling organizations to evolve their infrastructure management practices at their own pace, ensuring a smoother transition and reducing the risk of disruption.

Trade-offs

• Integration Challenges: Requires careful planning to ensure compatibility and maximize the benefits of both approaches.
• Learning Curve: Teams may face a learning curve as they integrate new IfC tools into their established IaC ecosystem.

Solutions that complement IaC

A Convergence on the future state

At Nitric, we've always believed that an open-source, multi-language, SDK-based approach was the right way forward. This approach ensures flexibility, broadens accessibility, and fosters innovation by enabling developers to work in their preferred languages and leverage the tools they are most comfortable with.

Over the last few years, we’ve learned that some teams prefer to maintain fine-grained control over their infrastructure and will sacrifice some convenience in service of that goal. That's why we designed Nitric to complement IaC tools like Terraform, giving you both control and convenience. By prioritizing open-source development, we contribute to a community-driven ecosystem where collaboration and transparency drive continuous improvement.

Other vendors in the IfC space appear to be coming to similar conclusions. For instance, Encore added multi-language support and is embracing open-source principles. Wing has started offering a TypeScript SDK, rather than being exclusively focused on building their own language.

These changes across the landscape suggest a growing recognition of the benefits of open-source, multi-language, SDK-based solutions and are changes we're glad to see.

What’s next?

The Nitric framework aims to bring speed and governance to existing projects and teams, not by creating a black box or introducing new skills to learn, but rather by allowing teams to adopt a technology that complements existing tools and skills.

Take a look at some of the features we’ve been working on:

• SQL Databases
• Visualizing your infrastructure
• Terraform providers