Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up Azure development by not using Terraform

nitric.io

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Speeding up Azure development by not using Terraform

#81

Post by sevagh »

thedougd wrote: post #23
sevagh wrote: post #20

After the Terraform relicensing ordeal, do yourself a favor, if you're starting greenfield, use your cloud provider's provided provisioning tools. I wish I had CDK/Cloudformation skills, and not Terraform skills.

What about outside of AWS? Are folks only using a single provider? Our list of providers is long and includes a whole ecosystem of stuff from GitHub to Okta and Datadog. Everything needed to host and operate an application is in the Terraform configuration.

Not sure I ever saw the point of learning "provider-flavored" Terraform, i.e. needing to write 100% different modules for GCP and AWS. But I guess the shared model of state, provider configs, apply/plan is still valuable.

Re: Speeding up Azure development by not using Terraform

#82

Post by k8svet »

pjmlp wrote: post #75
FridgeSeal wrote: post #42

Earlier quoted context omitted.

MS/Azure just seems to have this weird obsession with Not-Invented-Here-ing things that didn’t need to be nih-ed, and their solutions are often…extraordinarily Microsoft. “Use our weird language, to interact with our awful, slow API’s, nobody else uses it, our support probably doesn’t know it exists, and it’ll be full of weird, MS culture specific idioms and eldritch code that compiles down into our previous failed e…

As if other cloud offerings were any different in behaviour and tooling.

Azure is straight up full of fucking clowns.

https://github.com/Azure/AzureVM/issues/26

This is not a serious platform: https://learn.microsoft.com/en-us/troubleshoot/azure/virtual...

Can you begin to imagine how fucked up Compute is internally that this shit remains true for 6+ years? VMSS was an entire nightmare that someone tried to point out was a mistake that AWS and GCP brilliantly avoided. Sure enough, now the product is confusing and even further internally fractured by supporting both deployment models.

Sorry, having been on the inside of a couple places and a user of all of them, Azure comes in last place every single time.

Re: Speeding up Azure development by not using Terraform

#83

Post by throw1234651234 »

throw1234651234 wrote: post #18
pjmlp wrote: post #4

Sure, by using their solution instead. The only real alternative is to use PowerShell or AZ CLI instead.

Terraform feels like a useless wrapper on top of AZ CLI and resource definition yaml files. In general, Terraform provides nothing but a useless wrapper that people need to understand. Furthermore, most companies don't need K8S either if they are using a cloud provider. It only starts being cheaper if you forget what you pay the DevOps team (or senior devs who do DevOps on top of code) AND have a huge number of resou…

I see the negs, but I don't see any coherent arguments, much like "irl", past "We just need it, ok". Nevermind the fact that even the OS-agnostic garbage argument falls apart the moment you do anything complex since it relies on the host kernel. Doing some graphics stuff (no, not games or AI, just say, PDF report generation)? Guess what, your library might be relying on OS-specific libraries and will break the moment you put your "agnostic" container on Linux. And now Docker desktop needs a license and everyone needs to learn Rancher.

Again, you don't need Docker. You aren't CoreWeave or a cloud provider. You DON'T need to virtualize your hardware and parse it out in pieces on a moment's notice. You don't need K8S to do a rolling update for you when on the cloud, you don't need Ingress to load balance, you don't need ECS/EKS to break every day.

I am persisting in hopes someone convinces me I am wrong by the way. This isn't a rant, I have a decade of experience of someone building a fancy container/orchestrator infrastructure only for all of it to fall apart the moment the DevOps team leaves. Perpetual cost center that adds nothing.

And yes, I know, I am not doing it right and we need Flux to fix all our problems now.

Re: Speeding up Azure development by not using Terraform

#84

Post by nickspag »

k8svet wrote: post #27
nickspag wrote: post #12

Earlier quoted context omitted.

Bicep is fantastic. But it compiles to ARM, so it's still limited by ARM's weaknesses and gaps, in addition to the underlying general instability of Azure and the inconsistencies from the Resource Providers. As well, Bicep is declarative- which is elegant in theory, but the stateful design of Terraform can cover up some of those underlying ARM/Azure gaps in practice. The deployment stacks approach on Azure should hel…

This just makes it even more asinine that they had to invent their own language. I'm sure I'd be just as productive with Nix and builtins.toJSON. At least they didn't do jsonnet, eh?

I don't know if I'd go that far. It's pretty easy to go from ARM to Bicep. And Bicep is genuinely better at everything ARM does and has a wider breadth of features as a DSL- and that is genuinely valuable. It was always going to have to be back compatible/compile to ARM: moving off it has to start somewhere.

re: nix, it does infra?

Re: Speeding up Azure development by not using Terraform

#85

Post by seabrookmx »

BarryMilo wrote: post #32
abound wrote: post #19

I've never used Nitric, but tools of this nature tend to run up against the realities of irreducible inherent complexity. 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 s…

I'm not sure if ORM is a great example, as they tend to work for the vast majority of use cases. If you're not using an ORM, you're either working on something where performance is critical, or you're making a mess.

Hard disagree. ORM's tend to cater to the lowest common denominator functionality of relational databases so if you want to for instance, make use of jsonb in postgres, you have to use weird workarounds or drop into SQL anyways.

SQL is a high level, declarative language. You need to use good libraries that ensure queries can be safely composed and arguments passed, but you are not automatically "making a mess" if you're writing SQL unless you or your tooling is incompetent.

Personally, I really like Dapper (C#) as it solves the "object mapping" and "query composition" cases in a performant and ergonomic way while letting me write the (exact) query I want.

Re: Speeding up Azure development by not using Terraform

#86

Post by neonsunset »

seabrookmx wrote: post #85
BarryMilo wrote: post #32

Earlier quoted context omitted.

I'm not sure if ORM is a great example, as they tend to work for the vast majority of use cases. If you're not using an ORM, you're either working on something where performance is critical, or you're making a mess.

Hard disagree. ORM's tend to cater to the lowest common denominator functionality of relational databases so if you want to for instance, make use of jsonb in postgres, you have to use weird workarounds or drop into SQL anyways. SQL is a high level, declarative language. You need to use good libraries that ensure queries can be safely composed and arguments passed, but you are not automatically "making a mess" if you…

(EF Core has been allowing this for quite some time too with .FromSql method which uses string interpolation API to turn an interpolated string into a parametrized query behind the scenes mitigating injection risks. Before that there were FromSqlInterpolated and FromSqlRaw which served the same purposed)

Re: Speeding up Azure development by not using Terraform

#87

Post by seabrookmx »

neonsunset wrote: post #86
seabrookmx wrote: post #85

Earlier quoted context omitted.

Hard disagree. ORM's tend to cater to the lowest common denominator functionality of relational databases so if you want to for instance, make use of jsonb in postgres, you have to use weird workarounds or drop into SQL anyways. SQL is a high level, declarative language. You need to use good libraries that ensure queries can be safely composed and arguments passed, but you are not automatically "making a mess" if you…

(EF Core has been allowing this for quite some time too with .FromSql method which uses string interpolation API to turn an interpolated string into a parametrized query behind the scenes mitigating injection risks. Before that there were FromSqlInterpolated and FromSqlRaw which served the same purposed)

I've heard this and been meaning to try it out. Linq-to-SQL really bit me a decade ago and pushed me to Dapper but I have always liked the way EF did migrations.
Post reply on HN