DEV Community: Rak

AI sped up development, not shipping

Rak — Mon, 30 Mar 2026 18:20:10 +0000

AI can generate Terraform, but generating it was never the hard part — trusting and deploying it is.

AI made me faster at writing code, not shipping it

The way I build software has changed more in the last year than in the decade before it. Take a decision like whether to process a new order with a background job or a webhook. Before AI tooling, the workflow looked something like this: identify the problem, spend time researching the tradeoffs, check how others had solved it in similar systems, form a plan, write the code, test it locally, then do everything needed to actually ship it. The whole thing, from identifying the problem to having it running in production, might take a couple of days or weeks depending on the feature.

Now I give an agent the context it needs, the codebase, the outcome, the constraints, and each option comes back as working code (usually) in minutes. The research, the planning, the implementation are compressed. We’re now looking at hours not days, and this is including the time it takes to review the result and wrestle with the AI to get to the end state that I had in mind.

That's not unique to me, I see it both in my organization and amongst my dev friends, AI is fundamentally changing the first half of the journey from problem to production. What hasn't changed much, is everything that happens after the code is written.

Every application has a shadow project

Behind every application in production there's a second project that nobody outside the immediate work ever sees. It's the infrastructure-as-code that provisions your databases and caches, the CI/CD pipeline config that builds and ships the containers, the Dockerfile, and sets the environment variables across staging and prod.

The two projects depend on each other but move independently. Add a service and the deployment project needs matching infrastructure. Add a queue and the pipeline config needs updating. Even something as trivial as changing a port can require an update to the infrastructure configuration.

During my review of the background job I found the performance wasn't good enough, fed that back to the agent, and it came back with a revised approach using a Redis cache. Once I had Redis running locally via Docker it worked perfectly, but from where the agent sits, the application code is the whole picture. It has no idea that Redis now needs to be provisioned, that the pipeline config needs an environment variable, or that staging and prod need to stay in sync.

Keeping the two projects in sync was already one of the harder parts of backend development. Teams hired platform engineers to manage it, but it remained and it was still a common source of production incidents. AI didn't create the problem, it just made it untenable. The problem now is that an agent can introduce new infrastructure requirements every time I prompt it, and it has no idea the shadow project exists.

Just generate the Terraform at the same time

The obvious response is to have the agent generate the deployment project alongside the application code. When the agent adds Redis, have it also write the Terraform module, the pipeline config, and the environment variables at the same time so both projects stay in sync.

The thing is, generating Terraform isn't the hard part. It's really not that different from leveraging an old project or selecting from a library of templates. The hard part is trusting it.

When an agent writes application code, there's a wealth of open source references, community patterns, and established conventions to validate against. IaC is different. It's privately held, idiosyncratic, and often tailored specifically for the application it's coupled to. There's no easy way to know whether what you're looking at reflects best practice or just how the last person happened to solve it. A misconfigured IAM policy or an incorrectly sized database doesn't throw an exception or print a stack trace. It either silently costs money or takes down production in a way that's genuinely difficult to debug.

Whether you write it yourself or generate it, someone has to review it before it touches production. That means verifying IAM policies aren't overly permissive, checking security groups are scoped correctly, confirming instance sizing makes sense for the workload, and running static analysis on the output before applying through staging and production. The work shifts from writing and reviewing Terraform to reviewing AI-generated Terraform, but you didn't write it, so you have to check everything with a fine-toothed comb.
Terraform wasn't built for this

I want to be clear that this isn't unique to Terraform. The same arguments apply to pretty much all IaC tools. The workflow Terraform enforces exists for good reason: plan, review, approve, apply, verify, repeat across environments. Infrastructure mistakes are expensive and sometimes irreversible, and when you're exposing your entire cloud provider's API surface including every IAM policy, every network rule, and every storage configuration, that level of scrutiny is genuinely warranted. The problem is that workflow was designed for infrastructure that changes infrequently and deliberately. It assumes the person writing the Terraform understands the full context of what they're configuring.

AI-assisted development breaks both of those assumptions at once. Infrastructure changes aren't just new resources, they're configuration updates, scaling adjustments, environment variables, and things being removed. During early development and every time a feature is added or removed, the rate of change spikes. Those are exactly the moments when you're moving fastest and leaning on an agent the most.

Think about what just happened with Redis, with just one performance issue during an iteration with your AI and the codebase had a new infrastructure dependency. That wasn't a deliberate decision made in a planning meeting, it was a side effect of a five minute conversation. The person reviewing is no longer reading decisions they made themselves, they're auditing a stream of generated output that has the potential to change the infrastructure in ways that are easy to miss and expensive to get wrong. The review process exists to catch exactly those mistakes, but it wasn't designed to run at this pace. So I'm either keeping up thorough reviews and becoming the bottleneck, or skipping them and accepting the risks.

I just want to show off my app

Frontend teams went through this transition years ago and it wasn't just that Vercel was more convenient. It's that the pace of frontend development made the old model impractical. Frameworks were proliferating, build tooling was changing constantly, and the effort required to keep Nginx configs, SSL certs, and CI/CD pipelines current with all of it had quietly become a job in itself.

When I first used Vercel for a frontend project, what struck me most was the ability to show someone what I'd built straight away, without having to configure a million things and hoping everything was right. Even if there were a few kinks to work out like bot protection or firewall rules, they could be resolved in minutes.

Teams that moved to Vercel didn't do it because they couldn't manage their own infrastructure. Many of them were very good at it. They did it because the return on that investment had collapsed.

Push to production

There are a few ways to close the gap between writing code and shipping it. Some teams that I have spoken to are adapting their review processes with lighter touch on low-risk changes and stricter gates before production. Others are looking to build or further adapt their internal platforms to encode guardrails and reduce per-change overhead. Both are reasonable, but neither gets you out of the review cycle; they just make it more manageable.

There's a specific feeling most backend developers rarely get to experience: finishing something and being able to share it immediately.

That's what we've been working towards with Suga, and it could be an interesting option for you if you aren’t looking to maintain a shadow project. The review, the auditability, the environment parity still matter, the question is whether they have to come bundled with a separate repo, a pile of YAML, and a review workflow that wasn't designed for the pace we're now working at.

Connect your repository, define your services on a canvas, and a push to your branch handles the rest.

Deploying a Sentiment Analysis API with Nitric and Python

Rak — Tue, 08 Apr 2025 18:58:47 +0000

