April 12, 2012, 4:12 PM — This excerpt is from 'The Economics of Cloud Computing: An Overview For Decision Makers,' by Bill Williams. Coming in July from Cisco Press (ISBN: 1587143062).
- Broad network access
- On-demand self-service
- Resource pooling
- Measured service
- Rapid elasticity (1)
Let's step through these of these concepts individually.
First, "broad network access." Access to resources in the cloud is available over multiple device types. This not only includes the most common devices (laptops, workstations, etc.) but also this includes mobile phones, thin clients and so on. Contrast "broad network access" with access to compute and network resources during the mainframe era. Compute resources forty years ago were scarce and costly. Usage was limited based on priority and criticality of workloads in order to conserve those resources. Similarly, network resources were also scarce. Internet Protocol (IP) based networks were not in prevalent usage back then, consequently high-bandwidth, low-latency networks did not exist. Over time costs associated with the network (like costs associated with computing and storage) have decreased due to manufacturing scalability and commoditization of associated technologies. As network bandwidth has increased, network access and scalability has increased accordingly. "Broad network access" can be seen both as a trait of cloud computing and as an enabler.
"On-demand self-service" is a key -- some say the primary -- characteristic of the cloud. If we think of IT as a complex supply chain with the application and the end user at the tail end of the chain, the ability to self-provision resources in typical IT environments fundamentally disrupts the workflow and processes that have evolved as a function of corporate IT over the last several decades. This includes workflow related to procurement of storage, servers, network nodes, software licenses, and so on.
In non-cloud or legacy environments, when the consumer can self-provision without "human interaction" with the provider, the supply chain becomes severely impacted. In non-cloud architectures the capacity planning function is typically performed in "silos" or in isolated organizational structures with little or no communication between decision makers and stakeholders. The downstream effect of such behavior is usually extreme inefficiency and waste.
Self-provisioning in non-cloud or legacy architectures causes traditional processes and functions -- such as capacity planning, network management (providing quality of service or QOS), and security (creation of Access Control Lists or ACLs) -- to grind to a halt or even break down completely. The well documented "bullwhip effect" in supply chain management -- when incomplete or inaccurate information results in high variability in production costs -- applies not only to manufacturing environments but also directly to the provisioning of IT resources in non-cloud environments.(2)
Cloud-based architectures, however, are designed and built with self-provisioning in mind. This premise implies the use of fairly sophisticated software frameworks or portals to manage provisioning and back-office functions. Historically, the lack of commercial off the shelf (COTS) software purpose-built for cloud automation led many companies to build their own portals and frameworks to support these functions. COTS software packages designed to manage and automate enterprise workloads now represent a significant portion of the overall potential cloud market.
"Resource pooling" is a fundamental premise of scalability in the cloud. Without pooled computing, networks, and storage a service provider must provision across multiple "silos" or discrete, independent resources with few or no interconnections. Multi-tenant environments, where multiple customers share adjacent resources in the cloud with their peers, are the basis of public cloud infrastructures. With multi-tenancy, there is an inherent increase in operational expenditures, which can be mitigated by certain hardware configurations and software solutions, such as application and server profiles.
Imagine a telephone network that is not multi-tenant. This is extremely difficult to do: it would imply dedicated circuits from end-to-end, all the way from the provider to each and every consumer. Now imagine the expense: not only the exorbitant capital costs of the dedicated hardware, but also the operating expenses associated with maintenance. Simple troubleshooting processes would require an operator to authenticate into multiple thousands of systems just to verify access. If a broader system issue affected more than one network, the mean-time-to-recovery (MTTR) would be significant. Without resource pooling and multi-tenancy the economics of cloud computing do not make financial sense.
"Measured service" indicates that usage of these "pooled resources" is monitored and reported to the consumer, providing visibility and transparency to consumption rates and costs. Usage monitoring, for the purposes of chargeback (or merely for cross-departmental reporting and budgeting) has been a long-time requirement of IT stakeholders -- another holy grail it seems -- but building such a system is usually not a core competency of most IT departments.
As computing resources moved from the command-and-control world of the mainframe (where measurement and reporting software was built into the architecture) to the controlled chaos of open systems and client-server platforms (where measurement and reporting was done in an ad hoc fashion) visibility into costs and consumption has become increasingly limited. Frequently enough IT teams have built systems to monitor the usage of one element (CPU for example), while using COTS software for another (perhaps storage).
Tying the two systems together, however, across a large enterprise often becomes a full-time effort. If chargeback is implemented, it becomes imperative to drop everything else when the COTS vendor releases a patch or an upgrade; otherwise, access to reporting data is lost. Assuming usage accounting and reporting is handled appropriately, billing becomes another internal function requiring management and full-time equivalent (FTE) resources. "Measured service," in terms of the cloud, takes the majority of the above effort out of the equation, thereby dramatically reducing the associated operational expense.
The final trait highlighted in the NIST definition of cloud computing is "rapid elasticity." Elastic computing is critical to cost reductions and time to market (TTM). Indeed the notion of elastic resources in the IT supply chain is so desirable that Amazon named their cloud platform "Elastic Compute Cloud" ("EC2"). In terms of FTE costs, as I will demonstrate in later chapters, the OPEX associated with provisioning (moves, adds, and changes or MAC) in the IT supply chain are typically the most significant portion of the charges related to application deployment.
Think of the workflow and business processes related to the provisioning of a simple web application. Whether the application is for external customer use or for internal employees, the provisioning processes are often very similar if not the same. The costs associated with delays in provisioning an external application, however, may be significantly higher than costs related to the delays of an internal release. The opportunity costs related to delays of a customer-facing application, in terms of customer acquisition and retention, especially in a highly-competitive market may be exorbitant.
What follows is an example of a typical provisioning workflow for an application. For any simple application (either internal or external) there will be disk storage requirements prompting the storage workflow -- logical unit number (LUN) provisioning and masking, file system creation and access control, etc. Then there is database creation and disk assignment. User creation and permissions management is required for both the application and the database. Finally there is network access to be provisioned, including Access Control Lists (ACLs) and IP-address assignments.
There is often a tendency for functional owners (network administrators, storage administrators, server administrators, etc.) to pre-provision resources in advance of upcoming requests. Unfortunately there is also a tendency for functional owners to overprovision to limit the frequency of requests and to mitigate delays in the supply chain.
The examples previously used are a gross oversimplification of what goes on behind the scenes in an IT environment, but it should be obvious how process delays in any one function could lead to deprivation or overprovisioning in the next function, thereby leading to the aforementioned "Bullwhip Effect." The costs associated with the Bullwhip Effect in a typical IT supply chain (and with concomitant poor utilization downstream) can be significant. Waste associated with poor utilization can easily cost multiple millions of dollars a year in a medium to large enterprise.
In a cloud-based architecture, resources can be provisioned so quickly as to appear unlimited to the consumer. If there is one single hallmark trait of the cloud it is likely this one: the ability to flatten the IT supply chain to provision applications in a matter of minutes instead of days or weeks.
Of these "essential characteristics" the fifth -- "rapid elasticity" or the ability to quickly provision and de-provision -- is perhaps the most critical.
The NIST definition also includes the notion of "Service" and "Deployment" models. For a more complete picture of what is meant by the term "cloud computing" it is necessary to spend a few minutes with these concepts as well.
1. National Institute of Standards and Technology, “NIST Definition of Cloud Computing,” http://www.nist.gov/itl/cloud/upload/cloud-def-v15.pdf, accessed December 2011.
2. The Bullwhip Effect and supply chain management has been widely studied and documented. “The Bullwhip Effect in Supply Chains” By Hau L. Lee, V. Padmanabhan and Seungjin Whang is a classic in this field. MIT Sloan Management Review, http://sloanreview.mit.edu/the-magazine/1997-spring/3837/the-bullwhip-effect-in-supply-chains/, accessed December 2011.