5 ms·

Yeap we did. I wrote it off around the time of the licence change, just after they decided to ditch the TF Team plan in favour of the utterly ridiculous “Resou

by danw1979 2y ago

Yeap we did. I wrote it off around the time of the licence change, just after they decided to ditch the TF Team plan in favour of the utterly ridiculous “Resources Under Management” billing model. I knew the company had lost the plot at that point.

jeeyoungk 2y ago
Who's the target audience for this pricing that can afford this? The RUM pricing is indeed quite ridiculous. It feels quite ridiculous, especially if you are managing "soft" resources like IAM roles via Terraform / Pulumi. At least with real resources (say, RDS instances), one can argue that Terraform / Pulumi pricing is a small percentage of the cloud bill. But IAM roles are not charged for in cloud, and there are so many of them (especially if you use IaaC to create very elaborate scheme).
- Schnitz 2y ago
  Pulumi’s RUM pricing is why I was very hesitant to even evaluate it as an alternative to just using terraform.
  - Aeolun 2y ago
    I’m finding that the basic backend functionality of Pulumi and Terraform managed cloud is fairly easy to build (especially Terraform, I can’t quite believe how absurdly simple their cloud is…)
    - hiatus 2y ago
      Plus there are open source projects like Atlantis that fit the bill for many teams with regards to terraform automation.
      - sausagefeet 2y ago
        Terrateam too[0] Although Terrateam is more tightly integrated with a VCS provider. Disclaimer: I co-founded Terrateam. [0]https://github.com/terrateamio/terrateam https://github.com/terrateamio/terrateam
- progbits 2y ago
  It also creates horrible incentives. Oh I won't run this in isolated project or under a separate service account since that costs more, let's just pile everything together.
  - ryanisnan 2y ago
    To be fair to RUM pricing, there are also horrible incentives for workflow invocation based pricing models, or workspace count models.
- brudgers 2y ago
  Who's the target audience for this pricing that can afford this? The kind of customers it is good to have. Because filtering out price sensitive customers is a sound business strategy. As a rule of thumb, solve any problem your customer might have. Except not having money.
  - bastawhiz 2y ago
    Good for who? Good for people getting bonuses? Good for executives? It doesn't seem to be good for the customers or the people using the software or the people contributing to the open source code. It also doesn't seem to have been good for the investors, looking at the other comments.
    - hiatus 2y ago
      Good for people who got in pre-IPO. Bad for people who got in post-IPO.
  - tiniestcabbage 2y ago
    There is an argument to be made that price-sensitive customers are a neglected market. Granted, marketing to them is very different - they're prone to being scooped if someone comes by willing to sell your same product to them at a loss (hi, Amazon and Walmart) - but there are a lot more of them and you're not fighting every startup on the planet for the same handful of clients. Business have made a killing in China and India for a reason, after all.
    - brudgers 2y ago
      + There’s an argument against every rule of thumb. + For what it is worth, the just-one-percent-of-all-Chinese is historically a poor business strategy. + As you point out, targeting price sensitive customers puts you in competition with Walmart and Amazon. Not only that but you are competing for their worst customers. you're not fighting every startup on the planet for the same handful of clients Not having access to good clients/customers suggests the business idea might not be viable. Chasing money from people without the wherewithal or will to pay, does not make your business idea viable. But again it is a rule of thumb.
- thedougd 2y ago
  That must explain why they broke up the S3 resources into a bunch of tiny resources.
eikenberry 2y ago
It was made apparent right after the IPO. Our team got a new VP in charge who changed the mantra from practitioner-first to enterprise-first. Soon after they then laid-off anyone not working on enterprise features. It was a sad death of a great company culture. Mitchell left around the same time which, IMO, speaks volumes.
- ethbr1 2y ago
  The older I get, the more I'm convinced that practitioner-first is the only reasonable way to drive a product's features, while enterprise-first is the only reasonable way to drive a company's revenue. Which is to say strong sustainable products need both. ... but ffs don't let the entire company use enterprise as a reason to ignore practitioner feature requests.
