Speeding up Azure development by not using Terraform
1–10 of 87 posts
Re: Speeding up Azure development by not using Terraform
#2It's all fun and games until you want to do something even semi non-standard. Nitric even calls this out:
> If you wanted to be able to completely customise your infrastructure, using IaC can be practical. However, it is rare that an application requires any level of customisation beyond the default.
I'm assuming this project is targeting rapid prototype/"entrepreneur" market because I can assure you that basically every project I've ever worked on at BigTechCorp needed some kind of customization beyond the defaults.
Re: Speeding up Azure development by not using Terraform
#3It's all fun and games until you want to do something even semi non-standard. Nitric even calls this out: > If you wanted to be able to completely customise your infrastructure, using IaC can be practical. However, it is rare that an application requires any level of customisation beyond the default. I'm assuming this project is targeting rapid prototype/"entrepreneur" market because I can assure you that basically e…
Certainly, but Terraform also sucks at this!
I have had all sorts of problems with providers that basically lie to your face about the guarantees they make, state files always getting funky and needing escalation, special things needing to be put in special files or "terraform will get mad" (the actual staff sre's comments)
It's not a tool I have ever thought was great!
Re: Speeding up Azure development by not using Terraform
#4Sure, by using their solution instead.
The only real alternative is to use PowerShell or AZ CLI instead.
Re: Speeding up Azure development by not using Terraform
#5Sure, you can hide all configuration behind some abstraction, but that doesn't really change the fact that the configuration is still there. The moment you need to do something even slightly different than out-of-the-box, you're hosed. Additionally - IAC can work as documentation. "What's running in (environment)?" is a question that can usually quickly be answered by looking at the IAC itself, whereas this solution, you'd have to go poking around in some console and pray to god you're in the right place.
Re: Speeding up Azure development by not using Terraform
#6Why do people do this? I skim the article. I go wait "Nitric sounds like Pulumi". A few googles later, I find this : https://nitric.io/docs/reference/pulumi
So, it's fast because it uses Pulumi... Does Pulumi no longer build on Terraform providers? (EDIT: looking, it seems like many Pulumi providers are still terraform wrappers...)
Either way, it feels like this is just a Pulumi feature.
Re: Speeding up Azure development by not using Terraform
#7It's all fun and games until you want to do something even semi non-standard. Nitric even calls this out: > If you wanted to be able to completely customise your infrastructure, using IaC can be practical. However, it is rare that an application requires any level of customisation beyond the default. I'm assuming this project is targeting rapid prototype/"entrepreneur" market because I can assure you that basically e…
Certainly, but Terraform also sucks at this! I have had all sorts of problems with providers that basically lie to your face about the guarantees they make, state files always getting funky and needing escalation, special things needing to be put in special files or "terraform will get mad" (the actual staff sre's comments) It's not a tool I have ever thought was great!
That's fine but that's not really a fault of terraform usually but the provider. Terraform itself is a wrapper around the cloud API's the providers use. For your comments regarding "state files getting funky" I have also never seen this as a problem with terraform itself, but rather people doing insanely stupid things with it. "terraform gets mad" seems like a constraint of whatever home-grown modules your staff SRE is using, not a feature/problem with terraform itself.
Re: Speeding up Azure development by not using Terraform
#8Why do people do this? I skim the article. I go wait "Nitric sounds like Pulumi". A few googles later, I find this : https://nitric.io/docs/reference/pulumi So, it's fast because it uses Pulumi... Does Pulumi no longer build on Terraform providers? (EDIT: looking, it seems like many Pulumi providers are still terraform wrappers...) Either way, it feels like this is just a Pulumi feature.
It looks like it's letting you put your application code and Pulumi code in one spot. Why...not really sure, outside of a very short "Hello World".
Re: Speeding up Azure development by not using Terraform
#9Sure, by using their solution instead. The only real alternative is to use PowerShell or AZ CLI instead.
Well, sorta. Azure has Bicep now [1], to compete with Terraform and ARM JSON templates. (Separately, there's also the whole Dapr thing, what a sight to see that Discord and complete lack of interest from anyone outside the company).
[1]: https://learn.microsoft.com/en-us/azure/azure-resource-manag...
Re: Speeding up Azure development by not using Terraform
#10As a heavy user of Pulumi for C# projects this looks highly promising, and the Azure ecosystem has a large number of .NET / C# focused developers that are either fighting with bicep or terraform (or Pulumi), who would also find this very useful.
Apart from the fact that C# examples seem to be lacking from the documentation at the moment, I’d also be interested to know if there is, or will be support for managed identities?
Edit. Just found the C# examples. Reading through now.
We are predominantly switching over to managed identities only to avoid key rotation hassles, and Entra workload federated identities in pipelines to remove those hardcoded identities in our pipelines.
I also wonder how you deal with combined function deployments. For example we deploy function apps or message consumers that process multiple message types as a bounded context, in one single app. I assume that Nitric would deploy each function endpoint as a separate app container?
Regardless of those niggles, I love the concept of combining the code and the infrastructure definitions together.