While I agree that a script can't match what Heroku does, in the end Heroku shouldn't be used for anything serious.

I love Heroku for it's simplicity. They give you very few levers, making it less likely for you to screw up.

When we had a production add we faced following issues with Heroku:

1. Frequent downtimes. Heroku would have a 3-4 hour downtime every 2 months. In some cases, site would be down. In most cases you couldn't deploy and add machines.

2. There is an end user impact in terms of performance. After moving to Elastic Beanstalk, we had a 20% decrease in response time and 5% increase in revenue.

3. In the end Heroku is very simplistic. They don't have features like rolling deployment or Blue-green deployment. They had some beta version of rolling deployment, however that was buggy and caused version issues with deployment. With Elastic Beanstalk we have a health check based rolling deploy, which has caught production issues many times.

4. To do custom things, you need to deal with buildpacks etc, which is not very convenient.

5. Thought it wasn't an issue for us, Heroku can be expensive. Our server costs went down 80% while giving better performance.

So, in summary - Heroku is great to get you started quickly. However if you are doing anything serious but do not want to get deep into DevOps, consider something like Elastic Beanstalk.

Eventually we managed our environments using CloudFormation. That allows us to create repeatable Elastic Beanstalk instances. Once we got the CloudFormation template right, it was easier to maintain Elastic Beanstalk vs Heroku.

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

OTOH, the Heroku people aren't personally managing each instance you create; their work is writing the automation code that turns AWS VMs into these more manageable, higher-level pods.

Maybe Dokku and Flynn aren't there yet, but conceptually, is there a real difference between the two? I don't see it.

It's that whole "as a Service" part people tend to forget when making overly generous analogies.