
Python and Django on Heroku - craigkerstiens
http://blog.heroku.com/archives/2011/9/28/python_and_django/
======
alanh
Python 2.7? They’re _years_ ahead of Google App Engine!

 _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...](http://code.google.com/p/googleappengine/issues/detail?id=757)

~~~
alexkon
App Engine announced they will release a Python 2.7 runtime in several months.
It's currently in their trusted tester program.

~~~
ccorda
More details on 2.7 and GAE:
<https://sites.google.com/site/gaepython27testing/>

------
Pewpewarrows
As much as I've come to enjoy and appreciate the various start-ups whose
mantra was "We're Heroku with Python/Django capabilities", it will be
interesting to see which of those survive the next 8-12 months now that Heroku
officially supports that stack.

It'd be a shame to see ep.io and Gondor go the way of the dodo bird, but what
sets them apart now?

~~~
andrewgodwin
Epio cofounder here - we're not worried by this, and we've known it was coming
for ages 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.

~~~
glimcat
"some of which are those low-level-design type of choices where if you go the
other route, a different set of people complain"

This is actually a wonderful scenario. If either party successfully grows the
market, both can benefit.

------
bmelton
I loved Heroku, many moons ago when I was working in Rails. As I've emigrated
away from Rails to Django, I've found dotcloud to be the premiere platform --
I want to qualify this, it is the premiere polyglot platform, but for each
individual environment I've deployed on dotcloud, their experience has been
the best.

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.

~~~
aashay
I still find Dotcloud's pricing violently expensive (and I have a free VIP
plan). YMMV I guess.

~~~
phzbOx
Still:

    
    
       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.

------
zachwill
I've been using Flask on Heroku since the Facebook apps announcement, and set
up a boilerplate template here: <https://github.com/zachwill/flask_heroku>

------
mhoofman
Heroku's cedar stack can now detect apps using:

    
    
      * Ruby
      * Node.js
      * Clojure
      * Python
      * Go ??
      * Scala
      * PHP
      * Java
      * Perl ??
    

Anything missing here? That covers a lot of whats out there.

~~~
willlll
Logo.
[http://blog.heroku.com/archives/2011/4/1/announcing_heroku_f...](http://blog.heroku.com/archives/2011/4/1/announcing_heroku_for_logo/)

------
ma2rten
This is great! Looking at the Django tutorial in the docs [1], I think it's
too bad, though, that they don't provide a build-in, well tuned WSGI Server.
This way, you have to choose your own WSGI server, configure and update it
yourself.

[1]
[http://devcenter.heroku.com/articles/django#using_a_differen...](http://devcenter.heroku.com/articles/django#using_a_different_wsgi_server)

~~~
craigkerstiens
We do not automatically use a wsgi server because we want to offer flexibility
to our users. Additionally we felt that having less magic in what we
automatically do to your application (other than run it) was more of the
Python way.

~~~
elithrar
> "was more of the Python way."

That you tailor each environment to the language/framework around it is a
great touch.

------
ayanb
$ ls

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.

~~~
micrypt
$ epio upload -a appname. epio is epio for Django.

------
sparky
Anyone know if there's a self-contained way to spool up a dyno sporadically to
complete scheduled tasks?

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 :)

~~~
aaronbrethorst
Use a single dyno, and set the caller's HTTP timeout threshold to a high
enough point that it can deal with the delay associated with reallocating your
app.

------
ymir
Some time ago Ask The Pony blog made a detailed tutorial on deploying Django
on Heroku and how to make it perform 8 times faster than usual using some nice
tricks: [http://www.askthepony.com/blog/2011/07/getting-django-on-
her...](http://www.askthepony.com/blog/2011/07/getting-django-on-heroku-
prancing-8-times-faster/)

------
jedc
Interesting... I wonder if this makes Google App Engine more appropriate for
internal apps for Google Apps customers? For quick/easy personal
hacking/development having a Python stack on Heroku seems pretty attractive
now.

~~~
bad_user
Personally I don't like Google App Engine, but I can understand its value --
it has reasonable free quotas (even now, after the pricing scheme changed),
and your app ends up running on Google's infrastructure which is rock solid.

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.

~~~
aashay
"it's like renting instances on EC2"

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?

~~~
bad_user

          dynos != virtual machines
    

Well, yeah, a small instance on EC2 is the equivalent of 20 dynos, maybe more.

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
    

I really do think that sysadmin work and rapid iteration are orthogonal. When
you're starting out, administrating you servers is something that hardly takes
up any time ... but the flexibility is priceless.

    
    
         ... infrastructure pieces such as reverse 
         proxies, caches, etc.
    

Well, Cedar doesn't have Varnish anymore -- and IMHO, setting up Varnish is
just a day's work, which includes configuring it for your own needs.

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.

~~~
Volpe
> you can do the same thing by having .... and a bunch of scripts with which
> you can start new instances in seconds.

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.

------
pxlpshr
Awesome news topped with even more awesomeness that Heroku is continuing to
truck along post-acquisition.

We're now looking into +/-'s of moving from RAX Cloud Servers to Heroku.

------
ricksta
I'm currently developing django app on a ec2 instance. What's the advantage of
heroku over just plain ec2?

~~~
zachwill
Ease of use — especially for prototyping ideas. It's easy to push a git repo
to heroku and have it fire up your site — but if you've already got a fabric
script to do the same thing with EC2, then that might be the better approach
for you.

------
Toddward
This is pretty much what I've been waiting for to finally migrate my project
to Heroku. I know you've been able to _unofficially_ run Python/Django on the
stack for a while now, but a lack official support (even in beta form) was all
that had been keeping me from taking the leap.

------
polemic
Python minimizes magic and maintains backwards-compatibility? LOL.

(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).

~~~
tricolon
Compared to Ruby on Rails, there's less magic going on.

------
_mayo
Does anyone know if the stack will only support WSGI or could I also run a
Tornado instance on the cedar stack? I know when I tried dotcloud several
months ago it only supported WSGI.

------
frisco
You always have to work with the information available at the time, and
personal tolerances for risk, but Heroku has become a case study in selling
too early.

------
NiceOneBrah
Can Haskell be next?

------
john2x
Great news! But why is the example for Flask?

~~~
Nic0
Maybe because it takes less code to write a "hello world" with Flask than with
Django.

~~~
paul-woolcock
Definitely this. A database is a requirement for a Django app, but not for
Flask. I always seem to go back and forth about whether to start a micro-
framework like Flask and use plugins and Python libs to assembly a framework
that has only what I need, or use Django and (possible) include a lot of code
that will never get run.

~~~
Pewpewarrows
It really depends on your vision for the app. If this is a single weekend
project or a toy web site that you'll likely never touch again, or if you do
will only be for minor updates, then I say go for Flask. It'll get in your way
less and let you just launch it sooner.

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.

~~~
fakeempire
I've been running multi file apps since before 0.7. If you read the
documentation or searched mailing lists or looked at example applications you
can see how. Blueprints made it even better.

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>

~~~
Pewpewarrows
I've read through all the documentation, and researched extensively. I still
ran into problems way too often to ever warrant using it over a full framework
for larger projects.

~~~
fakeempire
I'm not trying to get you to use Flask or anything. But I definitely find it
interesting that you have "read through the documentation or researched
extensively" but were unable to find `add_url_rule`.

Either way, I'm glad we have selection and choice. At least we both like
python! Peace

------
overshard
Django has been able to run on Heroku for a while now. This topic keeps coming
up over and over again and it is very old news. There are a lot of major flaws
in running Django on Heroku right now too simply because of how their system
works.

~~~
flarg
Hi, care to list some of the flaws?

