Don’t Sacrifice Developer Experience for Platform Governance
Infrastructure as Code (IaC) tools, such as Terraform and Pulumi, have undeniably transformed the way we manage cloud infrastructure. While these tools are invaluable, there’s always potential to further enhance and optimize the workflow for both operations teams and developers. I’m part of one of the teams forging the emerging Infrastructure from Code (IfC) approach. Our goal with Nitric and IfC isn’t to replace these tools but to harmonize with them.
We’re building capabilities to streamline the entire deployment process, inferring intricate infrastructure code directly from the application itself. Instead of overwriting the IaC toolchain, we’ve integrated it seamlessly into our process. This ensures that operations teams can continue using their preferred IaC tools, while developers benefit from a more intuitive interface.
IaC DX Could Use a Revamp
When we talk about the developer experience (DX) gap in relation to IaC, we are referring to the disconnect many developers feel when moving from application development into the realm of infrastructure provisioning and management. Traditional IaC tools, while powerful, often come with a steep learning curve. They require developers to think in terms of cloud resources, configurations and dependencies, which can be quite distant from their core application logic.
This makes it easy to get bogged down by the nuances of each specific cloud provider. Whether it’s the intricacies of identity and access management (IAM) roles on AWS, networking rules on GCP or storage configurations on Azure, the devil is always in the details. This complexity derails our teams from providing core business value.
Drastically Improving DX with Self-Service
Let’s explore how we’ve crafted a platform engineering tool that uses IaC modules to automatically generate and fulfill resource specifications directly from your code. Here’s a snippet of code enabling users to fetch a download URL from their storage bucket:
|
1 2 3 4 5 6 7 8 9 |
import { api, bucket } from "@nitric/sdk"; const photoApi = api('photos'); const photos = bucket('myPhotos').for('reading'); photoApi.get("/photo/:path", async (ctx) => { const { path } = ctx.req.params; ctx.res.body = await photos.file(path).getDownloadUrl(); }); |
The Nitric CLI inspects this code, automating the creation of a detailed specification that comprises a list of resources and global attributes. This list includes resources like an API, bucket and execution unit, alongside the necessary information to configure them for the cloud.
The resource specification clearly defines the deploy and runtime requirements of the application, which allows us to produce resource diagrams and documentation that live alongside the project.
Importantly, it also plays a role in addressing rogue infrastructure and drift. Any time we change the application code, at deploy or local runtime, the resource specification is automatically updated to add/remove/modify resources to align with the requirements of the application.
So, we have a resource specification autogenerated; the next logical question is “How do we convert this spec into deployed resources?”
Bring Your IaC to the Party
Here’s where integration with Infrastructure as Code tools like Pulumi and Terraform becomes essential. They act as the powerhouses that fulfill provisioning requests. We aim to eliminate the need for each project team to maintain a version of the IaC code alongside their project. Instead, the Nitric framework automatically fulfills the resource specification.
At its core, Nitric is defined by its provider system. These cloud providers function as plugins, divided into two main types:
- Deployment Provider: Interprets a resource specification and turns it into tangible cloud resources. Examples include provisioning an API gateway or a bucket.
- Runtime Provider: Converts abstract SDK calls into specific cloud API requests. Examples include publishing a topic or reading/writing from a bucket.
The Deployment Provider
Using Pulumi deployment code to set up an S3 bucket could look something like this. The code iterates through the resource specification, gathering the necessary details to establish a bucket resource.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
for _, res := range request.Spec.Resources { switch b := res.Config.(type) { case *deploy.Resource_Bucket: s3Bucket, err := s3.NewBucket(ctx, b.Bucket, &s3.BucketArgs{ Tags: pulumi.StringMap{ "x-nitric-project": pulumi.String(ctx.Project()), "x-nitric-stack": pulumi.String(ctx.Stack()), "x-nitric-name": pulumi.String(b.Bucket), } }) if err != nil { return nil, errors.WithMessage(err, "s3 bucket "+name) } } } |
The primary advantage is that deployments become both more declarative and reproducible. Additionally, it encourages the reuse of modules and templates, expediting and standardizing deployments. This modularized method is essentially future proof, allowing flexibility in resource configuration, choice of provisioning tool and even future cloud targeting.
The Runtime Provider
Beyond deployments, Nitric ensures that runtime interactions with cloud resources are abstracted. SDKs are mapped to the appropriate cloud APIs. For instance:
|
1 2 |
const images = bucket("images").for("writing"); bucket.file('cat.png').write(data); |
The write command is mapped to a provider implementation, which fulfills the write request as follows:
Note: The Nitric framework is open source, and the providers are written in Go with the Pulumi automation engine for AWS, GCP and Azure that are packed full of best practices. Requests to provider implementations are made with gRPC, allowing the provider to be written in any language you prefer. Learn more about gRPC and our use of it in this blog post written by our CTO Tim Holm.
Building Bridges and Tearing Down Walls
Nitric automatically produces a detailed resource specification from developer-written code. This spec acts as a conduit, enabling operations teams to use their preferred IaC tools to provision the exact resources required. It’s a collaborative interplay between code, specification and infrastructure, ensuring that all teams are aligned.
For operations teams, this integration means oversight and governance without compromising scale and performance using their favorite IaC tools without digging deep into app-specific details.
For developers, it means a streamlined deployment process, where they stipulate their needs, and Nitric, in tandem with IaC tools, brings them to fruition.
The Nitric community is blossoming, and we’d be thrilled to connect with you. There are various ways to show your support. Learn more about Nitric and engage in lively discussions on our Discord channel. Give us a star on GitHub to show your enthusiasm for our mission, and join us in reshaping platform engineering.
