Hacker News Reader

Comment by wobblyasp | Hacker News Reader

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

View on HN

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.

Often, I've experienced state file issues as a result of some not-so-nice dependencies between AWS services. For example, Terraform deletes one thing and then turns around and tries to delete another thing, which fails because the first thing was deleted (it's been a while, so I don't have a detailed example, unfortunately). The result is the state file can no longer be reconciled without manual intervention.

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.

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.

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 with terraform, and it was due to the mechanism locking the state file failing during simultaneous updates. In today's version I'm not even sure how I'd go about corrupting a terraform state file sanely. There are a lot more guard rails and QoL stuff since the pre-1.0 version days.

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.

You can't stop people from doing dumb things if they don't want to learn.

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.

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.

This tool is going to have the same problems as Terraform only worse.

It's wrapping Pulumi and managing the state file for that. Yet another abstraction layer on-top of it all.

I'd love to be proven wrong if they can output Pulumi code from their application code?

Even then, I'm not sure what the monetization play here is? You're standing on the shoulders of Pulumi and you're open-source. If you go down the managed route and host the state files you'll be in direct competition with Pulumi's cloud offering...

I am not any of those things nor do I know anything about their product, just saying that when anyone is crap potting for Terraform it just has always sucked in every job I have ever worked at.

I've seen quite a bit of Terraform code over the past 8 or 9 years. Most of the problems are related to:

  1) Rampant copy-and-pasting instead of attempting any sort of code reuse
  2) Reinventing the wheel poorly: instead of bringing in an existing module, they'll attempt to build their own half-baked one.
  3) Poor ops practices like manually editing configuration through the console, then complaining about drift when TF overwrites their changes.
  4) Lack of systems and networking fundamentals, like DNS or load balancing. If you don't understand it, how can you hope to configure something properly?

Nitric doesn't wrap the state management for Pulumi, we actually encourage integrating directly with Pulumi's own cloud offerings to manage your infrastructure state. https://nitric.io/docs/reference/pulumi

Note this only applies to our OOTB providers which use Pulumi as our deployment engine of choice.

When you take away our providers Nitric becomes a communication layer between your application and any deployment engine that implements the Nitric deployment API: https://nitric.io/docs/reference/providers/custom/building-c...

This allows collecting a Bill of Materials of cloud concepts (e.g. APIs, topics, buckets, queues, policies etc.) and providing them however you like with code. This could be templating IaC, directly executing IaC, rolling your own solution or anything in between.

As for how we make money, currently we're doing consulting and dog-fooding our own tooling while working with existing teams struggling with more traditional deployment setups to make them more productive, their feedback is used to make own product even better :).

It's a valid point, Nitric isn't a good fit in some cases. We've been working on improvements to the underlying provider implementation to allow for easier extension for non-standard cases. Nitric is a gRPC API under the hood, so alternate implementations can be built to satisfy the APIs when customization is needed.

Reply on news.ycombinator.com