[aneth4]

My startup is heavily invested in and tied to Heroku. We don't have the resources right now to get off of the platform quickly, but plan to as soon as possible.

Like Rapleaf, we have spent an enormous amount of effort optimizing and searching for the causes of latency, and overpay for dynos to reduce but not eliminate the chance of latency issues. Heroku has always told us it's our fault.

While I have no interest in recovering money through a class action lawsuit - which is just grossly unproductive - my confidence in heroku has been shattered and I am embarrassed to have chosen and advocated for them for so long. I look forward to getting off their platform for good, and there is no way I could recommend it to others for similar applications.

Heroku's most recent statement does nothing to resolve the issue for most of their customers, and does not reduce what is clearly a gross overpricing and misrepresentation of what they provide.

It's quite clear that Heroku is not just a bad, but a horrible choice for rails applications that are not carefully designed for concurrency and don't go against Heroku recommendations and use a concurrent application server.

[lsc]

So, uh, what was the thought process when choosing a PAAS provider? I mean, step back for a moment, and ignore the specifics of Heroku; they are a PAAS provider with no completely compatible competitors, is that not so?

Whenever I choose service providers (or choose to outsource services) my first thought is "what happens if I have to switch away from them?" Even if you think my first rule of business is too cynical, everyone has problems, and if you are locked into a provider while they are having problems, well, you have a problem.

I mean, PAAS seems like a great idea for people who want to write apps but not be sysadmins. But personally? I don't understand why anyone would sign up with a PAAS provider that was unique. I mean, if you have to re-write your app to change providers, you are locked in, in a terrifying way.

[aneth4]

That's certainly a consideration, but every PAAS is "unique" by definition. Something like Google Apps has more lock-in than others. Some like Heroku are attractive because they have features not available elsewhere that would take a lot of resources to reproduce.

We chose heroku and Rails for the reasons you suggest, and even tried to avoid major tie-ins to the platform. That doesn't mean it's trivial to move to another platform.

[okalex]

That's not entirely true. Cloud Foundry (the software) is an open-source platform that allows for compatibility across providers. You can see a list of compatible providers here, in addition to cloudfoundry.com: http://www.cloudfoundry.com/partners

Full disclosure: I work for AppFog, one of the providers listed.

[lsc]

> That's certainly a consideration, but every PAAS is "unique" by definition.

I don't see how this is true.

There is nothing about PaaS that says there can't be compatible competitors. Hell, there have been PHP shared hosting platforms that were very nearly identical between providers for a decade before anyone started saying PaaS, and really, the "Innovation" that made shared hosting PaaS lies in per-usage billing.

[tedchs]

> We don't have the resources right now to get off of the platform quickly,

I hear people say this a lot but I believe it comes more from the emotion of fear than a rational consideration of the possibilities. For example, Amazon Elastic Beanstalk now supports Rails deployments that are just as easy as Heroku, and you retain 100% control over the underlying EC2/ELB/etc resources while having a nice management layer to help you out.

[aneth4]

Honestly I have not looked into it so far and hope you're right. We also use a number of addons, though I don't think any would be too difficult to replicate.

Regardless, it's a significant amount of work for a startup with just a few engineers, perhaps a week of two of distraction. I expect a bunch of "how to migrate off of heroku" blog posts will be out there shortly.

[tedchs]

Thanks very much for the blog post idea, I think I'll do something with that!

FYI you can keep all your Heroku addons inside your Heroku account while utilizing them from a server outside Heroku. For example, if you use the "Redis To Go" Heroku addon, you can fire up your own EC2 instance (possibly through AWS Elastic Beanstalk) and connect to your Redis To Go instance using the same connection info. The main difference will be that you won't have access to Heroku's environment variables that you're using now, but you can use a config file instead.

[jpdoctor]

> While I have no interest in recovering money through a class action lawsuit

I note that there are zero words devoted to what fraction of the money will leave the coffers of the lawyers and actually make it to the customers.

[wilfra]

That's regulated by law.

[grey-area]

Like Rapleaf, we have spent an enormous amount of effort optimizing and searching for the causes of latency, and overpay for dynos to reduce but not eliminate the chance of latency issues. Heroku has always told us it's our fault.

You may well find that running your own ops means you run into exactly the same sort of issues - most companies see multiple major problems with their infrastructure as they scale. Heroku certainly haven't delivered for everyone, and it seems their promises of painless scaling are just not being met when it comes to larger customers, but this stuff is hard, and moving off heroku won't get rid of these problems for you, but it will make them your problems and perhaps give you more of a chance to fix them.

It would be really interesting (for heroku customers and for everyone else) to see a write up of your transition when you do move - it may not be as painful to do so as you anticipate.

Kudos on not recommending a lawsuit, which I can't see helping anyone but lawyers at this point.

[talklittle]

> Rapleaf

You mean Rap Genius?