Head in the Clouds and feet on the ground

Today, you aren’t considered to be techno-savvy unless you have “cloud” somewhere in the your company tagline, or are contracting for some kind of cloud-based service. Not one to miss out on a hot market, I too have a cloud story. I’ve been around since the time before it became “the cloud” when it was simply called “The Internet.”  I even played a rather significant role in how it the Internet was being managed backed in the mid-90s.  We founded one of the first Internet Web filter companies call Purview. Our software was called “Internet Manager” and we helped IT organizations and company management control how the Internet was being used. NASA was one of our first customers.

Fast forward to today’s cloud context and what’s changed…besides the name? All the same issues exist. Network visibility is still a challenge and most organizations have little or no idea how well their technology and services are performing. From a cloud perspective, the prevailing service metric is focused entirely on UP-TIME. “Our data center/hosted application infrastructure provides 99.999% uptime!” The untold part of this story is that the customer is given no assurance whether they can access those up-time resources in a timely and well-performing manner. In other words, 99.999% uptime is of little value when the company’s users are burning minutes or hours of otherwise productive time waiting for the Cloud Services to respond. The demarcation where cloud services  meets the customer premises is the “Feet on the ground” and where the rubber meets the road in terms of actual user performance.

There are several factors to consider that effect cloud performance: WAN bandwidth and application response time. Both directly impact performance individually and in combination. I would suggest that by monitoring and examining these resources an operator or system administrator will be better able to maximize performance and avoid disruptions. Without this kind of visibility, basically everyone is operating in Internet Circa 1995 but paying the Cloud 2012 premium.  Just saying, but the price of visibility is quite affordable compared to the embarrassment of of wasted productivity.

Network alarms: Waking the sleeping IT manager?

I think most people rely upon an alarm clock to awaken and start their day. We’re talking about going from sound asleep to nearly wide-awake in a matter of seconds or minutes.

Network management thresholds and alarms have been around for years and have been adopted by network managers world-wide.  May I suggest that if you’re inclined to waiting for a network alarm, aren’t you, in effect, asleep at the wheel? Some might argue, alarms are an effective way to identify the squeaky wheel so they can grab their IT grease gun and run as needed.  Viewed another way, an alarm event means the problem and disruption has already occurred and now you’re chasing-down causes and network effects. In my view of the world, network alarm-response is exactly the same as your bedroom alarm clock:  Alarm goes off=>figure out what needs to be done=>get ready for work => do the work =>start all over again. What’s the difference? Ok, in one example you’re actually dressed and at work.

I think some additional perspective is needed to clarify why IT management alarm-response is a vicious and ultimately unproductive cycle. First, network monitoring systems evolved out of the process control world.  Almost all controlled processes revolve around some kind of manufacturing or the continual production of  stuff: electricity, candy bars or beer. The inputs, outputs, processes and variables could all be well-defined, monitored and managed because the process is closed the end-product is well-defined. You can set process thresholds and set-points and when an alarm goes off there are a finite number of variables that can be handled with simple logic controllers. On the other hand, when you’re trying to manage a dynamic global open electronic communication system operating at gigabit speeds and used by fallible humans inside and outside the company, with various poorly described business outcomes (how many emails is ideal? how many files can one download? what constitutes a threat?) how can anybody do anything else but react?  Is it any wonder that today we have 100 times more IT complexity and all the IT management problems from the birth of Ethernet still exist? There are millions of viruses with news created daily. There are hackers doing what they do. There are curious users who will continue to abuse and misuse the network.  A lot of stuff shouldn’t be automated and needs to have human eyeballs monitoring what’s happening. Adding layer upon layer of complexity is good for the technology company and analysts, but at the end of the day for the company that bought buys these bells & whistle boxes, someone still has to manage for the desired result. I’d like to say: We’re here to help sort it all out without the complexity and costs!

What I’m suggesting, is that if you monitor the technology, people, content and connectivity from a single integrated reporting platform you can avoid over 90% of network disruptions and threats….without even having to reach an alarm threshold. We’re talking better performance, less reaction and greater productivity. It’s possible because rather than start with an alarm event in mind, we envisioned creating a process so users can move through their network and operations in a logical manner. It’s akin to how a doctor makes hospital rounds rather than the way most IT systems operate which is like a fire fighter. The former is proactive. The latter reactive.

So let this post serve as your wake-up call for giving Inspector software a try.  I guarantee you’ll sleep better at night too.