"I probably wouldn't put anything mission-critical in the Cloud now." That's a recent quote from the CIO of a major consumer brand talking about his enterprise IT infrastructure. The CIO of a consumer e-commerce Web site would be equally nervous about moving its front- or back-end resources to the Cloud.

As tempting as its cost savings and scalability may be, the risks of the Cloud are now also coming to light. Availability and security concerns have dominated this discussion, but the performance of the Cloud - the response time or speed at which services are delivered to an end user - may, in practical terms, be one of the most important risks to your business.

In this article we'll describe the performance risk inherent in the Cloud. We'll explain how this applies to the various Cloud services, offer data and analysis that may surprise you, and suggest a series of tough questions to ask when evaluating the performance of a Cloud provider and its impact on your bottom line. Our overriding question: Are you getting what you're paying for?

With broadband at critical mass, and with connection speeds continually increasing, all customers, B2C or B2B, now expect Google.com- or Amazon.com-like response times. But should we expect that Amazon's EC2 service delivers the same speedy performance one experiences when shopping at Amazon.com?

The assumption that Amazon EC2 or Google App Engine can provide levels of performance commensurate with their brand is convincing enough for the many small businesses now jumping on Cloud services. However the CIO or CTO of a large complex IT infrastructure has a much longer checklist of performance considerations. Small or large, you require assurances that your Cloud provider will deliver the service your business needs. But do the service-level agreements being offered today by Cloud providers meet your expectations for accountability and guarantees?

Levels of Cloud Services
The Cloud promises computing as utility: off-premises, on-demand, easily scalable (elastic), and paying only for what you use. The common classifications of Cloud services are:

• Infrastructure as a Service (IaaS): This is typically a server and storage connected to the Internet, a blank page on which to build the underlying platform and every element and application required in your infrastructure. Examples include Amazon EC2, Mosso, and 3Tera.
• Platform as a Service (PaaS): Here the underlying platform is abstracted out and you're given an on-demand solution stack, a development environment on which to build your necessary applications. As the underlying platform isn't changeable, there are fewer configuration options, and therefore less flexibility than with IaaS. Examples of PaaS services include Google App Engine and Force.com from Salesforce.com (also SaaS).
• Software as a Service (SaaS): This Cloud option is the most mature. It provides turnkey applications on-demand, usually accessible via a Web browser. All else is hidden from view and maintained by the provider. Examples include SAP, Zoho, and Gomez.

So what are your implicit and explicit expectations for each of these services?

Many Cloud SLAs promise 99.99% uptime, but what does that mean to your business? Does availability mean the server is running or that applications are performing to your specifications? Is availability measured from within the Cloud's firewall or from end users' actual devices? A look at the status dashboard of a major Cloud provider (see Figure 1) doesn't offer this detail.

CIOs need to ensure that a Cloud SLA addresses the company's specific business needs. This means every service in the delivery chain has to have someone responsible and accountable for it - just as they would in a non-Cloud infrastructure with its detailed service level objectives (SLOs) from internal teams and SLAs from outside vendors. But if you're outsourcing vital portions of your infrastructure to the Cloud, many of those elements are handled outside your direct control. So who is accountable if one aspect of that service performs below expectations? Watching for these potential Cloud disconnects is an important part of your due diligence in evaluating Cloud services.

With IaaS, elasticity is the most promoted benefit. Elasticity equals velocity plus capacity. That means a quick ramp-up during peak customer usage periods, and only during those times. How efficiently can this occur based on your needs? If you ramp up early, cost benefit is diminished; too late and your system performance deteriorates under the increased load. Will this ramp-up be fast at all times of the day and across all geographies? And just how much capacity can you get? Will an additional hundred or 300 instances be there when you need them? If you're using the Cloud for as-needed, behind-the-scenes data crunching, this isn't a concern, but it certainly is when you're serving a worldwide base of users.

Although not an explicit benefit, connectivity is certainly implied. You assume you're getting fast servers with redundant Internet connectivity in multi-homed data centers with good peering relationships to major networks nationally and internationally.

Similarly with PaaS, what are the implied performance guarantees? With Google App Engine, you assume the underlying service is performing at adequate speeds for your business. Velocity and capacity are a given. With PaaS, this happens transparently based on the number of customers using the system. But are all APIs functioning at mission-critical levels at all times or will a spike in usage slow down the underlying performance?

