Python and Django on Heroku
blog.heroku.com
blog.heroku.com
Addendum: The previous statement is slightly tongue-in-cheek, but: (1) GAE is running a version of Python (2.5) so old, that it’s hard to get fully patched binaries of it anymore (depending on your platform); and (2) By “years ahead,” I don’t mean it will take Google years to catch up, but merely that their Python version is years old. Puzzling, given that Guido works for Google and has for years.
Second Addendum: Linked: an issue opened in 2008 pleading Google to add 2.6 support. Three whole years ago. (Ironically, perhaps, the issue was closed as a duplicate of a 2010 issue asking for 2.7 support.) http://code.google.com/p/googleappengine/issues/detail?id=75...
It'd be a shame to see ep.io and Gondor go the way of the dodo bird, but what sets them apart now?
The hosting market is plenty big enough for more than one player - we're expanding to multiple languages, much like Heroku expanded from Ruby, which provides an ample feeding ground of old-style hosts to slowly steal business from - and there's also still a lot of room for innovation.
Heroku, as much as I like their product - and I do, which is why we started this a year ago - still has its flaws and idiosyncracies, some of which are those low-level-design type of choices where if you go the other route, a different set of people complain. You can't be all things to all people, and I don't think anyone will end up being that.
This is actually a wonderful scenario. If either party successfully grows the market, both can benefit.
As a very happy user of some of Python PaaS services [1], there are a few reasons why I don't see myself switching to Heroku:
* These services are written by our community, for our community. The principles at most of these companies are people I've known for years. I've reviewed their code; they've reviewed mine. We'd argued, commiserated, and bought each other whiskey. They've helped shape the Python/WSGI/Django ecosystems. Their tools embody the best practices from our communities because they were there when those practices were debated and determined.
This is by no means a slight on Heroku's staff: I've met people from their team, as well, and they're wicked smart, very motivated, and highly focused on delivering an awesome product. Which it is! But as a company, Heroku is going to have to do some work to get to the same level of trust as the companies that have grown organically out of our community.
* Deploying a Python stack on Heroku is something of a small pain: there are few defaults, so you're left to do most of it by hand.
Take, for example, the bits from the Heroku/Django tutorial about configuring Celery. Not a lot of work, to be sure, but it is some work, and the result won't perform well at all (it uses a database for message transport instead of something that'll perform better). On mot Python-specific PaaS offerings, a single line in a config file (or checkbox in a web UI) gets you a fully-configured, optimized, ready-to-roll Celery setup.
I'm pretty damn good at deploying Python setups. I'm not going to use a PaaS offering unless it provides similar features to a hand-rolled setup for less work/money.
* On Heroku, I'm a small fish in a large pond. I'm the weird customer doing Python, but the bulk of their cash (presumably) comes in from their Ruby customers. Deploying Python on Heroku feels rough around the edges. A trivial example is the broken links in the Python documentation: it's no big deal, and easily fixed, but the many similar rough edges send the message that Python support is a hobby project, a sideline to the main business.
This will probably be fixed with time, I think, but again: it's going to be quite a while until I feel I'll get the same level of support on Heroku as on a tool that comes out of the Python community.
* Finally, Heroku really expensive compared to most of the Python-specific offerings. Maybe a typical Django site features more "pieces" than a typical Ruby one (???) -- a standard "smallish" site of mine will consist of Django, a task queue (Celery), a search server (Solr), a non-relational DB (Redis), and a relational database (PostgreSQL).
On Heroku, this will easily run me $100/mo. By comparison, I'm paying between $15/mo and $50/mo for sites of similar size on some of Heroku's competitors.
So all this to say: I welcome Heroku to this space; more competition is awesome. It'll really make life better for every Python web dev. But it's going to take some serious work to convince me to switch.
[1] I'm really sorry to be obtuse here, but I'm trying to be careful not to write anything that might be construed as an endorsement. As a Django core dev I don't feel comfortable playing favorites (just look at the drama that ensued when GvR had the temerity to say that he liked Django...)
Of all the points you raise, this is probably the least relevant in business terms. PaaS is about opening up platforms to all comers; one's standing in relatively insular language communities doesn't say much about one's marketability outside those communities.
He wasn't listing business reasons per se - He was listing reasons why he isn't considering Heroku. And that's a very valid reason - work with people you know and trust, rather than be a second class citizen at a primary ruby PaaS.
I haven't used dotcloud's Ruby/Rails stack, so I can't compare that, but Heroku is definitely fighting a hard battle if they're going to swing me from dotcloud, but it's always good to have competition, and if anybody is going to bring their A-game, it will be Heroku, who were sort of pioneers in the space.
The Heroku Python Free platform might be better in some instances than dotcloud's, and I'll definitely investigate that, but for anything I can think of using, dotcloud has been amazing for me.
Q. Are there discounts for education and non profit users?
A. Yes. DotCloud provides special free and low cost plans for open source
developers, educational users and other qualifying non-profits. To inquire
about adding free or low cost capacity to your DotCloud account, please
contact support.I never really felt that way with Ruby, though I still like and occasionally use it. I'm actually working on a Ruby project right now, mostly due to circumstance (hosting was donated for the project, and it supports RoR but not Django or Flask).
The other main thing, at the time, was that there were a LOT of very valid options with Python. I could crank out small projects very quickly in Flask or Tornado, work on larger, more custom solutions with Django, or if it was pretty cookie-cutter, fall back to Zope. At the time, AppEngine and web2py were catching on as well. For the most part, a module written for one of those ports really easily to any of the others.
Bottom line though, learning one has really made me a better programmer and taught me to appreciate the WHY behind some of the decisions a given framework has made. If you only know one, I encourage you to look at the other side of things, even if just for perspective.
* Ruby
* Node.js
* Clojure
* Python
* Go ??
* Scala
* PHP
* Java
* Perl ??
[1] http://devcenter.heroku.com/articles/django#using_a_differen...
That you tailor each environment to the language/framework around it is a great touch.
app.py,requirements.txt,Procfile
$ git init
$ git add .
$ git commit -m "Init"
$ heroku create --stack cedar
$ git push heroku master
With that Heroku becomes the Heroku for Django.
I have a webapp now that's hosted on a VPS and uses Celery to schedule tasks. The tasks themselves only take about a second, the dyno needs to stay active for ~5 minutes to service a bunch of HTTP requests from another webservice that will result from the task, and then shut down until the next task. There are O(100) tasks spaced throughout the day, and they each must be completed at a very specific time. My aggregate dyno-hour requirements are very low, but I haven't figured out a way for a dyno to turn itself on and off for scheduled tasks this way. Admittedly, my use case is a bit niche, but a solution sure would be useful. Whiteboxing my webapp in such a way that it could be deployed on Heroku would be great, but keeping a dyno running all month to run the Celery polling process, when 'actual' computing is happening << 1 percent of the time, is a bit steep :)
However, I never understood why people like Heroku ... it's like renting instances on EC2, only 10 times more expensive.
Of course, people then start enumerating a whole bunch of stuff that they don't have to worry about when using Heroku. However, when starting out, configuring a server is just like configuring your localhost development environment. You just have to start with something that works, then gradually keep learning.
Heroku doesn't provide anything to me other than an unreasonable free quota that's basically useless for serving anything other than static content (poorly) ... even GitHub does a better job with their static pages option, since GitHub's servers don't go sleeping when unused.
False. I'd suggest you take a look at their architecture overview. It's not like renting instances on EC2 at all because dynos != virtual machines. http://www.heroku.com/how
"Of course, people then start enumerating a whole bunch of stuff that they don't have to worry about when using Heroku. However, when starting out, configuring a server is just like configuring your localhost development environment. You just have to start with something that works, then gradually keep learning."
This may be fine for some, but for those that _don't_ want to worry about sysadmin work and want to focus on rapid iteration, Heroku makes more sense. Besides, it's not the initial configuration that is the most painful, it's the maintenance and cost associated with managing your own virtual instances, and infrastructure pieces such as reverse proxies, caches, etc.
"since GitHub's servers don't go sleeping when unused."
I'm not even sure what this means. Can you elaborate?
The advantage is you get to run arbitrary code rather than, say, serve static pages, though.
dynos != virtual machines
What you do get with dynos is scaling out when you need it, however you can do the same thing by having a prepared AMI, a load-balancer and a bunch of scripts with which you can start new instances in seconds.
focus on rapid iteration
... infrastructure pieces such as reverse
proxies, caches, etc.
Yes, Heroku takes that away by (1) giving you a useless Varnish configuration OR (2) eliminating Varnish altogether, as they couldn't figure out a common denominator.
Also, I know that "reverse proxies" and "caches" sound bad ass, but it's really a solved problem.
Of course, infrastructure can get very hairy further down the road, but that's what I've been saying -- when starting out, you just need Passenger or mod_wsgi, as in one "sudo aptitude install" or "gem install" away. It took me a day's work to configure an EC2 instance, including a deployment workflow with Capistrano (for the first time ever). That server is still running just fine, with no further maintenance.
And if small deployments is not Heroku's strength, than what is? If you've got a successful app that needs special infrastructure care and you can't afford a good developer/sysadmin to take care of it, then you're doing it wrong.
Right, so if you already have everything you need, you don't need to buy it. This argument is similar to "I don't need water when I'm not thirsty". Hardly compelling.
> administrating you servers is something that hardly takes up any time
Sure if your servers never get any traffic, or you never scale.
> It took me a day's work to configure an EC2 instance, including a deployment workflow with Capistrano (for the first time ever). That server is still running just fine, with no further maintenance.
Right, it took me less than a minute to do that with heroku, and with less dependencies (on capistrano). When I decide my app needs an extension written in node, that is another minute on deployment for me, and another day for you. I'd gladly compete on those terms :)
> And if small deployments is not Heroku's strength, than what is? If you've got a successful app that needs special infrastructure care and you can't afford a good developer/sysadmin to take care of it, then you're doing it wrong.
This is just your highly opinionated view of things. Who ever said anything about 'special infrastructure'... Heroku deal in commodity infrastructure (that's the point). You also never successfully made the point that small deployments are not their strength.
But I'm with you that I find it a bit too costly as I know (and actually like) configuring my stuff.
We're now looking into +/-'s of moving from RAX Cloud Servers to Heroku.
(I'm a programmer who recent dived into python - it's awesome and it's easily my favourite language to use now - but those statements are fallacies).
For anything larger than that though, Flask has always turned into a giant headache for me. As soon as I ever start to try and organize the project better because it's become too large for a single file, all shit hits the fan. Supposedly this has gotten slightly better with 0.7's Blueprints, but I've yet to see it. Circular imports and Flask's global variables bite me in the ass on a regular basis. I also have come to really miss tons of features that Django offered, like URLconfs. The decorator technique works great when you can count the number of URLs that your app has on two hands. Beyond that, ack/grepping my project to find where anything lives isn't my idea of maintainable. With Django I can very cleanly trace through the whole request/response cycle in my head and by looking at the code paths.
2. In the documentation you will find that you can list out routes just like django. http://flask.pocoo.org/docs/api/#flask.Flask.add_url_rule
Either way, I'm glad we have selection and choice. At least we both like python! Peace
[edit] does adding Flask in requirements.txt automatically handle the easy_install portion?