Deploying a Sentiment Analysis API with Nitric and Python

In this guide, you’ll build a serverless API using Nitric and Python that performs sentiment analysis on text input using a pre-trained machine learning model. You'll use the transformers library from Hugging Face and keep your project lightweight by installing dependencies directly with uv.

What You'll Build

A POST /analyze HTTP endpoint
A Python function that loads and uses an ML model
A serverless app you can run locally and deploy to the cloud

Prerequisites

Python 3.10+
Nitric CLI Install using official instructions
uv Install from https://github.com/astral-sh/uv
- (optional) Your choice of an AWS, GCP or Azure account

Create a New Project

Create a new Nitric Python project:

nitric new ml-api py-starter
cd ml-api

Install Dependencies

Use uv to install your required libraries:

uv add torch transformers==4.39.3

Write the Sentiment API

Open or create the file functions/api.py and add the following:

from nitric.resources import api
from nitric.application import Nitric
from transformers import pipeline

# Load the model once globally
analyzer = pipeline("sentiment-analysis", model="ProsusAI/finbert")

# Define an API
ml_api = api("ml-api")

@ml_api.post("/analyze")
async def analyze(ctx):
    body = ctx.req.json
    text = body.get("text")

    if not text:
        ctx.res.status = 400
        ctx.res.body = {"error": "Missing 'text' field"}
        return

    result = analyzer(text)[0]

    ctx.res.body = {
        "sentiment": result["label"],
        "confidence": round(result["score"], 3)
    }

# Create the Nitric app and run it
Nitric.run()

This defines an API route that accepts a POST /analyze request and returns the sentiment and confidence score based on the input text.

Run Locally

Start your app locally using the Nitric CLI:

nitric start

Once running, test it using the dashboard - http://localhost:49152/

Or you can use cURL:

curl -X POST http://localhost:4001/analyze \
  -H "Content-Type: application/json" \
  -d '{"text": "The market is showing strong signs of recovery."}'

Example response:

{
  "sentiment": "positive",
  "confidence": 0.996
}

⚠️ The first request may take a few seconds as the model is downloaded.

Deploy to the Cloud

Step 1: Create a Stack

nitric stack new dev aws

Edit nitric.dev.yaml:

provider: nitric/aws@latest
region: us-east-1

You can also use gcp or azure depending on your cloud preference.

Step 2: Deploy

nitric up

Nitric will:

Package your function (including installed ML libraries)
Provision the API Gateway and runtime
Deploy to your cloud account

The CLI will print the public URL when deployment is complete.

Test the Deployed API

Replace <your-url> with the deployed API base URL:

curl -X POST https://<your-url>/analyze \
  -H "Content-Type: application/json" \
  -d '{"text": "Interest rates are expected to rise."}'

Clean Up

To destroy the cloud stack and avoid charges:

nitric down

Summary

You built a serverless ML inference API
Ran it locally with Nitric
Deployed it to the cloud with one command

You can now adapt this pattern for other use cases like classification, moderation, or lightweight recommendations.

Separating Concerns: Developers vs. Operations

Rak — Wed, 08 Jan 2025 16:16:22 +0000

When you’re building applications for the cloud, you naturally use a cloud provider’s SDK—AWS, Google Cloud, or Microsoft Azure, for example—to interact with services like storage buckets, queues, or databases. What seems straightforward at first can grow into a challenge. Before you know it, your application logic is tangled up in cloud-specific configuration, and two critical teams—Development and Operations—end up stepping on each other’s toes.

The Real Cost of Mixing Code and Cloud Config

Cloud SDKs were designed to make cloud resources easy to access from your codebase. But the convenience they bring also drags provisioning details into application code. In other words, a developer writes logic to “store a file” and ends up having to specify which S3 bucket, its region, and the permission settings. This bleeds infrastructure concerns into the application domain.

For developers, this means spending extra time wrangling IAM permissions and resource configurations instead of focusing on product features.

For operations, it forces them to decode the application’s code just to understand everything that needs provisioning. Suddenly, managing the application’s infrastructure is more about code archaeology than consistent, reliable deployment strategies.

Why Separating Concerns Matters

In well-functioning organizations, developers and operations each have distinct objectives:

Developers want to deliver business value quickly. They need to focus on crafting features and refining user experiences, not dealing with the specifics of IAM policies or message queue retention.
Operations want to ensure those applications run reliably, securely, and cost-effectively in production. They need the freedom to optimize and manage cloud services without rewriting application code.

When either side is forced to handle the other’s responsibilities, it creates friction. This friction can manifest as slower deployments, increased bugs, and a lot of confusion about who is responsible for what.

A Better Way

The key to restoring order is to isolate cloud resource details behind an abstraction. Instead of importing AWS S3 or Google Cloud Storage SDKs directly in your application code, you can use a framework like Nitric that exposes common operations—like creating an API route or storing a file—without tying you to a specific cloud provider.

Consider this code snippet (TypeScript):

import { schedule, bucket } from '@nitric/sdk'

const profiles = bucket('profiles').allow('write'); // Developer expresses "write" intent

schedule('process-often').every('1 days', async (ctx) => {
  const profile = 'image data';
  await profiles.file('image.png').write(profile); // Developer doesn't worry about S3 or GCS
});

Developer’s Perspective

Developers can now write application logic with minimal infrastructure distractions. They know there’s a storage bucket available, but they don’t need to specify which region it’s in or which encryption rules are in place. Their code focuses on creating user value—storing images, sending messages, processing events, etc.

Operations’ Perspective

Operations sees a clearly defined “bucket” resource. They decide whether it’s an S3 bucket, a GCS bucket, or something else. They can choose to enable cross-region replication or encryption, all within their own IaC configuration. Developers aren’t forced to refactor or even touch the code; the ops team simply updates the infrastructure modules as needed.

The Missing Link: Automating the Specification

Abstracting the cloud details is only half the battle. You also need a mechanism to document and communicate which resources each application needs.

Tools like Nitric scan your code to gather a specification of resources used at runtime:

Buckets
Schedules
Queues or Topics
Access policies
Services

That spec is automatically generated—no guesswork. As a result:

Developers don’t have to manually create or maintain a list of necessary resources.
Operations receives a clear map of what the application needs, making provisioning easier and more consistent.

Here’s an example of the kind of specification that might be generated:

