> in the end Heroku shouldn't be used for anything serious.

This is a provably false statement. There are thousands of companies running very serious things on Heroku handling load that would exceed the needs of the majority of audience here. All with near zero effort from a developer perspective.

They've also always been transparent about downtime, retrospectively creating/amending cases if required. The only multi-hour outages in the past 60 days afaict affected the ability to launch new processes & use the API but didn't actually cause downtime for apps that were already running (https://status.heroku.com/). That said, uptime for the past 60 days for the US region is > 4 nines, and EU is 5 nines. Better many ops teams achieve.

I was using rolling deploys (and preboot before that) on Heroku without issue back in 2013. I can't speak to the issues you had, but there were (is) a number of documented caveats to be aware of when using it.

You get all of that simply by doing `heroku create; git push heroku master`. Plus a broad range of automatically provisioned, configured, and fully-managed services you can use with a single click.

There's plenty of valid reasons to not use Heroku, claiming one if them is it's unsuitable for anything serious is disingenuous.

> All with near zero effort from a developer perspective

For a very small subset of developers.

The last time I was tethered to a Heroku installation, I spend 60% of my time coding, and 40% of my time working around Heroku's shortcomings.

It doesn't matter how many times you reply to people on HN stating that their position is "provably false," that doesn't make it true.

I've been using Heroku for many serious projects since its inception. It's been nearly a zero effort, especially compared to doing it all myself. This alone is enough to prove the statement false (counterexample).

A little nitpicky here, but the original claim is "shouldn't be used for anything serious" which is an entirely subjective statement. I don't know if proving something subjective is false is really possible.

That's the fault of the original claimer. They shouldn't be making subjective claims and trying to pass it off as objective.

Just for the other perspective...

1.) I’ve been running production apps on Heroku for 7 years and we’ve had about 3-4 hours of downtime total in that time with the exception of the major AWS outage a few years ago that was a full day. Maybe US-East is more robust than other regions?

2. It’s true. Request queuing specifically can be a killer.

3.) Heroku has had rolling deployments for a long time. 5 or 6 years at least. It was a beta feature for a lon time, but has worked perfectly since the day they opened the beta for my apps.

4.) sure, but there are a ton of build packs out there and even if they aren’t a little scripting makes everything pretty straightforward. Especially compared to scripting everything yourself.

5.) definitely true. But, if you have a team less experience or less interested in devops it can be a great platform to trade salary for ease.

I think we're agreeing more than disagreeing here.

But I think you're not properly valuing yourself in this scenario. People that can utilize AWS and navigate through all the services, use CloudFormation, etc. are in a high demand and at some level in the cost analysis you need to factor that in.

In terms of my time, it has been very valuable.

I had to spend quite some time working around Heroku's limitations. We have had 100% uptime (based on external monitoring) since we moved to Elastic Beanstalk.

Health check based rolling deploys are awesome. Caught production bugs 3-4 times.

I agree that it was easier for me to do, because I have extensive DevOps experience. However if someone is getting to anything more than a hobby project, consider investing in someone to build a basic CloudFormation script for ElasticBeanstalk. I will open source ours in a couple of months (things really hectic right now).

My company hosts a whole bunch of critical software on Heroku. It generally works fantastic. We do use relatively less "batteries infra for some of our services, and we'll probably shift further in that direction, but I think you're underselling just how effective Heroku is. It goes a long way towards letting your team worry more about the business domain and less about the infrastructure concerns that aren't at all unique.

My last job we were 100% hosted on Heroku and coming from managing hundreds of EC2 instances and databases via autoscaling, CF, Puppet and home-grown scripts, it was a dream to use Heroku. We simply didn't need any operations staff to manage infrastructure, maybe a few hours a week for 1 developer out of 11 to adjust or verify a few things.

Need a bigger database? Just a few Heroku CLI commands. Bigger web servers? 2 clicks. Want a test database to run queries against? 1 Heroku CLI command. Want to test a branch of your code against the staging database? Automatically done via GitHub PRs, with DNS setup too.

We had 0 downtime in a year due to actual Heroku issues, developers could push code easily (git push), databases were backed up automatically, servers auto-scaled, etc.

I was genuinely amazed at how well it all worked. The amount of operations work was easily 10x less than if we had to run our own infrastructure on AWS due to not just the hosting, but the tooling. Deployment, rollbacks, slave database setup, configuration management, access control, log aggregation, 3rd party integrations and more.

Heroku does have some drawbacks, request queuing is one of them, mostly due to lack of clear docs and information. Even with its flaws it still saves a massive amount of time and money. For nearly all startups to medium sized companies I'd highly recommend using Heroku.