In-Depth

Networking for the Cloud: 3 Vendor Views (Part 2, CloudSleuth)

Three vendors, three opinions on what drives their solutions. In this second of a series, Doug Barney talks with Lloyd Bloom, senior product manager of CloudSleuth at Compuware Corp.

• By Doug Barney
• 01/30/2012

We contacted three major networking vendors to talk about bandwidth and the cloud, and peppered each with essentially the same questions so as to gather an array of opinions.

In this second of a series, Doug Barney talks with Lloyd Bloom, senior product manager of CloudSleuth at Compuware Corp. CloudSleuth is a community for IT pros interested in the cloud and offers an array of software tools.

Redmond: What are the most important networking/WAN issues IT has to think about when considering the cloud?
Lloyd Bloom: The issue that most people think about right off the bat is bandwidth. The cloud provider certainly has to be able to provide sufficient bandwidth to the Internet to support the volume of users and associated traffic. But, there are other less obvious -- but equally important -- network considerations. In our work with cloud providers and CloudSleuth, we've learned that routing effects have a potentially serious impact on performance. [For] one, performance slowdown occurs when routes are excessively long. We saw one case where a Singapore provider's connection to users in Tokyo over NTT networks was routed through California -- ouch! We're working another case where a router that sits midway between our backbone node measurement points and a cloud provider is fragmenting packets from large images and causing many retransmissions. That's another performance killer.

How does one evaluate the network/WAN's readiness for the cloud?
Testing. For example, with CloudSleuth's Global Provider View [GPV], we monitor performance of two pages every 15 minutes from named cloud hosts. That's how we discovered the issues [I described earlier]. That's one dimension of test, which gets the routing perspective. The other dimension is load testing, a service available from [the] Compuware Gomez Performance Network, which will identify issues with bandwidth.

How do these issues differ depending on application?
Aside from the volume of users hitting an application, application pages present different numbers of objects and the objects come in different sizes. For example, with our GPV monitoring, we measure performance of a two-page application that represents a catalog application to test these two cases. One page has 40 small objects, like a catalog selection page, to test the network's ability to handle many small objects. The second page has a moderate-sized object of 1.7MB to test [the] ability to download objects that exceed network window sizes.

How do these issues differ depending on the size of the enterprise?
Not so much the size of the enterprise, but the size of the user base hitting the application. If it's a cloud application serving the enterprise, then, yes, enterprise size impacts network sizing and performance considerations. If it's an e-tail site with external users [customers], for example, then enterprise size is less of a consideration as it's only indirectly related to traffic.

What are the basic steps you can take to get the network ready for the cloud?
Pre-size based on analysis of the application design and user loads. Test. Adjust network configuration and sizing. Re-test. Adjust. Re-test...

The up-front analysis is really critical to minimize the iterative cycle of testing and tuning. Once the network is ready and the application is deployed, it is essential to monitor 24x7 to detect performance impacts due to application and network changes, and changes in usage patterns.

Can cloud SLAs be as aggressive as on-premises apps?
Yes. Especially with the redundancies built into large cloud hosting centers, the SLAs should be at least as aggressive as for on-premises apps. The bigger question is, "Which SLAs?"Cloud and enterprise datacenter owners prefer to use infrastructure-based SLAs like server uptime and network availability. These are important from an internal management capability, but not as a measure of whether the infrastructure is capable of delivering satisfactory application performance. The only meaningful SLA is end-user experience. How fast does the application respond when the user hits Enter? These are difficult SLAs for cloud and network providers to support, because they don't own the application, but they are nonetheless the most important.

What are cloud providers doing to mitigate some of the network performance issues?
Hosting in well-provisioned datacenters with redundant connections. Offering multiple hosting locations. Virtualizing your application deployment among multiple locations (Google App Engine is a good example of this). Offering CDN services, such as Amazon's CloudFront, to bring content closer to users.

How much are bandwidth issues holding back cloud adoption?
Network performance, in general, is not at the top of the list, at least not directly. Anecdotally, availability and security are the most frequent concerns we hear about as top-tier concerns, and performance -- our specialty -- is rapidly gaining recognition as a key decision-making criterion. Performance depends upon both the compute side of the equation, as well as the network. So, indirectly, bandwidth and routing are key concerns.

Does the cost of additional bandwidth and the ever-lower cost of on-premises servers and storage still make the cloud an economic advantage?
It's not clear that the cloud has ever held a convincing direct-cost advantage. Instead, the cloud offers advantages with elastic provisioning and freeing of on-premises resources to focus on applications rather than infrastructure. Ultimately, it's more about how you run your IT operations and business, the type of applications you run, the sophistication of your existing facilities and the skill sets you have on staff.

Can the Internet and network providers keep pace with a possible explosion in cloud demand?
Do they have a choice?