Cloud Computing. A simple term – but what, exactly, does it mean? The National Institutes of Standards and Technology (NIST) has their Definition of Cloud Computing (Special Publication 800-145) which is fairly widely accepted as a good definition. To avoid confusing the issue, I’ll use that as the foundation upon which to build my expanded definition.
As you read through the NIST definition, you’ll notice that it talks about essential characteristics, service models, and deployment models. There’s pretty much nothing about technology. That’s worth paying attention to! I’ll cover a couple of the essential characteristics here, I think a few are pretty obvious.
Cloud computing is a paradigm shift in how IT is exposed to the consumer
On-demand self-service: the first of NIST’s essential characteristics. There’s a reason it’s first – in my opinion, it is the most important of the five essential characteristics. There are nine words in this definition that really drive home the essence of cloud: “unilaterally provision … as needed automatically without requiring human interaction“. This is why most environments that have been virtualized are not “clouds”. A virtualized environment can frequently satisfy the other four characteristics, but this on-demand self-service piece adds a significant wrinkle.
This level of automation implies that the cloud service exposes its capabilities either through a self-service portal or via an application programming interface (API) — and most likely, via both. Some good examples of this are Amazon Web Services (AWS) and Microsoft Windows Azure . With either offering, you can go to their portal, sign up for an account, and begin using their services – all without ever interacting with a human. You could do the same thing from a program via the APIs that they expose. You could also integrate the acquisition, provisioning, scaling, and deprovisioning of cloud services into your trouble ticketing or workflow system (think BMC Remedy and other help desk/change management solutions here). That’s a pretty powerful capability!
Rapid elasticity: having the ability to quickly add and remove capacity can be the difference between having satisfied customers or vacated shopping carts. There are a few really good examples of businesses/entities that have very high fluctuations in demand. For many, the changes are seasonal: the IRS in the first quarter of the year, just about every US-based retailer over the Christmas season, etc. For others, it can be product driven.
A prime example of a company that used the cloud to meet extreme fluctuations in load due to product release is Zynga:
“Then along came FarmVille. After the game’s 2009 release, 10 million users were hitting FarmVille servers within six weeks, and 25 million within five months.
“We couldn’t get power fast enough. We couldn’t get servers fast enough. We just couldn’t scale our infrastructure to match the needs of FarmVille,” said Allan Leinwand, Zynga’s CTO of infrastructure.
** How Amazon saved Zynga’s butt—and why Zynga built a cloud of its own
The first part of second paragraph of that Allan Leinwand quote is critically important: “We couldn’t get power fast enough. We couldn’t get servers fast enough. We just couldn’t scale our infrastructure…“. This was a company that was using a “traditional” data center-based IT infrastructure and they suddenly had a worldwide hit on their hands. The demand grew so quickly that they simply could not provision capacity quickly enough to keep up. It’s also important to note that, eventually, the demand for FarmVille fell off. That meant that Zynga no longer needed all that capacity. Since they were on AWS, they simply spun down the instances they no longer needed and stopped paying for them; try that in your private data center!
I’ll come back to this Zynga example in a subsequent post – I want to talk about why it was the right thing for them to do to go from a private infrastructure to a public cloud and then back to a private (cloud) infrastructure — stay tuned!
While we’re on the topic of rapid elasticity, consider this:
“Each day Amazon Web Services adds enough new capacity to support all of Amazon.com’s global infrastructure through the company’s first 5 years, when it was a $2.76B annual revenue enterprise”
** Expand Your Infrastructure with the Elastic Cloud see slide 4
I’m certain that Google, RackSpace, and a few others can make the same claims … can you?
This ability to scale as needed is especially important for smaller companies (and larger ones who don’t like equipment sitting idle on the data center floor!). Take a quick look over at Amazon’s case study page to see a few examples of companies that launched in the cloud and grew exponentially.
Cloud computing is, more than anything else, a new business model for delivering IT services
Measured service: this is the last of NIST’s essential characteristics. Why am I calling this one out? What makes it so important? Remember, we’re changing the business model for delivering IT. One of the most important shifts is that we’re moving from a capital expenditure (CapEx) model to an operational expenditure (OpEx) model. This simple change allows you to much more accurately track the business value of IT services. Since you’re paying for the capability that you use, there’s a direct correlation between your cloud computing bill and the business impact IT provides.
Why is it important that cloud-based services be “measured”? For two reasons:
- So that the provider can understand the cost to deliver the service and establish a price for which to sell it, and
- So the consumer can evaluate the price against the value it will bring to his purpose
I introduced three terms there that I’d like to take a quick detour to discuss:
- The “cost” of something reflects the expenditure (time, labor, power, cooling, etc.) required to provide the service to the consumer.
- The “price” represents the amount of currency that the provider is willing to make the thing available to consumers for.
- A thing’s “value” represents the benefit that is derived through its use.
In very gross terms, the delta between a providers “cost” and the “price” to the consumer represents the provider’s return on investment (ROI). The difference between the “price” and the “value” is the consumer’s ROI.
OK, I lied. There aren’t only two reasons why measured service is important. There’s another, critically important reason why cloud services need to me measured: the measurement of cloud services provides transparency and allows both the provider and the consumer to know whether the service that’s being delivered meets the parameters established in the contract between the provider and consumer.
Oops! There’s another term: contract. Before a consumer can access the services made available by the provider, there has to be a “contract” put in place. The contract defines what it is that the provider is making available to the consumer, establishes some performance characteristics, sets the price, and establishes penalties to be imposed if the provider fails to meet the terms of the contract. The performance characteristics and the penalties combine to form the basis for a “service level agreement” or SLA. The SLA will define the key performance indicators (KPIs) that need to be monitored and the thresholds that are considered “acceptable” performance.
This SLA is one area where most cloud service providers tend to make it difficult for the consumers. In most cases, the SLA template is highly tilted in favor of the provider. If you look at the KPIs, they’re often vaguely defined with thresholds that are easy to meet. Then, when you look at the penalties that are imposed for failing to meet the SLA, you’ll frequently find that it’s something along the lines of “hey, we screwed up, so we’re going to let you use our service for free during the next billing period” – that’s some penalty!
I’m not trying to scare you away from using cloud computing, just want to make you aware of one of the areas that can represent a bump in an otherwise smooth road. The other thing that I want to mention should be fairly obvious: the cloud service provider is on the other side of a network connection. If that connection goes down, you can’t access your cloud-based resources.
OK, that wraps this quick intro to cloud computing. We’ve talked about three of the five “essential characteristics” as enumerated in The NIST Definition of Cloud Computing, the other two are pretty obvious. In summary, cloud computing has the following characteristics:
- On-demand self-service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service
Cloud computing is all about changing the way in which we consume computing services. It represents a dramatic shift away from the purchase of onsite hardware that you have to maintain and depreciate towards a much more operationally focused model that basically amounts to leasing computing capability on an as-needed basis. It provides you with the ability to dynamically add and remove capacity as needed, and to pay only for what is actually used.
The next post in the series, Cloud 101: The Three Service Models, address the three cloud service models:
- Infrastructure as a Service (IaaS)
- Platform as a Service (PaaS)
- Software as a Service (SaaS)
I will have that post up in the next couple days, so stay tuned!