Recently, I had the opportunity to speak with Steve Riley, Technical Director in the Office of CTO at Riverbed Technology. Steve does a lot of forward thinking about technology, so it was fascinating listening to him opine about the direction of enterprise infrastructure. During the chat, Steve mentioned an area of technology and networking he’s been thinking a lot about lately, which is hybrid cloud architectures. He posed the question “How do we make the cloud feel local?”

On the surface, it seems like a straight-forward question that surely must have a clear technical answer. After stewing on his question for a while, I realized it’s deeper than it seems at first blush, and the “answers” are themselves some big challenges for the IT industry to tackle.

Before we approach the “how” of making the cloud feel local, perhaps we need to examine the “why”. What makes “local” inherently better for our applications? Is it better? After all, most of the in-house data centers I encounter, when compared to large, shared colocation facilities or data centers of cloud providers, lack many things. The reality is that for most enterprises, maintaining a data center is considered an overhead cost, rather than value-add. As such, the in-house data center usually isn’t as well equipped, staffed, or designed with the same level of redundancy. Neither is it usually held to the same procedural standards of a cloud-scale facility.

Indeed, “local” applications can often be associated with relatively low reliability, occasional data loss, and security hassles. This survey commissioned by Microsoft indicates that many SMBs who’ve gotten to the cloud realize it’s better than local. That’s not to say that we IT practitioners are all terrible at our jobs, but simply highlights the case that most enterprise IT environments are chronically understaffed, under-funded, and usually not equipped to deal with true catastrophes.

So why, then, do we like for our apps to feel “local”? I think a lot of it is psychological. “Local” is a code word for “fast,” or specifically for not feeling like the thing we’re trying to do is artificially slower than we think it should be. Funny thing is, how are we to tell whether a transaction takes the amount of time it does because the service is running in a cloud instance 4,000 miles away, or because it’s running on an on-premises, severely overworked server? It’s about setting and meeting expectations, and being able to prove that performance is consistent with predictions.

Additionally, humans as a species have been accustomed to manipulating and observing our world in a physical sense for, well, forever. We perceive that things we can reach out and touch, that are close to us, are better. We feel more in control of those things. Have you ever walked into the data center when the network, or application, or storage is down, just to stare at it — inspect the cabling and watch the blinking lights — while you consider possible causes or resolutions? I certainly have. But when our services run in a cloud, we feel (and are) physically disconnected from the infrastructure, which makes us feel insecure. Even when we are monitoring things electronically, the metrics to measure cloud performance, availability, or errors, are often hard to directly equate to the metrics or methods we use to monitor and troubleshoot those same things in local systems. Again, we tend to feel less in-control because we can’t watch a switch port for error counters or try shutting off other systems to see if that fixes the mysterious behavior we’re battling.

So, how do we make the cloud feel local? It’s easy. We just have to eliminate any performance degradation versus the arbitrary performance expectations of local systems, demonstrably prove that we’ve done so, and reprogram countless generations of human nature with regard to observing, diagnosing, and repairing broken things. Clearly, we have some work ahead of us.

Ed Note: Be sure to check out Riverbed’s take on the Hybrid Enterprise from Ginna Raahague (@GinnaRaahague).  Her post can be found on the Riverbed blog at  http://www.riverbed.com/blogs/Enterprise-Architecture-for-the-Hybrid-Enterprise.html.