3 ms·

I think that'll be pretty useful for a lot of companies but I'm not sure whether going with container count as limit will work. Staging is where the software i

by monus 7y ago

I think that'll be pretty useful for a lot of companies but I'm not sure whether going with container count as limit will work. Staging is where the software is tested as a whole before the production and in many cases it's more than a few containers. I'd not pay $500 for "Up to 5 containers/env" to set up a staging environment for my app that consists of many microservices deployed on Kubernetes. My two cents; change the pricing model. It's not only expensive but also container count is not that helpful. Number of environments is a good proxy for the value I get but I don't want to be punished just because of my number of containers; cpu + memory could be more acceptable.

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 ago
  I 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 ago
    Yeah, 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.
ashrodan 7y ago
https://runnable.com/preview-environments/ https://runnable.com/preview-environments/ Runnable has the same offering, now bought out by mulesoft. They charged per user.
- deleted 7y ago
  [deleted]

by monus 7y ago

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 ago
I 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 ago
  Yeah, 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.

ashrodan 7y ago

https://runnable.com/preview-environments/ https://runnable.com/preview-environments/ Runnable has the same offering, now bought out by mulesoft. They charged per user.

deleted 7y ago
[deleted]