{
  "resources": [
    {
      "id": { "type": "Bucket", "name": "profiles" },
      "bucket": {}
    },
    {
      "id": { "type": "Schedule", "name": "process-often" },
      "schedule": {
        "target": { "service": "demo_services-hello" },
        "every": { "rate": "1 days" }
      }
    },
    ...
  ]
}

Converting Specifications into IaC

Once you have a consolidated specification, you can “transpile” it into Terraform, CloudFormation, or other Infrastructure as Code (IaC) tools. For instance, Nitric can automatically generate a Terraform stack using the CDK for Terraform (CDKTF).

Developers remain blissfully unaware of the provider-specific config.
Operations is free to create or reuse modules that set up buckets, schedules, or messages exactly how they want. They can decide on replication strategies, naming conventions, and compliance rules—all outside the application code.

The Outcome: Clear Boundaries, Less Friction

By pushing cloud-specific details out of application code, teams can return to their core competencies:

Developers focus on creating rich features and experiences.
Operations ensures robust, secure, and efficient infrastructure.

This is a sustainable model that benefits both sides:

Less context-switching: Developers don’t wade into Ops territory.
Fewer misconfigurations: Operations controls provisioning details centrally.
Faster deployments: Changes no longer hinge on back-and-forth clarifications or digging into code to find resource dependencies.

Conclusion: Level Up Your Dev–Ops Collaboration

Separation of concerns isn’t a new concept, but it’s often overlooked in cloud development. Mixing infrastructure configurations directly into application code can weigh down both developers and operations, slowing innovation and complicating deployments. By abstracting away cloud SDKs and automating infrastructure specifications, each team can focus on what they do best.

Ready to see it in action? Explore Nitric to discover how you can simplify your application code, streamline provisioning, and enjoy smoother collaboration between Dev and Ops. It’s a win for developer creativity, a win for operational control—and a big win for your entire organization.

Llama 3.2 on Lambda

Rak — Mon, 25 Nov 2024 14:08:21 +0000

Llama 3.2 1B is a lightweight AI model that makes it interesting for serverless applications since it can be run relatively quickly without requiring GPU acceleration.

We’ll use models from Hugging Face and Nitric to demonstrate using it and manage the surrounding infrastructure, such as API routes and deployments.

Prerequisites

uv — for Python dependency management
The Nitric CLI
(optional) An AWS account

Project Setup

Let’s start by creating a new project using Nitric’s Python starter template.

nitric new llama py-starter
cd llama

Next, let’s install the base dependencies, then add the extra dependencies we need specifically for loading the language model.

# Install the base dependencies
uv sync
# Add the llama-cpp-python dependency
uv add llama-cpp-python

Choose a Llama Model

Llama 3.2 is available in different sizes and configurations, each with its own trade-offs in terms of performance, accuracy and resource requirements. For serverless applications without GPU acceleration, such as AWS Lambda, it’s important to choose a model that is lightweight and efficient to ensure it runs within the constraints of that environment.

We’ll use a quantized version of the lightweight Llama 1B model, specifically Llama-3.2-1B-Instruct-Q4_K_M.gguf.

If you’re not familiar with quantization, it’s a technique that reduces a model’s size and resource requirements, which, in our case, makes it suitable for serverless applications but may affect the accuracy of the model.

The LM Studio team provides several quantized versions of Llama 3.2 1B on Hugging Face. Consider trying different versions to find one that best fits your needs, such as Q5_K_M, which is slightly larger but of higher quality.

Let’s download the chosen model and save it in a models directory in your project.

Download link for Llama-3.2-1B-Instruct-Q4_K_M.gguf:

mkdir models
cd models
# This model is 0.81GB, it may take a little while to download
curl -OL https://huggingface.co/bartowski/Llama-3.2-1B-Instruct-GGUF/resolve/main/Llama-3.2-1B-Instruct-Q4_K_M.gguf
cd ..

Your folder structure should look like this:

/llama
    /models
        Llama-3.2-1B-Instruct-Q4_K_M.gguf
    /services
        api.py
    nitric.yaml
    pyproject.toml
    python.dockerfile
    python.dockerfile.ignore
    README.md
    uv.lock

Create a Service to Run the Model

Next, we’ll use Nitric to create an HTTP API that allows you to send prompts to the Llama model and receive the output in a response. The API will return the raw output from the model, but you can adjust this as you see fit.

Replace the contents of services/api.py with the following code, which loads the Llama model and implements the prompt functionality. Take a little time to understand the code. It defines an API with a single endpoint /prompt that accepts a POST request with a prompt in the body. The process_prompt function sends the prompt to the Llama model and returns the response.

from nitric.resources import api
from nitric.application import Nitric
from nitric.context import HttpContext
from llama_cpp import Llama

# Load the locally stored Llama model
llm = Llama(model_path="./models/Llama-3.2-1B-Instruct-Q4_K_M.gguf")

# Function to execute a prompt using the Llama model
def process_prompt(user_prompt):
    system_prompt = "You are a helpful assistant."

    # See https://www.llama.com/docs/model-cards-and-prompt-formats/llama3_1/ for details about prompt format
    prompt = (
        # System Prompt
        f'<|start_header_id|>system<|end_header_id|>{system_prompt}<|eot_id|>'
        # User Prompt
        f'<|start_header_id|>user<|end_header_id|>{user_prompt}<|eot_id|>'
        # Start assistants turn (we leave this open ended as the assistant hasn't started its turn)
        f'<|start_header_id|>assistant<|end_header_id|>'
    )

    response = llm(
        prompt=prompt,
        # Unlimited, consider setting a token limit
        max_tokens=-1,
        temperature=0.7,
    )

    return response

# Define an API for the prompt service
main = api("main")

@main.post("/prompt")
async def handle_prompt(ctx: HttpContext):
    # assume the input is text/plain
    prompt = ctx.req.data

    try:
        ctx.res.body = process_prompt(prompt)
    except Exception as e:
        print(f"Error processing prompt: {e}")
        ctx.res.body = {"error": str(e)}
        ctx.res.status = 500

Nitric.run()

OK, Let’s Run This Thing!

Now that you have an API defined, we can test it locally. The Python starter template uses python3.11-bookworm-slim as its basic container image, which doesn’t have the right dependencies to load the Llama model; let’s update the Dockerfile to use python3.11-bookworm (the non-slim version) instead.

Update line 2:

FROM python:3.11-bookworm
1
FROM python:3.11-bookworm

Update line 19:

FROM python:3.11-bookworm
1
FROM python:3.11-bookworm

Now we can run our services locally:

