A funny thing happened on the way to the clouds, though. The following year, incumbent vendors started preaching private clouds, preying on fears of lost control and invaded privacy. Change-resistant IT executives listened to them, and soon after, hybrid clouds were a hot topic.

I’ve no idea what a hybrid cloud is. I can’t go and buy one, or subscribe to one. I can, however, have an application that relies on hardware I own and hardware I rent. I think that’s what they mean. To me, hybrid clouds are a gateway drug to the adoption of public computing—as economies of scale and skill take over, companies will be drawn inexorably into a more on-demand world.

With much of what passes for clouds, I call shenanigans. The co-opting of cloud computing by organizations that don’t want change ignores the promise of cloud computing: the end of the IT monopoly. No surprise, then, that the monopolists are resisting.

In DC a few weeks ago, I joked that cloud computing was IT socialism. Nobody laughed. Inside the beltway, it seems, socialism is a dirty word. But the statement rings true: cloud computing is computing for the 99 percent, and the 1 percent that controls technology today is resisting change. IT conservatives worry about retaining control, when instead they should worry about delivering competitive IT services.

The ultimate purpose of clouds, in the clouds-as-utility model, is to abstract a layer of complexity away. It’s the same as payroll services, or the electrical system: immensely complex, but the business has a simple interface to them. The one percent forgets this at their peril.

That doesn’t mean a company can’t be cognizant of those services. I need to understand payroll tax, or home wiring, now that we have ADP or the utility grid. Clouds are about managing and quantifying complexity, abstracting it through simple interfaces. James Urquhart, who got me thinking about this a few months ago, is right—complexity abounds. It does so at a higher layer of abstraction: data centers instead of machines, services instead of ports, and applications instead of subroutines.

Look at it another way. Physics is applied math. Chemistry is applied physics. Biology is applied chemistry. By the time you get up the scientific stack to biology, systems are hopelessly complex, and we have to understand them by observing emerging behaviors and working with patterns. Down at the math level, we can work with the numbers themselves.

At the lower, simpler levels we use deduction, causality, and the burden of proof. At the higher, more complex levels we use induction, correlation, and the strength of probability. This is true in the sciences; it’s also true for complex computing systems. This may be why many of the best IT operators I know are biologists.

What clouds do is allow us to transition from device-level thinking to system-level thinking. Just as biologists, ecologists, and anthropologists work with observation and make up the “wet” sciences that aren’t precise, so cloud architects are doing “chaotic IT.”

This chaos has its rewards. We get a lot more emergent complexity and interestingness from biology than math, at least from a practical, hands-on perspective.

Now I’m really going to wax rhapsodic and philosophical. Gottfried Leibniz spent a lot of time trying to figure out what the best of all possible worlds was. He concluded that it’s the one of plentitude, where the fewest starting conditions give us the most outcomes. In his words, the best world would “actualize every genuine possibility.”

I suspect Leibniz would have considered today’s connected, abstracted, service-oriented Internet a better world than yesterday’s islands of client-server and mainframe computing. Biology, and cloud computing, are complex. They’re messy. And according to Leibniz, they’re also better, because they allow more possibilities.

It’s interesting to note that Leibniz also used this to argue that the world needs to have evil in it, because this is a “better” world as it has more possibilities. So the next time your cloud app dies a horrible, complex death, remember that Leibniz says it’s for the best.

He wasn’t able to make the Strata conference earlier this year due to storms in New York, so he spent his time writing an extensively researched piece on e-discovery, big data, and the law. It’s been published in the National Law Journal. We’re distributing it here with permission from the April 11, 2011 edition of the National Law Journal, but unlike other content available from Bitcurrent, further duplication without permission is prohibited. If you’d like information on using this article, contact 877-257-3382 or reprints@alm.com or visit www.almeprints.com.

Nolan will be joining David Snead at this year’s Interop conference in Las Vegas to tackle the thorny subject of cloud computing SLAs and terms of service on May 12.

In the end, nobody wants to see the sausage being made. Recent announcements by folks like VMWare, public provider acquisitions of PaaS products, competing private stacks like Openstack and Cloud.com, and private cloud tools that run higher up the stack remind us of one thing above all else: herding your boxen is a distraction from the business of building software and deploying applications.

I tried to argue this point at Cloud Connect, in a presentation entitled The Move to Turnkey Computing. Here it is on Slideshare, as a PDF with speakers’ notes.

This is dense stuff; we’re distributing it under a Creative Commons license, and we ask that you attribute us when you re-use it. In addition to data about cloud performance from almost every country and service provider, the report also shows which clouds perform best from which regions.

Some quick takeaways:

• Regional effects matter tremendously, and the difference between countries can be significant.
• ƒDirecting a regional client to the correct regionalized zone for a cloud provider does improve performance.
• The average time to complete an HTTP request and receive a response, worldwide, was 426.4 milliseconds. The average availability worldwide was 97.69%.
• ƒWhile most cloud providers had roughly similar average availability, a closer analysis of percentiles shows that the worst-served visitors fared very differently. This underscores the importance of doing proper analysis on performance data.
• End user information is an important complement to synthetic testing. While the results aren’t as consistent, they provide insight into the conditions of far-flung end users across a broad spectrum of networks and countries.
• ƒGiven variance in cloud performance and availability by region and by day, it makes sense for serious cloud users to hedge their bets, and find ways to arbitrate cost and service quality across providers.

As with other studies we’ve published, this one was sponsored by Cedexis, who also gave us access to their raw data. They didn’t have any editorial input into the content; as with other firms with whom we’ve published research—Citrix, Coradiant, and Neustar Webmetrics—Cedexis is a proponent of sharing data that advances the understanding of emerging technologies. We’re big fans of this approach to marketing, and thank them for their support.

