Sneak Preview of Django Zoom (Heroku-like service for Django apps)

http://noderabbit.com/2010/09/18/sneak-preview-djangozoom/

by dannyr • 16 years ago

37 15 16 years ago

kilian• 16 years ago

Looks...kind of unpolished ;) I understand that getting it to work is the hard part, but adding a little style can't hurt.

Requested access to the beta, I have a couple of django projects that would be nice to run on such a service.

nateaune2• 16 years ago

@kilian - we fully intend to polish the UI and make it look nicer, but you're right - we've been focusing on getting the backend working well, as that seems to be the biggest challenge. It could like all nice and pretty but people won't use it if it breaks. Looking forward to getting your feedback when you deploy your Django projects!

bmelton• 16 years ago

I've also requested an invite.

I'm less concerned with the lack of polish (as kilian brought up) -- but I would definitely start copying and pasting some of the information that you have on the noderabbit site to the DjangoZoom page, or at least, before you come anywhere close to live.

I would tell you to look at the Heroku site for what kind of information sells to users, but I've always had a hard time reading their color scheme, so I much preferred yours.

Any plans on support for Tornado, or is it JUST Django on the roadmap?

nateaune2• 16 years ago

Thanks for your suggestions! What kind of info would you like to see that would help you understand the service better?

We have no plans to support Tornado, but if there's enough demand we'll consider adding support for it.

csytan• 16 years ago

DjangoZoom (http://djangozoom.com/) is mentioned several times in your article, but none of them are clickable.

General request for business blogs: make it easy to navigate to the site you are talking about!

KingOfB• 16 years ago

Looks great, but It's more of an 'EngineYard-like service for Django apps'. Heroku does this marketing / technical trick where you don't have machines, just ruby running in the cloud. No servers to reboot or configure, just X$/mo add-ons to click.

I use and think both services are great, but Engine Yard has all of it's thunder stolen by Heroku. Steeper learning curve, but far more dynamic than Heroku.

mgrouchy• 16 years ago

This is pretty awesome, it really kind of sooths a pain point I have been dealing with. The company I work at is a Django Shop and every time I type "fab Prod deploy" I consider starting work on a gui interface to provision servers(with the linode api), run test suites and deploy code from Github.

endlessvoid94• 16 years ago

already exists: djangy.com ;-)

zalew• 16 years ago

http://news.ycombinator.com/item?id=1616704

SkyMarshal• 16 years ago

One thing Heroku (and Engine Yard) had/have going for them is you can't run Rails on Google App Engine. Any opinions on how Zoom is going to stack up to Django on GAE?

pwim• 16 years ago

You can run Rails on GAE by using JRuby.

jonknee• 16 years ago

You can use a RDBMS. That's a pretty big difference.

dannyr• 16 years ago

You don't get the full Django on App Engine. You cannot use Django's ORM but instead use App Engine's.

You also cannot just use any of the pluggable Django apps especially those with model changes.

ianb• 16 years ago

* You only get the GAE database, no RDBMS, not even alternate nosql things like Mongo.

* Doing geo stuff on GAE is pretty infeasible.

* You can't run other commands, e.g., shell out to git. * You can't connect to any services except HTTP (on port 80/443).

* While you can use the database instead of a filesystem most of the time, it's often harder. Even simple things like using a library that does file-based caching adds challenges to code reuse on GAE.

* There are no C-based libraries on GAE, including things like lxml, image processing libraries, etc. GAE slowly adds new GAE-specific libraries for some of those operations, but slowly and inconsistently.

Often an app won't need these things, but maybe at some point in the future it will -- with GAE you are kind of stuck at that point, or you have to setup external services to augment your core GAE app (removing a lot of the operational simplicity of GAE). And because Django Zoom uses individual virtual servers there's no point at which you can't somehow accomplish what you want to accomplish, even if it's not something directly baked into the service.

In practice it's extremely uncommon to develop an application then move to GAE -- people always develop for GAE from the beginning.

js4all• 16 years ago

Great idea with much potential.

Have you solved the problem how to sandbox/protect against apps that have gone wild?

Are you allowing or planning to clone using git protocol instead of http?

Do you support or have planned custom domains?

Sneak Preview of Django Zoom (Heroku-like service for Django apps)

Related Stories