nitric run

nitric run will start your application in a container that includes the dependencies to use llama_cpp. If you’d rather use nitric start you’ll need to install dependencies for llama-cpp-python such as CMake and LLVM.

Once it starts, you can test it with the Nitric Dashboard.

You can find the URL to the dashboard in the terminal running the Nitric CLI. By default it’s http://localhost:49152. Add a prompt to the body of the request and send it to the /prompt endpoint.

IMAGE GOES HERE

Deploying to AWS

When you’re ready to deploy the project, we can create a new Nitric stack file that will target AWS:

nitric stack new dev aws

Update the stack file nitric.dev.yaml with the appropriate AWS region and memory allocation to handle the model.

provider: nitric/aws@1.14.0
region: us-east-1
config:
  # How services will be deployed by default, if you have other services not running models
  # you can add them here too so they don't use the same configuration
  default:
    lambda:
      # Set the memory to 6GB to handle the model, this automatically sets additional CPU allocation
      memory: 6144
      # Set a timeout of 30 seconds (this is the most API Gateway will wait for a response)
      timeout: 30
      # We add more storage to the lambda function, so it can store the model
      ephemeral-storage: 1024

Since we’ll use Nitric’s default Pulumi AWS Provider, make sure you’re set up to deploy using it. You can find more information on how to set up the AWS Provider in the Nitric AWS Provider documentation

If you’d like to deploy with Terraform or to another cloud provider, that’s also possible. You can find more information about how Nitric can deploy to other platforms in the Nitric Providers documentation.

You can then deploy using the following command:

nitric up

Take note of the API endpoint URL that is output after the deployment is complete.

If you’re done with the project later, tear it down with nitric down.

Testing on AWS

To test the service, you can use any API testing tool you like, such as cURL, Postman, etc. Here’s an example using cURL:

curl -X POST {your endpoint URL here}/prompt -d "Hello, how are you?"

Example Response

The response will include the results, plus other metadata. The output can be found in the choices array.

