The new sandbox: open-source and self-hosted(blog.dotcloud.com)
blog.dotcloud.com
The new sandbox: open-source and self-hosted
http://blog.dotcloud.com/new-sandbox
14 comments
You can combine the AWS free tier with our BitNami Django cloud images http://bitnami.org/stack/django/cloud
>What are some other good free (tier) PaaS options out there?
Cloudbees for JVM apps. You can get started with a free tier git repo, Jenkins build service, db (MySQL default, Postgres available), Tomcat or JBoss instance, and custom domain, and set it up for continuous deployment whenever you push changes to your git repo.
Cloudbees for JVM apps. You can get started with a free tier git repo, Jenkins build service, db (MySQL default, Postgres available), Tomcat or JBoss instance, and custom domain, and set it up for continuous deployment whenever you push changes to your git repo.
Appfog no longer allows custom domains on new free accounts, and bandwidth is down to 5GB from 50GB. It's good for testing, but little else.
Not that I wouldn't like more, but I'm perfectly happy even with those terms, they still mean I can deploy as many experiments and prototypes as I want.
I wouldn't expect to run a production application with 50GB/month traffic for free (unless it was some kind of great free service itself, and then you can probably talk it over with them).
I wouldn't expect to run a production application with 50GB/month traffic for free (unless it was some kind of great free service itself, and then you can probably talk it over with them).
Google App Engine is a good free tier alternative. You have to use their SDK or use the Django-nonrel library, but I've overall been happy.
Django-nonrel is in somewhat rough shape and your code ends up coupled to the platform anyway. No plausible path off of App Engine except a rewrite. So better keep it small.
I believe AppScale is a plausible way out. I tried to use Typhoonae, but couldn't make it work.
I've been playing with the idea of building a App Engine gear able to run Python apps on top of OpenShift, but my day job is interfering with my hobbies...
I've been playing with the idea of building a App Engine gear able to run Python apps on top of OpenShift, but my day job is interfering with my hobbies...
.NET, no custom domain: https://appharbor.com/pricing
Interesting. I'll definitely check them out as a replacement for dotCloud.
Would anyone happe to know a trick to view localhost apps on the iOS Simulator, so I don't have to deploy to an external site to view how my CSS behaves on iOS devices?
Would anyone happe to know a trick to view localhost apps on the iOS Simulator, so I don't have to deploy to an external site to view how my CSS behaves on iOS devices?
http://stackoverflow.com/questions/6077888/how-do-i-access-t...
> http://localhost:<port>/ works from Safari on the iPhone Simulator.Weird. Must have shut down postgres.app by accident the last time I tried it or something.
Cheers!
Cheers!
Since my comment on Dotcloud's blog post hasn't been approved, I'll repost here. Mind that this was addressed to Dotcloud...
First of all, I want to congratulate you guys on what you’re doing for the community by open-sourcing these projects. I have hope that it will lead to faster extension of the options provided by the already-slick configuration scheme to better support new variations on deployment strategies, as well as better documentation.
That being said, my days as a Dotcloud customer may be numbered. Back when I was evaluating PaaSs to use for my commercial project, I chose Dotcloud because I could be free to experiment and test using the Sandbox. While we use a Live application for our production deployment, my company still relies on the Sandbox for staging and one-off tests.
I have since run into a couple pain points using Dotcloud’s services. The first of these is the fact that your Postgres service cannot be easily scaled. Dotcloud support themselves recommended that I use Heroku’s Postgres hosting as an alternative. This seems to be just one step down the slope of potentially migrating our whole stack. The second pain point is that the instance-based model is not amenable to running New Relic for monitoring. This is not a problem specific to Dotcloud, but again, Heroku is outflanking you by integrating New Relic pricing directly into their basic pricing model. This provides for much more predictable and bounded billing–super important for my company in our bootstrapping stage.
While I certainly understand that the Sandbox flavor must come at a significant cost to your company, the fact that it’s phasing out is a significant reduction in value for mine. I’m sure this wasn’t an easy decision, but I hope you understand that this is a strong push toward testing out my deployment on your competitors’ services so I can evaluate the pros/cons of bailing. I hope you’ll consider this as just one customer data point.
First of all, I want to congratulate you guys on what you’re doing for the community by open-sourcing these projects. I have hope that it will lead to faster extension of the options provided by the already-slick configuration scheme to better support new variations on deployment strategies, as well as better documentation.
That being said, my days as a Dotcloud customer may be numbered. Back when I was evaluating PaaSs to use for my commercial project, I chose Dotcloud because I could be free to experiment and test using the Sandbox. While we use a Live application for our production deployment, my company still relies on the Sandbox for staging and one-off tests.
I have since run into a couple pain points using Dotcloud’s services. The first of these is the fact that your Postgres service cannot be easily scaled. Dotcloud support themselves recommended that I use Heroku’s Postgres hosting as an alternative. This seems to be just one step down the slope of potentially migrating our whole stack. The second pain point is that the instance-based model is not amenable to running New Relic for monitoring. This is not a problem specific to Dotcloud, but again, Heroku is outflanking you by integrating New Relic pricing directly into their basic pricing model. This provides for much more predictable and bounded billing–super important for my company in our bootstrapping stage.
While I certainly understand that the Sandbox flavor must come at a significant cost to your company, the fact that it’s phasing out is a significant reduction in value for mine. I’m sure this wasn’t an easy decision, but I hope you understand that this is a strong push toward testing out my deployment on your competitors’ services so I can evaluate the pros/cons of bailing. I hope you’ll consider this as just one customer data point.
Their new strategy is to decommission the free plans and re-invest in building open source instead.
It's not really clear how to self-host and how to transition from self-hosting to their platform if the need arises.
It's not really clear how to self-host and how to transition from self-hosting to their platform if the need arises.
The sandbox was a good incentive to try DotCloud out and keep a healthy staging server etc.
But I suppose the freemium model (I understand it's a kind of freemium) costs, again, too much in this case.
But I suppose the freemium model (I understand it's a kind of freemium) costs, again, too much in this case.
I'm sure they have the numbers to support decision. It's never a one-size-fits-all, unfortunately, and I think I'll stop using dotCloud at this point.
Not that I want to make the impression that there are any obvious alternatives for a fairly easy Django deployment experience.
Not that I want to make the impression that there are any obvious alternatives for a fairly easy Django deployment experience.
As someone who is going to launch a SaaS all-paid (no freemium), I can certainly understand their decision :-)
The thing is, it's easy to upgrade a sandbox account into a paying one. I would recommend that they make sure that the upgrade path from self-hosted to dotCloud be as simple.
Sounds like they want to be like WordPress.org for PaaS, and are hoping someone else will step up and serve as WordPress.com.
They can do that themselves, if they can find a way to keep the Sandbox around.
I think this is great, with one request: I would love to be able to use the same dotcloud toolchain to deploy to a local VM (or, container, I guess.)
Something like `dotcloud local push`. This way I don't have to mess with chef/vagrant/etc for my staging environments: I can simply use my dotcloud configurations for both local and production deployments.
It would be sad if I had to create one deployment system for testing environments, and something entirely different for production - because by the time I set things up for tests, I might as well use that same tool chain for prod!
I don't mind that the free tier is going away - because for me, it has been less about the "free" and more about the "easy to throw a stack together".
Exciting times!
Something like `dotcloud local push`. This way I don't have to mess with chef/vagrant/etc for my staging environments: I can simply use my dotcloud configurations for both local and production deployments.
It would be sad if I had to create one deployment system for testing environments, and something entirely different for production - because by the time I set things up for tests, I might as well use that same tool chain for prod!
I don't mind that the free tier is going away - because for me, it has been less about the "free" and more about the "easy to throw a stack together".
Exciting times!
That's a really good point. If it were really, super painless to set up a local Dotcloud "Sandbox", it would alleviate a lot of the pain of the loss of the free Sandbox. But it's gotta be as easy as it used to be. For me, this means that there should be a zero-config Homebrew package for Mac and a zero-config Apt package for Debian/Ubuntu.
If this existed, it would be really easy to convert self-hosting customers to the paid service for scalability and support, and maybe some of the Dashboard tools. But considering this could be months away, I really wish the Sandbox were sticking around for a while...
If this existed, it would be really easy to convert self-hosting customers to the paid service for scalability and support, and maybe some of the Dashboard tools. But considering this could be months away, I really wish the Sandbox were sticking around for a while...
Docker provides the local execution environment. Not sure how compatible it is with the entire dotcloud PaaS they are releasing though.
https://github.com/dotcloud/docker
https://github.com/dotcloud/docker
Yeah, that is absolutely the goal. Docker was the first step in that direction, and now that we have an awesome community building on top of it, I hope that `dotcloud local push` will soon be a reality :)
I'd love to talk about it some more - just drop by #docker@freenode anytime.
I'd love to talk about it some more - just drop by #docker@freenode anytime.
Install lxc package and you have pretty much everything you need to creat Linux Containers. Check out this part: https://help.ubuntu.com/12.10/serverguide/lxc.html#lxc-admin
Does anybody else feel that less than 3 weeks is not enough advance notice before permanently destroying applications?
It's even shorter: 4 days before you cannot update your staging server if you have one. The people who forwarded me this announcement were really surprised about that (they use sandboxes as staging server).
DotCloud CEO here. You're right, that does feel too short. We're going to extend the grace period.
You probably want to update http://docs.dotcloud.com/guides/flavors/#sandbox too so that it doesn't give the impression that this is a service you still intend to offer.
We can convert apps (including staging servers) to Live pretty quickly, usually the same business day. Or you can create a Live app yourself and re-push the code there, still talking to your staging database (giving you more time to copy the data on that database to the new application).
Hello Andy :-)
Those people were not concerned about the speed at which to convert, more about the sudden extra cash needed.
(note that I don't blame DotCloud for this really! Just giving a data point on something I heard).
Those people were not concerned about the speed at which to convert, more about the sudden extra cash needed.
(note that I don't blame DotCloud for this really! Just giving a data point on something I heard).
I will agree here: I will be given the budget to upgrade these to live instances, and that is what I'll do in the interim. But this mean time I'll have to explain it to my boss (it will shake some of his confidence in my decisions), and it'll put pressure on me to find a lower-cost way to do testing.
I don't disagree with Dotcloud's decision! But our entire stack literally depends on them, so here is another data point about how this will affect us.
I don't disagree with Dotcloud's decision! But our entire stack literally depends on them, so here is another data point about how this will affect us.
How does this affect the ability to run staging vs production environments? We had been looking at using dotCloud thanks in large part to the ability to run as many staging environments as we needed on the same infrastructure.
With that said the possibility of using the open source variety - bringing along with it the ability to use it outside of US East - sounds pretty promising.
With that said the possibility of using the open source variety - bringing along with it the ability to use it outside of US East - sounds pretty promising.
A lot of dotCloud customers use paid apps for staging because it more accurately reflects production and makes for zippier demos (Live apps get faster machines).
You can keep it scaled to a minimum (but still >1 containers to catch scaling bugs) and destroy it after your tests.
You can keep it scaled to a minimum (but still >1 containers to catch scaling bugs) and destroy it after your tests.
Their prices seem really high. 1 instance with 1.7GB RAM is $233/m vs $44/m for Amazon EC2. What an I missing here?
Dotcloud is built on top of EC2 to provide super painless configuration and management. If you want to manage your whole stack, EC2 is not a bad way to go, but for early testing and deployment with modest hosting needs, it's a cheap way to avoid a lot of sysadmin work. Particularly if you haven't done it a whole bunch of times before. There are a whole bunch of folks that provide this type of service, it's called "Platform as a Service".
Hi, dotCloud employee here. You're missing the 24x7 on call engineers who monitor your application, the single-command scaling, the built-in metrics and logging, and the easy deployments, at a minimum.
The way I look at it, personally, is that we're not hardware providers. Instead, we provide some level of "ops as a service" -- partially through tooling and partially through highly skilled engineers.
The way I look at it, personally, is that we're not hardware providers. Instead, we provide some level of "ops as a service" -- partially through tooling and partially through highly skilled engineers.
You can try something like DigitalOcean combined with http://www.cloud66.com for even a cheaper combination and greater control.
Wow, that's pure awesome, and ballsy.
I highly dislike how docker is structured, LXC itself is a somewhat mess of enterprisism and slathering on more abstractions on top of it makes it even more so. Look at http://criu.org for a more modular approach (a sandboxing interface would still be needed) and IMHO what is needed is a sane library to abstract sandboxing (not libvirt) and another for resource limiting (which includes hardware)
Seems like a typical "pasture-source" play - when something gets too hard to maintain, put it in the open-source pasture to let it live or die however it might.
Except that they still use all of the technologies that they are open sourcing! They benefit from any fixes & features.
Is this a fail about the business model of dependant Paas?
IMO open source is not an "alternative" business model, but a complete model (see Redhat, Talend etc...). I don't know open source PaaS that made money then big companies... Curious to see if they will monetize with open source what they couldn't closed source...
I wonder how simple this is going to be getting set up and running. Non-trivial, I would have thought?
So how long before BitNami announces something clever related to dotCloud?
There is some overlap with our LAMP/Django/etc. stacks, but we are much more focused on the application layer. We like the dotCloud guys, they are nice people and very smart. I am sure they will figure out a model that works for them. It is always difficult to get it right the first time. The PaaS business is tough though, because you are competing with the underlying platform providers in a very direct way.
dotCloud (YC '10). :)
From the free options I've seen so far, AppFog comes closest, but last time I tried them the Python/Django documentation was pretty sketchy and the build process had some issues.
What are some other good free (tier) PaaS options out there?