5
Table of Contents 9 Volume 1, 2010: Issue 4 Cloudbook June 2010 9 IS THE CLOUD BROKEN? AND A LOOK AT HOW A SECOND GENERATION CLOUD PROVIDER OFFERS A SOLUTION. By Vince Vasquez

IS THE CLOUD BROKEN? Is The Cloud Broken?media.cloudbook.net/pdf/is-the-cloud-broken.pdf · IS THE CLOUD BROKEN? AND A LOOK AT HOW ... Madonna was on ... was making her “Confessions

Embed Size (px)

Citation preview

Page 1: IS THE CLOUD BROKEN? Is The Cloud Broken?media.cloudbook.net/pdf/is-the-cloud-broken.pdf · IS THE CLOUD BROKEN? AND A LOOK AT HOW ... Madonna was on ... was making her “Confessions

Table

of Co

ntents

Is Th

e Clou

d Bro

ken?

9Volume 1, 2010: Issue 4Cloudbook June 2010 9

IS THE CLOUD BROKEN? AND A LOOK AT HOW A SECOND GENERATION CLOUD PROVIDER OFFERS A SOLUTION. By Vince Vasquez

Page 2: IS THE CLOUD BROKEN? Is The Cloud Broken?media.cloudbook.net/pdf/is-the-cloud-broken.pdf · IS THE CLOUD BROKEN? AND A LOOK AT HOW ... Madonna was on ... was making her “Confessions

1Volume 1, 2010: Issue 4

eam your memory back to the ‘80s (if you can, of course). Madonna was on

top of the charts singing about a “Holiday” and acting

“Like a Virgin.” Meanwhile, many of us geek-nerds were hanging

out in computer basements chatting with our geek-nerd colleagues over the Internet using UNIX talk. Back then, traditional computing architecture was relatively simple (and simply put): server + operating system + application.

Page 3: IS THE CLOUD BROKEN? Is The Cloud Broken?media.cloudbook.net/pdf/is-the-cloud-broken.pdf · IS THE CLOUD BROKEN? AND A LOOK AT HOW ... Madonna was on ... was making her “Confessions

2 Volume 1, 2010: Issue 4

And as Madonna kept delivering the hits through-out the 80s and ‘90s, enterprise data centers kept building out more and more siloed traditional computing environments. Nearly every new proj-ect (from strategic to pet) meant another server + OS + application combo, as the building of ad-ditional raised flooring tried to keep up with the server sprawl. Unfortunately, not only did this archi-tectural approach consume a lot of data center ping, power and pipe, it also meant a lot of wasted compute cycles. Indeed, server after server were being sized to handle infrequent peak loads, leav-ing NOP and Idle as the “applications” consuming the most workload.

From the mid-1990’s through the 2000’s came the age of the virtual enterprise, with the arrival of serv-er consolidation and virtualization. As Madonna was making her “Confessions on a Dance Floor,” IT managers were confessing to better server utiliza-tion by taking advantage of the ability to run mul-tiple App + OS stacks on a single server enabled through a virtualization layer. The trade-off, though, was extra compute resources required to run the virtualization software, plus the inefficiency of run-ning many instances of various operating systems on a single server; however, this seemed a small price to pay for the benefit of not having to report

more 5-10% utilization numbers back to the CIO during budget negotiations.

Next came the emergence of Cloud Computing in the mid-2000s. Madonna was again on the scene scoring big spending “4 minutes” to “Give it 2 Me.” Meanwhile, the initial Cloud providers were spin-ning up virtual machines in around four to ten min-utes, as they were giving it 2 developers plenty of software stack options on a promised elastic, pay- per-use business model.

It’s important to realize, however, that the under-lying architecture chosen by these first-generation cloud providers borrowed heavily from the server consolidation and virtualization era. The major dif-ference was that the pools of compute cores were now being deployed as public-facing services, versus running the previous generation of siloed applications. Unfortunately, the resulting inefficien-cies prevent full realization of the Cloud promise of truly low-cost, high-performing, elastic comput-ing. In response, Joyent has emerged as a second generation provider, rethinking fundamental cloud architecture, and ushering in the era of what they call “Smart Computing.”

Evolution of Computing Architecture

smartmachine

architecture

Appcode

Appcode

Appcode

hardwareresource pool

smart os

smartmachine

architecture

Appcode

Appcode

Appcode

hardwareresource pool

smart os

Page 4: IS THE CLOUD BROKEN? Is The Cloud Broken?media.cloudbook.net/pdf/is-the-cloud-broken.pdf · IS THE CLOUD BROKEN? AND A LOOK AT HOW ... Madonna was on ... was making her “Confessions

3Volume 1, 2010: Issue 4

WHAT’S BROKEN?Elasticity

When discussing what’s broken in first generation cloud architectures, let’s start with elasticity (i.e., the ability to spontaneously and easily scale up re-sources based on real-time demand).

Unfortunately, with a virtual machine architecture, the application can’t truly scale vertically because the purchased machine image can’t access re-sources beyond the subdivided, assigned physical environment. Therefore, even though there may be unused CPU cycles available on a core, the de-veloper can only scale horizontally by purchasing additional machine images to access more com-pute resources.

Provisioning

This leads to the provisioning of new machine im-ages (which one might argue is also a bit broken).

To begin, the developer has to spin up new in-stances manually, or deploy a third party applica-tion to execute the provisioning. Both options add cost and complexity.

