One of the things that worries me about "the Cloud" is exactly what everyone is talking about when they use the term, especially when the meaning appears to change as the conversation develops. I can remember "bureau computing" 30 or 40 years ago - where you shipped your company payroll data, say, to an external service provider, who processed everyone's payroll data (separately and securely) on a big mainframe (taking advantage of mainframe security for multi-tenancy) and then shipped the results, plus pay slips, back to you. How is this different from Cloud Computing?
Well, that's an "exercise for the reader", but I suggest that defining terms might be a very good starting point for any discussion of Cloud Computing. And, ideally, these shouldn't be personal definitions but come from some recognised, vendor-independent industry- or user-based organisation.
Might I suggest turning to a new book from the Open Group: Cloud Computing for Business, the Open Group Guide, published by and available from Van Haren Publishers.
The definition of Cloud Computing this book chooses to espouse, from NIST (the National Institute of Standards and Technology), strikes me as a pretty good starting point:
"Cloud Computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models."
The book then goes on to explore what this means, its implications and limitations (NIST itself recognises that this definition will probably evolve over time, in the light of experience). It possibly isn't perfect, but as Dr. Christopher J. Harding, (Director, Interoperability, The Open Group) points out, it's quite good enough to be the basis for something more useful than academic nit-picking.
There's no point in me précising a book that repays in-depth study by anyone contemplating Cloud Computing, but I will say that I like its practical focus: it has an appendix of "Cloud Business Use Cases" and chapters on "Buying Cloud Services", "Understanding Cloud Risk" and "Building Return on Investment from Cloud Computing", for instance. Cloud Computing is not (or shouldn't be) an end in itself, a cool way to play with interesting technologies, but an enabler for more effective, more agile, business process automation.
I am also pleased to see sections devoted to Cloud and Architecture (focussed on TOGAF, of course), as an approach to managing risk; and to the relationship of Cloud and SOA. Perhaps more space could be devoted to Architecture, however, as I see it (in part) as a way of translating the language and concepts of technology or, in this case, Cloud Services into the language and concepts of business strategy - helping to ensure that you are not only doing Cloud Services right, but also choosing the right Cloud Services. And, while Cloud is not the same thing as SOA, as the book points out, my personal belief is that useful Cloud Computing is inherently service-based (and that's an organisational and cultural issue as much as a technology one) and that Cloud Computing can be thought of in terms of a subset of Service Orientation generally.
I also welcome the book's coverage of changing Cloud suppliers in the section on Exit Strategies: "Today it may be easy to switch mobile phone providers, but the ease of switching Cloud providers is still largely untried". To my mind, the current situation, where you are often locked into a particular cloud provider and can't easily unplug from one cloud and plug into another with any assurance of maintaining similar service levels even if the move is feasible, makes a mockery of the abstraction of business automation from underlying technology which is part of what the business expects from Cloud. Nevertheless, as the book points out: "When negotiating with a new supplier, or re-negotiating with an existing one, or if you wish to in-source a particular service, you should be sure that you have an exit strategy - a way of moving to another supplier if you wish to do so. Insisting on requirements for supplier choice and bulk data transfer will help you achieve this".
The book itself takes on a certain authority from the Open Group, which also maintains the TOGAF architectural framework, amongst other standards, and has a vision for "Boundaryless Information Flow™" (it also owns the UNIX trademark). It has an Editorial Board, comprising Chris Harding, of The Open Group (lead author); Pamela K. Isom, IBM and CBUC project co-chair; and Mark Skilton, Capgemini and CBA project co-chair and Cloud Computing Work Group co-Chair. It has been subjected to external review by 18 people with business or business/technical roles, mainly external to The Open Group and internal review by 72 Open Group member company representatives. Oh, and it's also quite readable...
So, I think that this book, and the Open Group's involvement in Cloud standards, is to be welcomed - I think that vendor-specific and vendor-maintained standards would be the wrong way to go. There is just one possible dark cloud (sorry!) on the horizon - I do hope Cloud Computing isn't entering a period of standards wars such as have beset operating systems and browsers, for example, in the past. It would, I think, be fundamentally inappropriate if moving a Cloud-based application from, say, a Microsoft environment to one based on, say, Amazon EC2 involved a major technology porting investment and significant recoding to new standards (beyond the fact that one or other basic platform might need value add services plugged in, to suit a particular application). There are several emerging Cloud standards covering different aspects of Cloud Computing (and the UK government G-Cloud may provide de-facto standards), including the interesting Service Management Index being developed at Carnegie Mellon (see here). However, Harding was able to reassure me that the Open Group, at least, is prepared to accept and work with complementary Cloud standards rather than insisting on owning the whole stack - which is a very good sign. As Harding says, "Competition can be good because it drives up quality, and this applies to standards too, but it must be based on the recognition that we are all serving the user community. The Open Group is proud to develop quality standards, but we recognise that this applies to other bodies too, and we are happy to work with them in meeting user needs for IT standards and guidance" .