JojoFatsani 2y ago
Pricing, and, generally speaking, customer engagement were not their strength
sepositus 2y ago
This is probably inaccurate, but it seemed like they wrote it off as a safe move, with their main competitor, Pulumi, getting away with it. However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately. I hate it, though. It's user-hostile and forces people to adopt anti-patterns to limit costs.
- hiatus 2y ago
  > However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately. That would make sense if you paid per API call to any of the cloud providers.
  - sepositus 2y ago
    What happens when you run `terraform apply`? Arguably, a lot of things, but at its core it: - Computes a list of resources and their expected state (where computation is generally proportional to the number of resources). - Synchronizes the remote state by looking up each of these resources (where network ingress/egress is proportional to the number of resources). - Compares the expected state to the remote state (again, where computation is generally proportional to the number of resources). - Executes API calls to make the remote state match the expected state (again, where network ingress/egress is proportional to the number of resources). - Stores the new state (where space is most certainly proportional to the number of resources) This is a bit simplified, but my point is that in each of the five operations, the number of resources can be used as a predictor for the consumed compute resources (network/cpu/memory/disk). A customer with 10k resources is necessarily going to consume more compute resources than one with 10 resources.
    - hiatus 2y ago
mnahkies 2y ago
I actually prefer the RUM model. The previous "per apply" based model penalized early stage companies when your infrastructure is rapidly evolving, and discouraged splitting state into smaller workspaces/making smaller iterative changes. Charging by RUM more closely aligns the pricing to the scale/complexity of the infrastructure being managed which makes more sense to me. That said it has tempted me to move management of more resources into kubernetes (via cross plane/config connector)
- danw1979 2y ago
  The previous model I was referring to was a flat-rate TF Cloud team plan at (in the UK) <$30/month. There were runtime limits IIRC but there was nothing stopping Hashicorp offering a “per user” fixed rate plan at several hundred dollars per month to enterprises for the same service. The various clients I’ve worked for who used TF would have lapped this up. RUM (or the equally opaque “call us” - we won’t answer! - enterprise pricing that proceeded it) not so much.

jeeyoungk 2y ago

Who's the target audience for this pricing that can afford this? The RUM pricing is indeed quite ridiculous. It feels quite ridiculous, especially if you are managing "soft" resources like IAM roles via Terraform / Pulumi. At least with real resources (say, RDS instances), one can argue that Terraform / Pulumi pricing is a small percentage of the cloud bill. But IAM roles are not charged for in cloud, and there are so many of them (especially if you use IaaC to create very elaborate scheme).

Schnitz 2y ago
Pulumi’s RUM pricing is why I was very hesitant to even evaluate it as an alternative to just using terraform.
- Aeolun 2y ago
  I’m finding that the basic backend functionality of Pulumi and Terraform managed cloud is fairly easy to build (especially Terraform, I can’t quite believe how absurdly simple their cloud is…)
  - hiatus 2y ago
    Plus there are open source projects like Atlantis that fit the bill for many teams with regards to terraform automation.
    - sausagefeet 2y ago
      Terrateam too[0] Although Terrateam is more tightly integrated with a VCS provider. Disclaimer: I co-founded Terrateam. [0]https://github.com/terrateamio/terrateam https://github.com/terrateamio/terrateam
progbits 2y ago
It also creates horrible incentives. Oh I won't run this in isolated project or under a separate service account since that costs more, let's just pile everything together.
- ryanisnan 2y ago
  To be fair to RUM pricing, there are also horrible incentives for workflow invocation based pricing models, or workspace count models.
brudgers 2y ago
Who's the target audience for this pricing that can afford this? The kind of customers it is good to have. Because filtering out price sensitive customers is a sound business strategy. As a rule of thumb, solve any problem your customer might have. Except not having money.
- bastawhiz 2y ago
  Good for who? Good for people getting bonuses? Good for executives? It doesn't seem to be good for the customers or the people using the software or the people contributing to the open source code. It also doesn't seem to have been good for the investors, looking at the other comments.
  - hiatus 2y ago
    Good for people who got in pre-IPO. Bad for people who got in post-IPO.
