Introducing the new dotCloud dashboard
blog.dotcloud.com
blog.dotcloud.com
One thing I'd really like to see with DotCloud is a way to more accurately replicate their environment locally for development. If I'm setting up a new site, I want my local environment to match the live one as much as possible, so a local VM that matches DotCloud's service settings would be pretty killer. Since each service is independent, that may be tricky, but it would be awesome if it could be done.
On adding CLI functions to the dashboard: this is the most common request, and as we hinted in the announcement: "going forward, you will see more command-line features making their way to the web dashboard, and vice-versa. It also means the CLI and dashboard experience will converge over time and feel more consistent"
On local dev environment: you are definitely not the only one asking for this. We're not quite ready to communicate on the topic, but you should definitely keep an eye out for future progress.
Feel free to hang out on freenode/#dotcloud, we'd love to get more feedback from you!
Essentially I am asking: If you were trying to sell me your product how would you justify the $132 for 1Gb mongodb when I can get a 1.7Gb instance at amazon for a fraction of the price ($46, on demand).
As I said I totally understand the whole sysadminless thing, and I definitely see it's usefulness. However, none of what you're saying is even advertised/mentioned by them (at least based on my quick search)...
We keep your app running 24/7 with built-in load-balancing, monitoring and failover. Scale in seconds to handle surges in traffic - and only pay for what you need.
It is admittedly below the fold, and they should probably replace its position on the page with their customer success stories, but they at least do try to tell you what they do.
I love DotCloud to pieces, but use them selectively. The real key to this question is how much you value the convenience and super scalability of it. For me, I would much prefer having my code on Dotcloud if only because it integrates with Github, can be pegged to a particular branch, and is super super scriptable (so that you can have a repository invoke a webhook that deploys your code to Dotcloud, for example.)
Well short of a one-click installation, of course. :)
A novice could probably set up a GitHub project on dotCloud, whereas there is no chance in hell said person could do it on Heroku, last I checked their guide.
Their support team is also pretty great. Of course, the ideal scenario is never having to deal with support. ;)
1. Sign up, install CLI, enter username/password
2. git clone foo
3. cd foo
4. dotcloud create bar
5. dotcloud push -A bar --git
And from a developer perspective we're just talking about setting up the DB, wsgi, postinstall, and dotcloud.yml.I didn't manage to find something in Heroku's guide that made it sound as easy for setting up Django on their PaaS. If I did, I'd probably have some services set up on Heroku at the moment. Maybe someone else just needs to write a better guide for them.
1. Sign up, install CLI, enter username/password
2. git clone foo
3. cd foo
4. heroku create bar
5. git push heroku master
So basically the same. Worth noting that this sets up a database for you as well, your project is configured to use it when you push. From memory you have to set up the DB yourself with dotcloud, it's been a while though. * vertical scaling (you can allocate arbitrary amounts of memory and cpu to your containers)
* You can allocate raw TCP and UDP portsI'm hosting my SaaS app on DotCloud and I really like the charts with http status over time, overall latency, RAM consumption etc!
Congratulations on the CLI improvement overall, all nice stuff!
Maybe turning off some extensions will help.
I can see that your new dashboard would be useful for scaling up and down once an app's running on dotCloud, but I'd prefer to be able to estimate running costs before committing to your platform.
Do you have any guidelines to estimate RAM/instance requirements? I'm new to PaaS-style hosting, so forgive me if this is simple stuff, but if I was running a basic Sinatra app with MongoDB and static file hosting, for example, how could I gauge my approximate running costs under dotCloud?
Went here https://www.dotcloud.com/pricing.html Selected mysql and php its $17.28. That's costly, with a little more one could take a linode server.
What Dotcloud affords me is the ability to not have to worry about system administration. I don't have to concern myself with whether or not my log files are public, or if I have PHP globals enabled, or if Apache is leaking user details.
I can deploy to Dotcloud with a single command (which can be automated, scripted or even remoted,) and I don't have to worry about scaling concerns.
For example, compared to AWS (pulled from http://news.ycombinator.com/item?id=4694689):
* For a clean architecture you want to isolate each Mongo and node process in its own system. So you need 6 instances, not 3.
* You'll need load-balancers in front of these node instances. That costs extra on AWS, and is included on dotCloud.
* Did you include the cost of bandwidth and disk IO in your estimate? Those are extra on AWS, but included on dotCloud.
* Monitoring is extra on AWS. It's included on dotCloud.
* I love to have a sandbox version of my entire stack, with the exact same setup but separate from production. That's an extra 2 instances on AWS (+io +bandwidth +load-balancing +monitoring). It's free on dotCloud, and I can create unlimited numbers of sandboxes which is killer for team development: 1 sandbox per developer!
* We only charge for ram usable by your application and database. AWS charges for server memory - including the overhead of the system and the various daemons you'll need to run.
* For small apps specifically, you can allocate memory in much smaller increments on dotCloud, which means you can start at a lower price-point: the smallest increment is 32MB.
I didn't even get into the real value-add of dotCloud: all the work you won't have to do, including security upgrades, centralized log collection, waking up at 4am to check on broken EBS volumes, dealing with AWS support (which is truly the most horrible support in the World, and we pay them a lot of money).
+ Our support team is awesome and might even fix a bug in your own code if you're lucky :)