My current project is a cloud deployment platform similar to GAE or Heroku. I'm trying to figure out what pricing method works best for us and the users. Assuming that I cannot currently provide a free plan, here are the options:

1) Have fully unlimited scaling (GAE-like), and charge for usage ($5 per project + x cents per CPU hour the project uses on our system, also charge a certain amount for bandwidth in/out, database storage + I/O, r/w data store, memcached, etc.)

This ends up being cheaper (around $20 for a moderately loaded website) and more "fair" for the user (pay only for what you use), but much more complicated with the many different factors that affect final price. This type of architecture is more resilient to what you throw at it, so if you get a traffic spike, it will work perfectly fine, you'll just get charged more.

2) Pay for "application readiness"/specific scalability (have a specific amount of processes per user available to accept requests, maybe $20 a month (3 cents per hour) per process), and for a specific tier of a database. No bandwidth/IO charges (within fair use, of course). Add-ons like email and memcached are extra. (Heroku-like)

This option is a lot more simple, and much easier to project costs on. However, the pricing curve is rather steep. You do end up likely paying more (probably $40-$60 a month for a moderately-loaded website), but all of those miscellaneous costs are completely abstracted.

Which would you more likely pay for? Also, is there another option I may be overlooking?

closed as primarily opinion-based by user22815, Ixrec, user40980, durron597, gnat Aug 31 '15 at 16:04

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Who are your users? – David Thornley Oct 15 '10 at 21:56
  • Ranging from small developers (probably not willing to pay more than $30 a month) to potentially large corporations. – dkulchenko Oct 18 '10 at 4:00
  • I prefer the structure where I pay nothing, ever ;) – Matt Ellen Oct 19 '10 at 12:08
  • How does that work? Servers ain't free, you know ;) – dkulchenko Oct 19 '10 at 13:06

I much prefer the first model. So many sites want to extract $x/month and some of these sites make it very difficult to unsubscribe from. Even if the first model was more expensive, I'd prefer it as I would only be paying if I had a project, in which case, justifying the cost is very easy.

  • I've found that the 1st option is not completely realistic, as having the ability to have incredible server readiness for all projects is too cost-prohibiting for a (currently) small project. So I'll probably end up going with a modified version of the 2nd option (more in a follow-up answer). – dkulchenko Oct 19 '10 at 13:11

I realized I can't go with infinite autoscaling because that would require a very large amount of idle servers on hand, which I can't provide at this point. Google has a large amount of slack capacity on their servers, so they can easily do so.

Here's what I will probably end up going with:

Each user pays a few cents (around 2-3) an hour per instance that they have running. There will be an autoscaling option in place (user can set the maximum the platform can increase the running processes to in times of high load). By default, each project will get bandwidth, disk storage, memcached, and a database (at no additional cost). If the project needs more, they can upgrade each of those components at a reasonable rate. Also included would be cron, web-based monitoring, mobile apps, alerting, development/staging environment, backups, redundancy, failover and so on, all as part of the service. Sounds fair?

  • huh? didn't you say in the first paragraph you can't go with autoscaling, then later on your say you will? Even googles scaling isn't infinite. They just have another slack capacity to guarantee scalabilty. Can your solution make the same claim? – Anonymous Type Jan 16 '11 at 22:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.