[ron22]

They tell you in the blog post.

"We continue to use Heroku as our main web platform. Despite its premium cost over AWS, Azure, and Google Cloud, Heroku’s built-in deployment and configuration tools allow our team to move faster, more confidently, and more reliably.

As we’ve detailed previously, the alternatives would undoubtably be cheaper on paper. But in reality, the increased simplicity and freedom offered by Heroku for a small, product-focused team is a major cost savings advantage."

[scarface74]

I’m far from a Devops guy. But deploying to AWS using their native tools are Azure using Microsoft’s tools is dead simple.

[paulddraper]

Yeah something doesn't add up.

I'll believe Heroku is easier, but can it be that much easier? For people spending piles of cash on their webscale?

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

[sudhirj]

I do both at work, small sites on Heroku and big / compliance required ones on AWS, and the Heroku ones don’t need a devops team, while the AWS deployments do. Given the cost of building the devops teams and the time they spend, it is a big factor. Prefer to default to a Heroku unless there’s a clear cost benefit analysis that includes human and opportunity costs.

[scarface74]

if it is a simple deployment that you could do with Heroku, it would be just as simple with Elastic Beanstalk. You just give it your zipped artifacts.

If later on you need to do something more complex you have all kinds of extension points.

If you want something cleaner and just to use a Github -> CodeBuild -> Code Commit/Lambda deployment and have something closer to traditional deployment pipeline, there are the CodeStar templates.

We are a small company without a Devops team. The leads all know how to setup a from scratch system on AWS.

[sudhirj]

I’ve done both, and many projects start on Heroku then move to AWS once they hit scale. And every single time I keep cursing at how many hidden man-hours are spent on AWS maintenance. If you’ve tracked the time spent on AWS that wouldn’t be spent on Heroku, and plotted that against the cost of your leads’ and devops team’s time, and your opportunity costs, and you still feel it’s worth it, by all means go straight to AWS.

The point is that costs on Heroku and AWS are two intersecting lines with different slopes and y-axis starting points. The dollar cost is the basic dimension, but once you add team hourly rate and opportunity cost you’ll see that Heroku is cheaper than AWS until you hit X000 req/sec or users. That number is varies from team to team, but it’s higher than you think.

[scarface74]

I’m mostly a developer but I am also the person they trot out as the representative of our (nonexistent) infrastructure team to clients and lead most of the “cloud native” initiatives.

We do a lot more with AWS’s managed services that would go beyond what Heroku could do.

That being said, if we were just a simple database+website. How would AWS maintenance be any more than going through the VPC creation wizard one time and using Elastic Beanstalk for deployments? I’m very much an advocate of managed services so it’s not that I’m anti Heroku - that would be hypocritical if I’m saying using EB - But how is it easier?

With Elastic Beanstalk if later on if you do need to add complexity, you easily can through startup scripts and .ebextensions (cloud formation).