- tiniestcabbage 2y ago
  There is an argument to be made that price-sensitive customers are a neglected market. Granted, marketing to them is very different - they're prone to being scooped if someone comes by willing to sell your same product to them at a loss (hi, Amazon and Walmart) - but there are a lot more of them and you're not fighting every startup on the planet for the same handful of clients. Business have made a killing in China and India for a reason, after all.
  - brudgers 2y ago
    + There’s an argument against every rule of thumb. + For what it is worth, the just-one-percent-of-all-Chinese is historically a poor business strategy. + As you point out, targeting price sensitive customers puts you in competition with Walmart and Amazon. Not only that but you are competing for their worst customers. you're not fighting every startup on the planet for the same handful of clients Not having access to good clients/customers suggests the business idea might not be viable. Chasing money from people without the wherewithal or will to pay, does not make your business idea viable. But again it is a rule of thumb.
thedougd 2y ago
That must explain why they broke up the S3 resources into a bunch of tiny resources.

eikenberry 2y ago

It was made apparent right after the IPO. Our team got a new VP in charge who changed the mantra from practitioner-first to enterprise-first. Soon after they then laid-off anyone not working on enterprise features. It was a sad death of a great company culture. Mitchell left around the same time which, IMO, speaks volumes.

ethbr1 2y ago
The older I get, the more I'm convinced that practitioner-first is the only reasonable way to drive a product's features, while enterprise-first is the only reasonable way to drive a company's revenue. Which is to say strong sustainable products need both. ... but ffs don't let the entire company use enterprise as a reason to ignore practitioner feature requests.

JojoFatsani 2y ago

Pricing, and, generally speaking, customer engagement were not their strength

sepositus 2y ago

This is probably inaccurate, but it seemed like they wrote it off as a safe move, with their main competitor, Pulumi, getting away with it. However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately. I hate it, though. It's user-hostile and forces people to adopt anti-patterns to limit costs.

hiatus 2y ago
> However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately. That would make sense if you paid per API call to any of the cloud providers.
- sepositus 2y ago
  What happens when you run `terraform apply`? Arguably, a lot of things, but at its core it: - Computes a list of resources and their expected state (where computation is generally proportional to the number of resources). - Synchronizes the remote state by looking up each of these resources (where network ingress/egress is proportional to the number of resources). - Compares the expected state to the remote state (again, where computation is generally proportional to the number of resources). - Executes API calls to make the remote state match the expected state (again, where network ingress/egress is proportional to the number of resources). - Stores the new state (where space is most certainly proportional to the number of resources) This is a bit simplified, but my point is that in each of the five operations, the number of resources can be used as a predictor for the consumed compute resources (network/cpu/memory/disk). A customer with 10k resources is necessarily going to consume more compute resources than one with 10 resources.
  - hiatus 2y ago

mnahkies 2y ago

I actually prefer the RUM model. The previous "per apply" based model penalized early stage companies when your infrastructure is rapidly evolving, and discouraged splitting state into smaller workspaces/making smaller iterative changes. Charging by RUM more closely aligns the pricing to the scale/complexity of the infrastructure being managed which makes more sense to me. That said it has tempted me to move management of more resources into kubernetes (via cross plane/config connector)

danw1979 2y ago
The previous model I was referring to was a flat-rate TF Cloud team plan at (in the UK) <$30/month. There were runtime limits IIRC but there was nothing stopping Hashicorp offering a “per user” fixed rate plan at several hundred dollars per month to enterprises for the same service. The various clients I’ve worked for who used TF would have lapped this up. RUM (or the equally opaque “call us” - we won’t answer! - enterprise pricing that proceeded it) not so much.