5 ms·

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

37 points by dannyr 16y ago

endlessvoid94 16y ago
already exists: djangy.com ;-)
- zalew 16y ago
  http://news.ycombinator.com/item?id=1616704 http://news.ycombinator.com/item?id=1616704
kilian 16y 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.
- nateaune 16y 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 16y 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?
- nateaune 16y 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 16y ago
DjangoZoom (http://djangozoom.com/ 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 16y 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 16y 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.
SkyMarshal 16y 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 16y ago
  You can run Rails on GAE by using JRuby.
- jonknee 16y ago
  You can use a RDBMS. That's a pretty big difference.
- dannyr 16y 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 16y 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 16y 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?

37 points by dannyr 16y ago

endlessvoid94 16y ago

already exists: djangy.com ;-)

zalew 16y ago
http://news.ycombinator.com/item?id=1616704 http://news.ycombinator.com/item?id=1616704

kilian 16y 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.

nateaune 16y 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 16y 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?

nateaune 16y 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 16y ago

DjangoZoom (http://djangozoom.com/ 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 16y 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 16y 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.

SkyMarshal 16y 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 16y ago
You can run Rails on GAE by using JRuby.
jonknee 16y ago
You can use a RDBMS. That's a pretty big difference.
dannyr 16y 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 16y 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 16y 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?