How I deployed my Django app onto DotCloud(kencochrane.net)
kencochrane.net
How I deployed my Django app onto DotCloud
http://kencochrane.net/blog/2011/04/deploying-my-django-application-to-dotcloud/
3 comments
That sucks about not knowing what was causing the errors. Too many variables.
That has been my issue with Dotcloud too, when it works its fine - when it breaks its really difficult to debug. It feels more restricted than the Heroku environment too, so even if I do know what's wrong it can't be fixed.
In that respect Dotcloud would need some more abstraction, almost fire and forget for some of this to be Heroku like.
But, I love competition and these guys are living the dream. Hope they continue to kick ass and add features.
But, I love competition and these guys are living the dream. Hope they continue to kick ass and add features.
Hi, DotCloud'er here! Those timeout errors are pretty common, and we are working very hard to reduce them. Almost all operations should be idempotent - meaning that you can repeat them without any danger. Basically: if the 1st time didn't work, the 2nd time will do; if the 1st time did work, the 2nd time won't do anything.
We got a fairly massive growth, and a lot of internal components required to be upscaled much earlier than planned. As we rewrite, optimize, and weed out bugs out of thos components, the timeouts will disappear, and the platform will be faster as a whole.
Just so you know - we are using the "eat your own dog food" principle as much as possible. API, website, docs... are all using the DotCloud platform itself, and we generally don't need escalated privileges to debug stuff. I think we need to be more explanatory about the various ways to inspect logs and debug code, since there is a lot more than meets the eyes :-)
I'm curious about how you feel that we are "more restricted than the Heroku environment"; I would really feel compelled to fix it in any case!
All the best,
We got a fairly massive growth, and a lot of internal components required to be upscaled much earlier than planned. As we rewrite, optimize, and weed out bugs out of thos components, the timeouts will disappear, and the platform will be faster as a whole.
Just so you know - we are using the "eat your own dog food" principle as much as possible. API, website, docs... are all using the DotCloud platform itself, and we generally don't need escalated privileges to debug stuff. I think we need to be more explanatory about the various ways to inspect logs and debug code, since there is a lot more than meets the eyes :-)
I'm curious about how you feel that we are "more restricted than the Heroku environment"; I would really feel compelled to fix it in any case!
All the best,
Out of ignorance & interest, if I'm familiar with the technologies I want is DotCloud worth it compared to say AWS etc?
Im guessing the main bonus for me would be having someone else worry about securing the server.
Im guessing the main bonus for me would be having someone else worry about securing the server.
I've been experimenting with DotCloud (about to push my first site live soon) and I've found it's pretty freaking awesome. It runs on AWS, so basically it's outsourced sysadmin-ing. Give the guys some time and I think DotCloud will be the best platform. Given they just raised some funding, if they get their feature set right, it should work out pretty well.
thanks, it will be interesting to see what the prices are and if its worth it (probably). The lack of control can be a bit scary.
Hi, DotCloud'er here - so take my comment with a bit of salt :-)
Regarding "lack of control", we do our best to address that, in multiple ways.
1. We don't require DotCloud-specific changes to your apps; if you install your Python dependencies with pip or easy_install, dropping a requirements.txt file at the top of you app will be enough to get them installed automatically when you push your code to DotCloud. Of course, if you are used to install Python stuff with other ways (apt-get install, or funky PYTHONPATH tricks), you will have to change that. But moving your dependencies to requirements.txt is not DotCloud-specific, and if you take the time to do it, your app will certainly run better, not only on DotCloud, but on other environments as well. Same thing for the wsgi.py wrapper: once you have done that, you app will run like a charm on any other WSGI-compliant hosting. We think it's a big win, but we won't fight to the death to convince you otherwise ;-)
2. We give a "fair amount" of control on your DotCloud services: SSH, crontabs... But you don't get root access. Why? Well, what if you deploy a Python+WSGI service, and then "sudo apt-get install redis mysql-server irb1.8"? If we want the scaling/monitoring/etc. to be working, we need to set some rules. However, if you need custom stuff, we will always do our best so you can get them.
3. There's the famous "I'm too scary to put my data in the Cloud" (especially after last week's EC2 outage); we address that by giving you many ways to setup automatic backups of your data. For instance, we have a tutorial explaining how to setup MySQL/PostgreSQL backups and ship them to a 3rd party server using FTP/SCP.
We are perfectly aware that many of you out there can do what we do with Puppet/Chef/#{my_fav_devops_tool}, but there are even more people who would rather get straight to the code, and we want them to be as happy and productive as possible!
Regarding "lack of control", we do our best to address that, in multiple ways.
1. We don't require DotCloud-specific changes to your apps; if you install your Python dependencies with pip or easy_install, dropping a requirements.txt file at the top of you app will be enough to get them installed automatically when you push your code to DotCloud. Of course, if you are used to install Python stuff with other ways (apt-get install, or funky PYTHONPATH tricks), you will have to change that. But moving your dependencies to requirements.txt is not DotCloud-specific, and if you take the time to do it, your app will certainly run better, not only on DotCloud, but on other environments as well. Same thing for the wsgi.py wrapper: once you have done that, you app will run like a charm on any other WSGI-compliant hosting. We think it's a big win, but we won't fight to the death to convince you otherwise ;-)
2. We give a "fair amount" of control on your DotCloud services: SSH, crontabs... But you don't get root access. Why? Well, what if you deploy a Python+WSGI service, and then "sudo apt-get install redis mysql-server irb1.8"? If we want the scaling/monitoring/etc. to be working, we need to set some rules. However, if you need custom stuff, we will always do our best so you can get them.
3. There's the famous "I'm too scary to put my data in the Cloud" (especially after last week's EC2 outage); we address that by giving you many ways to setup automatic backups of your data. For instance, we have a tutorial explaining how to setup MySQL/PostgreSQL backups and ship them to a 3rd party server using FTP/SCP.
We are perfectly aware that many of you out there can do what we do with Puppet/Chef/#{my_fav_devops_tool}, but there are even more people who would rather get straight to the code, and we want them to be as happy and productive as possible!
That sure is a lot of steps when compared to Heroku... that's why Rails is gaining so fast on Python.
To be fair, DotCloud offers much more flexibility than Heroku. With DotCloud you can mix and match different stack components. Currently in beta: Java, PHP, PostgreSQL, Python, Redis, Ruby, and SMTP. Plus there are tons of others in alpha, including more esoteric stuff like Erlang. DotCloud also supports any type of version control.
Heroku does Rails apps using Git, and thats it.
The tradeoff is flexibility vs. complexity.
Heroku does Rails apps using Git, and thats it.
The tradeoff is flexibility vs. complexity.