Infrastructure from Code FAQ

At Open Source Summit North America in April, Anmol Sachdeva and Kingsley Madikaegbu from Google presented on Infrastructure from Code (IfC) – explaining the evolution leading to this technology, how it solves some challenges with Infrastructure as Code (IaC), and demoing Nitric as an open source project you can use to start exploring IfC yourself. Check out their full presentation on YouTube.

The questions asked by attendees of the presentation had a lot of alignment with the questions we often hear from folks first learning about IfC, so we were inspired to share those here alongside other common questions about IfC. The answers from Anmol, Kingsley and our team can help you place IfC alongside existing processes and technologies you may be using.

What is Infrastructure from Code (IfC)?

IfC is a new paradigm for productive and cost-efficient cloud development. IfC removes complexity from cloud development and deployment by automating infrastructure requirements. It analyzes application code, creates a resource specification and then automatically provisions the right resources from that code to the target deployment environment.

The core of your application becomes the source of truth for both the application logic and deployment architecture. This approach removes the often brittle relationship between infrastructure projects that deploy resources and the application code that depends on them.

Leveraging IfC lets teams scale DevOps without the complexity and maintenance burden associated with manual infrastructure provisioning work. It improves the experience for developers as they can focus on building their core application logic rather than on infrastructure and provisioning. And it gives platform engineers the ability to implement consistent technologies, configuration and policies to maintain compliance.

Does using IfC remove the ability to have fine-grained control over infrastructure?

Not if you want that control. While the convenience IfC offers is the main benefit, it can allow for the control needed by advanced teams. You can get started quickly with the best-practice starting points that IfC frameworks offer, and some also allow you to make changes to specify exactly how your infrastructure will be deployed.

For example, Nitric interprets the resource specification and translates the requirements to IaC modules. By modifying those modules you can directly control the interpretation of the resource specification. Here is an example of a Terraform module you can leverage with Nitric to deploy all CloudRun instances on GCP; the fine-grained configuration is in your control.

# A Google CloudRun resource
resource "google_cloud_run_service" "nitric_compute" {
  name     = replace("${var.service_name}", "_", "-")
  location = var.region
  project  = var.project_id
  autogenerate_revision_name = true

  template {
    spec {
      service_account_name = google_service_account.service_account.email

      containers {
        image = "gcr.io/${var.project_id}/${var.service_name}"
        ports {
          container_port = 9001
        }
        args = var.cmd

        env {
          name = "NITRIC_STACK_ID"
          value = var.stack_id
        }

        env {
          name = "NITRIC_ENVIRONMENT"
          value = "cloud"
        }

        env {
          name = "GCP_REGION"
          value = var.region
        }

        env {
          name = "SERVICE_ACCOUNT_EMAIL"
          value = google_service_account.service_account.email
        }
      }
    }
  }

  traffic {
    percent         = 100
    latest_revision = true
  }

  depends_on = [
    docker_registry_image.repo_image,
    # Add other dependencies here
  ]
}

How is the platform team involved with IfC?

Platform engineering is able to lay down company-specific or organization-specific guardrails as part of the team’s use of IfC; they determine the infrastructure practices. For example, if the developer has a resource such as a key value store which allows "get" and "set", the platform team may determine not to use predefined IAM, which could be too permissive, but instead some restricted custom roles, which could be really very strict in nature.

There could be some other things that you may want to enforce as part of your standardization and governance journeys. This is where the platform engineering team will write custom providers on top of Nitric or any other platform. They’ll code in golang or or whatever the provider has been written in, but it's extensible. There are already tested, vetted patterns available for different providers and you can tweak those according to your governance standards.

How is Nitric/IfC different from IaC?

IfC complements IaC by bridging the communications gap between the application and its runtime environment. IfC automatically infers the application’s requirements, which means that you don’t have to manually synchronize the differences as you would when using IaC on its own.

IaC is ultimately what provisions the infrastructure. IfC cannot perform its duties without having modules written in IaC to fulfill the applications requirements. With Nitric, we currently use Pulumi’s automation engine to streamline the deployment process, so the IaC component is more behind-the-scenes.

So how does Nitric compare with Pulumi?

Nitric is an IfC tool, whereas Pulumi is IaC. Pulumi is more oriented towards a CDK approach wherein you are using programming languages to define the infrastructure. Your application code is still separate, but you can use Pulumi Automation APIs to embed your infrastructure code that you have written in Pulumi within your application.

With Nitric, you aren’t really focusing on any infrastructure code. Instead you’re just writing an application, and you're having the infrastructure interpreted and then inferred and it automatically gets deployed (leveraging Pulumi IaC for our v1 standard providers).

Check out some more differences between Pulumi and Nitric in the documentation.

Can IfC work in an on-premise environment?

Yes, technically this is possible, especially with the design concepts behind providers in the Nitric framework. Providers are separate plugins comprising two components—a Deployment Engine, which automatically deploys your resources, and a Runtime Adapter, which handles requests from the SDKs and forwards them to the appropriate service APIs.

Nitric built providers to be flexible to work with any framework. While our standard providers currently support AWS, Google and Azure, we’d love to work with teams interested in other clouds or on-premise use cases.

Reach out in our Discord or set up time with us to discuss if you’re interested.

How should I introduce IfC to my team?

First help your team understand the pain points that are there associated with IaC and the kind of velocity that you can bring by adopting the IfC pattern.

Check out these articles for some interesting results to reference:

Then you could do some PoCs. For example, come up with applications and share your time in development and time to go to market; let's say it was only one week because you just focused on application code and writing a solid application rather than focusing on how the DevOps cycle would look. By the time you present this to your team, you didn't have to reach out to talk with platform teams and think about dependencies. Moreover the platform teams really did not have to know about your applications.

That concept is important, that it's a two-way street. It's not just about application developers or developer experience getting refined. It's also about the platform team members – or DevOps engineers, infrastructure system administrators, whatever personas there are who generally deal with infrastructure – not needing to spend time and manage the specific, individual application from a deployment perspective. Of course, site reliability engineers (SRE) do need to know about the reliability aspects of an application, so they need to be aware of the application codebase, but platform or or infrastructure administrators who really deal with IaC stuff can have a big burden reduction.

When communicating with your team, also be clear that IfC doesn’t have to be a replacement for IaC. It's complementary, depending on your strategy.

Thanks again to Anmol and Kingsley for a great talk!

If you have further questions about IfC, come chat with our team anytime in Discord. We’d be happy to chat about the concepts and how they fit in with the tech you’re using today.