The Cloud: a short introduction

The Cloud: a short introduction

Few terms have been as simultaneously hyped and reviled as "cloud computing," but there's definitely more to the phenomenon than just a buzzword and some vague talk of "efficiencies" and "agility." We've put together this short, simple introduction to cloud computing that you can send to your CIO the next time you catch him abusing "the cloud" at a meeting.

 

There's a kind of supply-and-demand dynamic that applies to technical terms—when a few knowledgeable insiders are hoarding a word, it maintains its meaning, but when the masses get hold of it and abuse it, it's quickly emptied of value. This is certainly the case with "the cloud," a term that used to mean something, and now means everything and nothing. "The cloud" is so overused by startups desperate for VC money, and by big companies desperate to look like hip startups, that IT professionals are increasingly wary of anything cloud-related. It doesn't help that the image conjured by the word is of something vaporous, flimsy, and fleeting—whatever cloud is, it doesn't sound like the kind of thing you want to entrust critical business functions to.
Despite the fact that everyone seems to see a different shape when they stare at it, there is something worth preserving in "the cloud" as a term that usefully describes one approach to what is often called "utility computing," which latter term is itself a metaphorical way of speaking about a business model centered around the idea of computing power as a service like electrical power.
In first defining and then describing cloud computing in this brief article, my aim is to provide a useful definition for IT professionals who are tasked with exploring cloud services as a potential avenue for finding new efficiencies, reducing fixed costs, tackling scaling challenges, and solving novel problems at Internet scale. My secondary audiences for this piece are IT pros who need to quickly explain "the cloud" to a clueless CIO, and clueless CIOs who'd rather not have to rely on IT pros to explain buzzwords to them.
This article takes a historical and comparative approach to the topic of cloud computing. First, I'll introduce the venerable client-server model, a model of which cloud is just the latest instance, and then I'll contrast the cloud with its immediate predecessor, the grid. Finally, I'll describe the three-tiered model of cloud services.

A brief history of client-server

One of the most common questions asked by cloud skeptics is, "isn't cloud just client-server?" The answer to this is, yes, it is. There are many producer-consumer relationships at every level of computing, from the individual system out to the network, that can usefully be thought of in client-server terms. For instance, a PC's main memory serves a variety of clients scattered throughout the system via DMA requests. In general, a client-server relationship is characterized by a single producer that allows multiple consumers access to its resource pool.
In this respect, cloud fits the client-server model, and, insofar as the typical cloud client is the same as the typical enterprise client (i.e. single desktop or laptop computer), some observers have a tendency to stop at this level of analysis. But, of course, the real action in the cloud happens on the server side of the equation, and that's where things get interesting. But before we get into the cloud in earnest, let's take a brief look back at client-server.
There are essentially two kinds of resources that a server can provide to clients: storage and compute cycles. Client-server models can generally be categorized according to which type of resource they provide.
Chronologically, the first type of client-server pair to become popular was the mainframe and terminal. Since storage and CPU cycles were so expensive, the mainframe pooled both types of resources and served them to thin-client terminals. With the advent of the PC revolution, which brought mass storage and cheap CPUs to the average corporate desktop, the file server gained in popularity as way to enable document sharing and archiving. True to its name, the file server served up storage resources to clients in the enterprise, while the CPU cycles needed to do productive work with those resources were all produced and consumed within the confines of the PC client.
The '80s also saw the rise of the supercomputer, which featured a large, homogenous array of processors and was designed to serve CPU cycles to "fat-client" workstations. Supercomputers were limited to government (mostly military) and government-sponsored parts of academia, not just because those sectors were the only ones with the appetite for that much number crunching power, but because those types of public institutions had pockets deep enough to afford these machines (it was very, very expensive to pool CPU cycles and serve them at a scale that could actually do useful work).
But while the supercomputer market was heating up along with the Cold War that much of its output went toward fighting, the seeds of that market's destruction were being sown by both Moore's Law and the Internet.

The grid, and the rise of utility computing

In the early 1990s, the budding Internet finally had enough computers attached to it that academics began thinking seriously about how to connect those machines together to create massive, shared pools of storage and compute power that would be much larger than what any one institution could afford to build. This is when the idea of "the grid" began to take shape.
The term "grid" is a metaphor deliberately drawn from the realm of electricity generation, where electric utilities provide power over a "grid" network to clients who pay on a metered basis for the electricity that they consume. The idea behind the grid model, and the related concept of "utility computing," was that a sufficiently large number of networked computers could be pooled together like a giant, virtual supercomputer or file server, and access to that pool of compute or storage resources could be sold in an on-demand, metered fashion.
In all, grid computing features a large number of networked, often geographically and institutionally separate nodes that together make up a shared pool of compute resources. Data and computational grids are characterized by autonomous, homogeneous nodes that are loosely coupled and often use public networks. Note that the grid's loose coupling of nodes is a major characteristic that distinguishes it from the cluster, a similar multinode computing concept with which the grid is often confused. Clusters feature nodes that are connected by very high-bandwidth links, and this bandwidth advantage gives them a lot more average compute power per node than a grid because nodes don't spend as much idle time waiting on data to arrive.
Computational grids are more common than data grids, and applications have to be specially written for such grids and designed to scale to a large number of parallel nodes. A typical computational grid client turns to the grid because he needs to run a massive, compute-intensive job that will occupy a large subset of those nodes for a given period of time.

The grid. Different colored jobs belong to different clients.

(One of those jobs belongs to the Department of Defense.)