{
  "id": "cmpl-61064b38-45f9-496d-86d6-fdae4bc3db97",
  "object": "text_completion",
  "created": 1729655327,
  "model": "./models/Llama-3.2-1B-Instruct-Q4_K_M.gguf",
  "choices": [
    {
      "text": "\"I'm doing well, thank you for asking. I'm here and ready to assist you, so that's a good start! How can I help you today?\"",
      "index": 0,
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 26,
    "completion_tokens": 33,
    "total_tokens": 59
  }
}

Summary

As you’ve seen in the code example, we’ve set up a fairly basic prompt structure, but you can expand on this to include more complex prompts, including system prompts that help restrict/guide the model’s responses or even more complex interactions with the model. Also, in this example, we expose the model directly as an API, but this limits the response time to 30 seconds on AWS with API Gateway.

In future guides, we’ll show how you can go beyond simple one-time responses to more complex interactions, such as maintaining context between requests. We can also include Websockets and streamed responses to provide a better user experience for larger responses.

Bringing declarative infrastructure to developers

Rak — Mon, 14 Oct 2024 15:13:30 +0000

Over the past decade, Terraform has revolutionized how operations (Ops) teams manage cloud infrastructure by providing a simple, declarative way to define and provision resources.
Terraform allows us to declare cloud resources using a simple configuration language (HCL), which can then be executed to create or modify resources.

Here’s a simple example of declaring a bucket:

resource "aws_s3_bucket" "example_bucket" {
  bucket = "my-example-bucket"
  acl    = "private"

  tags = {
    Name        = "MyExampleBucket"
    Environment = "Dev"
  }

  versioning {
    enabled = true
  }
}

When you run terraform apply, terraform relies on providers to parse and translate the configuration into API requests. The provider acts as a bridge between Terraform and the AWS API, it constructs the necessary API calls to fulfill the requirements specification and sends them to AWS, where the actual creation of the bucket, tagging, and versioning happens.

Terraform handles all the communication with cloud providers, ensuring that resources are created or updated according to the configuration file, without requiring direct interaction with cloud APIs. But what about developers who also need to work with cloud infrastructure?

Our current workflow generally leads us towards building an application first, then handling the infrastructure.

This means that developers have a few choices:

Create variables for all unknown configuration and throw the ball over the fence to an ops team
Work intimately with the ops team to detail resource names, configuration etc.
Do it themselves with tools they aren’t in love with

None of these options are particularly desirable as they rely on a lot of manual steps which often lead to communication breakdowns and runtime/provision time errors. We need a way of shifting the declaration of resources forward in the workflow without introducing additional complexity to our teams.

Declarative infrastructure for developers

I’m not suggesting that developers don’t need to know how storage buckets, databases or APIs work, they just don’t need to know the specifics of how they will be provisioned while they are writing their application code.

With Infrastructure from Code (IfC), developers can declaratively define and request cloud resources such as APIs, storage buckets, and queues directly within their application logic. This declarative approach allows developers to specify what they want without worrying about how they will be provisioned.

Here’s an example of how this might work, and, actually, this should look extremely familiar, the only addition a declaration of the developers intent - to allow reading and writing on the bucket and this information is the missing link to assign the right permissions for the resources to interact with each other.

import * as nitric from '@nitric/sdk'

// Define a bucket for storing images
const imagesBucket = nitric.bucket('images').allow('read', 'write')

// Define an API for serving images
const mainApi = nitric.api('main')
mainApi.get('/images/:key', async (ctx) => {
  // Your image-serving logic here
})

From this example it's simple enough to recognize that we need the following cloud resources:

bucket('images').allow('read', 'write'): Creates a cloud storage bucket named "images" and sets access permissions for reading and writing.
api('main'): Creates an API named "main" with a route to serve images. The developer can then define application logic for handling image requests.
OpenAPI specification: From the routes configured we can automatically create the configuration required for our API gateways.

We can automatically generate the requirements specification -

{
  "resources": [
    {
      "id": {
        "type": "Bucket",
        "name": "images"
      },
      "bucket": {}
    },
    {
      "id": {
        "name": "main"
      },
      "api": {
        "openapi": "{\"components\":{},\"info\":{\"title\":\"main\",\"version\":\"v1\"},\"openapi\":\"3.0.1\",\"paths\":{\"/images/{key}\":{\"get\":{\"operationId\":\"imageskeyget\",\"responses\":{\"default\":{\"description\":\"\"}},\"x-nitric-target\":{\"name\":\"api-testing_services-hello\",\"type\":\"function\"}},\"parameters\":[{\"in\":\"path\",\"name\":\"key\",\"required\":true,\"schema\":{\"type\":\"string\"}}]}}}"
      }
    }
  ]
}

Bridging Runtime and Provisioning Gaps

One of the major challenges developers face is ensuring that the resources their application depends on are correctly provisioned at runtime. The generated specification ensures that the correct resources (storage buckets, APIs, etc.) are provisioned with the appropriate settings (permissions, paths, etc.). This removes the potential for mismatches between what the application requires and what is provisioned, ensuring a smoother deployment process.

We can now use it to orchestrate the necessary IaC, like the Terraform module above, to provision the required resources. This approach minimizes runtime and provision-time errors, ensuring that resources are automatically provisioned in line with application requirements.

It also means that the same application can be deployed across different cloud providers, which means you can pivot at any time to take advantage of the latest technologies and disruptors like AI.

Nitric is Terraform for Developers

Rak — Mon, 19 Aug 2024 14:45:40 +0000

As of the 29th of July this year, Terraform has been around for an entire decade! That’s right a one and a zero, Happy Birthday Terraform 🎉.

Terraform is best known for its declarative approach to infrastructure engineering, the product of which is executable documentation. Not only do we get clean documents that allow a reader to quickly reason about the architecture of a deployment, but that documentation can also be executed by Terraform to produce and execute a plan for that deployment.

Unsurprisingly, after a full decade of modern Infrastructure as Code (IaC) tooling we’re starting to see a whole new category of software emerge around it, Infrastructure from Code (IfC).

The core goal of the IfC paradigm is to bring to application development the same capability that tools like Terraform have allowed infrastructure engineers to enjoy for the past 10 years: the ability to document the requirements of our applications in a clear, concise, and executable fashion.

Using Nitric as an example:

import * as nitric from "@nitric/sdk";

// Document we need a bucket
const imagesBucket = nitric.bucket('images').allow('read', 'write');

// Document we need an API
const mainApi = nitric.api('main');
mainApi.get('/images/:key', async (ctx) => {
  // Code here
});

The Nitric SDKs allow us to not only express our requirements but also allow interaction with those requirements as well.

While these requirements can be spread out across a number of different services as files, it’s simple for us to capture this in a single highly declarative format using the Nitric CLI if we run:

nitric spec -o spec.json

Against our project, your Nitric infrastructure specification can be viewed as a simple JSON document, detailing your application’s requirements.

{
  "resources": [
    {
      "id": {
        "type": "Bucket",
        "name": "images"
      },
      "bucket": {}
    },
    {
      "id": {
        "name": "main"
      },
      "api": {
        "openapi": "{\"components\":{},\"info\":{\"title\":\"main\",\"version\":\"v1\"},\"openapi\":\"3.0.1\",\"paths\":{\"/images/{key}\":{\"get\":{\"operationId\":\"imageskeyget\",\"responses\":{\"default\":{\"description\":\"\"}},\"x-nitric-target\":{\"name\":\"api-testing_services-hello\",\"type\":\"function\"}},\"parameters\":[{\"in\":\"path\",\"name\":\"key\",\"required\":true,\"schema\":{\"type\":\"string\"}}]}}}"
      }
    },
    {
      "id": {
        "type": "Policy",
        "name": "3ed1c501e832fef808a464f42959858c"
      },
      "policy": {
        "principals": [
          {
            "id": {
              "type": "Service",
              "name": "api-testing_services-hello"
            }
          }
        ],
        "actions": [
          "BucketFileList",
          "BucketFileGet",
          "BucketFilePut"
        ],
        "resources": [
          {
            "id": {
              "type": "Bucket",
              "name": "images"
            }
          }
        ]
      }
    },
    {
      "id": {
        "type": "Service",
        "name": "api-testing_services-hello"
      },
      "service": {
        "image": {
          "uri": "api-testing_services-hello"
        },
        "workers": 1,
        "type": "default"
      }
    }
  ]
}

Behind the scenes, Nitric uses this infrastructure specification to provide support for multiple clouds and IaC technologies.

If you check out this recent blog, Putting Terraform behind an API you can see how the above JSON could be provided as a payload. Suddenly you would have an API that outputs Terraform directly from application code.

The point here is that while Terraform and similar technologies have existed for the past decade, providing Ops and Infrastructure teams with the tools they need to cleanly document their infrastructure, application development teams have had access to no such tools in this time. This is what the emergence of IfC is all about.

If you’re someone who works with infrastructure to help organizations deliver value by getting software out into the world, and care about a smooth and cohesive development experience, I would urge you to take a closer look at IfC as a whole and how you could leverage existing technology in this space or even build your own version of it.

If you'd like to support us, please check out the framework and give it a try, also help us spread the word by 🌟 starring us on GitHub!

Secure Upload URLs Buckets with Nitric in Python

Rak — Mon, 11 Mar 2024 18:54:15 +0000

Creating a secure method for users to upload files directly to an S3 bucket is a common requirement in modern web applications.

By using pre-signed URLs, you can allow a client to upload a file directly to S3 without exposing your AWS credentials, they also provide a secure mechanism to upload files directly to S3 from a client, avoiding the need to pass the file data through your server.

In this tutorial, we will leverage the Nitric SDK in Python to generate secure upload URLs for an S3 bucket, which can then be used from your front-end application.

If you haven't used the Nitric SDK before, then start with this tutorial.

Step 1: Initialize Nitric Bucket Instance

Inside the main function, initialize a new Nitric bucket instance with the name of your S3 bucket.

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

main_api = api('main')
images = bucket('images').allow('reading')

Step 2: Generate a Secure Upload URL

Now, generate a secure upload URL for a specific file. In this example, we are creating a URL for uploading a file named cat.png. We also specify a time-to-live (TTL) for the URL of 300 seconds (5 minutes).

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

assets = bucket('assets').allow('reading')

logo = assets.file('images/logo.png')

logo_url = await logo.download_url(expiry=300)

Nitric.run()

Now, you have a secure upload URL for your cat.png file. You can use this URL in your front-end application to securely upload the cat.png file to your S3 bucket. The URL will expire after 1 hour, ensuring that the upload URL cannot be misused after a reasonable amount of time.

This setup abstracts much of the boilerplate and complexity involved in generating pre-signed URLs for S3, allowing developers to focus more on building their applications.

In the case that you want to get an image url for rendering, then simply redirect the URL with a 303 status and a location.

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

main_api = api('main')
images = bucket('images').allow('reading')

@main_api.get('/images/:id')
async def get_image(ctx: HttpContext):
  id = ctx.req.params['id']
  url = await images.file(id).download_url()
  ctx.res.status = 303
  ctx.res.headers['Location'] = [url]

Nitric.run()

The Nitric SDK offers a streamlined approach to interacting with AWS S3, among other cloud services, in a cloud-agnostic manner.

Running a scheduled task with Nitric in Python

Rak — Mon, 11 Mar 2024 18:09:32 +0000

Setting up a scheduled job is a common requirement for many modern applications.

With the Nitric SDK, this task is simplified, and you can even test your scheduled jobs offline without needing Terraform.

In this tutorial, we'll walk through setting up a scheduled job that aggregates data every three days using the Nitric SDK in Python.

If you haven't used the Nitric SDK before, then start with this tutorial.

Step 1: Import Necessary Libraries

Start by importing the necessary libraries.

from nitric.resources import schedule
from nitric.application import Nitric
from nitric.context import IntervalContext

Step 2: Define Your Scheduled Job

Next, define a function for your scheduled job. In this example, we're creating a new scheduled job named "aggregate-data" that will run every three days.

Inside the function, we've added a simple print statement "aggregating data" to demonstrate the job's activity.

from nitric.resources import schedule
from nitric.application import Nitric
from nitric.context import IntervalContext

report_schedule = schedule('run-a-report')

@report_schedule.every('1 days')
async def process_transactions(ctx: IntervalContext):
  # do some processing
  fmt.Println("aggregating data")

Nitric.run()

Test Your Scheduled Job Offline

nitric start

One of the advantages of using the Nitric SDK is the ability to test your scheduled jobs offline. This is particularly useful for debugging and ensuring your jobs are working as expected before deploying them to the cloud.

In just a few steps, you've now created a scheduled job that aggregates data every three days, here are a few more examples showing you how to set up other frequencies.

description	example schedule
Every day	@schedule("work").every("day")
Every 14 hours	@schedule("work").every("14 hours")
Every 30 minutes	@schedule("work").every("30 minutes")
Every day (cron)	@schedule("work").cron("0 0 * * *")

Creating Bucket (S3) Notifications on AWS with Python

Rak — Mon, 11 Mar 2024 17:59:11 +0000

In this tutorial, we’ll explore how to set up bucket notifications in Python, enabling your applications to react to changes in file storage buckets. This is particularly useful in scenarios where you need to monitor a bucket for new file uploads or deletions.

If you haven't used the Nitric SDK before, then start with this tutorial.

1. Create a Bucket Instance

Import the necessary packages and instantiate a new bucket object. In this tutorial, we'll name our bucket 'assets'.

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

assets = bucket("assets")

accessible_assets = bucket("assets").allow("reading")

2. Set Up Notifications for File Write Events

To monitor for file write events, specifically for files starting with a certain prefix, use the On method on the bucket object. Let’s trigger notifications for files starting with '/users/images'.

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

assets = bucket("assets")

accessible_assets = bucket("assets").allow("reading")

# The request will contain the name of the file `key` and the type of event `type`
@assets.on("delete", "*")
async def delete_anything(ctx):
  print(f"a file named {ctx.req.key} was deleted")

@assets.on("write", "/images/cat")
async def create_cat_image(ctx):
  print(f"A cat image was written")

# If `on` is called with a permissioned bucket, a file will also be provided with the request
@accessible_assets.on("write", "/images/dog")
async def access_dog_file(ctx):
  dog_image = await ctx.req.file.read()

  print(dog_image)

Nitric.run()

3. Set Up Notifications for File Delete Events

Similarly, to monitor for file deletion events for any file, set up a notification like so:

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

# Create a reference to an 'assets' bucket with permissions to delete
assets = bucket('assets').allow('deleting')

logo = assets.file('images/logo.png')

await logo.delete()

Nitric.run()

Avoid writing or deleting to the bucket from within a notification as this can trigger the notification again, potentially causing an infinite loop which can be costly.

Let's run this thing!

nitric start

Conclusion

Now you have set up bucket notifications in Python using the Nitric SDK.

This setup will help you monitor file write and delete events, allowing your application to react to changes in your bucket accordingly.

Your first Nitric API using Python

Rak — Mon, 11 Mar 2024 17:52:34 +0000

Hey Dev.to community!

Today we are diving into an exciting project where we'll create a Profile Management API using Nitric and Python.

This API will handle the creation, updating, and deletion of user profiles. We’ll then extend it to manage profile images.

Use Nitric to create an API to create and update profiles
Create handlers for the following API operations

Method	Route	Description
`GET`	/profiles/[id]	Get a specific profile by its Id
`GET`	/profiles	List all profiles
`POST`	/profiles	Create a new profile
`DELETE`	/profiles/[id]	Delete a profile
`PUT`	/profiles/[id]	Update a profile

Run locally for testing
Deploy to a cloud of your choice
(Optional) Add handlers for the following API operations

Method	Route	Description
`GET`	/profiles/[id]/image/upload	Get a profile image upload URL
`GET`	profiles/[id]/image/download	Get a profile image download URL
`GET`	profiles/[id]/image/view	View the image that is downloaded

Prerequisites

Pipenv
The Nitric CLI
An AWS, GCP or Azure account (your choice)

Introducing Nitric

Nitric is a tool that helps developers create applications for the cloud (like AWS, Google Cloud, or Microsoft Azure) quickly and with less repetitive code. It acts as a bridge between your code and the cloud services, making it dead simple to build and deploy your application.

By using Nitric, you can focus more on building your application, and less on the specifics of the cloud provider and eliminate the Terraform (or other IaC) project required to deploy it.

Learn more about it by checking out some of my other blogs, or heading to the docs.

Let's Code

We'll start by creating a new project for our API.

nitric new my-profile-api py-starter

Next, open the project in your editor of choice.

cd my-profile-api

Make sure all dependencies are resolved:

pipenv install --dev

The scaffolded project should have the following structure:

+--services/
|  +-- hello.py
+--nitric.yaml
+--Pipfile
+--Pipfile.lock
+--README.md

You can test the project to verify everything is working as expected:

nitric start

If everything is working as expected you can now delete all files in the services/ folder, we'll create new services in this guide.

Building the Profile API

Let's start building our profiles API. Create a file named 'profiles.py' in the services directory and add the following:

from uuid import uuid4

from nitric.resources import api, kv, bucket
from nitric.application import Nitric
from nitric.context import HttpContext

# Create an api named public
profile_api = api("public")

# Access profile key value store with permissions
profiles = kv('profiles').allow('getting', 'setting')

Nitric.run()

Here we're creating:

An API named public,
A key value store named profiles and giving our service permission to get and set to that store.

You could separate some or all of these request handlers into their own
functions if you prefer. For simplicity we'll group them together in this
guide.

Create profiles with POST

@profile_api.post("/profiles")
async def create_profile(ctx: HttpContext) -> None:
  pid = str(uuid4())
  name = ctx.req.json['name']
  age = ctx.req.json['age']
  hometown = ctx.req.json['homeTown']

  await profiles.set(pid, { 'name': name, 'age': age, 'hometown': hometown} )

  ctx.res.body = { 'msg': f'Profile with id {pid} created.'}

Retrieve a profile with GET

@profile_api.get("/profiles/:id")
async def get_profile(ctx: HttpContext) -> None:
  pid = ctx.req.params['id']
  d = await profiles.get(pid)

  ctx.res.body = f"{d.content}"

Remove a profile with DELETE

@profile_api.delete("/profiles/:id")
async def delete_profiles(ctx: HttpContext) -> None:
  pid = ctx.req.params['id']

  try:
    d = await profiles.delete(pid)
    ctx.res.body = { 'msg': f'Profile with id {pid} deleted.'}
  except:
    ctx.res.status = 404
    ctx.res.body = { 'msg': f'Profile with id {pid} not found.'}

Ok, let's run this thing!

Now that you have an API defined with handlers for each of its methods, it's time to test it locally.

nitric start

Once it starts, the application will receive requests via the API port. You can use cURL, Postman or any other HTTP client to test the API.

We will keep it running for our tests. If you want to update your functions, just save them, they'll be reloaded automatically.

Test your API

Update all values in brackets [] and change the URL to your deployed URL if you're testing on the cloud.

Create Profile

curl --location --request POST 'http://localhost:4001/profiles' \
--header 'Content-Type: text/plain' \
--data-raw '{
    "name": "Peter Parker",
    "age": "21",
    "homeTown" : "Queens"
}'

