Peter Christy

Why Clouds Exist

At times it can be hard to understand what part of the Cloud discussion has substance and what is just marketing fluff. What I want to do here is argue that over the last ten years there as been a "perfect storm" of events that collectively led to today's Cloud world. Clouds are not just yesterday's time sharing or ASP offerings with fresh marketing lipstick. Here's the story.

Consider all that has happened over the period time since the Dot Com bust:

• The Intel architecture "won."  If you were planning a Dot Com venture your funders would probably tell you to use an Oracle database on Sun Solaris. In 2000, many businesses had strategic investments in the IBM Power Architecture (or HP's proprietary architectures). Today there is widespread agreement that Intel's X86 is good enough. Intel won the microprocessor battle. Without that architecture convergence there would be no Cloud.
• The network got a lot better. Broadband access wasn't common ten years ago. It is now. Without modern connectivity and bandwidth there would be no Cloud.
• Wireless networks expanded. Wireless build-out during the period was remarkable on a global basis bringing developing areas immediately into the networked world, bypassing entirely the wired phase.
• Mobile devices became powerful and smart. With Apple's iPhone deal with AT&T, mobile applications escaped the control of the mobile carriers. The evolution in wireless and mobile devices (and the rapid rise of consumerism -- employee chosen devices) has really changed the enterprise application and design model. This transition is an ideal time to also transition the front-end parts of the application to a Cloud implementation.
• We consolidated server applications into data centers. During the Dot Com boom, businesses spent profligately for IT, fearing that otherwise they would be "Amazoned." When the bust came there was broad retrenchment in IT spending (it's a cost center, remember). One of the easiest ways to reduce IT cost is to consolidate diverse applications into data centers where the administration and support can be local and shared. This cost-driven consolidation was an important precursor to today's Cloud world.
• Google demonstrated the promise of very large scale commodity computing. Ten years ago if you suggested building "mission critical" applications on anything other than "enterprise class" servers and storage you would be laughed out of the room. Google changed the game entirely. They showed that the most powerful systems in the world could be built from high-volume, commodity parts, and operated with high availability at remarkably low cost. In part the drive to the Cloud is motivated by the radically improved cost structure clearly visible downstream.
• Intel adopted multicore microprocessor design.  For years Intel converted semiconductor design and process improvements (the train under "Moore's Law") into faster CPU's by making the CPU's more and more complex.  In the end complexity yields diminishing returns. Early in the decade progress looked threatened: new processors got the same task done more quickly, but required more energy in the process. Finally Intel followed AMD and adopted a multicore strategy in which technology improvements are used to put more independent processors on the chip (more "cores") rather than to build more complex processors. It was a risky decision. It wasn't clear how many cores a desktop PC could use productively and the same problem existed in the data center where Windows servers were commonly built to each run on an separate server. The adoption of multicore designs enables a rapid increase the power of a data center of a given size and with a given power budget.
• VMware created commercial quality X86 virtualization and server consolidation occurred. Virtualization abstracts a workload from the specific details of the hardware on which it runs and enabled the shared use of a virtualized server by many X86 workloads with no requirement that they all ran the same "stack."

Virtualization is the magic lubrication that brings it all together: we consolidated applications into data centers; the victory of the X86 architecture and virtualization enabled running many disparate workloads on a shared server; multicore enabled an uptick in performance and power efficency improvements; Google proved that large scale data centers could be built from commodity technology and operated with amazing economics. The rapid evolution on mobile access and devices are transforming the requirements for enterprise applications providing a high-value motivation to change application front end architecture, just at the right time to leverage Cloud implementations.

There is hype and fluff in the Cloud discussion but underneath that there is a remarkable confluence of independent technology waves. In this case the substance is far greater than the hype.

The Cloud Crashes

Just when things were looking so good Amazon suffered a major outage in its Virginia data center. The cause was simple and classic: during a network upgrade an admin fat-fingered a configuration and took the network down. Then the real problem began and in many ways it was like the problem that brought Skype down a couple of times: software design. The critical elements of AWS are all designed to deal with failure and elasticity, but didn't deal gracefully with the shock of a lot of things failing at once. In fact the programmed remediation strategy under these conditions created more load, and made things worse. The AWS team had to take over operations almost manually, and carefully breathe life back in the system over a painfully prolonged period of time. Is this an indictment of the whole idea of Cloud computing: surely not. Crap happens and the worst kind of crap is always what you forget to think about (Cheney's infamous "unknown unknowns"). Over time the AWS design will change less rapidly as more is added and things like this will happen less often. But it was probably a good call to action to the system designers to go back and carefully consider their assumptions in other areas (now that it's a "known unknown:)") .

Juniper Stratus Becomes Concrete

With a great deal of hoopla Juniper introduced QFabric, a quite revolutionary data center networking offering that they have been alluding to for some time as Project Stratus. Although Juniper doesn't choose to think of it this way, there are clear parallels between QFabric and OpenFlow. In both cases all the decision making is done at the edge of the network (the entry and exit ports) and the control of the network is unified. In the case of QFabric, Juniper has introduced an element called a Node in the form of a top–of–rack switch. In QF 2011 a data center network consists of <100 of these switches that act in concert in a unified way (in the OpenFlow analogy), the OpenFlow controller has been implemented with elements in each of the edge T–o–R switches. There is a second element called the Director that is an X86 based appliance that serves both to help coordinate the activity of the nodes (although dynamically they don't require the Director on most actions) as well as presenting a unified management and control abstraction of the network (not unlike that management appliance in a Cisco UCS or VBlock system). The final element is the fabric proper. In this kind of architecture the interior of the network is basically a data backplane interconnecting the edge switches, and Juniper has built exactly that – a carefully designed and modularized physical network. The Fabric has three important properties: (1) cost and power requirements scale linearly with the number of edge ports in the network (conventional data center network interiors scale exponentially and fail at large scale); (2) the mesh provides feedback so that the entry nodes quickly learn of congestion at an exit node, and can use that feedback to assure that the Fabric proper will never have to drop traffic; (3) the Fabric is fully non–blocking meaning that the only time congestion will occur is if the target exit port is congested. QF is much less vendor–neutral that legacy network elements that can be intermixed. The Nodes must be connected to the Fabric although QF can grow within a heterogeneous network. So using QF is a pretty big decision. However what it offers is exciting enough that it's hard to imagine that it won't make some waves in enterprise and SP data center networking.

Cisco — Democratizing Strategy

The Cisco Live meeting in Las Vegas continued the explosion of new products that we've seen all of 2010. Over the last few years Chambers restructured planning and decision making to involve more people and attack more strategic areas than was possible with a traditional top down / command and control structure, and the impact can be seen in new products across a remarkable spectrum ranging from a new consumer brand (Valet), to innovative collaboration offerings (Quad and Pulse), advances in video, telephone pads (Cius) and of course a flood of network technology advances (e.g., Data Center 3.0). The amount of creative energy released by Cisco's innovative organizational structure is amazing; what remains to be seen is whether it all adds up to a coherent product offering or whether Cisco starts behaving more like a conglomerate of largely independent businesses (and whether that is in Cisco's best interest). Only time will tell! pchristy@irg-intl.com

Huge Data Centers

One of the speakers at the TechEd Analyst Summit was Dileep Blandankar, the Chief Hardware Architect of Microsoft's large web properties, and as it turns out, an old friend from our mutual DEC days and his long stint at Intel. Like Google, Microsoft has paid a lot of attention to the building of huge data centers. Like Google (and unlike Facebook apparently) Microsoft has used a container approach. The data center is constructed from a set of container-sized modules (literally shipping containers). The containers are fitted out and tested at a factory and then shipped to the data center where they are positioned and power, cooling water and the network plugged in. Whereas Google has increasingly prescriptive about the design, Microsoft chooses to push more of the engineering work down on the supplier (companies like HP or Dell for example). Like Google, Microsoft has a very informed view of what the component technology should be (both emphasize power efficient servers for example with relatively low power CPU's). Microsoft gives the vendor a spec that has key parameters such as the total power budget and how they will measure performance and challenges the vendor to optimize that while solving all the attendant design issues like cooling. Microsoft showed off their forward looking design which is a smaller module and (more importantly) designed to operate with ambient air cooling (without refrigeration) when possible. Toward this goal the module incorporates what I grew up calling a "swamp cooler" — the kind of evaporative cooler often used in desert locations for economical cooling of homes based on the temperature drop achieve by the evaporation of water. The unit on the show floor had a garden hose (literally) that got a water supply somewhere up on the ceiling of the exhibit floor. I asked Dileep if dust was a problem and he said in general not because they can measure the pressure drop across the filters and require service as needed. He said a bigger environmental problem (for example) was sulfur particulates that turned to sulfuric acid when exposed to water — spraying servers with sulfuric acid is still a very bad idea J.

Data Center Networking

Boy, is this an interesting area for so many reasons? The point we would make here is that it's rife for change, without question. An easy way to see the problem is to realize that there can be hundreds of thousands of endpoints in a virtualized data center (many VM's per core, many cores per CPU, many CPU's per blade, many blades per rack, many racks) and that only a few years ago that number of end points could only be found across a significant piece of WAN geography. The network technologies developed for those circumstances are far from ideal for a large data center (for example, why would you ever run traditional routing within a data center as a way of connecting the end points?). One example of an alternative architecture that people are talking about is Open Flow, an academically centered effort. In this model, grossly simplified, the switches within a data center are operated much like an ATM network where particular flows are precompiled into the switch fabric so the switch just does a fast look up (and abide whatever QoS or bandwidth allocation that has been defined). The "routing" is decoupled from the switches and done (in most cases) on the virtual machine fabric with the data center as standard software. The good news if you start the software from scratch you can make it do whatever you want (e.g., deal with multi-tenant delegated management requirements). The bad news if you start from scratch is that you need to get the software really solid — a distributed routing design is pretty robust and only fails locally by and large. These kinds of architectures could take the whole data center down with a bug in the software. To me the interesting question is not where these are important ideas but rather how we might get from here to there and evolve from legacy solutions. 

Flashes into the Google Kimono

Google is very cryptic about everything (excessively if you ask us) creating an environment not unlike celebrity watching where a table napkin used by Julia Roberts would be a revered souvenir.   There have been a couple of Google disclosures in the last few months that are really interesting. First, in April, Google held a meeting to tell IT leaders about their power and carbon practices. Google has achieved amazing power utilization efficiency (the percentage of power that actually goes to running the IT) and continues to improve with fascinating innovation. One source of power inefficiency is battery backup, since many data center designs create battery voltage and then reconvert to data center voltage. The Google design puts a little backup battery on each server as a smart (from a systems point of view) but intuitively unexpected solution. Google authored a book (The Data Center as a Computer) that by their direction is available as a free PDF for download. It provides more insights into the design and operation of large data centers. If you want one of Larry Page's napkins you'll have to look on eBay.

Cisco Data Center Competitors

It's interesting times in the data center. Cisco is brewing "California" -- a data center offering that is rumored to include servers, and not surprisingly the competitors are showing signs of friskiness as well ("the best defense is a good offense!"). First HP held a somewhat cryptic introduction of ProCurve partners. Grotesquely oversimplified, HP believes they can build on their large server business and provide switches that are price competitive and integrate well with HP servers. Further, HP believes that because they are a minority vendor (the #2 market share leader but with a miniscule share compared to Cisco) they have to do better at compatibility and partnership (that part must be true) but by meeting those obligations they produce a product with clear TCO advantages over Cisco (the more intriguing claim). Following soon thereafter Juniper held its Analyst Meeting featuring the new team, and as part of that previewed tiny bits of what they call Project Stratus being done in cooperation (of some form) with IBM. Juniper argues they can build switches that are as fast as Cisco (because of their very large system SP business), and at the root of Stratus is a large and flat switch, probably somewhat like what Google is building internally (pure speculation) and maybe like what Andy Bechtolsheim did at Sun (the new Juniper advanced technology leader, David Yen, comes from a long career at Sun). Like HP, Juniper says that it will partner better than Cisco and that will bring TCO value to their customers. They also believe that their cleaner JUNOS software base (one O/S shared by all products; quarterly releases) gives them advantage, specifically the ability to manage the data center fabric as if it were one big switch, again with TCO advantages for the customer. One key argument from both HP and Juniper is that Cisco's complexity and inconclusive progress in network management yields a cost-of-ownership liability competitors can exploit, especially in the "more for less" recessionary time. Cisco's big California shoe is of course yet to drop (although it is starting to block the sun J ).