3 ms·

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

by 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 :).

by wrnch 3y ago

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