I knew the company had lost the plot at that point.
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).
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.
Business have made a killing in China and India for a reason, after all.
+ 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.
The only point I was trying to get across is that even "bad" customers are still customers, and that there's still a lot of money to be made meeting people's needs doing the work others don't want to do. I feel like this applies from the bottom of the socioeconomic ladder all the way to the top - that's all. Perhaps I should've made that clearer, and that's on me.
An unsolicited side note: I think the bristling to this post was because of the language you were using. Talking about the poor as if they were to be discarded made you look a bit as if you have no empathy, which might not be fair to you. I get it - business require being hard-hearted if you want to get ahead because if you don't make tough decisions, someone else will - but it probably wasn't your best look, you know?
The context was Hashicorp pricing for a web service, I was not talking about the poor.
Not being able to afford a B2B service is not an injustice.
there's still a lot of money to be made meeting people's needs doing the work others don't want to do. I feel like this applies from the bottom of the socioeconomic ladder
Are you betting your breakfast on walking your talking?
even "bad" customers are still customers
That’s why I don’t recommend going out to find them. They tax your ability to provide high quality. You will have enough problems without trying to get lava from a turnip.
it probably wasn't your best look, you know
For better or worse, it’s not going to keep me up grieving on long winter nights.
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.
A good customer makes it easier to stay in business.
For fixed price customers that means paying a premium over time and materials.
If a customer pays more under time and materials pricing, they were not a good customer because they were making it harder to stay in business.
Although Terrateam is more tightly integrated with a VCS provider.
Disclaimer: I co-founded Terrateam.
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.
That would make sense if you paid per API call to any of the cloud providers.
- 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.
And then at the end as you said "stores the new state". Which is basically a big JSON file. 10 resources? 1M resources? I'll leave you to work out how much it probably costs to save a JSON file of that size somewhere like S3 ;)
The previous pricing model, per workspace, did the same. Pricing models are often based on "value received", and therefore often can be worked around with anti-patterns (e.g. you pay for Microsoft 365 per user, so you can have users share the same account to lower costs).
In that world, I think it'd make more sense to charge per run-time second of performing an operation. I understand the argument you are making but the issue is you get charged even if you never touch that resource again via an operation.
It might make sense if TFC did something, anything, with those resources between operations to like...manage them. But...
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.
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)
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.
Not great for investors, but insiders benefitted a lot!
I’m not passing judgment as to whether that’s “good” or “bad.” It simply is.
They will get capital losses.
That's not perfect.
At least in the startup narrative that circulates on HN, most early employees at a company with that kind of IPO would hope to have a lottery like level of financial windfall. Now their upside is if they manage to get luck a second time they get to offset their winnings? :/
I don't.
But the IRS will let you pay your taxes that way.
It obviously depends how much equity vs income you're talking about.
My doubt in the value of the company was that I've been using Terraform for years in Enterprise settings and never needed to pay the company for anything.
Running a few products. Quoted $1MM or so over 3 years for support. I was able to say no and saved six figures each month.
Retail will always be holding the bag. This is known.
They didn't with HashiCorp certainly. Bought some but not too much and were part of a housecleaning a few years back (which I'm glad I did).
OpenTofu[0] is the OSS fork though.
[0]: https://github.com/opentofu/opentofu
Disclaimer: involved with OpenTofu
And thanks for contributing :)
My kind of operations work VERY well in highly regulated industries because I'm meticulous about regulations. Just because I can do it quickly doesn't mean I do it poorly, and I don't appreciate the assumption that I'm a "cowboy" being reckless.
And it would appear to me you are underinformed about how much migration off of VMware is really happening in these highly regulated industries. There's a tremendous amount of low-profile engineering going on to migrate away. No one is tipping off Broadcom because they don't want BCom to try turning the screws even more.
Org's already knee deep in vault / vault-agent for PKI and secrets wont be eager to switch.