SIDENOTE: When we first published this study on March 3, 2011, we let Google know that we’d calculated a significantly lower percentage availability for Google App Engine than other cloud providers. We let the folks at Google know, and the App Engine team looked into the situation. They helped us investigate the problem, which initially seemed like a billing problem. The team worked closely with Bitcurrent and Cedexis, and we’ve updated our study with a detailed analysis of that discussion. The short version: there’s a big difference between what App Engine sees as availability, and what end users see; and that experience is significantly worse for certain countries.

While the data is instructive, the sample size for some responses is not statistically significant, and warrants further research. Nevertheless, our findings suggest that for vendors, tailoring their benefits and concerns to their audiences may be helpful; and for IT buyers, understanding how their top issues compare to their peers in other industries may offer a more nuanced perspective on the move to cloud.

The questions are designed to let attendees compare offerings—while they’re not strictly apples-to-apples, at least they bound the discussion.

Public clouds (here’s the slide deck)

• Main elements of your service: What are your main service offerings (i.e. the top 3 technologies, services, or APIs your subscribers use?)
• Pricing: How are those services priced? (i.e. what is the unit of measure, what do you charge, do you have an elastic pricing model based on usage?)
• Security and certifications: What security or similar certifications do you have? (i.e. FIPS, SAS-70, PCI)
• Data centers and zones: Where are your data centers or availability zones (i.e. Europe, US, China)
• Customers: What are three companies building things on your platform? (One slide per customer profile is OK here)
• SLAs and compensation: What SLAs do you offer (i.e. data recoverability, uptime, latency?) and how do you compensate those (i.e. service refund)?
• Architecture: How is the system architected (i.e. what underlying stacks do you rely on?) A couple of diagrams are OK here.
• Portability: How can people move things onto and off of your platform (i.e. are there APIs? Portable machine image formats? Private stacks they can run?)

Private clouds (here’s the slide deck)

• Service library: What cloud services does the stack offer? (i.e. virtual machines, code execution, large-object storage, message queueing.)
• OS, language, and API support: What operating systems, languages, or APIs can the user employ? (i.e. Python, any OS, etc.)
• On what stack is it based? (VMWare, Xen, KVM, etc.)
• Requirements & limitations: What are the underlying hardware requirements or constraints? (i.e. pairs of machines; Intel quad-core processors; sub-10-ms latency between nodes)
• Portability: Is the stack portable to other stacks, or to public cloud provider environments? (i.e. can you move an AMI to Amazon?)
• What standards or de-facto standards does it support?
• How is it priced? (i.e. by core, by user, open source with a support contract, etc.)
• Included tools: What management tools do you offer? (a screenshot or two is fine here)
• Capacity, performance, availability: What are the capacity, performance, and availability constraints? (i.e. scales to a maximum of 20 nodes)
• Global distribution: Can it work in a distributed, multi-city mode with additional redundancy?

Putting vendors on stage to talk about their wares can be a disaster, and ECS is a paid event with a focus on content. To be sure this works, we’re doing two things: First, we’re limiting each presenter to ten minutes and the slides we’re providing them. And second, if we don’t get the slides from a provider at least 2 weeks in advance, we’re either going to replace them (as you can imagine, there are plenty of folks who didn’t make our list of 12 providers that would like the visibility) or present the content ourselves (based on our research).

Hopefully this will keep the signal-to-noise ratio high. Anyway, it’s the first time we’re trying something like this, and it’ll be interesting to see what happens. We’ll consolidate the responses and publish them as a research paper once we get everyone’s answers.

CloudOps will be providing pizza and snacks. Attendance is free, but limited.

You can sign up using Eventbrite.

A.

eBay 2B page views/day 6000 application servers 9PB of data.

Cloud bursting: control costs and increase efficiency.

2000 servers provisioned at a fixed cost but only 300-1600 used at any given point of the day. A lot of “whitespace” or excess capacity.

How can we remove the peaks? Time shifting the workload helps a little bit, bringing us down to about 800 servers required.

Financial model structure: take the hourly demand in average TPS and max TPS per CU to get the hourly computing units required (CUs). Take the number of CUs in the internal cloud and the hourly cost, plus the hourly CUs in the extermal cloud, you get total hourly cost.

Cost benefit analysis shows that an external cloud at 4x the cost of the internal cloud still yields economic benefits in dealing with the spikes.

If the cost of the cloud is half of the internal cloud then it makes no sense to run anything internally.

In between is the interesting area where we need to make hard choices.

Cloud bursting is very interesting to eBay, allowing us to cut costs by at least 25%.

Lower the investment in infrastructure to focus on the business intelligence.

Scale, automation, resource management, permission and policy management are the key challenges.

The hypervisor is NOT the Cloud OS, rather an essential component.

Large enterprises have shown that commodity hardware can lower costs. Design the application for commodity hardware and you can dramatically lower costs.

Network: topology no longer defines security, which now needs to be automatically and dynamically managed.

Federation: challenges are API, identity, data and application environment. Identity is the key.

Billing: metering, rating, and bill generation. The business is where the rating is.

Storage: Lots of data on enterprise platforms, opportunity to re-architect with low-cost storage. No one-size-fits all. The key is balance.

The cloud ecosystem has many components, many issues PER component. Focus on the key issues per component.

Market will divide into 2 sectors: the self-service cloud, and the managed cloud. Just like in hosting versus managed hosting.

Service is what matters.

Pick the right platform for the right application. Rackspace’s strategy is that a hybrid approach of dedicated infrastructure and cloud is best served by a single provider.

SaaS – the “other” cloud. Rackspace hosts a huge number of SaaS platforms. SaaS is a huge agent of change in IT, and reduces IT staff.

OpenStack is a Nasa collaboration to provide an open-source platform that is hypervisor agnostic and provides storage portability.