Cloud computing resources will be accessed by the public Internet, private networks and often by hybrids of the two. Providers and users of cloud services must understand the performance, redundancy and cost associated with the four styles.

• The Internet will be the most cost-effective cloud access method due to its ubiquity, but it will not support even the most basic performance guarantees. Network planners can mitigate this through proper architecture and sourcing.
• Augmented Internet services, like optimized Internet overlays, will be required for many applications and will become a common approach to improving performance, although at additional cost.
• Carrier-provided Multiprotocol Label Switching (MPLS) services offer guaranteed performance but have coverage limitations, until universal network-to-network interfaces (NNIs) or gateways, are implemented via carriers — which we do not expect to see before 2011.

• Recommendations for providers of cloud computing services:
  • Understand the performance requirements of your applications.
  • Consider adding network- or equipment-based acceleration to improve client experience and to reduce bandwidth charges.
  • Have clear criteria for what is business-critical. Don't just assume the public Internet is, or isn't, capable of providing an adequate service.
  • Focus on the response time service-level agreements (SLAs) and monthly bandwidth charges, rather than the acceleration methods used by your cloud services provider.
• Buyers of cloud computing services should:
  • Not assume that "the cloud" and "the Internet" are one and the same, or that the Internet is or isn't an appropriate delivery mechanism for business-critical applications delivered via cloud-based services.
  • Evaluate network options from your cloud provider and from your network service provider that can reduce network charges or improve application performance.
  • Test or emulate the performance of cloud-based applications in all geographies where you plan to deploy them. Latency can cause dramatic differences in application response time.

The promise of cloud computing is ubiquitous access to a broad set of applications and services, which are delivered over the Internet and related networks, to multiple customers.

To deliver on that promise, the cloud must provide a rich set of network services to a broad set of applications and services. Not all applications are the same: some will only require the basic capabilities available on the public Internet, while others may require an overlay on top (the "augmented Internet"), or even a private, Internet Protocol network with application-specific capabilities. What may work for one subscriber of a cloud-based service may not be appropriate for another, so cloud computing providers need to understand network delivery issues and be prepared to deliver multiple cloud network options to their subscribers. This research analyzes the different types of cloud networks and identifies application characteristics, which will drive the selection of a particular type of cloud network. We list five use cases, which clients can use to compare their needs to these types of cloud networks.

These options are not mutually exclusive and we expect combinations to be common. For example, a combination may be used to support a demanding application or one approach may be used when users are in their offices and another approach may be used for remote access.

The public Internet is the simplest choice for delivering cloud-based applications or services. In this model, the cloud service provider simply purchases Internet connectivity and its customers access the services via their own Internet connections. "Basic public Internet" refers to commonly available Internet access and transport capabilities. It does not include application-fluent enhancements such as caching, Transmission Control Protocol (TCP) acceleration, advanced compression, or application-specific optimizations.

Advantages of the public Internet include:

• The cloud service can be sold to a large audience: anyone with Internet access.
• It is inherently tolerant of faults.
• Many providers are in the market.
• Secure Sockets Layer (SSL)-based, Hypertext Transport Protocol Over Secure Sockets Layer (HTTPS), encrypted access provides confidentiality.
• It is very cost-effective.

The disadvantages of the public Internet include:

• Lack of end-to-end quality of service (QOS), which make end-to-end service-level agreements (SLAs) difficult to achieve.
• The possibility of poor response over high-latency or "high-jitter" connections or in conditions of packet loss. These are exacerbated by protocol inefficiencies in TCP, Hypertext Transport Protocol (HTTP) and Web services.
• Cable cuts, routing issues and other impairments can severely degrade performance, or make service entirely unavailable for extended periods of time.

Performance consistency and service availability can be improved by obtaining bandwidth through multiple Internet service providers (ISPs). Cloud service providers should certainly obtain bandwidth from multiple, major ISPs, while subscribers of the service could elect to home their access with at least two of the major providers used by the cloud vendor. At the very least, the subscriber could use one of the same major ISPs as the cloud vendor to provide basic SLAs. Smaller offices can achieve better performance and some limited guarantees by purchasing business-grade Internet access services.

Advanced application delivery features can provide significant advantages to both provider and subscriber of cloud services (see "Toolkit Best Practices: Use the Network to Improve Application Performance"). These features can provide major efficiencies (of around 20% to 50%) within the cloud provider data center by offloading network-related functions off the server. SSL termination, TCP connection management, augmented by client and server-side caching, removes significant cycles from front line servers. Beyond this, dynamic caching, compression, pre-fetching and other related Web-acceleration technologies will result in major performance improvements for end users, often exceeding 50%.

Examples of providers include AT&T Hosting, Citrix NetScaler and F5's WebAccelerator options. These technologies can be deployed in the cloud services provider's data center and many will opt to do so. Enterprise buyers should be more concerned with response time SLAs and monthly bandwidth charges, rather than the acceleration method selected.

This form of acceleration requires a server-side appliance and often leverages a small downloadable client component. It improves the performance of both ends of the service, but it does not address many of the network-related reliability issues described in Option 1. We expect this option to be the most widely deployed solution.

