[photonios]

I work for a company that runs multiple major websites pulling in tens of millions of users a month. We run on Heroku. We made that decision when we didn't have a single user. Right now we're a team with 25 engineers.

Every time we need to re-negotiate our contract with Heroku we ask ourselves whether we should move away from Heroku or not. So far, the answer has always been no. Complexity would go up and the time spent on DevOps would go up. Right now, any idiot can do a deployment, or a rollback. Most of the things we need are taken care off for us by Heroku and it doesn't cost us any effort. We use Heroku Postgres for our database and we get point-in-time restore for free, without doing anything. We can upgrade our database or create a new follower in minutes. It just requires a couple of clicks. On top of that, all the monitoring is taking care of by Heroku. It just gives us a nice dashboard.

As for costs, on an negotiated Enterprise contract, it's not that bad. If we'd move to AWS or DO for example, we might save a little bit, but the extra engineering resources would quickly make those savings useless. Even if it's a bit more expensive to run on Heroku, it's still cheaper than cobbling together all of those features on another platform.

We've made a couple of small engineering investments to get features that Heroku doesn't offer. For example, we built a simple auto-scaler for dyno's that consume from RabbitMQ. This helps a bit to keep our costs down and respond to massive spikes quickly.

We run our web servers, database, caching, data pipeline etc on Heroku. However, we are not _that_ dependent on Heroku. We use Docker for deployments, so we can easily reproduce what's happening and it reduces our vendor lock-in.

I hope this explains a little why some people might choose to stick to Heroku. It works for us, it might not work for you or anyone else.

[scarface74]

We've made a couple of small engineering investments to get features that Heroku doesn't offer. For example, we built a simple auto-scaler for dyno's that consume from RabbitMQ. This helps a bit to keep our costs down and respond to massive spikes quickly. We run our web servers, database, caching, data pipeline etc on Heroku. However, we are not _that_ dependent on Heroku. We use Docker for deployments, so we can easily reproduce what's happening and it reduces our vendor lock-in.

I missed this part. If you are okay with using managed services, why are you doing so much “undifferentiated heavy lifting”? Setting up autoscaling based on queues, managed RabbitMQ based messages (Amazon MQ), and without knowing what your data pipeline consists of, probably that too could all be done with managed services.

[photonios]

Don't imagine anything fancy here. This is roughly 100 lines of Python code that scales based on some tresholds. It took a day or two to develop, test and deploy.

However, we recently found a managed service to do this for us so we'll be switching to that as soon as we can.

If we'd have to spend more engineering resources on our infrastructure than the occasional simple tool, then we'd consider switching away from Heroku. The benefits still outweigh the potential engineering effort of not running on Heroku.

[GordonS]

> We use Heroku Postgres for our database and we get point-in-time restore for free, without doing anything

For the record, you get this with Azure too. Not sure about AWS and GCP, but I would have assumed the same.

[photonios]

It isn't an individual feature that makes us stay with Heroku. It's all of them in a single platform with a unified interface that is very easy to use that makes it very attractive.