4 ms·
We originally started with the CPU+memory concept but as we explained it to customers it was confusing. They kept asking why we cared about CPU/memory. We're tr
by tommy_mcclung 7y ago
We originally started with the CPU+memory concept but as we explained it to customers it was confusing. They kept asking why we cared about CPU/memory. We're trying to proxy application complexity and our thinking was containers was an easy way to approximate that. Great feedback, we'll keep iterating and thinking about it.
- stingraycharles 7y agoI would rather have the CPU+memory concept as well. But I think you’re running the applications on the customers’ cloud accounts, right? In that case, if you want to stick to value-based-pricing, I would look at the amount of users the customer has rather than amount of containers. The latter depends upon the complexity of software and the choices of architecture, rather than “value” gained from your product. Having said all this, you have a great product and something like this has always been on my “dream list”, which tops my wish list. It always struck me as the ultimate form of immutable, throwaway infrastructure but I never had a proper excuse to build the necessary tooling to do this. Seems like you guys did, and I’ll be keen to give it a try!
- tommy_mcclung 7y agoYeah, we're running in the customers cloud account so charging based on compute was a really awkward conversation when we had those initial conversations. (Different if we're hosting it). Charging based on the number of environments feels right to us and our customers because that's when they derive value. The number of containers is just a proxy for the amount of complexity we are orchestrating for them. I'm 100% certain we don't have pricing figured out and I really appreciate the discussion.