Over a million developers have joined DZone.

Let Us Praise Cloud Development Environments

DZone 's Guide to

Let Us Praise Cloud Development Environments

· Cloud Zone ·
Free Resource

I like my laptop.  It's great for email, web browsing, spotify, and a ton of other applications.  It sucks for programming, though.

Most of my programming time is spent on our platform and supporting services at Famigo.  It's a nice Django app that relies on a few different datastores, and much of the CPU-bound work occurs in asynchronous tasks fired off by Celery.  It's not a terribly complex environment, and we keep it manageable and portable with virtualenv (Ruby folk, imagine I just referenced rvm).  All our config files are stored in github, as are shell scripts to automate directory creation, etc.

Even with all of that, it still takes hours to setup a new environment for the first time on someone's machine.  It's a damn nightmare just to get everything installed.  I'll spend hours googling cryptic error messages about a mangled dependency several layers deep in the OS.  (The exact error will differ depending on whether it's Ubuntu 10.04, 10.10, or 11.04, of course.  Ditto Windows XP versus Windows 7, and whatever kitty cat they're naming OS X releases after.)

When I finally get everything installed and I run our test suite, I discover a whole new set of baffling dependency issues, perhaps because the database versions are slightly off.  When that works, I'll run some of our asynchronous tasks and discover yet another esoteric problem, related to directory permissions or path issues or Spaghetti Monster knows what.  (It's easy for me to accidentally skip this step, and only discover that things aren't working a week later.  Whoopsie!)

Once the new development environment is up and functioning properly, we still see environment issues, but they're now reversed.  Here, we make changes that look great locally, then we push to staging or production and see an explodes.  After much complicated debugging, it's typically another unpredicted dependency issue, where the dev environment OS comes with v1.1.8.4 of an imaging library while our production instances have v1.1.7.1.  This is way scarier, because we've probably been frustrating actual users.

I've made this sound awful, but there is good news!  You don't have to worry about this.  There's an easy technical solution that, once implemented, allows you to save your brain power for interesting problems, like actual programming or creating a thunderously-jammin' Turntable.fm playlist.

We already have a wonderful environment where everything works: it's called Production.  For us, it's all hosted in the cloud via Amazon EC2 instances.  If you wish to work on our great projects, then I just take a snapshot of Production and spin up a new EC2 instance for you.  This process takes about a minute.  Sure, there's a bit of maintenance: every once in a while, when our production environment changes, we need to update our dev instances with new snapshots.  This takes another minute.  Through cloud hosting, we've turned our development environment into a commodity.

Of course, this doesn't work for everything.  If you do a lot of development without internet access (perhaps you're a hobo riding the rails?), this won't work.  (You could do something quite similar via the aptly-named Vagrant, though!)  It's also not such a great idea for non-web development.  You unlucky folks get to wrangle your own, local, development environments.  Have fun with that!


Source: http://www.codypowell.com/taods/2011/07/let-us-praise-cloud-development-environments.html


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}