
Heroku Pricing Changes - jmonegro
http://blog.heroku.com/archives/2010/1/21/pricing_changes_part_i/
======
patio11
_You, our customers, have given us great feedback that in some places our
pricing isn’t aligned with the value we provide, and in other places our
pricing is just confusing._

That sounds familiar.

<http://news.ycombinator.com/item?id=577622>

There is a user-visible _application_ to determine pricing which has, by my
count, 52 separate items I have to pay attention to figure out how much you
charge me.

How's about replacing it with this:

Cool Japanese Name for Hobbyist: $25

Cool Japanese Name for Small Business: $100

Cool Japanese Name for Enterprise: $1,000

Cool Japanese Name For Customize Your Own Plan: Click here for disgustingly
complicated form.

The best part is you _don't have to change anything about pricing_. Just
assume you know what people want (which should be easy since you have
thousands of customers and can look at what customers at particular sizes
actually need), put that into the plans, and you're done. If folks want to
shave $2 off their costs by playing Spreadsheet Samurai they still can.

------
swombat
I'm still not sure what market Heroku is addressing. It's great for free apps,
but as soon as you start to have to pay money, it doesn't seem competitive
compared to other options... Am I missing a trick here? Are paid Heroku
accounts actually the best thing ever?

~~~
andrewvc
Maybe I can provide some insight, I'm a current paying Heroku customer, our
monthly bill's in the hundreds/mo and I think it's a great value. I've been a
user of Engine Yard Cloud in the past as well (same app). I like EY Cloud just
fine, it's a great product, but Heroku's got a moderately more awesome
experience, and I like their architecture and the granularity of their billing
better.

To put it in simple terms, if you want a host with deep Rails knowledge that
will manage systems administration for you, Heroku and Engine Yard Cloud are
great offerings.

I actually have a reasonable amount of experience provisioning bare metal and
virtual servers from the ground up and I still opted to go with Heroku and pay
the premium for convenience. I just don't have the time to deal with hosting
issues, my company can afford it, and I'd rather spend all my time developing.
Additionally, compared to managed hosting from a company like Rackspace both
options are much better. The Rackspace techs I spoke with, that would've been
on my team didn't have much Rails specific knowledge, so I didn't see how
they'd be able to offload as much work as a Rails specific host.

The Heroku workflow beats every other develop/deploy workflow I've ever seen.
You could achieve the same stuff yourself, but it'd take a ton of work.

Want to send emails through sendgrid? 'heroku addons:add sendgrid', mailing
just works, no reconfiguration.

Want pull your production db down to your dev machine? 'heroku db:pull'.

Want to deploy your app? 'git push heroku master'

Want to scale up the number of Dynos? heroku dynos 6 #Scale to 6 Dynos

Want to make a backup of your DB and Code, then download it? heroku
bundles:capture heroku bundles:download

Want to reset your application to the state it was in when you snapshotted a
bundle? heroku bundles:animate BUNDLENAME

Yeah, I could set up an approximation of this, but the fact is keeping stuff
running is a chore that I'd rather not have, and my homegrown solution would
have more warts and be funkier to use.

Additionally, their stack is pretty awesome, and you only pay for code that
gets executed in the dynos, that means that rake tasks, cron jobs, and stuff
cached by varnish is effectively free. This is important because it means
those infrequently run CPU intensive tasks don't cause short losses of
responsiveness.

Lastly, I've spoken at length with some people on the Heroku team, and I know
them by blog posts they write. They're damn smart developers, and I definitely
trust them to run Heroku right.

~~~
ericd
Great answers to the questions I've been wondering about. I might have to give
Heroku a try.

How's the database performance?

~~~
andrewvc
It's been reliably fast, our DB response times are typically between 3 and 4
ms, though at the moment our DB is overpowered as we haven't yet transitioned
our truly DB intensive stuff onto it quite yet (we're on a Fugu, which is a
High CPU Medium, and the dataset we're using easily fits in memory).

That being said, working on Postgres has been noticably faster and more
pleasant than MySQL. Complex queries in MySQL didn't benchmark as well as they
did in Postgres.

As far as the shared plans go, we use a cheap shared (koi) DB for our staging
stuff, it's been snappy enough, even when re-syncing it with our production DB
which obviously puts on a massive write load, but I couldn't really
extrapolate much from that, and I have no idea how variable the performance
winds up being with multi-tenancy on the DB.

BTW, one of the joys of heroku really is db:push and pull. I can easily do:

heroku db:pull #Pull production database onto local machine heroku db:push
--app mystagingapp #Push the local DB onto the staging heroku db

Just be sure to do this with a script, the last you ever want to do is push
your dev DB to the production site.

~~~
ericd
Yeah, db:pull sounds pretty excellent - setting up a proper dev db mirror is
more pain than it's worth, usually.

Thanks again for the overview.

------
dcurtis
Seems like they're focusing on monetizing the compute performance and making
the database stuff essentially free.

I'd be interested to learn more about the business strategy behind this
change. It's an interesting direction.

------
jackowayed
This article's pretty old (~a month). I don't know that it was posted here,
but I'd guess it was.

