DotCloud updates pricing, uses new elastic pricing model
dotcloud.com
dotcloud.com
Your pricing scheme is extraordinarily complex and the page does the poorest possible job at explaining anything. Heck, it doesn't even mention that RAM is your discriminator - it simply implies it as if that was natural.
Moreover none of the terms are explained (what is "Vertical Scaling", what is "Proportional to application memory")...
There is not even a calculator/slider to get a rough idea of actual cost without engaging in Excel-gymnastics.
You should seriously get outside help for this.
The page doesn't mention whether it's per day, month, or year for example, but they seem to be taking feedback from a couple of the other comments.
Not sure why you've been downvoted for this, seems a bit harsh.
I suppose it's the elastic nature of the pricing that you find complex? I can't disagree with you, it is less straightforward than flat monthly plans. However it is what litteraly thousands of developers have been asking us for over the last year. Our previous pricing was focused on simplicity... but ended up sweeping the reality of our product under tbe rug.
I think you're right that we don't explain enough on the pricing page. Our concern was text overload., but there's probably a balance to be found.
What about the content - any opinion on our actual pricing?
But that's just my gut reaction. What you really need is a webdesigner who can lay down an approachable visualization for such a complex pricing scheme (which will probably involve sliders, and also big honking tooltips).
As for your actual pricing - I don't know. It wasn't obvious from the page what a small/medium/large deployment would cost and I didn't bother to fire up excel to figure out a number that you should absolutely spoon-feed me.
I don't want to click through 5+ random scenarios to perhaps find one that comes close to what I have in mind.
Well, at the risk of repeating myself. You seem to be generating revenue already, so I would seriously look into hiring a designer for this (or make a contest or such).
My gut feeling is that you're so deep into all this (which is generally good!) that you have a hard time reviewing it through the eyes of a first-time visitor.
I think it's important to note that the page is about pricing, but 99% of the info isn't a price. Above the fold there's only one price, which you have to use in calculating the actual value yourself. Way, way down are the examples, but they might or might not represent what a customer's workload will look like, so they still don't really have what they came to the page for. Getting the customer their own price, super-fast, (assuming it's a good one) is the path to showing why you guys are so fantastic.
Also there could be small hints next to the slider (yes, I'm a fan of sliders;)) as it snaps into the various positions...
But those are again just ideas. You should get a good designer on the case, this is their bread & butter.
Have a slider. When you move it have a window that lists what applications can be served with the selected allotment.
Hell... that'd be pretty damn cool looking
I can't get the examples to come out right. Looking at the 3rd one for $172.80, if i get out my calculator and crunch, it looks like it should be $112.32 to me.
(256 x 1) + (448 x 1) + (128 x 1) = 832 total MB RAM
at $0.006 per 32MB ram per hour you get $4.32 per month per each block of 32 MB
832 / 32 = 26 blocks of 32 MB RAM
26 x 4.32 = $112.32
what am i doing wrong here?
Thanks for pointing that out.
It's hard to get excited when I see 1 GB of total RAM costing $350 when my 24 GB, 2 TB, i7 server costs $60. Sure, scalability, blabla, but if you're talking startup-friendly, then a dedicated server is hundreds of times cheaper.
I always regret getting a Linode box for historious rather than a Hetzner server.
However managing servers is a form of technical debt. A lot of private corporate and public web apps are written, deployed, and not changed much assuming that they do what people need. "Set and forget" PaaS reduces technical debt.
That said, I have been thinking myself of getting one large memory Hetzner box to replace machine learning and other background stuff that I might otherwise do with Elastic MapReduce. Scale vertically rather than horizontally.
I get a Hetzner box that I know will probably last me for the lifetime of the app. If it doesn't, and I actually have ten million users, I have a good problem, and will study how to overcome it at that point.
I think I don't need the cloud until I need a fourth dedicated server. That sounds like a good rule of thumb. It also depends on your growth rate, if it looks like another server will last me another five years, why pick a cloud offering?
I think that EC2/dotcloud/etc are pretty close to the metal anyway, it seems to me that you get the high prices with fewer benefits. Can someone tell me what the advantage of EC2 is, given that each dedicated server has 32 GB RAM and no contention, and that EBS is known to be really flaky?
With dotCloud, you start higher up: list the components (eg Python web frontend, MySQL and Redis) that make up your actual application, push your code and you're handed back a URL with your app running. A single command lets you scale out for reliability, with load balancing across your multiple web front-ends and master-slave replication for your databases. Running a single physical server? Sure, not that hard. Setting up reliable, automated failover for every component in your stack? That's a bit more work.
In the end, it's really a question of the value of your time. Can you do all your own sys admin work? Sure. You could also build and maintain your own hardware, but from the sounds of it, you've decided that work is worth outsourcing Hetzner.
In the same way, for a lot of people, wasting time administering servers is just time taken away from building a real business: a distraction that is worth paying a few extra dollars a month to make disappear.
- If you think of dotCloud as expensive hosting, then don't use it because you're missing the key value proposition. DotCloud is affordable managed hosting: we do the work of operating, monitoring, maintaining which you would otherwise need to do yourself. And we do it better and more cost-effectively than our customers could do it, because it's all we do for hundreds of thousands of deployments.
- dotCloud scales down way better than iaas. What's the cheapest ec2 setup with production trafic, load-balancing, failover and monitoring, plus a bunch of sandbox environments? Hint: we're cheaper.
- Our large customers benefit from volume discounts
What do you guys manage exactly? What sort of work am I saving if I get dotcloud?
- We curate a configuration of each service that "just works", and we maintain it over time for upgrades and security patches.
- We implement scaling and reliability best practices for each service: load-balancing, deployment across multiple datacenters, database replication and failover, hot deploy, strict change management, etc. We do this in production at a very large scale, so even for a very small application you benefit from the equivalent of a 20-people ops team serving tens of millions of uniques.
- We actively monitor and support everything we deploy, and are on call 24/7 to fix things when they break. This is important because 100% automation never happens in the real world. When things break we fix them, or help you fix them. We've been known to fix bugs in our customer's code, but don't tell anybody :)
Our job is to be a provider you can trust to run your stuff in the long run. That's what PaaS is supposed to be.
Also, what's with the jump from $8 to $80? Seems like quite a few people would be interested in hosting something between those two price points...
Being able to get little apps up and running quickly for free (just like on Heroku) is a great marketing tool, and a feeder for bigger accounts. Any app that's serious will quickly outpace the sandbox (horizontal/vertical scaling, failover, loadbalancing, etc.) And there's little point in trying to extract value from apps that aren't generating enough value themselves.
Seems like a very smart move to me.
Lets say I have a Python Django app that gets 10k hits a month, and it uses PostgreSQL on the backend. What will that set me back? How will I know how much memory to scale by?
I am an engineer and I find this extremely difficult to grok...
It depends how much work is done in each "hit". If 99% of those 10k hits are to display the 10 most recent entries in a table, a very small setup will take you very far. A couple of 96 MB Python front-ends, 64 MB for SQL, you would pay maybe about $40/mo for a decent setup.
Now if most of the hits trigger complex geographic queries against a database of millions of records, with a high write/read ratio, it's a whole different story. You need to know about the size of your working set (you can then infer your database memory requirements), and have a rough idea of the average request time and concurrency (to infer your number of workers, if you're using a synchronous server like most deployments of Django or Rails).
While the "per-megabyte" price will be higher than "raw hosting", keep in mind that the granularity will allow you to do huge savings. Instead of paying for this 1.7 GB instance, you can pay for just 200 or 300 MB of RAM if that's what your app requires :-)
Once you push a configuration to a 'live' flavor then you can also get an estimated bill via 'dotcloud info'.
There are some sample prices from real apps available too: https://www.dotcloud.com/pricing.html#slider_pricing
Sure, you can buy it in little pieces, and sure, it is managed, but really!
I can imagine colour-blind or bespectacled users find it particularly straining to read.
We've pushed an update to the pricing page based on your suggestions: https://www.dotcloud.com/pricing.html
Links to more explanations (i.e. horizontal vs. vertical scaling, details of CPU resources, memory allocated to sandbox apps, etc.) and a cost calculator would be sufficient. Now you've taken away information.