If a cloud service provider utilizes an optimized Internet overlay approach, customers access the service via a standard Internet connection, which terminates at the cloud edge, on a particular carrier's network. Within these termination points of presence (POPs), a number of things can occur, such as:

• Optimized real-time routing, which avoids Internet hot spots, making SLAs easier to achieve by providing much more consistent end-to-end latency.
• The SSL session can be terminated and protocols and payload optimized and re-encrypted.
• A portion of the application's logic may reside in the POP, significantly improving scalability, fault tolerance and response time, often by 80% or more.
• Frequently accessed content may be delivered from local caches.

The disadvantages of this approach are as follows:

• It is more expensive than the public Internet, often two to four times as much.
• It involves a strong vendor lock-in if the application is distributed into the carrier's network. Provider selection is limited and may have associated vendor risk. Providers offering these services include Akamai and Internap.

Some customers may prefer to connect directly to the cloud service provider via a private WAN connection (usually an MPLS/virtual private network (VPN) connection). Two principal architectures are common practice:

• Site-to-site WAN connections between the cloud service provider and one or more of the customer's principal sites.
• A private MPLS/VPN dedicated to the cloud service provider, with dedicated links between the provider and each of the clients.

The MPLS VPN provides confidentiality, guaranteed bandwidth and end-to-end SLAs for availability, latency and packet loss. For a price, MPLS can scale to meet variable bandwidth needs and additional service level guarantees, such as "jitter" and QOS can support predictable performance for sensitive applications. However, private WAN connections of this type are not necessarily more reliable than Internet connections, particularly redundant, multi-homed connections via multiple ISPs.

Most of the benefits of private carrier MPLS-based VPNs are limited to a single carrier backbone as most carriers have fairly limited interconnection agreements (aka NNIs). Mapping quality of service classes and service levels requires a common definition and mediation engine, which are only available on an individual case-by-case basis. Some European carriers have led the market, as have some in Asia/Pacific. In the U.S., only a couple of carriers, Verizon Business and Global Crossing, have built considerable NNIs.

Table 1 summarizes the characteristics of various options and provides several case scenarios where each might be applicable.

For composite applications, which use services dispersed across the cloud, a more robust mechanism is required. Private tunnels ensure that bandwidth, latency and loss don't impact negatively on application performance, with the added benefit of security via encryption and strong authentication when needed.

Cloud computing providers may incur significant network bandwidth charges as their businesses grow. These charges can result from traffic to and from customers and traffic between provider sites. Very large providers like Google can avoid significant charges by building their own WAN with multiple peering points with all major ISPs. Most cloud providers lack the resources to do this, although options, such as wavelength services, can make it more cost-effective. For lower speed connections, WAN optimization controllers (WOCs) can be used to reduce bandwidth requirements by 50% to 80% and optimize "chatty" protocols.

To reduce bandwidth charges and improve performance for browser-based applications, providers may choose to implement asymmetrical optimizations (aka "dynamic" Web caching). This involves a device in the data center and small, zero footprint client applets, which are dynamically loaded. This approach can reduce response times by 50% to 70% and bandwidth requirements by 50% to 80% for many applications. The benefits are that it does not require equipment at each client site, as it can be equipment-based or purchased as a managed service. To improve application response times for mobile clients, such as laptops or PDAs with cellular data connections, dynamic Web caches with client applets may be used. If applications require more than browser-based access, SoftWOC client code is a better solution.

When access to cloud services is via a limited number of sites, the cloud provider may place a WOC on the client's premises, which can significantly reduce bandwidth charges and improve application performance. This may not be acceptable when the client has multiple cloud providers and doesn't want to deal with the complexity of routing each provider's traffic to the appropriate WOC, but this can be overcome via a providers' managed WAN/WOC service.

Large companies may choose to build out their own, highly scalable distributed IT infrastructure, which resembles a cloud computing service, similar to that of a cloud provider.

In this case, data centers are linked with private fiber, wavelength services, Synchronous Optical Network (SONET) or VPN services, depending on distance, bandwidth requirements and budget. Links to external services (for composite applications) can be through a VPN service or via accelerated Internet services with VPN tunnels. For the most demanding applications a dedicated private link, combined with acceleration technologies, will become the norm. Whatever the link type used, when connecting to these external services, security and identity management become a major concern (see "Best Practices Checklist for Web Services Security, 2006").

Internal clients located at major sites, typically access applications over corporate WAN, commonly via MPLS. In this case, QOS capabilities are often required to protect interactive traffic from "bursty" server-to-server traffic. For temporary or very few offices or mobile workers, VPN connections across optimized/accelerated Internet services provide the most robust service. VPN tunnels across the Internet should only be used as the primary link when consistent performance is not critical — although they may serve as an excellent standby service during MPLS outages and may even serve as an inter-carrier NNI. To improve application response times for mobile clients (small office/home office [SOHO], laptops with packet radio cards or PDAs). dynamic Web caches with client applets may be used. If applications require more than browser-based access, centrally located WOCs with SoftWOC client code is a better solution.