Cloudhosting (or Platform-as-a-service, PaaS) I think is a mixture of the two, I think.  The idea itself is very good: your code runs on our servers, and you pay us to manage the servers.  Web sites and web apps have worked this way for awhile: hosting companies like Dreamhost and Slicehost give you access to the machine your code runs upon, but they manage the infrastructure around that machine.  They take care of networking and maintenance.  This model worked really well for a long time.

Amazon came out with their Elastic-Cloud service (EC2) and it shifted things.  Now you could manage many machines very quickly with very little effort.  Amazon got the defaults right.  You don't need to care how the firewall is set up as long as it works.  That's what you pay Amazon for.  They took the hosting model and added another dimension to it.  You can bring up new servers very quickly and spin down others.  Amazon succeeded in executing very well to a specific market: engineers.  EC2 is more usable by non-sysadmins, but it still takes a bunch of knowledge about how to, say, configure apache or your mail daemon on TOP of EC2.  In this manner, Amazon's EC2 service is an instance of them capturing the idea and executing it very well for a specific market.

Heroku (and to a lesser extent, Google App Engine) did the same thing for different markets.  The beauty of a service like Heroku is that it requires zero sysadmin knowledge.  None.  I don't need to have a glimmer of understanding as to the inner workings of the server -- I just know it runs my application.  I write a rails app, test it locally, and it JUST WORKS on the server.  All of a sudden the time between development and launching has completely disappeared.

I believe there are specifics to each of these services that cater to their market.  Heroku, for example, is targeted exclusively to Ruby on Rails developers (and they're experimentally supporting Node.js, another community).  This is an important distinction.  App Engine, while it supports Java and Python, doesn't get the defaults right.  They force you to use their libraries, which breaks the entire abstraction.

What's the point of using that infrastructure if you still need to know how it works underneath?  Sure, it's always helpful to know how it works.  But that shouldn't be FORCED on you.

And that's what we're doing at Djangy.  We're working to get the defaults right for the Python community.  For example, the Python community is far more varied in certain respects than, say, the Ruby community.  Ruby has a few frameworks but Rails is by FAR the most popular.  Django is probably the most popular Python framework, but the others are still very significant.  Pylons, Turbogears, CherryPy, and others are most definitely on the radar.  This is one area we're investigating.

I believe the software industry benefits immensely from an incredibly fast cycle from imagination to product.  If I want to build a bridge, I have to go to school, learn physics, math, and join a company that has enough resources to throw at my bridge-building venture.  Then, if I somehow discover halfway through the project that I made an error, it might require weeks, months, or even years until the project gets back on track.  My imagined bridge takes a long, long time to become reality.

With software, though, it's completely different.  We can take our mere ideas and transform them into products very quickly.  Djangy aims to make this even faster.  We're taking care of the tedious work and the sometimes difficult scaling problems and letting you focus on building.

Wouldn't it be great if more people could experience turning your ideas into reality?