Live data from Hacker News

Speeding up Azure development by not using Terraform

nitric.io

71–80 of 87 posts

Re: Speeding up Azure development by not using Terraform

#71
post #66
post #49

Earlier quoted context omitted.

One of the co-founders of Nitric here, and I'll bite on this one :) I hear the separation of concerns between IaC and application code argument quite a bit, but always see an inherent coupling between the two. If changes to your IaC require changes to your application code for your application to continue working then where is the separation of concerns? If its just deployment and runtime, this separation still exist…

> increase cohesion between an application and its running infrastructure > without increasing coupling to that infrastructure These are contradictory. I don't know what people are doing to fuck up their TF so much, but I've never seen an issue where TF and application code were coupled in a way that wasn't trivially solvable. Of course, that depends on people not being really dumb.

Disagree on the contradiction but want your take on where you see it.

I don't know what your experience is but "never" having seen any issues could also be bad thing, seeing the "don't" is just as valuable as the "do" when it comes to building experience.

Some concrete examples to demonstrate where coupling is trivially solvable would be good if you have some that you can share, where it wouldn't be trivially solvable what are the common mistakes that would be made in those cases?

If you have time to share your experience I'd really appreciate it.

Re: Speeding up Azure development by not using Terraform

#72
post #55

Earlier quoted context omitted.

Much of the consulting work I do surrounds terraform and most people are doing it very poorly or incorrectly. I do not think this is a fault of terraform. For instance, not going all in on IAC and having mixed/poor practice around automation and click-ops'ing things for "speed" is a great way to have inconsistent terraform states. As far as a flat out state corruption, I've only seen that one time in ~6 years working…

As a database person this pains me to say, but if the people keep using the tool wrong you may want to start fixing the tool.

The problem is that the domain requires flexibility. If you aren’t allergic to the documentation, the problems described are exceedingly uncommon (or entirely self-inflicted like the “gets mad” bit) but there are a lot of people who treat infrastructure as somewhat beneath them and get upset when it doesn’t work like other things they know. That’s a really hard problem for a tool developer because people who do know what they’re doing often need odd configuration points. I think the general answer is to push the first group up the stack: you get fewer choices but also fewer decisions you need to understand the consequences of.

As a database analogy, most of the problems I’ve seen are similar where people chose not to learn how their tools worked and then said it was the database’s fault that they were making billion-row joins or O(n) queries because they knew what they wanted and the database should have had Do What I Meant mode.

Re: Speeding up Azure development by not using Terraform

#73

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.

Well, to me it is. I've been working on a relatively large projects based on Node (Typescript), various Lambdas, some doing server stuff only, other serving Client ... It's a pretty complex and large application overall and the whole architecture was really well designed from the ground up, except one thing: typeorm. It was fine at the beginning when doing simple things, but it got really tricky after. Then, I've had…

Okay fair point, you need a good ORM!

Re: Speeding up Azure development by not using Terraform

#75
post #27

Earlier quoted context omitted.

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?

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.

Re: Speeding up Azure development by not using Terraform

#76
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…

In general we don't need Docker, but that isn't what CV driven development looks like, thus here we are.

Re: Speeding up Azure development by not using Terraform

#77
post #26

Earlier quoted context omitted.

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…

Well, maybe there's some terraform jedis out there but I have seen the same problem at four companies so far, and at this point I keep my nose right out of it because its always a chore treadmill.

I've been using Terraform for 4 years with Azure and compared to the alternatives (ARM templates or Bicep) it's definitely a win. When you run into issues Terraform is usually very transparent about them and its source code is readable. Even when something is not supported by a provider (yet) you have the local-exec escape hatch to deploy and tear down a resource.

Re: Speeding up Azure development by not using Terraform

#78
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…

> 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.

If it reassures you, their own tooling uses the same APIs so everything is slow by definition. Also, their security posture is a joke with multiple (around 10?) cross-tenant vulneabilities in the past 2 years, many of which were trivial to exploit.

Re: Speeding up Azure development by not using Terraform

#79
post #64
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…

Another consideration is the release of new features. You use ARM templates, that support comes with a feature GA. Terraform has to wait for the updated GO SDK, and then you have to wait for them to build it into Terraform. Bicep in theory carries a similar risk, but I have not heard any complaints so far. Maybe product teams release ARM and Bicep functionality at tbe same time?

Famously on that front, the Terraform AWS provider gets new features before CloudFormation does.

Re: Speeding up Azure development by not using Terraform

#80
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.

Or, don’t, because the vast, vast majority of users are almost certainly not affected by the licensing change, and your life can continue on, literally unchanged.

Were you not quoted a significant price increase for your Terraform Cloud bill? Our firm (and many others) ran into this.
Post reply on HN