I'm sad to see their free sandboxes going away, they were a good option for deploying Django for small, non-commercial projects or tests. The experience was better than Heroku (rsync deploy, reasonable database limit, ssh shell) and the docs were alright.
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?
>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.
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).
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...
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?
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.
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".
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...
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.
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.
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).
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).
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.
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.
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.
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.
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.
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...
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.
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?