With SaaS, many of the same performance considerations apply. Can you be sure a transaction made in your Paris bureau is available minutes later for use by the San Francisco sales team trying to close an end-of-quarter deal? In other words, how long will it take the end user to complete his multi-step workflow, regardless of the time of day, point in the quarter, or geographic location? Under certain conditions, performance issues can quickly become availability issues as the increased load weighs on the system. A sample SaaS status dashboard (see Figure 2) does provide average speed data, but these numbers may not reflect the experience of your end users from their desktop, laptop, or mobile device.

Putting the Cloud to the Test
A CIO who has optimized his existing IT infrastructure wants answers to these questions and others, as he considers migrating to the Cloud. To illustrate some of these important points, we conducted a few basic Web application performance tests of well-known Cloud services using Gomez's worldwide testing and monitoring network.

As the basis of our tests, we mocked up a small static Web application, a series of click-throughs and transactions a user might typically perform in the process of navigating a Web site. Any problem along the way triggers an availability error, since the goal is to complete the transaction successfully. In our nomenclature, availability is defined as the success rate of the transaction, not just the reachability of the site.

In our first test (see Figure 3), we compared the performance of four major IaaS and PaaS services over a one-week timeframe. We've obscured the names of the vendors tested. Identical tests were conducted in nine large U.S. cities. Note that one major Cloud provider (dark blue bar) fared very well in East Coast cities, but as you move farther west you see slower performance, especially in Denver and San Jose. This detailed performance monitoring isn't available in the Cloud provider dashboards shown above.

In fact, no current Cloud provider offers this level of performance monitoring, nor does it guarantee performance levels. This underscores the need to conduct your own performance measurements and, as this test shows, track them across all geographies. FYI, most Cloud providers won't guarantee geographic placement of servers.

One might consider closing the geographic performance gap by engaging content delivery (CDN) services from your Cloud provider. That's what we did in our next test of a major IaaS provider that also offers CDN. Measuring only that provider, we conducted tests with and without its CDN service in the same nine cities. The yellow bars (see Figure 4) indicate the CDN did its job, significantly improving performance times. However the pattern of slower performance in western cities reappeared, with Denver, San Jose, and Seattle showing CDN-enabled response times of up to six seconds compared to Boston and Newark, both under one second.

We also performed measurements to compare only CDNs, testing two Clouds and one traditional CDN vendor. We hosted our web pages on each service and ran tests from network backbones in every region of the U.S. The results (see Figure 5) are average performance numbers, that is, the average of all tests taken throughout a one-day test period. They showed one of the Cloud CDN providers had an average response time of almost three seconds; the other two were both under one second.

Before we draw any conclusions, let's look at a parallel test of the same CDN providers, this one taken from the last mile, a network of actual home and business users with consumer-level devices and home Internet connectivity (minimum 2 mbps connection). The last mile test (see Figure 6) shows almost identical performance for the three CDN providers, with response times in a tight range of 4.466 seconds to 4.605 seconds. Barely 1/15 of a second separates them. These results are quite different from the test performed from the backbone, with its data-grade connectivity and server-grade machines.

There are several lessons to be learned from this exercise. First, your customers do not live in data centers. Testing from the lab-like conditions of a backbone alone doesn't provide meaningful performance metrics. Testing from the end-user perspective is a much better approach as it mirrors the real world - your customers. Second, as accurate as these tests are, they are still average performance figures taken over time, similar to charts used to market such services. Detailed performance measurements, tuned to the specific needs and user patterns of your business, should be the basis of your assessment of Cloud services.

Demanding More from Cloud Services
In its 2008 report "Is Cloud Computing Ready for the Enterprise," Forrester Research said that Cloud platforms are maturing but would not be enterprise-ready for two or three more years. Part of this maturing, we hope, will be the inclusion of detailed and relevant performance guarantees in Cloud SLAs along with real-time performance monitoring by providers.

Remember too that whether your installation is simple or complex, all Cloud services have one thing in common: they rely on the Internet to satisfy the needs of end users. So regardless of which provider is engaged, Cloud services do not relieve IT managers of the responsibility of conducting their own ongoing performance monitoring of all Web applications delivered by the Cloud.

In closing, your guidelines for measuring the performance of the Cloud should always include:

1. Getting clear on what your business needs from the Cloud, then testing based on those expectations, implicit and explicit,
2. Testing before deployment and continually in production, due to the constantly fluctuating nature of the Cloud,
3. Knowing your end users - how they connect to the Internet, their location, times of day they log on, even which browser they use - and delivering on their expectations.

Once you've established your performance benchmarks, demand an SLA from your Cloud provider that addresses all your performance needs. Cloud SLAs are a work in progress and will evolve only when IT professionals demand it. Right now the client is king, as Cloud providers look to fulfill the promise of utility computing, but without the risks.