From Point A to Point B.

The complexities of life often escape a young child. The Little Man asked me the other day why I had to go work, which was both a compliment to wanting to spend time with me and an unintended backhand slap at Lori, who was going to hang out with him while I took care of business. The answer was the usual stuff, that working paid the bills, and work has its own rewards… It did not include “and I like my job”, though I do, simply because I didn’t want to imply “more than hanging out with you” to a three year old.

But children boil everything down to simplicity. The picture over there is said son, wearing a picklehaube with a Transformers shirt and (yes really) proclaiming he was an autobot because of the helmet.

We adults, on the other hand, tend to layer complexity upon complexity until we’re not certain we’re getting value anymore, but we’re proud of whatever it is we have done/built/know. IT is like that sometimes. What is “the network” – in tweet length, for example?

Not only is the answer tough to cram into tweet length, it is tougher to cram into tweet length and make useful. It is even more difficult to cram it into tweet length and include all the various constituencies of IT in the answer.

But it can be done, because a “network” is a simple concept. You’re moving information from point A to point B. That’s it. Everything else is layers we’ve added over it to make some aspect of that movement better, or to facilitate the movement of data. But in the end, it is just sending bytes over the wire. If, for example, a business person with no IT background asks why a whole section of the corporate network is down, they don’t care about routing tables or even DNS, they care about “The network broke, and those clients can’t get to the datacenter. The network is complex, but we’ll have it up soon.”

If you’re moving data over the WAN, it gets another layer of complexity – because you want to move data over the WAN at a decent speed, but most applications aren’t designed for network communication optimization. Instead they’re designed to be very good at moving data, and expect the network to worry about performance issues. But business users don’t want to hear about compression, dedupe, SSL offload, or any of that when things go wrong, they want to hear “The copy of our data at the remote site is a little out of synch right now, but we’re on it, and it will all be fine soon.”

Want to secure the network? BAM! Another complex layer is tossed on top of that – but the point is that you don’t just want to move data from point A to point B anymore, you want to move data from point A to point B securely. Again, if your ADS or LDAP system goes on the fritz, you’re going to want to be able to tell people “users can’t log in right now, the servers that know who can do what are offline, but we’ll have them back up soon.” because users care that data isn’t moving from point A to point B, not about whatever bugbear has cropped up with authentication or the network.

Want to give web users – internal and external – an enhanced experience while reducing the load on your servers? Another layer of complexity piles on, as you use Web Application Optimization techniques. They work great – at least those by F5 do, since I’ve been a user of them – but they add a whole new layer of oddities. “No, the new logo isn’t showing reliably, but the team is flushing the cache and/or changing the expiration date to get that fixed, and it’ll be right soon.” is what business users want to hear.

Load balancing to increase reliability and performance adds yet another layer of complexity to the overall system, a layer that has all of its own terminology. But when load balancing goes wrong, “We misconfigured the Virtual IP and the Pool it points to does not serve your app” isn’t what the business person wants to hear. “Yes, we had an error, but your application should be back online soon.” is the right answer.

Server virtualization doesn’t directly add complexity to the network, but server sprawl certainly does because now there are a lot more clients out there. One of the early problems with server sprawl that seems to be largely defeated was “where is that non-responding virtual running again?” But still, if the hardware goes down that a users’ VM is running on, they want to hear “Yes, we had a hardware failure, but your application should be back up on another server soon, and we’ll get the problem fixed then move your application back.”

Desktop virtualization adds both complexity and traffic to your network, but simplifies a whole array of things from desktop management to licensing. Still, when it is performing poorly, a business leader does not want to hear about oversubscription, congestion, or the number of VMs per server, or anything else technical, they want to hear “Yes, we see that performance is down for those users. We’ve got a plan to fix it, and all should be back to normal soon.”

The thing is, F5 sells tools to help with all of these issues. In fact, F5 sells a platform that you can customize to help with all of these issues… But notice that all the answers to business are simple, and end with "some variant of “back up soon”? We can supply you with tools to manage the “back up soon” or even make you able to say “there was a problem, but you shouldn’t have noticed”, we cannot provide you with a tool to make everything simple. The business sometimes needs educating, but most of the time they just need less detail and more information.

We’ve got a ton of cool stuff going on in IT these days, but sometimes the complexity masks the simplicity. Boil it down to the basics, and tackle real problems. And enjoy talking simplicity for a change... Because the next round of Buzzword Bingo is on its way in 5,4,3,2,1…