Fetch Profile

curl --location --request GET 'http://localhost:4001/profiles/[id]'

Delete Profile

curl --location --request DELETE 'http://localhost:4001/profiles/[id]'

Deploy to the cloud

At this point, you can deploy what you've built to any of the supported cloud providers. To do this start by setting up your credentials and any configuration for the cloud you prefer:

Next, we'll need to create a stack. A stack represents a deployed instance of an application, which is a collection of resources defined in your project. You might want separate stacks for each environment, such as stacks for dev, test and prod. For now, let's start by creating a dev stack.

nitric stack new

? What should we name this stack? dev
? Which provider do you want to deploy with? aws
? Which region should the stack deploy to? us-east-1

AWS

Note: You are responsible for staying within the limits of the free tier or any costs associated with deployment.

We called our stack dev, let's try deploying it with the up command

nitric up

When the deployment is complete, go to the relevant cloud console and you'll be able to see and interact with your API.

To tear down your application from the cloud, use the down command:

nitric down

Optional - Add profile image upload/download support

If you want to go a bit deeper and create some other resources with Nitric, why not add images to your profiles API.

Access profile buckets with permissions

Define a bucket named profilesImg with reading/writing permissions

photos = bucket("photos").allow('reading','writing')

Add imports for time and date so that we can set up caching/expiry headers

