4 ms·

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 yo

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.

hobs 3y ago
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!
- JohnMakin 3y ago
  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.
  - aliasxneo 3y ago
    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.
  - hobs 3y ago
    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.
    - JohnMakin 3y ago
      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.
      - hobs 3y ago
        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.
        tekla 3y ago
        You can't stop people from doing dumb things if they don't want to learn.
        acdha 3y ago
        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.
- wrnch 3y ago
  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...
  - hobs 3y ago
    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.
    - icedchai 3y ago
      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?
  - tholm 3y ago
    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 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-custom-provider 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 :).
jcusch 3y ago
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.

hobs 3y ago

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!

JohnMakin 3y ago
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.
- aliasxneo 3y ago
  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.
- hobs 3y ago
  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.
  - JohnMakin 3y ago
    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.
    - hobs 3y ago
      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.
      - tekla 3y ago
        You can't stop people from doing dumb things if they don't want to learn.
      - acdha 3y ago
        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.
wrnch 3y ago
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...
- hobs 3y ago
  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.
  - icedchai 3y ago
    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?
- tholm 3y ago
  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 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-custom-provider 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 :).

jcusch 3y ago

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.