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 Exchange in the Clouds

(If you squint your eyes just right it looks like a bull!) The NYSE, in conjunction with VMware and EMC, announced a Financial Services Cloud offering. This is a really good example of what IBM introduced generically some time ago — an industry specific cloud. What's significant about this announcement is the participation of an industry segment leader (NYSE) and that it's built on VMware/VCloud, not what IBM would have used, not built on Microsoft Azure (although in some ways it is probably the more suitable platform). As I noted in the last issue with respect to Hyper-V, VMware is the putative winner in data center virtualization. Given that the enterprise data center is getting more enterprise attention than the public cloud, it stands to reason that VMware is going to have significant influence in what gets build in public clouds (perhaps multi-tenant clouds would be a better term), and that is certainly the case today. Many other vendors want to ignore this because it may not speak well to their future success (e.g. as a security provider) but that won't make VMware's success and influence go away.

"Ticket to Ride"

The Butcher, Baker and Candlestick-Maker Clouds? In the most recent IBM's quarterly Cloud updates for the analyst community, a lot of the discussion was focused on the idea of an industry specific Cloud. IBM provided substance and the focus is quite different from an "Amazon" discussion. The idea is to create synergies with real monetary return when the Cloud tenants share an industry focus: (1) Basic workflow synergies: industries share common subsystems and use common middleware. Consider the advantages if all of this already exists as a service in a Cloud platform. (2) Application structure synergies: For some time IBM has been working to standardize application templates. For all commercial applications there are only a few tens of general templates required, and within a particular industry, only a subset of those. IBM believes there is great value in herding customers and application suppliers toward the use of these standard forms. An industry specific Cloud will include specific support for these templates (application componentization, industry specific middle ware, industry specific SaaS elements). This in turn would reduce the cost and complexity of the applications and their use, and increase the opportunities for cost-effective integration. (3) Security and Compliance: Security and compliance are usually given as inhibitors to the use of Cloud solutions, but IBM argues (quite correctly) they can be solution accelerators. An industry specific Cloud would (by definition) encompass applications and services that were all subject to the same externally imposed security and compliance requirements. IBM will provide a technical and management architecture that is designed to meet these requirements (IBM has extensive experience in this because of all the architecture and development services performed for their customers). Just as Terremark argues correctly that they win Government business because of the security services they imbed in their Cloud offering, IBM is right in seeing this as a real plus rather than a minimized liability. All in all this is a very interesting offering especially building on IBM's business franchise. It wouldn't make much sense for Amazon to offer industry-specific Clouds but neither would it make much sense for IBM to offer an Amazon like service since they choose to focus on higher contribution components.

Cloud Services as an Appliance

We had a chance to catch up with Dan Decasper, an old friend from many lives back and now founder and CEO of Cirtas Systems, a company building appliances for Cloud Storage. It's an interesting idea, especially while Cloud Storage is very much in flux, as it is today. The cloud storage offerings all differ in the precise functions offered, in exactly how they operate, in the pricing, and in what it takes to connect optimally across the Internet to the service. Cirtas sells an appliance — the Cirtas Bluejet controller — that looks like a local storage while doing what it takes to interface to one or more cloud storage services, masking the specifics, and providing a framework for deciding which service to use for specific use cases. Bluejet has a significant amount of real storage built in that is used to cache the most frequently accessed data. Without local caching the bandwidth limitations of a Cloud Storage service severely constrain the reasonable uses. We talked with Dan a little about the potential use of a Bluejet controller in conjunction with an Acopia device (now the F5 ARX file virtualization appliances). The ARX presents a virtual storage system and then automatically tiers and balances the use of storage in back. A Bluejet controller could be added as a new storage class at which point the ARX could automatically (based on policy and use) decide what should be moved to the Cloud and automatically move it there. With this combination Cloud storage becomes just another storage option that can be transparent used based on policy but without much thought, leaving the ARX to make the policy decision and the Bluejet to optimize the Cloud Storage access. All this certainly simplifies getting going with Cloud Storage.

Appliances as a Cloud Service

Whereas Cirtas presents a cloud service as an appliance; Aryaka flips it around and provides what has been an appliance — WAN acceleration — as a cloud service. Aryaka is the brainchild of Ajit Gupta who we've known since he headed Speedera, the Akamai competitor that Akamai ultimately acquired. Aryaka differs from many cloud services in having a CDN like architecture with a set of POPs that are relatively near (in network latency specifically) the end points of the desired accelerated WAN link. This network proximity to the endpoints is central to the Aryaka design in that it permits much more of the WAN acceleration functions to be implemented at the POP (and shared) than as appliances at the end point (there are some cases where you still need end-point processing but in most cases the POP suffices). So with Aryaka, to WAN optimize a connection between two end points you just subscribe to the service (not cheap but cheaper than buying appliances). It's a very interesting blend of these two important infrastructure technologies. As always, the proof of the pudding is in the eating, but this one looks pretty tasty.

The Sandy Bridge to PC Hypervisors

Having a "bare metal" hypervisor on a PC is the basis for the optimal "virtual desktop" solution for many use cases because different application sets can be isolated from one another (e.g., business and personal) and the system image maintenance can be done from a Cloud based service, while at the same time application performance can take nearly full advantage of the client PC power. For client hypervisors to be broadly used they have to come pre-installed on OEM PC's with the "normal" software load constructed as a virtual machine on top of that (few customers will be up to the process of "inserting" a bare metal hypervisor under an existing "bare metal" software load. Intel's Sandy Bridge processors will make client hypervisors much simpler simply because more and more of the critical hardware definition (what the hypervisor needs to support) will be defined by the Intel CPU, greatly diminishing the combinatorial variations that might have existed on a PC or laptop in the past. So will 2011 be the year of the bare metal hypervisor finally?

