Different working-groups have defined and re-defined cloud computing over the last few years. Peter Mell, Timothy Grance, Murugiah Souppaya, Lee Badger and other brilliant minds working together with the NIST (National Institute of Standards and Technology) have drafted a document characterizing cloud computing as:
A consumer can unilaterally provision computing capabilities, such as
server time and network storage, as needed automatically without requiring human
interaction with each service’s provider.
Broad network access
Capabilities are available over the network and accessed through standard
mechanisms that promote use by heterogeneous thin or thick client platforms (e.g.,
mobile phones, laptops, and PDAs).
The provider’s computing resources are pooled to serve multiple consumers
using a multi-tenant model, with different physical and virtual resources dynamically
assigned and reassigned according to consumer demand. There is a sense of location
independence in that the customer generally has no control or knowledge over the exact
location of the provided resources but may be able to specify location at a higher level of
abstraction (e.g., country, state, or datacenter). Examples of resources include storage,
processing, memory, network bandwidth, and virtual machines.
Capabilities can be rapidly and elastically provisioned, in some cases
automatically, to quickly scale out, and rapidly released to quickly scale in. To the
consumer, the capabilities available for provisioning often appear to be unlimited and can
be purchased in any quantity at any time.
Cloud systems automatically control and optimize resource use by leveraging
a metering capability at some level of abstraction appropriate to the type of service (e.g.,
storage, processing, bandwidth, and active user accounts). Resource usage can be
monitored, controlled, and reported, providing transparency for both the provider and
consumer of the utilized service.
After attending a few Cloud Camp events I had the privilege of discussing what cloud computing is with Dave Nielsen. Here is the OSSM (pronounced awesome) CloudCamp definition of cloud computing Dave Nielsen has been presenting:
On-demand: the server is already setup and ready to be deployed
Self-service: the customer chooses what they want, when they want it
Scalable: the customer can choose how much they want and ramp up if necessary
Measureable: there’s metering/reporting so you know you are getting what you pay for
While I really couldn’t dispute the awesomeness of Dave’s definition, I challenged it. I just felt the need to add automation to the definition. Here is the OSSAM definition I came up with:
Architecture is implemented by an operating framework that allows for rapid elasticity. This framework determines which hardware and software resources are required to meet a range of service-level agreements and subscriber (i.e. customer) expectations.
Scalability is achieved on the back end via tight and loose coupling of hardware resources, orchestrated to meet the changing demands of different use cases. A grid may provide the computational and storage resources or a network of edge caching servers may provide content distribution. Many public cloud providers offer both. On the front end, virtual and paravirtual machinery provides subscriber-facing service nodes powered by an elastic hardware and network infrastructure layer (resource pool) of computational nodes and storage area networks on the back end. Vertical scaling is limited to the capacity of one piece of today’s best hardware, but cloud scalability means that arrays of nodes can be offered a service layer or unit… which provides horizontal scalability, rapidly on demand.
A multi-tenant framework must exist to provide at least two tiers of service layers. The underlying infrastructure tier represents technical operations and the top tier(s) represent one or more abstracted service layer(s) … oriented to providing services specific to an applied scope of operations. (For example, a business use case for a particular department or organizational unit). Self-service also means that you have the ability to manage your own service layer(s) if that is how you, the subscriber, decide to provision your resources. For example, if someone is a systems administrator he or she may decide to provision a computer in the cloud with or without a managed operating system or with or without the management of a software library layer. Commodity virtual-machinery which is unmanaged is an example of this, but certainly a fully managed virtual machine could fall under the category of ‘self-service’ if the subscriber tells the API to provide them a managed virtual machine. This leads to my bastardization of the Cloudcamp definition…
There must be some degree of automation for cloud computing to be a true “vending machine” and more than just a puppet show. When an order is placed, human resources, engine-squirrels, or monkeys must not be employed to carry out the provisioning of services… no matter how rapidly they may be able to provide services. The system must automatically, via an API be able to mechanically provide services within the range of some kind of service-level agreement. While it’s arguable that this is part of “on-demand” services, I think it’s worth making a distinction. The importance is that on a large scale, on-demand services can’t exist without automation. Fail-over at the hardware level, for example, may not be required for cloud computing to be defined… but fail-over is a crucial piece of the puzzle if storage and compute nodes within a cluster are to provide reliable and sustainable support for complex layers of virtualization.
Metering and reporting is important not only for billing in public cloud service implementations, but also in private clouds which service enterprise departments. Measurement provides a quantitative analysis of resource utilization and allows for more efficient use of computational resources. On the “front-end” metering tells subscribers how much resources they are consuming and on the “back-end” measurement should also tell infrastructure operators when to add hardware resources to the computational / storage grid. With proper fail-over, automation and orchestration these resources should be highly available and a monitoring system should measure that availability.