A Full OS Instance per Virtual Machine Image

Next, each virtual machine has to carry an instance of the full operating system. This is problematic on a few fronts.

For starters, a typical production OS like Windows or Linux contains a very complex array of functional-ity. There’s code to handle such things as network-ing, security, peripherals, input/output devices and resource scheduling, to go along with the ability to actually run an application.

That adds up to a lot of source code. For exam-ple, a single Linux distribution can contain over 200 million source lines of code. That’s a lot of

code to spin up every time a first-generation cloud virtual machine image is deployed. Most of this code is necessary when the operating system is running a desktop or a server, but it’s overkill for a single application.

The result is that larger machine images beyond what the application requires need to be de-ployed to house each OS. Additional CPU cycles are consumed by these operating systems, de-creasing performance by taking cycles away from the application and again adding costs.

In addition, it takes minutes to boot up a full image of the operating system, leaving developers with another dilemma: submit their customers to frus-trating latencies waiting for new virtual machines to get spun up, or increase costs by over-provision-ing to maintain performance levels to meet unex-pected increases in work loads.

The Need to Manage the Operating Systems

Running a full operating system means the devel-oper needs to manage this portion of their de-ployed stack, adding complexity to the already challenging task of deploying an application.

This also means the operator has to take extra steps to make sure there’s no malicious use of all that extra OS functionality for things like security and networking breaches. This adds complexity for the operator. It also fuels additional questions in the potential user’s mind on whether security in the cloud is robust enough.

Virtualization Overhead

Finally, there’s the cost of running the virtualization infrastructure layer in terms of additional compute cycles, management resources and, if a commer-cial virtualization product is deployed, licensing costs. These added costs get passed along to the developer as increased virtual machine instance costs.

Evolution of Computing Architecture

smartmachine

architecture

Appcode

Appcode

Appcode

hardwareresource pool

smart os

smartmachine

architecture

Appcode

Appcode

Appcode

hardwareresource pool

smart os

Page 5: IS THE CLOUD BROKEN? Is The Cloud Broken?media.cloudbook.net/pdf/is-the-cloud-broken.pdf · IS THE CLOUD BROKEN? AND A LOOK AT HOW ... Madonna was on ... was making her “Confessions

4 Volume 1, 2010: Issue 4

FIXING WHAT’S BROKENIt’s About the Running the Application

Before diving into how second-generation cloud architecture can help fix what’s broken, it’s impor-tant to step back and remember that the primary objective in the cloud is to run an application. All costs and overhead associated with running the underlying infrastructure is a means to an end. Put another way, no CIO would be very happy receiv-ing a large cloud computing bill for only running an operating system in a virtual machine instance.

Modern Languages and Virtual Machines

Not too long ago, developers wrote applications in languages such as Cobol, Fortan, and C. These programs needed to be ported to the underlying OS + server combinations.

Then came virtual machines. Developers could now write in modern languages such as Java, PHP, Ruby and Rails, which in turn were run on virtual machines that were already ported to the under-lying OS + hardware combi-nations. Developers no lon-ger needed to worry about porting their applications. In-stead, they could just devel-op in a platform supported by their cloud provider of choice.

The Operating System Revisited

Next, let’s return to one of the fundamental ele-ments to the computing infrastructure: the OS.

It’s important to recall that a a basic job of any operating system is to arbitrate which processes get access to the system’s resource through the resource and process scheduler.

Smart Computing and the SmartOS

That said, the second generation of Cloud Com-puting provider - Joyent - introduces what they call “Smart Computing.” In their Smart Comput-ing architecture, they deploy a “SmartOS” which effectively replaces the first generation’s use of a virtualization layer. The SmartOS is optimized to run applications, not operating systems.

Many hundreds of virtual machine platforms are ported to the SmartOS. Therefore, each applica-tion running on one of the ported platforms just be-

comes another process that gets managed by the SmartOS.

The scheduler in the SmartOS is hardened and up-dated to handle the management of the underly-ing available resource pool. Now, instead of the hardware being cut up in fixed sizes, as is the case with virtual machine architectures, the SmartOS can allocate more or less of the available resource pool based on the requirements of the applica-tions sharing that pool. This enables true vertical scaling, without requiring manual or third-party code intervention.

The SmartOS delivers a further benefit by eliminat-ing the cost and complexity of running both the virtualization layer and the numerous OSes.

The Joyent SmartDataCenter

Having said this, of course, peo-ple who run applications in the cloud do so partially for the ben-efit of being able to burst across multiple cores if and when us-age spikes arise.

Therefore, Joyent deploys what they call the SmartDataCenter. The SmartDataCenter provides an abstraction layer for the en-tire data center -- including compute, storage, and network resources -- and centrally man-ages these resources.

For example, in a SmartDataCenter, application processes are profiled and deployed on the appro-priate servers depending on resource consump-tion requirements. Whereas the SmartOS might de-ploy more compute resources on a single CPU for vertical scaling, the SmartDataCenter can deploy more server cores for horizontal scaling without in-tervention. In addition, the SmartDataCenter can move an application from one physical resource to another automatically to improve load balanc-ing and resource utilization.

GETTING SMARTClearly, first-generation cloud providers are in vogue, providing a huge leap forward in delivering on the promise of Cloud Computing. However, as is the case wity many first-generation products, there is room for improvement. Second-generation pro-viders like Joyent have entered the game, rethink-ing architecture, and as a result they are improving the overall efficiency of running in the cloud.