Grid jobs are often run in batches, where available nodes are pooled together and then assigned work that monopolizes them until it's done. (Note: many grid nodes, like those involved in the distributed.net project, also run local client software simultaneously with their grid job; but from the point-of-view of the grid, that node is still working on a single job.) When the grid job is complete, the nodes are released back into the pool of available resources, and are ready for some other client to use.
One key aspect of the grid is that multiple institutions can share the same hardware resources without worrying about anyone else on the grid gaining unauthorized access to their data. Even though the data is on a publicly accessible grid, it remains accessible only to the client that owns it. It's also the case that the grid hardware itself often has many institutional and/or individual owners—each party contributes compute resources to a shared pool, and in exchange, contributors can bid for cycles from that pool.

The cloud

The cloud is the same basic idea as the grid, but scaled down in some ways, scaled up in others, and thoroughly democratized.
Take a look at the diagram below, and contrast it with the grid diagram above:

The cloud. Different colored jobs belong to different clients.

(One of those jobs belongs to your 18-year-old nephew.)

Like the grid, the cloud is a utility computing model that involves a dynamically growing and shrinking collection of heterogenous, loosely coupled nodes, all of which are aggregated together and present themselves to a client as a single pool of compute and/or storage resources. But though the server side of the model may look similar, most the major differences between cloud and grid stem from the differences between their respective clients.
Instead of a few clients running massive, multinode jobs, the cloud services thousands or millions of clients, typically serving multiple clients per node. These clients have small, fleeting tasks—e.g., database queries or HTTP requests—that are often computationally very lightweight but possibly storage- or bandwidth-intensive.

Cloud vs. Grid

Another difference between the cloud and the grid is that the grids are biased toward serving compute cycles, while clouds typically offer more in the way of storage than cycles. Indeed, most grids would be very ill-suited to cloud workloads like Web serving, and most clouds would fall far short of grid clients' massive compute needs.
Because of the nature of their respective client profiles, clouds and grids also have different ownership characteristics. I noted above that grids tend to be multi-institutional, where institutions and/or individuals all contribute hardware resources that are then shared by other contributors. A cloud, in contrast, is always owned by one institution, regardless of whether use of the cloud is open to clients outside that institution or not (i.e., whether the cloud is public, private, or hybrid).

Cloud services: tiers and fears

Cloud services are offered at three basic levels, or tiers, that are distinguished by the level of abstraction that each presents to the client. These tiers roughly map to the three layers of the standard hardware/OS/applications stack familiar to anyone who uses a PC.
The lowest cloud tier is infrastructure-as-a-service (IaaS), which looks to the client like a dynamically scalable pool of compute and/or storage resources. The basic metered unit of IaaS is usually either a single virtual machine (e.g., Amazon EC2) or an abstract storage object of a certain size (e.g., Amazon S3).
Next up the ladder of abstraction is platform-as-a-service (PaaS), which provides API-level access to a cloud infrastructure layer. Examples of PaaS are Google AppEngine and Force.com. Because PaaS offerings often come wrapped in a vendor-specific API, the use of this layer pretty much locks you into a particular vendor. It's at this tier that enterprise customers must take seriously the risk/reward tradeoff between the convenience and agility afforded by a vendor's cloud offering and the potential inconvenience of being unable to easily move away from that vendor's platform should business or technical considerations demand it.
The final and most popular tier of cloud service is software-as-a-service (SaaS). Google Apps and Salesforce.com are the two paradigmatic SaaS examples, and they're so ubiquitous that not much more needs to be said about this cloud tier.
Insofar as anyone old enough to have their name on a credit card can instantly access a growing suite of services at all three of the above levels to build applications at Internet scale, the cloud represents a huge step forward in the democratization of access to compute resources. A college freshman can tap hardware and software resources that a Fortune 500 company could scarcely dream of just five years ago. But as transformative as the cloud paradigm is, especially for individuals and smaller organizations, it has met with some well-justified resistance in enterprise circles.
For many IT pros, the most important aspect of all cloud services at any of the three tiers is that they all ultimately depend on servers that someone else owns and controls. When I asked the Ars Server Room to define "cloud computing" this past April, "black box" was a word that came up quite a bit in the responses. IT pros are fine with black boxes as long as they're on the inside of them and their users are on the outside, but when IT is outside the black box as well, the comfort level drops markedly.
This issue came up at a press roundtable for the launch of the OpenCirrus cloud testbed a little over a year ago. Intel's Andrew Chien suggested that IT departments are concerned about the loss of control associated with a shift to cloud services, and that they're attached to the status that the "trophy server" or "trophy datacenter" confer on their department. When IT is asked to give up the critical parts of the company's capital that it "owns" so that this infrastructure can be replaced by cloud services that IT will still have to support, the IT function gets something that looks suspiciously like a classic raw deal: less control, fewer resources, and more responsibility.
To return at last to the definitional problem posed at the outset of this article, I'd like to offer a definition of cloud computing that I hope will be relatively unoriginal and uncontroversial, but nonetheless useful:
Cloud computing is an approach to client-server in which the "server" is a dynamically scalable network of loosely coupled heterogeneous nodes that are owned by a single institution and that tends to be biased toward storage-intensive workloads, and the "clients" are a wide variety of individuals and institutions that use fractions of shared nodes to run jobs that are transient with respect to time, lightweight with respect to compute-intensity, and anywhere from lightweight to heavy with respect to storage-intensity.
In the next article, we'll take a closer look at some of the actual technologies involved in cloud computing. Most of the discussion will be centered on Google's cloud, but we'll also look at clouds from a few other vendors.