Monthly Archives: June 2011

A Call for Coordinated Cloudbursts

While researching this post, I received an invitation from About.Me, a service where I already have a simple profile posted about myself in classic vanity press fashion. What struck me most was that the main request in the invitation was for me to try out the new in-dashboard feature from Klout, a web service that allows you to track the number of and quality of (ranking) posts you provide in the Twitterverse and Blogosphere. Yes, two buzzwords at the end of one sentence.

However, visiting the link from the invite on Klout works just fine, while the link to About.Me’s in-dashboard new Klout feature fails. Not from user error, where a mass email was sent with a typographical error in the URL, not from database code in the CRM’s mass email system, but where About.Me apparently sent it to everyone at once. Now, like a fifth-grade rumor that has everyone flushing the toilets at the same instant, ruining the school’s plumbing, or every human being on earth jumping up and down in the same moment to move the planet out of orbit, a very real effect has been achieved: the link can’t respond to all the users at once.

The methods behind cloud computing allow for quick scalability, for immediate response to overwhelming web traffic and processing, but the sad truth is that they can be throttled. By choice, by service level agreement, by paid tier, there are numerous reasons why banks of servers that were built to handle small spikes in traffic but can’t hold up to large jumps in processing…. Often the CPU-sharing agreements allow for a “burst” method where processor power on the server banks aren’t always working, but pulse in large part, then slow down.

The beauty on the example of About.Me’s ask was that within minutes (about 8-10 minutes, in fact) they had remedied the problem and the links were working, the integrated Klout functionality was up and running, and I was amazed. Not by the feature, although it’s delightful. I’m amazed at the digital ability to scale in more processor power when needed, in a way that makes me reminiscent of the machines in Fritz Lang movies or steamboat engineers, twiddling knobs and opening valves for more power when needed, slowing it down when no longer necessary. The Amazon Cloud, Google Apps Cloud, and a variety of private services like seem to have this handled within limits in a very clear way.

But the innovation is still in its infancy.

What is needed is a predictive model, tied in with the CRM systems, so that when an email leaves the “house” containing a link to servers hosted on the same (or a connected) cloud platform, the system can presumptively throttle open more spillways or even veritable floodgates depending on how many recipients are targeted, or, to take it another step further, to integrate with the response mechanisms in those messages, in case a small group of recipients is included in the initial mailing, but the email “goes viral” and includes a high pass-along rate.

A model is needed that can take all of these data points and feedback items into account and can plan to work and react ahead of usage in an overall architecture.

The technology, of course, will follow.

Leave a comment

Filed under Business History