from datetime import datetime, timedelta

Get a URL to upload a profile image

@profile_api.get("/profiles/:id/image/upload")
async def upload_profile_image(ctx: HttpContext) -> None:
  pid = ctx.req.params['id']

  photo =  photos.file(f'images/{pid}/photo.png')
  photo_url = await photo.upload_url(expiry=3600)

  expires = datetime.utcnow() + timedelta(seconds=(3600))
  expires = expires.strftime("%a, %d %b %Y %H:%M:%S GMT")
  ctx.res.headers['Expires'] = expires

  ctx.res.body = photo_url

Get a URL to download a profile image

@profile_api.get("/profiles/:id/image/view")
async def download_profile_image(ctx: HttpContext) -> None:
  pid = ctx.req.params['id']

  photo =  photos.file(f'images/{pid}/photo.png')
  photo_url = await photo.download_url(expiry=3600)

  expires = datetime.utcnow() + timedelta(seconds=(3600))
  expires = expires.strftime("%a, %d %b %Y %H:%M:%S GMT")
  ctx.res.headers['Expires'] = expires

  ctx.res.body = photo_url

You can also directly redirect to the photo URL.

@profile_api.get("/profiles/:id/image/view")
async def download_profile_image(ctx: HttpContext) -> None:
  pid = ctx.req.params['id']

  photo =  photos.file(f'images/{pid}/photo.png')
  photo_url = await photo.download_url(expiry=3600)

  expires = datetime.utcnow() + timedelta(seconds=(3600))
  expires = expires.strftime("%a, %d %b %Y %H:%M:%S GMT")
  ctx.res.headers['Expires'] = expires
  ctx.res.headers['Location'] = [photo_url]
  ctx.res.status = 303

Time to test the updated API

Update all values in brackets [] and change the URL to your deployed URL if you're testing on the cloud.

Get an image upload URL

curl --location --request GET 'http://localhost:4001/profiles/[id]/image/upload'

Using the upload URL with curl

curl --location --request PUT '[url]' \
--header 'content-type: image/png' \
--data-binary '@/home/user/Pictures/photo.png'

Get an image download URL

curl --location --request GET 'http://localhost:4001/profiles/[id]/image/download'

Wrapping Up

In this exploration, we created a Profile Management API using Nitric, handled core profile operations, and extended it for image management.

Nitric proves to be a reliable companion in swiftly moving from idea to a live, cloud-hosted API. Now it's your turn to expand this project or embark on new adventures with Nitric.

Happy coding!

This post originally featured on the Nitric website.

Open-Source Framework that understands Your Application Infrastructure Needs

Rak — Wed, 24 Jan 2024 21:09:30 +0000

Hello Everyone!

You may have heard of the open source Nitric framework that my team and I have been developing – it’s a cloud-aware application framework that provides a seamless dev experience and confident cloud deployments. Put simply, Nitric handles the infrastructure and runtime requirements of your application, so you can focus your efforts on building it.

