Apple has finally unveiled its long-rumored iCloud service, and these days it seems like you can’t swing a mouse without running into “the cloud” — a nebulous term that sometimes seems to represent anything that runs anywhere on the Internet.
In reality, there is an actual definition for cloud computing, and it turns out to be the single most disruptive technology to hit data centers since the mainframe. Combine cloud computing with the equally transformative growth in mobile computing and we find ourselves traveling through a technological thunderstorm that may have an impact as substantial as the Internet itself.
Forming the Cloud -- The term “cloud computing” has been floating around for many years, but started to take a more precise form in 2006 after Amazon opened up its Elastic Compute Cloud (EC2) service, an extension of Amazon Web Services. EC2 allows customers to “rent” computers in Amazon’s data centers. You aren’t renting an actual dedicated computer, but a virtual machine that boots and runs for however long you need on whatever host machine Amazon has where there’s enough free computing capacity, memory, and storage.
EC2 is an extension of technologies that Amazon developed to optimize the resources in its data center. Running dedicated computers for dedicated functions is horribly inefficient. You have to build systems to handle the largest possible spike in demand, or else your application will fail when the load increases too much. Just ask anyone whose site has crashed under high traffic after being linked to by Daring Fireball.
For some scenarios, such as a large retail Web site that can’t afford to fail during pre-holiday shopping spikes, you might have to plan enormous capacity that’s rarely used, and unevenly distributed, since that capacity needs to be available on each individual system that comprises the entire service. For example, every single database server will need extra capacity to handle spikes, plus you’ll need extra, dedicated, database systems for when things get really bad.
EC2 (and Amazon’s internal platform) addresses this problem by collecting all the hardware into a pool of processors and memory that runs “hypervisors” instead of normal operating systems. Also known as a “virtual machine manager,” a hypervisor is the software that enables virtualization. Operating systems like Windows, Linux, and Mac OS X run on top of the hypervisor, which divvies out processor time or cores, and allots storage and memory to each virtual machine. Virtualization enables you to run a database server and application server on the same platform, in separate, isolated, virtual machines. They may or may not be on the same physical server, but you don’t care whether they are or not. (TidBITS went virtual last year when we had problems with our primary Xserve. Read “TidBITS’s Emergency Brain Transplant,” 24 August 2010.)
As powerful as virtualization is, it’s still inefficient. You can’t escape planning for capacity on each virtual server, as we’ve learned (some recent outages of the TidBITS and Take Control Web sites have been related to needing to tweak Apache and MySQL settings to handle unexpected load). While it is sometimes possible to do nifty things like move a running virtual machine to larger hardware without shutting it down, there’s still a lot of manual management involved. This is where the magic of the cloud comes in. With cloud computing all the resources are pooled together and a “cloud controller” orchestrates provisioning and utilization of the pools on demand.
Here’s how it works. If you need a database server of a particular size, you request one from the cloud controller, telling it things like how much memory and storage you need and what operating system you want. You can even ask it for an “image,” a pre-configured virtual machine with all the applications you need that lets you avoid having to install everything from scratch. The cloud controller chooses a physical server with the capacity to handle your request (it may be running all sorts of other virtual machines as well) and tells it to load and instantiate your requested image from storage. The controller is smart, and places the virtual machines to use the available capacity most efficiently.
Better yet, instead of having a bunch of extra virtual servers running to handle spikes in demand, the cloud controller can rapidly spin up extra virtual machines as needed (automatically, based on pre-set rules), then shut them down when demand drops. If you’re running a bunch of different applications in your data center (the typical large business runs hundreds of applications on thousands of servers), the odds are low everything will be in high demand at the same time, and thus the cloud controller orchestrates everything to use your resources most efficiently.
Thus our data center moves from being a bunch of independently running servers, all with extra capacity and spare servers to handle burst loads, into a pool of shared hardware (the cloud) where servers spin up and down as needed. This is known as a “compute cloud,” and we also have “storage clouds” designed to combine all the hard drives into storage pools. If Amazon needs more capacity, its technicians only have to add dumb hardware, load up some software to connect that hardware to the company’s cloud, and let the cloud controller figure out how to best use it. That’s key — the whole point is that you don’t have to configure everything specially for each individual application or service.
Now, I’ve simplified things a bit, but this is pretty much how a cloud infrastructure works. Amazon had to build it themselves with custom software, but these days there are both commercial cloud infrastructure platforms (like VMware) and open-source options (like OpenStack and Eucalyptus).
Going Public -- Amazon still faced a problem. Although it was much more efficiently using its resources for its core business, the company still needed enough spare hardware capacity to handle major increases in activity, like the holiday shopping season. All this hardware would sit around waiting to be used, with the hypervisors twiddling their virtual thumbs.
Amazon realized that others might find it useful to rent this spare capacity; perhaps for developing new applications (instead of buying extra internal servers), or even for permanent purposes. So the firm launched Amazon EC2 and enabled anyone with a credit card and some technical knowledge to run their own virtual systems in Amazon’s cloud. Amazon also released Amazon S3, a storage service that works on its own or with EC2, as well as Amazon RDS, a relational database service, and other offerings so abstract that only information technologists can love them.
This raised an interesting problem. Now all sorts of people may run all sorts of applications on the same infrastructure, but they don’t want their neighbors poking at their servers. Amazon thus included features to isolate customers from one another. Although you can connect all your virtual services to each other, they are walled off from everyone else.
The first version of EC2 was pretty limited, but these days it runs lots of different things, including popular Web applications like Evite, large enterprise applications, and even individual blogs. All these customers pay based not on a fixed rate, but based on what they use, much as your power bill is based on how much power you use. This is called “utility computing” since you draw on computing resources like any other public utility. For example, my company runs a VPN server on EC2 so we have encrypted connections when using wireless Internet connections in coffee shops. That virtual VPN server costs us about the same as a cup of coffee — black coffee, not a latte — every month.
Building a Platform -- What I just described is known as “Infrastructure-as-a-Service” (often abbreviated to IaaS), where you consume raw computing infrastructure over the Internet (or build it yourself internally), but there’s a lot more to the cloud. What if you want to run a custom application and don’t want to bother with things like virtual machines?
To address this need, a service model known as “Platform-as-a-Service” (often abbreviated to PaaS) emerged. Platform-as-a-Service is a strange collection that includes things like over-the-Internet databases, building in features from Google (like Maps) into your application by connecting them to Google’s service, and even running complete applications like blogs or custom Java applications.
Let’s focus on the blog example for a moment. Traditionally, you would run your blog on either a shared host, with limits on the resources you can use, or maybe a dedicated host or virtual private server you have to configure yourself. With Platform-as-a-Service, and a supported blog platform, you completely ignore the capacity problem. Most Platform-as-a-Service runs on Infrastructure-as-a-Service, and the Platform-as-a-Service controller simply grabs the resources it needs to meet your demands. You are totally abstracted from things like processors, memory, and operating systems; you simply run your application on a supported platform which grows and shrinks as needed. Examples of Platform-as-a-Service include Microsoft’s Windows Azure (for running .NET-based applications) and Amazon’s Elastic Beanstalk (which supports Java applications for Apache Tomcat).
Thus you have an elastic application that uses only the resources you need. Of course, since you’re billed based on what you use, you have to be prepared for a serious bill if your site suddenly increases in popularity.
Cloud Software -- What if you want to skip all the low level stuff and just pay to use an application? This is called “Software-as-a-Service” (abbreviated to SaaS) and was around long before Amazon EC2. If you use a webmail service like Gmail, an online calendar such as Yahoo Calendar, or advanced application like Salesforce, those are examples of Software-as-a-Service. You still share resources with other customers, and your pieces are walled off from everyone else, but instead of building anything, you consume a complete application, pay for what you use, and never worry about the raw resources.
But as we’ll see in a moment, just because something is Software-as-a-Service doesn’t mean it’s an example of cloud computing.
Defining the Cloud -- What I’ve just described — Infrastructure-as-a-Service, Platform-as-a-Service, and Software-as-a-Service — are the service models for cloud computing. They are the different major buckets of services you can consume. I also talked about the two main deployment models: a private cloud that you run internally, and the public cloud, like Amazon Web Services and Rackspace. Other deployment models include a hybrid cloud, where you connect your internal resources to an external cloud for extra capacity, and a community cloud, where related groups like government agencies share a dedicated cloud.
While there are many different definitions for cloud computing out there, one of the most accepted comes from the U.S. National Institute for Standards and Technology. NIST breaks its definition of the cloud (PDF link) into three main pieces: essential characteristics, service models, and deployment models.
We’ve covered the service and delivery models of cloud computing, and a few of the essential characteristics (elasticity, measured service, and resource pooling). Two additional characteristics are on-demand self-service (no need for someone to set things up for you manually) and broad network access (otherwise, it’s hard to connect to your cloud).
This is where definitions get a little tricky. Technically speaking, not everything we call “cloud” really is “cloud.” For example, many Software-as-a-Service providers still run on traditional infrastructure and must manually add resources to handle increased demand. Their services lack elasticity. Another example is blog hosting services — most set a fixed number of blogs on a particular server, capping the resources of each, and all without using virtualization. When they do use virtualization, it is still a static virtual machine not managed by a cloud controller. Contrast this with the resource pooling I described earlier.
Just because an application or service is on the Internet doesn’t mean it’s using cloud computing.
Other services, like Dropbox, cross these definitional lines. Dropbox has a Web interface that functions like Software-as-a-Service (since it allows you to access your files, and download older versions of them, for instance), but Dropbox also supports APIs that enable programmers to use it as a Platform-as-a-Service. Finally, when you put a file in your Dropbox folder and it’s mirrored to the cloud, Dropbox is functioning a bit like Infrastructure-as-a-Service. It’s all quite confusing, and as a user, all I care about is that my files magically appear on all my computers.
The Power of the Cloud -- Here is where the real power and magic of cloud computing comes into play. From a bunch of random hardware sitting in a data center to cross-Internet distributed applications, we now have a massive, global, pool of resources we consume on demand, as needed, and pay for like our power bills.
Combine this with broad network access and mobile computing, and the Internet as we’ve known it — email, file transfer, browsing the Web — starts to seem a bit passé, as do our personal computers, much as we may love them. All our files become accessible wherever we are, whenever we want. Our to-do lists and calendars magically sync to any device we want. We manage our blogs from our phones, and never worry about our sites crashing if we’re Fireballed.
And for those of you who run servers? You can tie together all your spare hardware and software into a shared pool and pull out what you need. Or provision your virtual servers in the cloud, manage them from your iPad, and grow and shrink them with the changing tides of Internet traffic. Automatically. Paying for only the computing, memory, and storage capacity you use.
And our Internet applications can connect to and draw on services from nearly anywhere. Run your database on Microsoft Azure, pull your maps from Google, and have a visitor log in using his or her Facebook ID. The Internet starts looking less like a bunch of isolated sites, and more like one big interconnected series of services that can be combined in all sorts of interesting ways.
It’s as if the entire Internet becomes one big resource pool that we can access from any computer or smartphone.
iCloud and the Cloud -- Apple’s MobileMe service currently offers an interesting mix of Software-as-a-Service (email, calendar, galleries, contacts) and Platform-as-a-Service (syncing, iDisk). While I don’t know if MobileMe’s back-end infrastructure really is a cloud platform, it meets most of the characteristics of cloud computing on the surface.
But what about the just-announced iCloud? iCloud appears to be a mixture of Software-as-a-Service, Platform-as-a-Service, and Infrastructure-as-a-Service all rolled up into a whole that will support both Mac OS X and iOS.
The Web interface we now use as MobileMe is clearly Software-as-a-Service, although Apple didn’t say if it would continue with iCloud. There will almost certainly be some Web-based access to aspects of iCloud.
The developer APIs to integrate iCloud capabilities into apps mean iCloud also serves as a platform. This flavor of Platform-as-a-Service is closer to something like the Google APIs than Amazon’s Elastic Beanstalk, but still well within our definition of a cloud Platform-as-a-Service. iCloud enables outside developers to use Apple’s data center as a platform to expand their own applications.
iCloud even treads on the edge of Infrastructure-as-a-Service by providing users with raw storage that’s fully integrated into their mobile and desktop operating systems.
While it’s possible that Apple built all of this without using cloud technologies in their data centers, from the consumer perspective, iCloud certainly meets most, if not all, of our essential cloud characteristics. It’s elastic, uses resource pooling, supports broad network access, and is fully self-serviced. It isn’t exactly metered, relying more on service tiers (where you’ll be able to buy more storage, for instance), but that’s easier for most consumers to deal with anyway (which is why we buy blocks of minutes on our cell phones instead of paying by the call).
iCloud is also an entirely new way of building out our desktop and mobile computing platforms. Thanks to its connections with Mac OS X and iOS, iCloud may turn out to be one of the most significant developments in the history of consumer operating systems and devices. It’s integrated into Apple’s operating systems, tying together all of our disparate endpoints. No more worrying about moving files between computers. No more hassles manually configuring new systems. No more losing all of your family photos when your hard drive crashes. Your computers and mobile devices stop being the center of your digital life, and become replaceable endpoints to a far larger platform. iCloud won’t provide all these features or address all these problems out of the gate, but it’s clearly headed down that path.
All of a sudden my Macs and iOS devices look less like a bunch of independent platforms and more like parts of a larger whole. It’s not magic, but as Arthur C. Clarke said, any sufficiently advanced technology — and cloud computing distinctly qualifies — is indistinguishable from magic.