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.
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.
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.
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.
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.
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.
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.
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).
To get Heroku gives you, you'd need to set up EB, RDS (with performance insights), CloudWatch (for logs and metrics), Code Pipeline (don't remember if EB supports GitHub pushes). If you use the heroku run command, you'll need to set up a jump box with SSH keys properly configured inside your VPC with DB access.
Even though it’s not considered best practice to tie your RDS with your EB stack, part of the wizard for EB is setting up a database and it will create your RDS cluster and the security groups for you. It also automatically sets up your CloudWatch logs. EB can use Github.
Again, I’m far from a dev ops expert, but I cringe at how much EB (and Heroku) does that’s magic and I would much rather use CodeStar with the templates that create a standard CodeBuild/Code Deploy/CodePipeline/CloudFormation set up, but I am comparing like for like.
I’ve never deployed anything to Azure but I have used VSTS (aka Azure Devops) with various combinations of hosted builds, on site builds with agents on the build servers and deployment servers and that’s even easier than AWS’s offerings. Even if the GUI setup would make a real Devops person cringe.
Yes I realize Heroku for all intents and purposes is just another managed service that sits on top of AWS and that you can even buy Heroku services from AWS Marketplace for consolidated billing (https://aws.amazon.com/marketplace/seller-profile?id=0112b5d...)
I’m also not arguing not to use Heroku just because it cost more. We always choose a managed service over having to manage things ourself even going as far as preferring Fargate even though regular EC2 based ECS would be cheaper.
But, I haven’t seen anything that Heroku gives you that couldn’t be duplicated with EB or if you need a more traditional approach a CodeStar generated template.
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.