Hacker News Reader

Comment by passiveincome | Hacker News Reader

That's the disconnect for me. There have to be prebuilt Amazon AMIs with push to deploy functionality for various stack flavors. I guess the simplicity and allure of Heroku's git integration makes it easy for developers to forego research on those. It still seems one hell of a price to pay especially when coupled with vendor lock-in (Disclaimer: I don't know if Heroku PaaS locks you in as much as say, GAE)

View on HN

Disclaimer: I don't know if Heroku PaaS locks you in as much as say, GAE

In my (limited) experience: not by a long shot. Heroku setups may seem locked in, but GAE is obscene. No outgoing HTTP requests, no normal DB, basically everything is GAE specific. Heroku is not the most generic thing out there, but, by God, it's still miles better than GAE.

The key is that Heroku is trying to support all major web app frameworks, whereas GAE only supports the GAE framework.

The tradeoff is super interesting: using their framework allows them to hella optimize the instance for you, but you're pretty darn stuck with it :/

No outgoing HTTP requests? GAE has URL Fetch API from first day.

Also, GAE can now run docker and also connect to MySQL running on Google Cloud infrastructure, which is a separate offering.

Sorry for not being explicit. My point was: you need to use a special API to do outgoing HTTP requests. This leads to vendor lock-in. In Heroku, you just do it.

No you don't. You still use your language's standard library. But GAE uses their own version behind the scenes. You code still uses urllib if on Python and net/http if using Go.

So in GAE too, you just do it.

I could re-deploy a heroku app on my typical stack (ruby, rails, postgres) to digital ocean or similar in a couple of hours.

Most of that would just be setting up the new one and migrating the data across.

You don't have to significantly alter apps (in that stack) to be heroku-compatible.

Reply on news.ycombinator.com