King Cloud by akakumo used under Creative Commons Attribution-Share Alike
The term "cloud computing" is being bandied about more and more recently, sometimes termed "x as a service", its proponents make it out to be the embodiment of an ideology whereby one doesn't worry about the details and simply wants to get things done. From my perspective as a developer, the most interesting parts of the CC paradigm revolve around infrastructure, service and storage but unlike a great many others, I'm unwilling to jump head-first into using CC implementations.
Growing up for me has always been about trying to get the most amount of bandwidth realistically available to me, often times verbally fighting for it, be it with my sister or the IT providers at my university. Coming from that background I have a healthy respect for how precious people make bandwidth out to be and the detrimental effects not having enough of it can cause. In this light, you can understand why I'm wary of cloud computing. Internet access is still not as ubiquitous as many people, most densely-packed city dwellers, make it out to be. The application end of the CC scale I'm always going to meet with scepticism, my documents are stored on my hard drive which is eminently more tangible than an increasingly ephemeral idea of connectivity.
Other uses of CC though include offering a service beneficial to developers and producers alike, and this for me is where the allure begins. Not having to worry about storage requirements or dedicated server space for a project is an enticing prospect, cutting out a swathe of niggles and possible overheads, breaking it down to what many feel is the future: it just works. Being able to simply sign up and start pulling and pushing data through a well defined API, to a service rather than a dirty filesystem has an elegance to it. Or perhaps the idea that servers are no longer tied to a physical machine, instances just minutes away from being summoned to life as quickly as they can be brought down.
Cotton Ball Clouds / Nuvole a Batuffolo by WTL photos used under Creative Commons Attribution-No Derivative Works
One large drawback to all of this ease though is the one aspect which has held me back from dropping my name into the lovingly documented Amazon Web Services: reliability. The most high profile hits recently included Amazon's S3 outage or GMail's downtime both of which may be isolated incidents, but demonstrate that five nines uptime isn't what these services are pushing as their tagline, only ease of use. Of course neither Amazon or Google want downtime and the hit to their credibility will take time to heal, but it highlights that these are not services to be relied on yet. Most current thinking is to use these services as side-cars or backups rather than your main technology platform and to rely upon a robust application to deal with hiccups; perhaps using EC2 as load balancer or for surge capacity, or S3 to store larger files with graceful fall-over to a generic "These files are not currently available" message.
At the moment the services occupy a part of my brain that is doing things backwards: trying to construct uses for the services to justify signing up for them. I'm always looking to learn new technologies, but for the moment I have no use for them that isn't already filled more than adequately by other services. I run a high-availability dedicated server for work which has no trouble handling several large capacity sites and a shared hosting solution with Dreamhost for this site which allows me to tinker and write without any artifical boundaries. For me, I enjoy the finer details of running these services, crafting and honing them to be as swift and efficient as possible; building robustness is part of that, but assuming the underlying foundations you're building on are less reliable than your application and that downtime should be factored into project scopes are foreign concepts to me.