Speeding up Azure development by not using Terraform

However, when it comes to solutions to problems "Separation of Concerns" is the best solution. I don't want my application code telling azure what resources to make. I want to tell azure what resources to make, and I want to be 100% sure that what is created is what I want because we're talking about something that costs my company money to run it.

While Terraform is a lot of code to get something defined and started (and I do think there's room for improvement), the degree of what you can define with it and how much you control are the key selling points.

The Terraform you've written out looks like a lot, but the Nitric code is doing a huge amount of lifting in this example.

Not to mention that Nitric is wrapping a Pulumi provider (granted they are using `pulumi-azure-native` unlike the `pulumi-azure` provider that's just a Terraform wrapper).

You can do this exact kind of Function Serialization in Pulumi anyway: https://www.pulumi.com/docs/concepts/function-serialization/....

At the end of the day this article is abstracting a huge amount and whilst for startups it might be fine? When something goes wrong you'll want to be able to debug the random queue backlog in your stack.

For an example of this done beautifully in one language where they're managed close the loop with monitoring, I would checkout Encore: https://encore.dev/.

As you pointed out, though, it's not an issue with Terraform, and the above case can be solved by manually managing the dependency with lifecycle management. So, I agree that most cases are often inflicted by things outside of Terraform.

Dapr has some love on the .NET community, and apparently is used by Aspire, however I have seen little adoption of it on polyglot projects.

When not using terraform, I find the scripting approaches easier to follow up.

You fundamentally cannot build abstractions that are both easier *and* as flexible as the thing you are abstracting away, and so tools like this, as other commenters have noted, are great for a simple happy path, but that's almost never what you need once you're outside the tutorial and building something "real", which requires the very flexibility that has been abstracted away.

This is very similar to the argument against (most) ORMs and similar tools. For simple, happy path cases, you can avoid knowing SQL (or in Nitric's case, infrastructure management, platform-specific resources) and use whatever DSL/framework you have, but if you want to do something more complicated, you either have to hack and kludge your way through with the system, or drop down to the lower level and forego the abstraction entirely.

As an aside: Azure is a pain to use with Terraform as its API endpoints seem to be an order of magnitude slower than the equivalent GCP or AWS APIs, so things like `terraform plan` can throw you out of flow even on modestly sized projects. Going back and forth between Azure and other clouds is night and day.