Cloud Computing: What UC Berkeley Can Teach You

Last month the UC Berkeley Reliable Adaptive Distributed Systems Laboratory (aka RAD Lab) published Above the Clouds: A Berkeley View of Cloud Computing.” The report is an excellent overview of the move to cloud computing. It identifies some key trends, addresses the top obstacles to cloud use, and makes some excellent points about cloud economics. It also, in my view, understates a few aspects of cloud computing as well, primarily as a result of addressing the topic with an academic detachment. Overall, it’s well worth tracking down and giving a read.

RAD defines cloud computing as having the following three characteristics:.

1. The illusion of infinite computing resources available on demand, thereby eliminating the need for Cloud Computing users to plan far ahead for provisioning. .

2.The elimination of an up-front commitment by Cloud users, thereby allowing companies to start small and increase hardware resources only when there is an increase in their needs. .

3. The ability to pay for use of computing resources on a short-term basis as needed (e.g., processors by the hour and storage by the day) and release them as needed, thereby rewarding conservation by letting machines and storage go when they are no longer useful..

From RAD’s point of view, an underlying requirement for these capabilities to be considered as cloud, they have to be available publicly, i.e., externally. Therefore, by definition, what is often referred to as “internal clouds” is not part of the RAD discussion. This is an interesting perspective on the part of RAD. Certainly a significant part of the vendor community (e.g., IBM et al) are trumpeting the transformation of internal data centers into cloud environments, and therefore RAD is standing apart from that trend. From a definition perspective, it would be easy to dismiss internal clouds due to requirement #1; however, RAD does not identify the lack of infinite resource illusion as the reason to exclude internal clouds from the cloud computing discussion. Instead, it defines external availability as the key condition, thereby excluding internal clouds altogether. I will have more to say about internal clouds in the near future, but I believe the key issues involving them relate more to the characteristics listed above, rather than whether or not any Tom, Dick, or Harry can access them..

RAD goes on to list ten objections (or impediments) to cloud computing: .

1. Availability of Service Use Multiple Cloud Providers .

2. Data Lock-In.

3. Data Confidentiality and Auditability.

4. Data Transfer Bottlenecks .

5.Performance Unpredictability.

6. Scalable Storage .

7. Bugs in Large Distributed Systems .

8. Scaling Quickly .

9. Reputation Fate Sharing .

10.Software Licensing Pay-for-use licenses.

The report also offers ways to mitigate each of the impediments, some of which make sense, and some of them which don’t. For example, impediment #4: data transfer roadblocks refers to the fact that if you have large amounts of data to process, your Internet connection can effectively throttle the speed at which you can upload it and delay starting work on the data. Animation rendering is a good poster child for this; the average animated movie is an ideal candidate for cloud computing as the task can be spread across many machines and the load is transient, since there is a finite amount of time rendering goes on: at some point the movie must be released, ending the need for rendering until the next movie comes down the pike. .

RAD recommends exploring “fedexing” entire disks to the cloud provider to overcome bandwidth limitations. They quote calculations that show that this option is 75 times as fast as using the network. My reaction is that Pixar can probably get special handling for its situation, but that a typical medium-sized IT shop is unlikely to get Amazon’s attention, so the attractiveness of this option will remain theoretical for most users. Overall, their list of impediments is not incorrect; however, they are presented as if they are all of equal weight, whereas some of them will have more impact on cloud adoptions than others. I will discuss the most important impediments in this list later in this post..

RAD then goes on to make three recommendations, and this is where you should pay very, very close attention. They say:.

“Hence, developers would be wise to design their next generation of systems to be deployed into Cloud Computing. In general, the emphasis should be horizontal scalability to hundreds or thousands of virtual machines over the efficiency of the system on a single virtual machine. There are specific implications as well:.

1. Applications Software of the future will likely have a piece that runs on clients and a piece that runs in the Cloud. The cloud piece needs to both scale down rapidly as well as scale up, which is a new requirement for software systems. The client piece needs to be useful when disconnected from the Cloud, which is not the case for many Web 2.0 applications today. Such software also needs a pay-for-use licensing model to match needs of Cloud Computing..

2. Infrastructure Software of the future needs to be cognizant that it is no longer running on bare metal but on virtual machines. Moreover, it needs to have billing built in from the beginning, as it is very difficult to retrofit an accounting system..

3. Hardware Systems of the future need to be designed at the scale of a container (at least a dozen racks) rather than at the scale of a single 1U box or single rack, as that is the minimum level at which it will be purchased. Cost of operation will match performance and cost of purchase in importance in the acquisition decision. Hence, they need to strive for energy proportionality by making it possible to put into low power mode the idle portions of the memory, storage, and networking, which already happens inside a microprocessor today. Hardware should also be designed assuming that the lowest level software will be virtual machines rather than a single native operating system, and it will need to facilitate flash as a new level of the memory hierarchy between DRAM and disk. Finally, we need improvements in bandwidth and costs for both datacenter switches and WAN routers.”.

Overall, they strongly recommend use of cloud computing due to its elasticity and transfer of risk. Elasticity refers to the first point in their description of cloud computing — the ability to scale up and down rapidly under conditions in which the illusion of unlimited capacity (should it be contemplated) is present..

