Since we're a small team, there is a lot we like about Heroku but would prefer to have one less moving part especially since Heroku has had reliability issues.
I'd love to know if you know of any deal breakers moving from Heroku to Beanstalk? Thank you!
We ended up switching to https://render.com and I got everything I needed spun up in 3 days. You don’t have the same access to underlying resources in AWS but you get everything EB is supposed to do but faster and more user-friendly. It is much more actively maintained than Heroku’s current zombie state.
This was done because the lack of Infra/DevOps specialisation in the company at the time and Beanstalk was the most similar service to Heroku. Biggest change was dockerising.
Advantage is EB has a somewhat friendly UI so you can do everything point and click if that's what you're used to with Heroku.
Disadvantages are the docker support is an afterthought (which is fair as EB predates docker). Trying to manage it through terraform is quite clunky. Release rollouts aren't the quickest (but depends on what you're used to). It works, is reliable, but it's not the future and hard to attract talent to work with it (doesn't make hiring any easier). AWS is maintaining and supporting it but it's not getting any new feature development.
Now we have grown and have Infra specialists we're moving to ECS fargate.
Using EB wasn't the path I'd have chosen for the company to take, but it was probably the best one given our company requirements/skills at the time. I don't regret it, but happy we have the skills to move off it. We were very glad to have been off Heroku when the recent security troubles became known. We moved off because of Heroku's constant instability and our increasing lack of confidence in them as a vendor. Which we were sad about as we loved Heroku.
Your mileage may vary.
I'm a big fan of beanstalk. It is tricky to work out exactly how to deploy to it when it's managed by Terraform but if you can put up with that then you get a well thought out app hosting + deploy with an escape hatch of being able to interact with the underlying machine using the hooks system they have.
It's and older service but still valuable for medium sized sites.
Pros (in addition to managing much of the complexity of a highly available application):
- Works well with docker-compose (multi-container environment)
- Easy to setup multiple environments (e.g. staging, production etc)
- EB extensions: these are optional scripts that run on newly created instances before they come online. This might include adding CRON jobs, attaching an EFS, or flagging an instances as the "leader" to ensure only one instance runs DB migrations.
Cons:
- It can be difficult finding relevant errors in logs, as several logs groups for different services are output. Be sure to stream logs to Cloudwatch (this is easily done in the config), otherwise you won't be able to extract logs from a buggy instance that has since been terminated.
- Depending on your configuration, deployments can be slow. If you've configured rolling deployments and have 5 servers running, you will have to wait for 5 newly created instances to come online, each in turn. The upside is that rolling deployments give you a chance to catch newly deployed bugs and rollback the deployment before it affects all servers. You could alternatively configure an "all at once" deployment strategy.
- If your instance health checks are too stringent, it can become frustrating to get your application back in the healthy state. Consider a scenario where your health check page (e.g. /health) pings a non-essential cache database. If your cache database goes offline, EB will treat your application as unhealthy. I recommend keeping the health check page very simple, and setting up separate alarms for other services.
To add to/counteract some points seen in another comment:
Cloudposse has modules that make beanstalk quite manageable with Terraform: https://github.com/cloudposse/terraform-aws-elastic-beanstal...
"Hard to attract talent": I'm skeptical this is an issue in most cases. After all, EB exists so that you don't have to think too much about the infra. For simple use cases, a general understanding of the infra components (not EB-specific) will go a long way. However I can understand talent/developer time could be an issue you're doing something really fancy with EB, such as making heavy use of EB extensions.
"Not the future": This sounds like another way of saying "it's not trendy". Whilst I agree, this point doesn't weigh heavily for me, as I'd try to focus on doing what's right for the application and the team.