Service-Oriented Is a Big Deal

VMware's vCloud Director (née Project Redwood) represents a really important step in utility computing because it enables the customer (the SP's that VMware introduced with, but more importantly enterprises converting their data centers to "private" clouds) to create service-oriented solutions "out of the box" rather than having to piece them together with a set of different products. There is no doubt in my mind that service-oriented IT — where the customer drives the system with minimal human intervention — is an important endpoint for most enterprises. To me it's a question of which enterprises get to SoIT in what timeframe, not whether it's going to happen. Ignoring that important timing question for a moment, consider what happens in a service-driven system (where the fast majority of "IT" requests are satisfied by automation) the business can deploy a new instance of an application by pushing a button assuming that enough aggregate resources exist and the business unit has budget. The result of all of this is that IT becomes a lot like Safeway — there is no way either can predict what a customer will ask for next and it's important that essentially all reasonable requests are met, while at the same time maintaining efficient and cost-effective operations. Accomplishing this demands that the infrastructure in turn be managed by automation — not by humans. The "service" definition needs to include all the salient details required to adjust the entire infrastructure to accept the new load. People don't disappear but rather than being "at the controls" they become the overseers, responsible for finding out where assumptions don't work and making things better over time. I've believed for many years that finding a graceful way of getting the humans out of the minute-to-minute operation of the (say) network would be an important and necessary step if the network quality of service was to continue to improve. Service-directed platforms now become a driving force to make these important changes actually happen.

vCloud versus Azure

One of the enduring back stories in virtualization is the role of Microsoft. Every time we ask VMware customers if they have counted out Microsoft the answer is "not yet" because these customers all have strategic relationships with Microsoft and most of the applications and services virtualized to date are based on Microsoft technology. Every quarter Microsoft reports gaining a larger hypervisor share, and yet from a VMware perspective, aren't vCloud Director and vSphere yet one more demonstration of how far VMware is ahead? Can we finally call the question from these initial returns and declare VMware the likely victor? Not really, because VMware and Microsoft are really running for different offices. As noted earlier in my TechEd notes, Microsoft's overarching goal is to convert their software offerings into continuously evolving services, delivered optionally locally or from the Cloud (to move beyond the "release" and "upgrade" model today). Microsoft has a more detailed understanding of the complete lifecycle costs of their customers than does VMware which should not be surprising given Microsoft's product breadth and their long standing study of infrastructure costs and benefits. And from that perspective, believes that eliminating the customer costs for the upgrade and maintenance of software "products" is the key driver they need to respond to, assuming that customers are basically driven by cost minimization (which of course is the primary value proposition of virtualization and the Cloud). VMware has clear leadership building utility computing but ones that are built on conventional software release and install models (it's vSphere 4.1 now). When you get an Azure Appliance you get your own patch of continuously evolving and remotely maintained Cloud, presumably with very different customer economics if you add up all the right bits. Which is the right strategy, assuming that each company can succeed in fleshing out its vision? Ultimately customers will vote with their budgets - it's all about money, presuming the products can be built. Time will tell.

Google Wave

The announcement at Google I/O that made the biggest waves was Wave — a provocatively interesting collaboration tool. Wave consists of a Cloud component — the distributed infrastructure that enables a worldwide set of collaborators to share a structured document (the "Wave") and a client component that actually provides the collaboration tool. It's really important to understand that Wave is not a demonstration why the Cloud obviates the need for a PC. The Wave client is implemented as a "browser" application (part of the Windows/HTML5  debate discussed briefly in the last issue). Wave wouldn't be interesting without the part that runs on your laptop. The most interesting criticism of Wave has come from Ray Ozzie. His comments at the Churchill Club were very thoughtful — if anyone appreciates a clever collaboration application it's Ray since he's been building them since college. His point is for most purposes Wave is overkill and much more complex than needed, comparing Wave to Live Mesh and its precursors Groove and Lotus Notes. We run our business on Groove, and Ray is right — for 99% of what we do Groove is sufficient.  In Live Mesh, Ray has pared down the complexity of Groove enormously because it assumes that the heavy lifting is done by Cloud services (permitting the client footprint to be smaller). To implement Microsoft's desktop/phone/Cloud integrated vision Live Mesh is much more suitable than Wave, no doubt. And there is every reason to believe that the Cloud part of Wave could be implemented in Azure and the client component in Windows far easier than in HTML5. This does not distract from the fact that Wave is one of the best examples of a "killer" Cloud app — something that will deliver real value (Ozzie's question is the breadth of the use cases compared to those that Groove or Live Mesh enable) and that absolutely could not have been developed without the integrating Cloud collaboration services.

Cloud Wisdom

The Structure 09 panel of successful Cloud practitioners (all the right places and people) had some real insight. Last year the key takeaway was scalability — if you didn't know how you were going to scale it would certainly kill you if you started to succeed. The wisdom this year was at a higher level, and the first part might be summarized by (a) think at the system level, (b) think probabilistically (bad things happen rarely but frequency with large numbers) and (c) it's really useful to own your own stack and be able to make everything work well together (this all speaks well to the Cisco UCS value proposition but that's a longer story). The second part was that humans are still the key to effective solutions and the ultimate cause of most problems (that was the Google perspective after 10 years and maniacal focus on tools and automation!). The broader wisdom at the meeting was that it really is mostly about virtualization (as a key enabler of pre-existing concepts) and utility computing, and it all makes sense if we stop elevating "Cloud" to something new and magical (as we here at IRG have concluded as well).