Transfer of risk is a really intriguing concept. Essentially, they are referring to a situation of uncertain or fluctuating demand. For traditional IT shops, this type of situation is risky, posing a Hobson’s Choice: either overprovision capacity to be certain of meeting peak demand (thus probably wasting capital by purchasing unnecessary capacity), or purchase capacity to meet average demand and thereby forego having the processing capacity available to meet user demand greater than average. Essentially, this risk boils down to being uncertain about how much hardware capacity to purchase; in environments with potential for extreme swings in demand, this risk is enormous. By relying on a cloud provider to provide sufficent capacity to absorb whatever user load might occur, an IT organization transfers the risk of capacity planning to the cloud provider. By using a cloud provider that operates on a scale one or two magnitudes greater than any one end user organization, the user can be comforted that, no matter what level of its own demand it puts to the cloud provider, the provider’s large infrastructure can easily manage fluctuations in overall demand..

To sum up, RAD identifies key characteristics of cloud as reflecting an easy-to-get-going, scalable upon demand, no upfront commitment computing environment. Its recommendations reflect systems that are attuned to that infrastructure and operating characteristics. And finally, they identify a number of impediments to cloud computing and recommend ways to mitigate them..

I’d like to address some implications of the report as well as what I view as its — if not shortcomings — its rather too-glib assumptions regarding this new environment..

As to implications, in its first recommendation, RAD suggests that “the emphasis should be horizontal scalability to hundreds or thousands of virtual machines over the efficiency of the system on a single virtual machine.” This sentence carries significant implications for IT organizations. In particular, it suggests that cloud-based applications need to be architected with specific capabilities — easily partionable, able to incorporate additional resources without need for manual intervention, lack of concurrency contention for key resources, and so on. These capabilities map extremely well to the cloud characteristics they identify. The key challenge this poses to IT organizations is that most applications today are not architected this way; most assume a relatively stable load and a fixed topology. In other words, most of the skills in today’s IT shops are not oriented toward the architecture RAD recommends as the basis for cloud-based apps. Probably the nearest most mainstream IT shops come to this kind of application is web-based systems, but these represent only a fraction of the overall application portfolio..

This is not to say that traditionally-architected applications cannot be run in cloud environments, merely to note that to fully leverage the unique characteristics of clouds a different architecture is required. Moreover, the type of applications that clouds enable, along with the suggested architecture, are just the type that could not be countenanced in traditional data centers, operated as they are with assumptions of capacity scarcity..

There are two aspects of the report that minimize issues that will challenges mainstream IT organizations will confront when moving to cloud computing. One of those challenges emanates from outside IT: it is located within the vendor community. The second resides within IT itself and relates to internal cultural issues..

In its second recommendation, RAD advises that “Infrastructure Software of the future needs to have billing built in from the beginning.” In that statement a whole range of issues resides. Infrastructure software, in this formulation, refers to commercial software obtained from third parties, i.e., databases, application servers, and so on. Most IT organizations would tend to look toward current vendors for infrastructure software, given pre-existing relationships, a trained employee base, and a desire to minimize component duplication. However, most software vendors are likely to take a long time to deliver this billing requirement. In particular, most vendor licensing assumes that individual software packages will be tied to a specific piece of hardware, and is licensed on a perpetual basis. There is definitely no pricing model that incorporates the likelihood of the number of operating instances of the package ballooning up and down with charges based upon duration of execution. Oracle has announced support for its products in AWS, but I believe its pricing is consistent with current assumptions and traditional application architecture, i.e., no ballooning or limited-duration pricing. Likewise, IBM has announced AWS support, but pricing (and the pricing basis) is not yet available. .

We can expect that support of the type of pricing RAD recommends will present significant issues for software vendors. They will want to craft pricing supportive of their current licensing schemes and revenue streams. Being reluctant to endanger current licensing means that vendors will probably take a long time to actually deliver the pricing structure RAD recommends. That probably won’t be much of a problem for applications designed consistently with traditional architectural assumptions, but will present real challenges for IT organizations that seek to design applications consistent with RAD’s recommendations. Consequently, the recommendation that infrastructure software needs to have billing built in glosses over real challenges IT organizations will face as they attempt to incorporate cloud infrastructures. For this reason, I expect that open source will get a boost from the move to cloud software, since it can be more easily implemented in a horizontal scaling environment..

The second challenge that is glossed-over in the report resides within IT itself. In its list of adoption impediments, the report identifies “Data Confidentiality and Auditability.” This is a commonly-cited issue, and the report recommends some ways to address it. However, too often this issue is raised as a stalking horse for a whole range of objections relating to risk that are brought up as reasons to avoid cloud computing. I have often heard these kinds of issues voiced reflexively, trotted out as rationales for sticking with the current mode of operation. While RAD has identified logical ways to address the issues, it fails to recognize that this battle is fought emotionally, not logically. Many IT organizations will hang back from cloud computing, citing these risks, but really preferring to avoid embracing something new that seems challenging. In my experience, culture always triumphs logic, and poses an enormous barrier to change. If you’re advocating cloud computing, prepare to confront a concern with risk that will be steady and stubborn..

With its report, RAD has indicated that academic institutions are paying attention to technology trends. The work RAD did for its report is excellent and valuable and should be required reading for anyone considering the potential of cloud computing. .

Bernard Golden is CEO of consulting firm HyperStratus, which specializes in virtualization, cloud computing and related issues. He is also the author of “Virtualization for Dummies,” the best-selling book on virtualization to date.