Web performance in the cloud: How do we retain control and visibility?

My head has been in the cloud lately. For the past six months, we’ve been offering Site Optimizer as a cloud-based service, and we recently announced partnerships with Akamai and Level 3 that will extend our cloud relationships.

I’ve been thinking about the general rush to public clouds and wondering if, in the rush, are people giving up too much control? And if so, how do we get some of this control back?

A recent survey by CA Technologies suggests that we feel ambivalent about the cloud. They talked to 434 executives and found that, while interest in public and private cloud computing is widespread, IT managers and business leaders have concerns about issues of security and control.

No big surprises there. On any given day, you can see this excitement and ambivalence echoing through your Twitter feed.

When people deploy apps to cloud platforms, they take a bit of a leap of faith because they lose a bunch of visibility and control that they may not be used to living without. Their infrastructure becomes a kind of blurry black box, and it may take some time to get comfortable with that. It’s the vendor’s responsibility, then, to ease the transition and provide those tools to make site owners more comfortable with putting their stuff on the cloud.

Control as it relates to cloud performance

Last summer, Alistair Croll released an excellent study in which his company, Bitcurrent, tested the performance of five cloud providers. He highlighted some of the main areas of concern, and the tradeoff we make in choosing the cloud:

Almost all the concerns around public cloud computing have to do with a shared resource. You may be worried about neighboring cloud tenants with bad security practices. You might fear that other applications will consume all available resources. Or perhaps you think that the cloud provider has chosen an underlying architecture that helps them, but won’t make the most of your application.

All of these concerns are legitimate. The pact that you’re making with a public cloud, for better or worse, is that the advantages of elasticity and pay-as-you-go economics outweigh any problems you’ll face

Performance pain points can happen in many places, in and outside the cloud

Alistair also illustrates the many performance pain points that can crop up:

The Performance of Clouds: Pain Points

Sample scenario: Isolating your performance problems

Has this happened to you? You start getting complaints from users that your cloud-hosted site is slow. You know that there are dozens of potential performance pain points. You ask your IT manager or lead developers what the problem is. They suggest that it might be your cloud provider. So you ask your cloud provider. They say that it’s probably a dev problem. Where do you go from there?

What you need from your cloud vendor

Knowing that performance has a direct impact on revenue, site owners are putting their entire business in the hands of their cloud providers. It’s understandable that we’re tempted to demand control over the performance of our applications, because this is what we had (or at least the illusion of it) before.

This demand is, ultimately, unrealistic, but it is realistic to expect that, in exchange for losing some of the infrastructural control you used to have before you deployed your apps to the cloud, you need to ask your provider for more visibility and assurances in how their infrastructure will perform for you, such as:

  • Analytics tools – You should continue to use the performance monitoring tools you already use to monitor your app performance with (Webpagetest, Keynote, Gomez, etc.), but you also need a new visibility toolset (that your cloud provider should help you with) so you can do root cause analysis over parts of the infrastructure that you don’t have control over or visibility into.
  • Detailed performance clauses in your service level agreements – Some cloud SLAs contain a performance clause that addresses availability, but speed is every bit as important as — and possibly more important than — uptime. This clause needs to spell out how your concerns about site speed will be addressed, should they occur.

(I’m very interested to hear other people’s thoughts here. What could these tools and clauses look like? Is there any other way we can retain control and visibility? I’d love to hear people’s first-hand experiences.)

What your cloud provider can’t do for you

In exchange for asking for more from your cloud provider, we also need to know when to ask for less.  Site owners need to realize that hosting in the cloud will not, de facto, make their sites faster. I don’t believe I’ve ever heard of a cloud vendor that makes the claim that they guarantee faster load times, but I’ve encountered this myth via a few site owners. Good hosting does not replace front-end optimization.

I’m the first to admit that the cloud is not my area of expertise. Fortunately, it doesn’t have to be, because we have Hooman Beheshti, VP of Product here at Strangeloop, who is our guru of all things cloud-related. In March, Hooman’s on his way to Cloud Connect, where he’s chairing the Performance and Monitoring track. He and a lot of other very smart people are going to spend a week discussing the cloud from many angles, including the current state of cloud SLAs. If you want to get a non-sensationalistic, non-hyped take on the cloud, I strongly recommend you check it out.

Related posts: