Dipping a Toe Into the Cloud, and Other Mixed Metaphors
Cloud computing is supposedly all the rage these days: the idea is that instead of running your own infrastructure, you just outsource everything.
There are some cases where this is almost self-evidently a good idea: renting a VPS is much cheaper and more reliable than sticking a server in your home and then dealing with the noise, electricity, and bandwidth that such a thing would consume. This blog, for instance, is hosted on a VPS at Panix. On the other hand, an Amazon EC2 instance at the seemingly low price of $0.10 per hour will cost $72 if you leave it on for a whole month—more expensive than many low-end dedicated physical machines.
But the cloud, we are promised, can do more for us than just save us money: it can run our services for us. Programmers no longer need know how to do anything but program the things specific to their application: everything else will be taken care of by “the cloud.”
I’ve traditionally run all my services on machines (usually VPSes) that I administer. But it would be nice to get out of the system administration business.
The Experiment
So, I tried moving one of my small websites, the PBCore Validator, completely away from servers I control and into “the cloud.” This is such a tiny site that I was able to make the move completely for free, which makes for a nice experiment.
The most important component of the setup is, of course, the hosting of the application itself. I selected Heroku for three reasons: they have a limited plan available for free; they support the development of Sinatra, the framework I’m using; and their service is incredibly slick.
Setting up the hosting was quite easy:
$ sudo gem install heroku $ heroku create validator $ git push heroku
This is certainly easier than creating a new nginx configuration, setting up Thin, and all the rest. However, there was an extra step here: I had to modify my application to work with Heroku’s restrictions. Previously, my application statically precompiled its homepage and stored it in the filesystem. However, Heroku provides you with a read-only filesystem, so I had to modify the application to dynamically generate the file and then to set some caching headers so it won’t actually be dynamically generated on every request.
The changes here were trivial, but a larger application might have required more changes and thus more work. This highlights a potential pitfall of cloudlike services: you have to adapt your application to your providers’ conventions; if you need to do something which can not be done under the your providers’ constraints, you need new providers.
Another pitfall was highlighted when I made a small change to the application, then tried to push a new version to Heroku, and got this:
Faced with such a vague, unhelpful error message, I could do nothing but try again after a few minutes, and when that failed, contact Heroku support. They fixed the problem and got back to me within a couple of hours, which is certainly not bad for a response to a nonpaying customer outside of business hours, but if this had happened to a more critical application under more critical circumstances, I might have been rather upset.
Other Services
Having successfully migrated my application away from my servers, what about the other services on which it depends?
DNS was easy. Heroku comes with an integration with Zerigo, so I could set that up with a few commands:
$ heroku addons:add custom_domains:basic $ heroku addons:add zerigo_dns:basic $ heroku domains:add pbcorevalidator.org $ heroku domains:add www.pbcorevalidator.org
After a quick trip to my registrar to switch the domain to use Zerigo’s servers, I was all set. I expect that my application will never get so much traffic that their free level of service would be insufficient.
The final component of the move was of the source code hosting. I use git, so there is not really any need for a centralized server, but since the Validator is a Free Software project, I want to provide access to the browse or download the code and to have an option for others to be able to commit to the project if they desire. It’s easy enough for me to host my own repositories, but if I want to move into the “cloud,” then the obvious choice is GitHub, so now the PBCore Validator code is on GitHub. As the Validator is a small Free Software project, the GitHub free plan is more than sufficient here as well.
And of course, the morning after I made these changes, GitHub went down for about an hour and a half. As they point out, this isn’t the end of the world with a distributed system like git, but it’s still downtime that I had given up any ability to do anything about.
Conclusions
I was able to relatively quickly and easily move a small service completely off of servers that I control for a total cost of $0. Of course, I now rely on the largess of three companies—if any of them goes out of business or decides that providing free limited service is unprofitable, I will need a new option. If lots and lots of people start to want to validate lots and lots PBCore documents, it’s possible I will have to pay to upgrade my service. For comparison, my Panix VPS isn’t free, but I can easily host a few smallish websites on it for one fairly low monthly cost.
Reliability is definitely a concern: I hit two snafus less than twenty-four hours after my move. On the other hand, the uptime of machines that I control seems to be somewhere under 100% as well.
I can’t say for sure if I would take this approach with larger projects, but I will definitely consider it.