The framework is not just a concept; it’s production-ready, ideal for small to medium scale projects. We’ve got a major release on the horizon, where we’re focusing on improvements for the DevOps community. With a strong foundation on the developer experience side, we’d love your feedback about how Nitric could work better for you on the operations side.

Key Features of Nitric:

Inline Cloud Resources: Nitric integrates with IaC tools like Pulumi and Terraform, enabling inline addition of cloud resources directly in the code, streamlining infrastructure deployment and IAM configuration.

Local Development Server: Offers a local server for running cloud apps, including features like hot reload, local cloud simulation, and instant testing for efficient debugging.

Multi-language Support: Facilitates cloud app development in various programming languages, compatible across multiple cloud providers (AWS, Google Cloud, Microsoft Azure), reducing boilerplate and enhancing infrastructure automation.

Multi-cloud Deployment: Enables deployment to different clouds (AWS, Google Cloud, Azure) without code alteration, promoting portability and reducing vendor lock-in.

Who Should Use Nitric?

Nitric bridges development and operations to create a productive workflow.

For Developers: Nitric simplifies cloud app development. It abstracts complex cloud services, letting you focus on coding rather than infrastructure management. This means faster development cycles and more time for innovation. It's language-agnostic, so whether you're into Python, JavaScript, Typescript, Go, etc., Nitric has you covered.

The bottom line: it's all about writing great code without the cloud setup headache.

For DevOps: Nitric automates the deployment process, enabling consistent and repeatable deployment of applications. The framework provisions infrastructure with the support of IaC providers written in cross-platform IaC tools including Pulumi & Terraform.

Operations teams can move fast by starting with Nitric’s best practices to provision infrastructure, but can also maintain control by customizing the providers.

The bottom line: Reduce the complexity and time involved in deploying applications consistently and securely across different applications and environments.

Tell us what you think

We’d love to hear your feedback here. If you’re interested in what we’re doing, please support us with a star on Github!

https://github.com/nitrictech/nitric

Cloud Deployment Anomalies that send us down rabbit holes

Rak — Wed, 24 Jan 2024 19:28:30 +0000

Building for the cloud is often perceived as a straightforward journey, but as many developers discover, it can be a path filled with unexpected twists and turns. This blog delves into the nuanced reality of cloud development, where seemingly simple tasks can lead us down intricate rabbit holes of deployment and configuration.

The Core Issue

Our journey began with the use of an OpenAPI specification to define our AWS API. The OpenAPI spec's info section, which typically includes a descriptive name for the API, presented an unexpected behavior.

During the initial deployment to AWS, the API name was derived directly from the info section of the OpenAPI spec.

Pretty straightforward? Except, in subsequent deployments, when the OpenAPI spec remained unchanged, AWS seemed to bypass it, defaulting to the name assigned by Pulumi, which was a generic name concatenated with a random string.

Technical Examination

Here’s a snippet written which the Pulumi APIs to reproduce the problem:

import * as pulumi from '@pulumi/pulumi'
import * as aws from '@pulumi/aws'
import * as awsx from '@pulumi/awsx'

// Create an AWS resource (S3 Bucket)
const bucket = new aws.s3.Bucket('my-bucket')
const body = `
{
   "components":{},
   "info":{
       "title":"my-api",
       "version":"v1"
   },
   "tags": [{
       "name":"testing",
       "x-amazon-apigateway-tag-value": "abc"
   }],
   "openapi":"3.0.1",
   "paths":{
       "/hello":{
           "get":{
               "operationId":"helloget",
               "responses":{
                   "default":{
                       "description":""
                   }
               }
           }
       }
   }
}
`
const apigateway = new aws.apigatewayv2.Api('my-api', {
  protocolType: 'HTTP',
  body,
})

// Export the name of the bucket
export const gatewayName = apigateway.id

If we switch to using CDK (cloud formation under the covers), we don’t get an error. This is because CloudFormation will not let you provide conflicting parameters - when you provide an OpenAPI spec, you aren’t allowed to provide meta information such as the name, method etc.

import {
 Stack,
 App,
 aws_s3 as s3,
 aws_apigatewayv2 as apigateway,
 StackProps,
 CfnOutput,
} from "aws-cdk-lib";
import { Construct } from "constructs";


export class MyStack extends Stack {
 constructor(scope: Construct, id: string, props?: StackProps) {
   super(scope, id, props);

   // Create an S3 bucket
   const bucket = new s3.Bucket(this, "MyBucket", {
     bucketName: "m4jik-bucket-9643",
   });

   const openApiSpec = {
     components: {},
     info: {
       title: "my-api-m4jik",
       version: "v1",
     },
     tags: [
       {
         name: "testing",
         "x-amazon-apigateway-tag-value": "abc",
       },
     ],
     openapi: "3.0.1",
     paths: {
       "/hello": {
         get: {
           operationId: "helloget",
           responses: {
             default: {
               description: "",
             },
           },
         },
       },
     },
   };

   // Create an API Gateway (HTTP API) using CfnApi
   const api = new apigateway.CfnApi(this, "MyApi", {
     body: openApiSpec,
   });

   // Export the API Gateway ID
   new CfnOutput(this, "ApiGatewayId", {
     value: api.ref,
   });
 }


const app = new App();
new MyStack(app, "MyStack");

The Pulumi implementation offers the same flexibility as the AWS CDK implementation, which means that the likely culprit is the AWS Terraform Provider under the covers which does not enforce the rules around API naming as stringent as CloudFormation.
Solution
To address this, we implemented a two-fold strategy:

AWS Extensions for Proper Tagging: We utilized AWS-specific extensions to ensure tags were formatted as key-value pairs, aligning with AWS's standard tagging practices.
Harmonizing OpenAPI and Pulumi Specs: We aligned the OpenAPI info section with Pulumi’s naming conventions, ensuring consistency across all deployments. Of course, we’ll also be raising a support ticket to address the underlying issue in Terraform.

Final Remarks

A lot of time can be lost when trying to implement something extremely simply, and being pulled deep into the rabbit holes of cloud deployment and configuration.

By sharing this experience, we hope to assist others navigating similar challenges, and improve our own framework which is now jam-packed with lessons learnt from continually building and experimenting with cloud deployments.

Thanks for reading, if you’ve enjoyed this blog or would like to share your support please give us a star on GitHub!