Cloud computing

King Cloud by akak­umo used under Cre­at­ive Com­mons Attribution-Share Alike

The term “cloud com­put­ing” is being ban­died about more and more recently, some­times termed “x as a ser­vice”, its pro­ponents make it out to be the embod­i­ment of an ideo­logy whereby one doesn’t worry about the details and simply wants to get things done. From my per­spect­ive as a developer, the most inter­est­ing parts of the CC paradigm revolve around infra­struc­ture, ser­vice and stor­age but unlike a great many oth­ers, I’m unwill­ing to jump head-first into using CC implementations.

Grow­ing up for me has always been about try­ing to get the most amount of band­width real­ist­ic­ally avail­able to me, often times verbally fight­ing for it, be it with my sis­ter or the IT pro­viders at my uni­ver­sity. Com­ing from that back­ground I have a healthy respect for how pre­cious people make band­width out to be and the det­ri­mental effects not hav­ing enough of it can cause. In this light, you can under­stand why I’m wary of cloud com­put­ing. Inter­net access is still not as ubi­quit­ous as many people, most densely-packed city dwell­ers, make it out to be. The applic­a­tion end of the CC scale I’m always going to meet with scep­ti­cism, my doc­u­ments are stored on my hard drive which is emin­ently more tan­gible than an increas­ingly eph­em­eral idea of connectivity.

“five nines uptime isn’t what these ser­vices are push­ing as their tagline”

Other uses of CC though include offer­ing a ser­vice bene­fi­cial to developers and pro­du­cers alike, and this for me is where the allure begins. Not hav­ing to worry about stor­age require­ments or ded­ic­ated server space for a pro­ject is an enti­cing pro­spect, cut­ting out a swathe of niggles and pos­sible over­heads, break­ing it down to what many feel is the future: it just works. Being able to simply sign up and start pulling and push­ing data through a well defined API, to a ser­vice rather than a dirty filesys­tem has an eleg­ance to it. Or per­haps the idea that serv­ers are no longer tied to a phys­ical machine, instances just minutes away from being summoned to life as quickly as they can be brought down.


Cot­ton Ball Clouds / Nuvole a Batuffolo by WTL pho­tos used under Cre­at­ive Com­mons Attribution-No Deriv­at­ive Works

One large draw­back to all of this ease though is the one aspect which has held me back from drop­ping my name into the lov­ingly doc­u­mented Amazon Web Ser­vices: reli­ab­il­ity. The most high pro­file hits recently included Amazon’s S3 out­age or GMail’s down­time both of which may be isol­ated incid­ents, but demon­strate that five nines uptime isn’t what these ser­vices are push­ing as their tagline, only ease of use. Of course neither Amazon or Google want down­time and the hit to their cred­ib­il­ity will take time to heal, but it high­lights that these are not ser­vices to be relied on yet. Most cur­rent think­ing is to use these ser­vices as side-cars or backups rather than your main tech­no­logy plat­form and to rely upon a robust applic­a­tion to deal with hic­cups; per­haps using EC2 as load bal­an­cer or for surge capa­city, or S3 to store lar­ger files with grace­ful fall-over to a gen­eric “These files are not cur­rently avail­able” message.

At the moment the ser­vices occupy a part of my brain that is doing things back­wards: try­ing to con­struct uses for the ser­vices to jus­tify sign­ing up for them. I’m always look­ing to learn new tech­no­lo­gies, but for the moment I have no use for them that isn’t already filled more than adequately by other ser­vices. I run a high-availability ded­ic­ated server for work which has no trouble hand­ling sev­eral large capa­city sites and a shared host­ing solu­tion with Dream­host for this site which allows me to tinker and write without any artifical bound­ar­ies. For me, I enjoy the finer details of run­ning these ser­vices, craft­ing and hon­ing them to be as swift and effi­cient as pos­sible; build­ing robust­ness is part of that, but assum­ing the under­ly­ing found­a­tions you’re build­ing on are less reli­able than your applic­a­tion and that down­time should be factored into pro­ject scopes are for­eign con­cepts to me. ¶