

DotCloud updates pricing, uses new elastic pricing model - sgrove
https://dotcloud.com/pricing.html

======
moe
This is easily one of the worst pricing pages I have ever seen.

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.

~~~
shykes
Hi moe, thanks for the feedback,

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?

~~~
richardw
Not the elastic nature, more that it takes longer than it should to understand
what the drivers are. If everything is related to memory and memory only goes
up in 32MB chunks, have a slider/radio/dropdown/whatever that moves memory and
related resources simultaneously, with a per-hour and monthly charge that's
auto-updated.

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.

~~~
shykes
All good feedback. However the one giant caveat is that most developers _don't
know_ how much memory their application needs.

~~~
cardmagic
Most people don't know how much disk space an email takes, it didn't stop
Gmail from just giving 2gb free disk space.

~~~
pbreit
But 2gb sounds like a lot and 32mb sounds like nothing. When a service like
rackspace _starts_ at 256mb you wonder just what you are getting.

~~~
shykes
What you're getting is the ability to deploy linux containers with very fine-
grained control over resource allocation. Maybe you're using redis as a job
queue, or to hold a handful of counters. Maybe you're running nginx to serve
static assets with custom rewrite rules. You can run it dotCloud and pay
peanuts - knowing that you're one "dotcloud scale" away from all the gigabytes
of ram you can eat.

------
StavrosK
Every time I see a cloud pricing page, I think "this is 100x more expensive
than my 50 Eur Hetzner server".

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.

~~~
mark_l_watson
+1 Everyone agrees with you that dedicated boxes rented from companies like
Hetzner are a much better deal for what resource you get for your money.

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.

~~~
StavrosK
I definitely agree with you. This is why, nowadays, I design all my
deployments to be repeatable, and document what cannot be (not much, so far).

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?

~~~
gabrielgrant
While you're right that EC2 is pretty close the metal, dotCloud starts at a
very different level of abstraction. On most VPS providers (as with dedicated
hosting) the first question you answer when you go to deploy your web app is
"what Linux distro do you want to run?" If you're trying to learn sys admin
skills, that's great, but for most people, the end goal is to deploy a web
app, not run a Linux box.

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.

------
glesica
The sample budgets are nice, but why not just say "$4.32 per 32MB of RAM per
month".

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...

------
mark_l_watson
I just wrote about this ([http://blog.markwatson.com/2012/06/more-on-paas-new-
dotcloud...](http://blog.markwatson.com/2012/06/more-on-paas-new-dotcloud-
pricing-and.html)). I wonder if the free sandbox vs. "live" setups will
encourage more developers to transition to paid services, and not permanently
host small web apps for free.

~~~
sgrove
Well, what's the value in the free, small web apps? Ultimately some money, and
maybe even a small company's worth of money, but not enough to affect the
bottom line of a company the size of what dotCloud is aiming for.

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.

------
pieter
I don't understand the sample budgets -- is that cost per hour? day? week?
month? Why don't they specify something as basic as that somewhere?

~~~
shykes
Hi Pieter, sample budgets are per month. We'll update the page to make it
clearer. Thanks for the feedback!

~~~
X-Istence
Looking at the sample pricing I am having a hard time understanding what that
means for a simple website for example...

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...

~~~
jpetazzo
Well, it's impossible to give an universal response. It's like trying to guess
how much you will pay on gas on your daily commute without knowing the
distance or the kind of car you're driving.

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 :-)

------
qikquestion
I like to use this for my redis setup...what about the data backups for the
persistent data..do you manage that?..If yes..what is the frequency ? I think
you should provide more data for database services..especially for redis about
the memory, disk space & connections. I like to move from redistogo if
comparable metrics are provided.

------
patrickgzill
There are 512, 32MB chunks in a 16GB RAM server (let's say with overhead, you
need 32GB RAM). $512 * $4 = over $2000 per month, for a single server that you
can buy for about $2000 and colocate for maybe $100-$150 per month.

Sure, you can buy it in little pieces, and sure, it is managed, but really!

------
rwhitman
Suddenly this service became a lot more interesting to me

------
kmfrk
The grey, grainy background makes for really bad contrast on the website. The
layout seems nice, but the contrast brings down the readability and aesthetics
orders of magnitude.

I can imagine colour-blind or bespectacled users find it particularly
straining to read.

------
shykes
Hi all, thanks for all the feedback!

We've pushed an update to the pricing page based on your suggestions:
<https://www.dotcloud.com/pricing.html>

~~~
detst
The top complaint was typical hyperbolic contrarianism. The first page
provided the basics well enough for you to get feedback on where to improve.
It wasn't that bad.

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.

------
Ecio78
in the $172.80 sample you have a typo: "PostreSQL"

~~~
KenCochrane
Thank you for letting us know, we will get that fixed.

