Heroku sells convenience, and resells EC2 instances to you. Their previous dedicated database option, Ronin, cost $200/month. When you connect the dots that this DB has a 1.7GB cache and that a small instance on EC2 has 1.7GB memory[1], you start to realize what you're really paying for.
While paying 3.3 times more[2] may be ok for the added simplicity, you have to wonder if your 'dedicated' database is really just a small instance on EC2? If it is a larger instance, then you are sharing it with other users.
However, even a small instance is far from not being shared. EC2 has performance issues, especially small instances. Disk IO is the worst.[3]
Disclaimer: These are all just my observations, and I don't how Heroku actually configure their Ronin databases. I'd love to be proven wrong, and to have someone from Heroku explain. But from personal experience with both EC2 and Heroku's Ronin database, if my conclusions are wrong, the results are not. I've seen very slow performance on the simplest of queries on both configurations.
If anyone from Heroku is reading, that page is a great example of how poor contrast results in poor readability. Blue-on-blue text makes me close the browser tab, and not actually see what you're trying to sell.
Heroku is really great to get your started if you don't want to worry about managing infrastructure. However, you're paying a major premium for that and you need to have an exit plan from the beginning incase you grow too big and the costs no longer make sense.
I agree with everything you said, except that I don't think you need to spend any time working on an exit plan until the day you realize you're paying "too much" (whatever that means to you) for the benefit you're receiving from their managed hosting. I recommend: Launch on Heroku. Reevaluate that choice on success.
Think about what "too much" Heroku spend is. Think about what level of adoption/success it will take to reach that much Heroku spend. Then consider if you actually get to that level of adoption, are your Heroku costs really going to be "too much?" Don't spend more than 90 minutes on the whole exercise.
My guess is that, for most apps, worrying before launch about migrating off of Heroku is a premature optimization.
I'm not sure, actually. Running an application on such specialized application servers as Heroku provides has the benefit of being highly scalable, but it also means you have to adhere to some architectural patterns, which I believe address a lot of the migration issues people would normally encounter.
The most obvious example (and probably most relevant) is that on Heroku you can't store permanent files locally. Instead you need to store them on something like Amazon S3. However, the application servers also aren't a great place to do things like video processing. Instead, you'd lean on a third-party service like Zencoder.
As a result, applications that run well on Heroku have very few environmental dependancies and migration should be relatively straight forward. They even make it brilliantly easy to dump your database to a file that can be imported elsewhere.
I think the real pain in migrating from Heroku is outside of the application itself. I think the real pain is duplicating all the infrastructure and staffing you never had to think about when you deployed your app in the beginning. Honestly, I don't even know all the details of what they do. But I know I've never set it up myself and I'm not really interested in doing it. I don't want to hire someone to do it, either. It's enough being on call for application issues, never mind all the rest.
In every venture I'm involved in, traffic and users translate directly into money, so paying Heroku a cut of that success is not a problem. They've earned it.
I think the people who are most likely to worry up front about a plan for migrating off of Heroku has a great deal of overlap with the sort of people who will make migrating off Heroku difficult for themselves by depending on too many "exotic" add-ins.
Absolutely agree that that is the first priority, but there are many factors you can keep in mind during development without slowing it down much, and this is one of them.
I am actually going through this right now as we saw our EC2 instances start doing 2-10 second response times under little load. So currently migrating to a dedicated server.
What is is found an interesting product called VCider which allows you to create mini private clouds. This might be something to look into using from day one to help with eventual migration. It is free up to 8 servers.
vCider is mostly a cleverly marketed VPN. It could be useful when you have servers mixed across different IaaS providers or IaaS and your own physical infrastructure. I don't see how it solves much of the problem of migrating off an IaaS or PaaS provider.
What Heroku features, products, or enforced architectural choices (like no permanent disk on the spawned processes) do you see as causing lock-in that you would plan around avoiding or taking into consideration for a migration off Heroku?
Can somebody clarify which heroku plans are best, as you work from development through MVP and initial traction? My current understanding is:
Development Stage: Use the free plan.
MVP Stage: When I have an MVP that I'd like to show people and get feedback on, I'm not sure if I should stay with the free plan, or if I need a paid plan at this point.
Gaining Traction: Still low overall volume, but consistent users. What is the cheapest paid plan that works for this stage? Is it the $15 plan, or the $50 plan?
Increasing Traffic: At this point, it's a little more clear that you choose add-ons to match your specific needs.
I would love it if someone could clarify what kinds of loads each of these plans could reasonably be expected to handle.
The answer to this depends on such a variety of factors that it's impossible to give a useful answer.
Use something like New Relic to watch your app's performance. If it's exceeding tolerable limits, you need to change something. This might be a re-write of your code to reduce load, or pouring more resource into dynos, workers, database or caching.
Congrats to the Heroku DoD on launching this long-awaited price point!
Can we create Crane followers of a larger master database yet? That would be really useful - keeping a cheap, eventually-consistent replica around for backup and analytics.
If you are on an older ronin or fugu you can't. But you can from all other plans and newer ronin/fugu databases. The limitation on older ronin/fugu databases is related to: https://devcenter.heroku.com/changelog-items/37
I'm building an app that will eventually use hstore for data. I say 'eventually', because I'm currently using serialized columns on the $15/month shared plan, and hstore is not yet supported.
At $50/month, this is cheap enough for me to use as a staging server or as a pre-release server to get hstore across my entire environment.
I have an app that has a number of test users with a set of data for each of them that shows off the app. Since the users interact in specific ways, I need to have several users otherwise the testing isn't useful.
My dev machine has a much smaller set of data, but on Heroku, I run stage servers with reasonable amounts of real life data that I need for final testing
Very cool. I've been looking at spatial databases and the fact that I could get MongoDB running on a free plan (e.g. with MongoLab and MongoHQ) made me go that way. (for now)
PostGIS has been available on Heroku's dedicated DBs (https://devcenter.heroku.com/articles/is-postgis-available), but the $200/month was a bit high for early stage. $50 is much more manageable and I might be looking towards Postgres + PostGIS in the future… (assuming that the linked post also applies to these new plans)
With that said I'm not sure how squid managed to be more dangerous than a kappa.
>Kappa are usually seen as mischievous troublemakers. Their pranks range from the relatively innocent, such as loudly passing gas or looking up women's kimonos, to the malevolent, such as drowning people and animals, kidnapping children, and raping women
It's kind of a love-hate relationship. They can be trouble when they're feeling mischievous, but if they're happy they'll help you out. The Japanese will leave gifts at Kappa shrines, just in case.
The best gift is cucumber, which the Kappa can't resist. Don't go swimming in Japan after eating cucumber, because they will drown you when they smell it on you.
Tried to set up a dev database from the dashboard; got a generic fail message. Told me why when I tried to add it from the CLI (my acct wasn't verified), may want to make this clear on the dashboard as well.
Damn, this is nice!
Thanks Heroku! I love the service, but 200 bucks as the lowest price point for a dedicated db didn't always make sense to me, especially in the startup world. This changes everything.
They've said they'll release something "at a comparable price point" to the $15/month shared plan. Hopefully the $50/month database isn't it as that seems high for hobby projects that outgrow the small dev database.
Most of our beta-testers have been using it just fine. We had one unlucky soul who encountered several pernicious bugs over a long period, but at this point I think they're all sewn up.
Nope, not on a Mac (fucking hate it that there are numerous apps for hackers now that are only made for Mac). This was my first time building a facebook app, playing with cloud hosting and using postgresql so the entire installation and use was complicated. I would have thought that since Facebook is encouraging you guys as the preferred/primary/sponsored cloud host that you'd provide a database that most people are familiar with - mySQL.
I ended up going with the clearDB addon just to save learning time, but at $10pm for only 1GB it's definitely a worse plan than the $15pm 20GB postgresql database you offer.
While paying 3.3 times more[2] may be ok for the added simplicity, you have to wonder if your 'dedicated' database is really just a small instance on EC2? If it is a larger instance, then you are sharing it with other users.
However, even a small instance is far from not being shared. EC2 has performance issues, especially small instances. Disk IO is the worst.[3]
Disclaimer: These are all just my observations, and I don't how Heroku actually configure their Ronin databases. I'd love to be proven wrong, and to have someone from Heroku explain. But from personal experience with both EC2 and Heroku's Ronin database, if my conclusions are wrong, the results are not. I've seen very slow performance on the simplest of queries on both configurations.
[1] http://aws.amazon.com/ec2/instance-types/ [2] http://aws.amazon.com/ec2/pricing/ [3] http://www.frederico-araujo.com/2011/12/27/why-ec2-still-sux...