I have been working very hard trying to identify just what cloud computing is. At this point, my working definition for cloud computing is two fold. From an engineering perspecitve the cloud is a computing architecture characterized by a large number of interconnected identical computing devices that can scale on demand and that communicate via an IP network. From a business perspective it is computing services that are scalable and billed on a usage basis.
It is my observation that many technologies commonly associated with computing cloud architectures are not intrinsically associated with them and could just as easily be provided by a different architecture. Thus, while they may be part of an offering that could be built on a cloud architecture they are not necessarily so. To try and understand the relationship between these services and cloud architectures, I think it is valuable to be able to understand them within the context of cloud computing. I have developed this framework of technologies and services associated with cloud computing to help me better understand in my own mind what the characteristics of the cloud are and what services cloud computing entails. The groupings shown in the gray boxes are the larger categories identified by NIST and Wikipedia, Software as a Service, Platform as a Service, Infrastructure as a Service. I have attempted to poke the services in these groupings that seemed most germaine to them.
Like the OSI model, this framework is best read from the bottom up. Everything is dependent upon security. Provisioning is above security because it cannot occur reliably without security, and all of the serivces are based upon the ability to perform the tasks in the provisioning group. Infrastructure as a Service is the first grouping dependent upon (resting upon) provisioning serivces. (i.e.; once provisioning services are provided, Infrastructure as a Service can be delivered. Likewise with PaaS and SaaS.
Integration and User Services are shown as vertical rectangles spanning IaaS, PaaS and SaaS because these regions represent services that are applicable to all three of these layers in the framework.
I am working on a hyperlinked version of this framework depicting the cloud and its components. As you can see from the image below, I'm not through experimenting with how this can be done in this portal.
It's not complete, but it's getting there.
I have tried to put most of the unique categories of services into the framework to show how they could be lumped within Infrastructure as a Service, Software as a Service, etc. I do not know everything. This site is intended to be a vehicle to allow people to contribute. So if there are other categories of offerings in the cloud computing community, please feel free to let me know.
The framework includes a set of terms for its components. I am in the middle of providing a definition of them on a definitions page.
What's interesting in looking at this diagram is that it is difficult to distinguish the services associated with cloud computing from those that any computer operations center would include. In fact, this diagram actually resembles the IT services that ITIL speaks of. Although ITIL discusses IT infrastructure as a set of services, it doesn't define what those services might be. I would submit that what we are looking at in this diagram is a service-oriented view of IT and thus a generalized form of the ITIL Services Directory. Whie it might be difficult to look at the diagram above and pick out what exactly is cloud related, it is easy to look at it and recognized the IT services that may be built on this architecture. And by the way, it might turn out to be a pretty good model for understanding IT infrastructure as services, à la ITIL.
One approach I am using is looking through some software inventories I have to see if I have overlooked anything. Tying the software inventory to the services it performs can help me determine how much we're paying for these services in house, so I can make a better decision about the cost-benefit of outsourcing to a cloud provider.
I am trying to link this model to the Federal Enterprise Architecture Framework. I'm thinking that this framework should fit somewhere in between the Service Component Reference Model (SRM) and the Technical Reference Model (TRM). As you can see by following this link, It's not a clean mapping to the SRM, but most things do match up.
My next step was to map to the TRM, which should have been easier since all of these blocks have some set of standards that would apply. Unfortunately, the TRM is about 5 years behind and many of the technologies are improperly grouped. As you can see from the link above, I put together the web page for it, but at this point am not sure whether to map to it, or propose a new technical taxonomy. More to follow...
In the mean time I have been trying to figure out security arrangements and cost/benefits of cloud computing. Following this link takes you to a spreadsheet I created to estimate the cost of not doing cloud computing. These figures are derived from empirical data I have gathered and match other estimates arrived at independently over the years.
So where is the cloud? Have we boiled it off?
My answer is to circle back and say that the cloud is an architecture and a way of paying for services in an on-demand fashion, not the set of services themselves. While many of the services in the diagram above could be provided by employing the use of a cloud architecture, they can (and often are) deployed in non-cloud architectures as well.
The advantage of disassembling the cloud this way and directly addressing the fact that these serivces already exist in most data centers is that it serves as a kind of menu system. By looking at this diagram, the IT director can pluck parts out of the framework and choose to outsource portions of their IT infrastructure depending on their needs, potentially yielding the organization greater levels of agility. For instance, suppose the person who knew how to service portals got a new job. One approach would be to hire a new person to replace them. Another might be to outsource portal serivces to an external provider and not backfill the position. Outsourcing can be used as a means of encouraging convergence across an enterprise. Currently one small bureau in the government has over 200 portal sites. Not only did it cost the organization a lot of money and productivity setting up all of these portals, but even after they are set up the organization continues to consume inordinate costs as it trys to maintain all of these portal instances. Probably the largest cost of all is the value that is lost by having all of these independent portals. Because these portals are all unique and don't talk to eachother, they have become just another form of stove-pipe architecture. Outsourcing portal service to an external provider would provide a means to have a single portal space with a comprehensive indexing and search capability that these 200+ portals would never have.
From an engineering perspective, cloud computing is an architecture characterized by a large number of identical computing devices that can scale on demand and that communicate via an IP network. From a consumer's point of view this just doesn't matter. As long as the provider can deliver these services, how they do it is really immaterial. From the consumer's perspective, the architecture the vendor uses to deliver their services is only significant in terms of the cost reductions that the vendor realized through commodity hardware and software purchases and that they choose to pass along to the consumer. A second factor that may affect the consumer might be a limited selection of technologies that the vendor is willing or able to support because their support infrastructure would be designed to support a certain limited set of technologies. Another significant concern is vendor lock in, but this concern exists whether the vendor is using a cloud architecture or not. In fact, those vendor who don't use cloud architectures to deliver serivces are probably more likely to impose vendor lock in, because the products they use will be proprietary and impose a vendor lock in that they will have little recourse but to pass along to their customers.
That's what I've got for now.
Pat Stingley firstname.lastname@example.org
(Tiny URL for this page is: http://tiny.cc/dkXLJ )
All are encouraged to share the material on this page with attribution in accordance with Creative Commons. I am the author of the text and most of the diagram. Nick Mistry deserves credit for coming up with an improved framework and sharing that with me. Thanks to Jeff Harrison of the Carbon Project for convincing me that web servers and web services are different enough to warrant separate mention and to Ty Fabling of ESRI for doing the same with Collaborative Services and e-mail. All of these ideas are subject to debate. Good debate is gratefully accepted. Colin Powel's Leadership tenant #3 - Share credit.