IS THE CLOUD BROKEN? Is The Cloud Broken?media. ?· IS THE CLOUD BROKEN? AND A LOOK AT HOW ... Madonna…
Post on 11-Jun-2018
Embed Size (px)
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
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.
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-1990s through the 2000s 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.
Its 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
3Volume 1, 2010: Issue 4
When discussing whats broken in first generation cloud architectures, lets 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 cant truly scale vertically because the purchased machine image cant 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.
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. Theres 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. Thats 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 its 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 theres 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 users mind on whether security in the cloud is robust enough.
Finally, theres 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
4 Volume 1, 2010: Issue 4
FIXING WHATS BROKENIts About the Running the Application
Before diving into how second-generation cloud architecture can help fix whats broken, its 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, lets return to one of the fundamental ele-ments to the computing infrastructure: the OS.
Its important to recall that a a basic job of any operating system is to arbitrate which processes get access to the systems 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 generations 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 b