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.

All this literally takes one click with Heroku.

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.