Second that. I moved my app from Elastic Beanstalk recently (just before the price hike) to Hatchbox.
In the end, I was troubleshooting my Rails app on Elastic Beanstalk so much I could have probably just set it up myself on a VPS. Solutions for issues were sometimes hard to find. I'm not sure if the documentation is up-to-date. You can't get an answer from AWS (unless you pay a lot which is not worth it for side-projects).
Hatchbox was a little bit more difficult than Heroku but Chris was very helpful. You can email him anytime and expect an answer (even on Sundays). Documentation could/should be improved as well. There are still some hiccups but can be resolved (and I expect it to get better over time).
However, they lack a basic support ticketing system on the lower-tier price plan. It is also not obvious if/how you can deploy a pre-existing app from an arbitrary Git repo, as their service is geared to use Divio project scaffolding (including their own SSO).
While the Divio service seemed appealing at first, the above issues are a bit disappointing (and it has been nearly 24 hours with no response, since I contacted their support.) Overall, Divio seems to leave a bit lacking when compared with other hosting options like WebFaction (a shared hosting provider with good Python support.)
Addendum: I received a response from Divio while typing the above review. The respondent said they would put me in contact with a technical support person.
Addendum: Divio have been really helpful in explaining their upcoming feature to allow Git remotes, which will allow projects to be managed via any Git service.
I'm using Passenger for serving up apps, which supports Python, Node, and Ruby. Got some basic Node support right now, but have plans to add Python soon. I haven't used Python deeply for quite a few years, so I've got a lot to catch up on to figure out what'd be best for that.
Shoot me an email and we should chat about Python support! chris @ gorails com
Another alternative to deploy a Rails and PostgreSQL app is on NodeChef where developers have three simple options to choose from to deploy apps. https://www.nodechef.com/
Yeah, that's not even bad... What AWS doesn't tell you, is elastic beanstalk creates new security groups and what not. So if (like me) you manage 12 Apps and you try to destroy one environment, the environment won't delete.
Apparently, they all try to create the same named security group (as well as other components). This happens even if you change the security groups after launch. So it'll error out and be unable to delete the rest of the components. Leaving a "ghost" environment.
That's just one of my many, many frustrations with it. I'm considering moving back to digitial ocean (where I was). However, the billing breakdown is nice to share with clients
I would recommend separation of those applications into respective sub-accounts. The hierarchy can be defined in AWS Organizations and you avoid resource overlapping of any kind.
All these applications use the same backend and what not. This makes it easier to share access / permissions vis security groups and IAM role. Its actually separated quite well, just rediculous that if I try to destroy an environment I can't.
My understanding is that EB is a packaging together of lower-level AWS components (like auto-scaling groups) that you can use individually and patch together yourself if you wish. Maybe that could be a route to look into?
It is, I've gone through before and done that, took me a couple hours. But either way, this seems like it should be obvious to the AWS maintainers and should be fixed.
New environments are given a new, uniquely named security group (SG) by the service. Additional SGs can be supplied to allow access to the environment. There is a situation you can get into if you supply an SG auto-created by another environment which might be what is happening here? The documentation has a note that calls out how to avoid this dependency issue [1]. If that is not what is happening here, I am happy to help but might need more information about your environments.
I'd also ponder the implications of storing your RDS password in an environment variable. There's no reason to potentially open up this information unencrypted to other applications.
You're a brave person.
As you say, Heroku has spoiled me and Elastic Beanstalk is a pile of trash. I'm usually an AWS evangelist, but I run as far and as fast as possible from EB. Configuring it for anything other than the most basic of use cases is a massive headache.
Even AWS itself offers much better PaaS-style solutions like OpsWorks.
Echoing this. Heroku is still such a treat, super reliable, and communicates when issues arise. I've even gotten support via reddit from them. I do like seeing things like this though in the event Heroku goes away. Being able to spin up a clone quickly with another service is good to have in the back pocket.
I've been an AWS evangelist because they are Not-Microsoft. But, after having to use Azure for the past 4 years where I'm at, I have to say that Azure's REAL portal (and naming scheme) is a LOT easier to navigate than Amazon's. I hate Microsoft as much as the next guy who ran Linux on the desktop for 19 years, but they've leapt past Amazon on this piece. (I'm not even saying it's GOOD, just a lot better.)
My thoughts and sentiment completely. It is just not worth my time and Heroku has proven to be reliable platform over the years. It is simple, interface is familiar and easy to onboard new people to.
Does anyone know how Heroku and Elastic Beanstalk compare with App Engine Flexible (ie, the one that runs an arbitrary docker container)? I can't believe how long ago Heroku nailed such a simple PaaS platform.
I started using Dokku in production a few years ago. It tries to provide an open source alternative to Heroku and ia compatible with their buildpacks. Deployments work via git pushes. And there is a large number of plugins available for different services like Redis, a plethora of databases, letsencrypt e.t.c.
I just finished installing my spring boot app on elastic beanstalk, I think features introduced in EB are not that important, I've mainly setup all by myself, except creating EC2 instance.
I scratched by head for 3 days to install a free certification on nginx ...
36 comments
[ 2.6 ms ] story [ 91.4 ms ] threadIt's really simple with a growing featureset.
[0] https://www.hatchbox.io/
I struggled with EB a few months ago and ended up breezing through the process with DigitalOcean.
https://www.divio.com/
However, they lack a basic support ticketing system on the lower-tier price plan. It is also not obvious if/how you can deploy a pre-existing app from an arbitrary Git repo, as their service is geared to use Divio project scaffolding (including their own SSO).
While the Divio service seemed appealing at first, the above issues are a bit disappointing (and it has been nearly 24 hours with no response, since I contacted their support.) Overall, Divio seems to leave a bit lacking when compared with other hosting options like WebFaction (a shared hosting provider with good Python support.)
https://webfaction.com
Shoot me an email and we should chat about Python support! chris @ gorails com
Apparently, they all try to create the same named security group (as well as other components). This happens even if you change the security groups after launch. So it'll error out and be unable to delete the rest of the components. Leaving a "ghost" environment.
That's just one of my many, many frustrations with it. I'm considering moving back to digitial ocean (where I was). However, the billing breakdown is nice to share with clients
[1] - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using...
Would recommend not to do that. Create Security Group, add EB to it and allow that only.
IMO, stick with Heroku if you want a PaaS.
Nice n easy. Well done :)
You can host it on any compatible server.