31–40 of 75 posts
Earlier quoted context omitted.
Maybe because it takes less code to write a "hello world" with Flask than with Django.
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.
Earlier quoted context omitted.
"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…
At Heroku, free applications get idled out when no request comes in for a while. As a result, when the first request comes in after some time, it can take a few seconds to find a piece of iron to run the process on, run it, and hook up all the tubes. The advantage is you get to run arbitrary code rather than, say, serve static pages, though.
Earlier quoted context omitted.
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…
"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…
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.
Earlier quoted context omitted.
At Heroku, free applications get idled out when no request comes in for a while. As a result, when the first request comes in after some time, it can take a few seconds to find a piece of iron to run the process on, run it, and hook up all the tubes. The advantage is you get to run arbitrary code rather than, say, serve static pages, though.
I'm sure someone will correct me if I'm wrong, but I'm pretty sure that's only true if you're on the free level (i.e. only running 1 dyno). Otherwise, your process is always active.
Great news! But why is the example for Flask?
found that interesting as well, given that the release is around python+django, but it makes sense for the sake of quickly doing a demo with minimal requirements. [edit] does adding Flask in requirements.txt automatically handle the easy_install portion?
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.
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?
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...
I'm currently developing django app on a ec2 instance. What's the advantage of heroku over just plain ec2?