About networkingnerd

Tom Hollingsworth, CCIE #29213, is a former network engineer that is now an organizer for Tech Field Day. Tom has been in the IT industry since 2002, and has been a nerd since he first drew breath.

Does EMC Need A Network?

EMCnetwork

Network acquisitions are in the news once again. This time, the buyer is EMC. In a blog article from last week, EMC is reportedly mulling the purchase of either Brocade or Arista to add a networking component to its offerings. While Arista would be a good pickup for EMC to add a complete data center networking practice, one must ask themselves “Does EMC Really Need A Network?”

Hardware? For What?

The “smart money” says that EMC needs a network offering to help complete their vBlock offering now that the EMC/Cisco divorce is in the final stages. EMC has accelerated those plans from the server side by offering EVO:RAIL as an option for VSPEX now. Yes, VSPEX isn’t a vBlock. But it’s a flexible architecture that will eventually supplant vBlock when the latter is finally put out to pasture once the relationship between Cisco and EMC is done.

EMC being the majority partner in VCE has incentive to continue offering the package to customers to make truckloads of cash. But long term, it makes more sense for EMC to start offering alternatives to a Cisco-only network. There have been many, many assurances that vBlock will not be going away any time soon (almost to the level of “the lady doth protest too much, methinks“). But to me, that just means that the successor to vBlock will be called something different, like nBlock or eBlock.

Regardless of what the next solution is called, it will still need networking components installed in order to facilitate communication between the components in the system. EMC has been looking at networking companies in the past, especially Juniper (again with much protesting to the contrary). It’s obvious they want to have a hardware solution to offer alongside Cisco for future converged systems. But do they really need to?

How About A BriteBlock?

EMC needs a network component. NSX is a great control system that EMC already owns (and is already considering for vBlocks), but as Joe Onisick (@JOnisick) is fond of pointing out, NSX doesn’t actually forward packets. So we still need something to fling bits back and forth. But why does it have to be something EMC owns?

Whitebox switching is making huge strides toward being a data center solution. Cumulus, Pluribus, and Big Switch have created stable platforms that offer several advantages over more traditional offerings, not the least of which is cost. The ability to customize the OS to a degree is also attractive to people that want to integrate with other systems.

Could you imagine running a Cumulus switch in a vBlock and having the network forwarding totally integrated with the management platform? Or how about running Big Switch’s Big Fabric as the backplane for vBlock? These solutions would work with minimal effort on the part of EMC and very little tuning required by the end user. Add in the lowered acquistion cost of the network hardware and you end up with a slightly healthier profit margin for EMC.

Is The Answer A FaceBlock?

The other solution is to use OpenCompute Project switches in a vBlock offering. OCP is gaining momentum, with Cumulus and Big Switch both making big contributions recently at the 2015 OCP Summit. Add in the buzz around the Wedge switch and new Six Pack chassis and you have the potential to have significant network performance for a relative pittance.

Wedge and Six Pack are not without their challenges. Even running Cumulus Linux or Open Network Linux from Big Switch, it’s going to take some time to integrate the network OS with the vBlock architecture. NSX can alleviate some of these challenges, but it’s more a matter of time than technology. EMC is actually very good at taking nascent technology from startups and integrating with their product lines. Doing the same with OCP networking would not be much different from their current R&D style.

Another advantage of using OCP networking comes from the effect that EMC would have to the project. By having a major vendor embrace OCP as the spine of their architecture, Facebook gains the advantages of reduced component costs and increased development. Even if EMC doesn’t release their developments back into the community, they will attract more developers to the project and magnify the work being done. This benefits EMC as well, as every OCP addition flows back into their offerings as well.


Tom’s Take

We’re running out of big companies to buy other companies. Through consolidation and positioning, the mid-tier has grown to the point where they can’t easily be bought by anyone other than Cisco. Thanks to Aruba, HP is going to be busy with that integration until well after the company split. EMC is the last company out there that has the resources to buy someone as big as Arista or Brocade.

The question that the people at EMC need to ask themselves is: Do we really need hardware? Or can we make everything work without pulling out the checkbook? Cisco will always been an option for vBlock, just not necessarily the cheapest solution. EMC can find solutions to increase their margins, but it’s going to take some elbow grease and a few thinking caps to integrate whitebox or OCP-style offerings.

EMC does need a network. It just may not need to be one they own.

 

Insecurity Guards

file000491308347

Pick a random headline related to security today and you’ll see lots of exclamation points and dire warnings about the insecurity of a something we thought was inviolate, such as Apple Pay or TLS. It’s enough to make you jump out of your skin and crawl into a dark hole somewhere never to use electricity again. Until you read the article, that is. After going through a couple of paragraphs, you realize that a click-bait headline about a new technology actually underscores an age-old problem: people are the weakest link.

Engineered To Be Social

We can engineer security for protocols and systems until the cows come home. We can use ciphers so complicated that even Deep Thought couldn’t figure them out. We can create a system so secure that it could never be hacked. But in the end that system needs to be used by people. And people are where everything breaks down.

Take the most recent Apple Pay “exploit” in the news that’s been making all the headlines. The problem has nothing to do with Apple Pay itself, or the way the device interacts with the point-of-sale terminal. It has everything to do with enterprising crooks calling in to banks an impersonating users to get a live, breathing person on the other end of the phone to override security safeguards and break the system down. An hourly employee of the bank can put all the defense-in-depth research to naught in a matter of keystrokes.

It is the way it is because people are dumb, panicky, and dangerous. When confronted with situations that are outside their norm they tend to freeze up and do the wrong thing. Take this scene from Sneakers (which is an excellent movie you should go watch right now):

When I originally started writing this post, that scene stuck out in my mind as a brilliant way to illustrate how less-than-savory people get around high technology with simple solutions, like kicking in a door protected by a keypad. But then I watched the scene again and found an even better example of my point. Look how Robert Redford and River Phoenix work together to distract and eventually overwhelm the security guard. The guard knows that no one should be able to get through the gate without the right keycard. With a bit of distraction, some added stress, and an apparently helpless but irritated user, Redford is able to social engineer his way into the building with little effort. The movie is full of these kinds of scenes.

The point is not that Robert Redford can talk his way into a building. The point that should be illustrated is that people override security decisions every day. Writing down passwords. Ignoring security warnings. Clicking on believable but fake exploits. It’s done because it’s quicker or easier or it’s done to remove a screaming customer on the other end of the phone. Polices are ignored and shortcuts are taken to make things easy. So how do we fix it?

Teach It, Don’t Tech It

The absolute last thing you should do when trying to fix these issues is to create another layer of technology to insulate the issue. That leads to two problems. The first is that people will being to see the new solution as yet another problem and try to create shortcuts to work around it. The second, which is a more sinister issue, is that you’ve essentially told those people that they can’t understand why this is a problem and you’ve decided to marginalize them instead of teaching them. They may not realize it, but you’ve silently placed them lower on the intelligence ladder than a few bytes of code.

People need to know why things are the way they are. If the policy says not to write down a password, tell people why that is. If the rules say you don’t override a lockout for a PIN or add a card to a person’s account without certain information then you need to tell people why you don’t do that. A policy or security feature without an explanation is merely an annoyance. One that will be circumvented. Making your users aware of the reason for a policy makes it something that’s hard to ignore. You’re more likely to get traction by treating your users like people, not automatons.


Tom’s Take

Kevin Mitnick (@KevinMitnick) wrote an entire book about social engineering and how easy it is to accomplish. As security systems become more complicated and much less simple to fool, the majority of miscreants aren’t going to spend hours upon hours trying to hack a handshake protocol or create hash collisions. Instead, they will attack the weakest link in the chain. That will almost undoubtedly be the users of the system. We have to make our users smart enough to know when people are trying to take advantage of them and close that loop. Or at least make that loop as difficult to breach as the rest of the system. That’s the only way to be sure that the security measures we put in place can be used to their fullest potential. Just make sure that everyone knows the Eddie Vedder doesn’t work in accounting.

 

Are We The Problem With Wearables?

applewatchface
Something, Something, Apple Watch.

Oh, yeah. There needs to be substance in a wearable blog post. Not just product names.

Wearables are the next big product category that is driving innovation. The advances being made in screen clarity, battery life, and component miniaturization are being felt across the rest of the device market. I doubt Apple would have been able to make the new Macbook logic board as small as it is without a few things learned from trying to cram transistors into a watch case. But, are we the people sending the wrong messages about wearable technology?

The Little Computer That Could

If you look at the biggest driving factor behind technology today, it comes down to size. Technology companies are making things smaller and lighter with every iteration. If the words thinnest and lightest don’t appear in your presentation at least twice then you aren’t on the cutting edge. But is this drive because tech companies want to make things tiny? Or is it more that consumers are driving them that way?

Yes, people the world over are now complaining that technology should have other attributes besides size and weight. A large contingent says that battery life is now more important than anything else. But would you be okay with lugging around an extra pound of weight that equates to four more hours of typing time? Would you give up your 13-inch laptop in favor of a 17-inch model if the battery life were doubled?

People send mixed signals about the size and shape of technology all the time. We want it fast, small, light, powerful, and with the ability to run forever. Tech companies give us as much as they can, but tradeoffs must be made. Light and powerful usually means horrible battery life. Great battery life and low weight often means terrible performance. No consumer has ever said, “This product is exactly what I wanted with regards to battery, power, weight, and price.”

Where Wearables Dare

As Jonny Ive said this week, “The keyboard dictated the size of the new Macbook.” He’s absolutely right. Laptops and Desktops have a minimum size that is dictated by the screen and keyboard. Has anyone tried typing on a keyboard cover for and iPad? How about an iPad Mini cover? It’s a miserable experience, even if you don’t have sausage fingers like me. When the size of the device dictates the keyboard, you are forced to make compromises that impact user experience.

With wearables, the bar shifts away from input to usability. No wearable watch has a keyboard, virtual or otherwise. Instead, voice control is the input method. Spoken words drive communication beyond navigation. For some applications, like phone calls and text messages, this is preferred. But I can’t imagine typing a whole blog post or coding on a watch. Nor should I. The wearable category is not designed for hard-core computing use.

That’s where we’re getting it wrong. Google Glass was never designed to replace a laptop. Apple Watch isn’t going to replace an iPhone, let alone an iMac. Wearable devices augment our technology workflows instead of displacing them. Those fancy monocles you see in sci-fi movies aren’t the entire computer. They are just an interface to a larger processor on the back end. Trying to shrink a laptop to the size of a silver dollar is impossible. If it were, we’d have that by now.

Wearables are designed to give you information at a glance. Google Glass allows you to see notifications easily and access information. Smart watches are designed to give notifications and quick, digestible snippets of need-to-know information. Yes, you do have a phone for that kind of thing. But my friend Colin McNamara said it best:

I can glance at my watch and get a notification without getting sucked into my phone


Tom’s Take

That’s what makes the wearable market so important. It’s not having the processing power of a Cray supercomputer on your arm or attached to your head. It’s having that power available when you need it, yet having the control to get information you need without other distractions. Wearables free you up to do other things. Like building or creating or simply just paying attention to something. Wearables make technology unobtrusive, whether it’s a quick text message or tracking the number of steps you’ve taken today. Sci-Fi is filled with pictures of amazing technology all designed to do one thing – let us be human beings. We drive the direction of product development. Instead of crying for lighter, faster, and longer all the time, we should instead focus on building the right interface for what we need and tell the manufacturers to build around that.

 

Are Your Tweets Really Your Own?

new-twitter-logo350105_lg

We’ve all seen it recently. Twitter bios and blog profile pages with some combination of the following:

My tweets are my own.

Retweets are not endorsements.

My views do not represent my employer.

It has come to the point where the people in the industry are more visible and valuable than the brands they work for. Personal branding has jumped to the forefront of marketing strategies. But with that rise in personal branding comes a huge risk for companies. What happens when one of our visible stars says something we disagree with? What happens when we have to pull back?

Where Is My Mind?

Social media works best when it’s genuine. People sharing thoughts and ideas with each other without filters or constraint. Where it breaks down is when an external force starts interfering with that information exchange. Think about corporate social media policies that restrict what you can say. Or even policies that say your Twitter handle has to include the company you work for (yes, that exists). Why should my profile have to include miles of disclaimers telling people that I’m not a robot?

Is it because we have become so jaded as to believe that people can’t divorce their professional life from their personal life? Or is it because the interference from people telling you the “right way” to do social media has forced people to become robotic in their approach to avoid being disciplined?

Personal accounts that do nothing but reinforce the party line are usually unimportant to the majority of social media users. The real draw with speaking to someone from a company is the interaction behind the message. If a person really believes in the message then it shows through in their discussions without the need to hit all the right keywords or link to the “right” pages on a site.

Voices Carry

If you want more genuine, organic interaction with your people in the social world, you need to take off the leash. Don’t force them to put disclaimers in their profiles. Don’t make them take up valuable real estate telling the world what most of them already know. People speak for themselves. Their ideas and thoughts belong to them. Yes, you can tell the difference between when someone is parroting the party line and giving a real, honest introspective look at a discussion. People are not robots. Social media policies shouldn’t treat them as such.


Tom’s Take

I find myself in the situation that I’ve described above. I have to be careful with the things I say sometimes. I’m always ready to hit the Delete button on a tweet before it goes out. But what I don’t do is disclaim all over the place that “my tweets are my own”. Because everyone that I work with knows my mind. They know when I’m speaking for me and when I’m not. There is trust that I will speak my mind and stand by it. That’s the key to being honest in social media. Trust that your audience will understand you. Have faith in them. Which is something that a profile disclaimer can’t do.

 

HP Is Buying Aruba. Who’s Next?

HPAruba_Networks_Logo

Sometimes all it takes is a little push. Bloomberg reported yesterday that HP is in talks to buy Aruba Networks for their wireless expertise. The deal is contingent upon some other things, and the article made sure to throw up disclaimers that it could still fall through before next week. But the people that I’ve talked to (who are not authorized to comment and wouldn’t know the official answer anyway) have all said this is a done deal. We’ll likely hear the final official confirmation on Monday afternoon, ahead of Aruba’s big Atmosphere (nee Airheads) conference.

R&D Through M&A

This is a shot in the arm for HP. Their Colubris-based AP lineup has been sorely lacking in current generation wireless technology, let alone next gen potential. The featured 802.11ac APs on their networking site are OEMed directly from Aruba. They’ve been hoping to play the OEM game for a while and see where the chips are going to fall. Buying Aruba gives them second place in the wireless market behind Cisco overnight. It also fixes the most glaring issue with Colubris – R&D. HP hasn’t really been developing their wireless portfolio. Some had even thought it was gone for good. This immediately puts them back in the conversation.

More importantly to HP, this acquisition cuts off many of their competitor’s wireless plans at the knees. Dell, Juniper, Brocade, Alcatel Lucent, and many others OEM from Aruba or have a deep partnership agreement. By wrapping up the entirety of Aruba’s business, HP has dealt a blow to the single-source vendors that are playing in the wireless market. And this is going to lead to some big changes relatively soon.

The Startup Buzz

Dell is perhaps the most impacted by this announcement. A very large portion of their wireless offerings were Aruba. They sold APs, controllers, and even ClearPass through their channels (with the names filed off, of course). Now, they are back to square one. How are they going to handle the most recent deals? What are their support options?

I little thought exercise with my friend Josh Williams (@JSW_EdTech) had a few possibilities:

  1. Dell forces HP to buyout all the support contracts for Dell/Aruba customers. That makes sense for Dell, but it will turn a lot of customers against them, especially when HP lets those customers know the reasons why.
  2. Dell agrees to release the developments they’ve done on the platform to HP in return for HP taking the support business. Quiet and clean. Which is why it likely won’t happen.
  3. Dell pays HP an exorbitant amount of money to take the support contracts. This gives HP the capital to take on all those new support contracts and gives Dell an exit to rebuild. This is probably what HP wants, but could end up sinking the deal.

Dell got burned, plain and simple. They likely could have purchased Aruba months ago and solidified the relationship. Instead, they are now looking for a new partner. However, I don’t think they are going to get burned again. Rather than shopping for a friend, they are going to be shopping for an acquisition. My money has always been on Aerohive. They have an existing relationship. The Aerohive controller-less cloud model fits Dell’s new strategies. And they would be a much cheaper pickup than Aruba. There is precedence for Dell skipping the big name and picking up a smaller company that’s a better fit. It’s a hard pill to swallow, but it gives Dell the chance to move forward with a lasting relationship.

Softwarely Defined

Brocade is a line-of-business partner of Aruba. They’ve only recently gotten involved since Motorola shut down their WLAN business. This is a good sign for them. That means they can exit from their position and not be significantly affected. It does leave them with a quandary of where to go.

The first choice would be to go back to the Motorola relationship, now in the form of Zebra Technologies. Zebra inherited quite a large portion of the WLAN space from Motorola, but they’ve been keeping rather quiet about it. Are they angling to be more of a support organization for existing installs? Or are they waiting for a big splash announcement to get back in the game? Partnering with Brocade would give them that announcement given the elevated profile Brocade has today.

Brocade’s other option would be to go down the SDN road. The plan for a while has been to embrace SDN, OpenFlow, and all things software defined. The natural target for this would be Meru Networks. Meru has been embracing SDN as well as of late. They had a nice event last year showcasing their advances in SDN. Brocade could bolster that SDN knowledge while obtaining a good wireless company that would give them the strength they need to augment their enterprise business.

Permission To Retire

The odd company out is Juniper. I’ve heard that they were involved at first in trying to acquire Aruba, but when you’re betting against HP’s pockets you will lose in the long run. Their other problem is Elliott Management, everyone’s new favorite “activist investor”.

Elliott has made no secret that they see the value in Juniper in the service provider market. As far back as last year, Elliott has been trying to get Juniper to reave off the ancillary businesses, including security, enterprise, and wireless. Juniper has officially ended sales for Trapeze-based products already. Why would Elliott let them buy another wireless company so soon after getting rid of the last one. Even as successful as Aruba is, Elliott would see it as another distraction. And when someone that active is calling the shots, you can’t go against them, lest you end up unemployed.

This is the end for Juniper’s wireless aspirations. That’s not a bad thing, necessarily. This gives them the impetus needed to focus on the service provider market. It also gives them a smaller enterprise switching portfolio to package up and sell off should that pound of flesh be necessary to sate Elliott as well. Time will tell.

Everyone Else

Any other companies with Aruba relationships are either dipping their toes in the wireless waters or don’t care enough to worry about the impact it will have. It will be an easy matter for companies like Alcatel-Lucent to go out and find a new OEM partner, likely with someone like Extreme Networks or Ruckus. Those companies are making great technology and will be happy to supply the APs that customers need. Showing off their technology will also give them great in-roads into customers that might not have been on their radar before.


Tom’s Take

It’s going to be an exciting time in the wireless space. HP’s acquisition is going to start the falling dominoes for other companies to buy into the wireless space as well. When the dust settles, there will be new number twos and number threes in the market. It also clears the middle of the space for up-and-comers to grow. Cisco is going to stay number one for a while, and HP will be number two when this deal closes. But until we see the fallout from who will be purchased and partnered with it’s tough to say who will be a clear winner. But make sure you’ve got your popcorn ready. Because this isn’t over yet. Not by a long shot.

 

Cumulus Networks Could Be The New Microsoft

CumulusMSTurtle

When I was at HP Discover last December, I noticed a few people running around wearing Cumulus Networks shirts. That had me a bit curious, as Cumulus isn’t usually on the best of terms with traditional networking vendors unless they have a partnership. After some digging, I found out that HP would be announcing a “britebox” branded whitebox switch soon running Cumulus Linux. I wrote a post vaguely hinting about this in as much detail as I dared leak out.

No surprise that HP has formally announced their partnership with Cumulus. This is a great win for HP in the long run, as it gives customers the option to work with an up-and-coming network operating system (NOS) along side HP support and hardware. Note that the article mentions a hardware manufacturing deal with Accton, but I wouldn’t at all be surprised to learn that Accton had been making a large portion of their switching line already. Just a different sticker on this box.

Written Once, Runs Everywhere

The real winner here is Cumulus. They have partnered with Dell and HP to bring their NOS to some very popular traditional network vendor hardware. Given that they continue to push Cumulus Linux on traditional whitebox hardware, they are positioning themselves the same way that Microsoft did back in the 1980s when the IBM Clone PC market really started to take off.

Microsoft’s master stroke wasn’t building an empire around a GUI. It was creating software that ran on almost every variation of devices in the market. That common platform provided consistency for programmers the world over. You never had to worry about what OS was running on an IBM Clone. You could be almost certain it was MS-DOS. In fact, that commonality of platform is what enabled Microsoft to build their GUI interface on top. While DOS was eventually phased out in favor of WinNT kernels in Windows the legacy of DOS still remains on the command line.

Hardware comes and goes every year. Even with device vendors that are very tied to their hardware, like Apple. Look at the hardware differences between the first iPhone and the latest iPhone 6+. They are almost totally alien. Then look at the operating system running on each of them. They are remarkably similar, especially amazing given the eight year gap between them. That consistency of experience has allowed app developers to be comfortable writing apps that will work for more than one generation of hardware.

Bash Brothers

Cumulus is positioning themselves to do something very similar. They are creating a universal NOS interface to switches. Rather than pinning their hopes on the aging Cisco IOS CLI (and avoiding a potential lawsuit in the process), Cumulus has decided to go with Bash. Bash is almost universal for those that work on Linux, and if you’re an old school UNIX admin it doesn’t take long to adapt to Bash either. That common platform means that you have a legion of trained engineers and architects that know how to use your system.

More importantly, you have a legion of people that know how to write software to extend your system. You can create Bash scripts and programs to do many things. Cumulus even created ifupdown2 to help network admins with simplifying network interface administration. If you can extend the interface of a networking device with relative ease, you’ve started unlocking the key to unlimited expansion.

Think about the number of appliances you use every day that you never know are running Linux. I said previously that Linux won the server war because it is everywhere now and yet you don’t know it’s Linux. In the same way, I can see Cumulus negotiating to get the software offered as an option for both whitebox and britebox switches in the future. Once that happens, you can start to see the implications. If developers are writing apps and programs to extend Cumulus Linux and not the traditional switch OS, consumers will choose the more extensible option if everything else is equal. That means more demand for Cumulus. Which pours more resources into development. Which is how MS-DOS took over the world and led to Windows domination, while OS/2 died a quiet, protracted death.


Tom’s Take

When I first tweeted my thoughts about Cumulus Networks and their potential rise like the folks in Redmond, there was a lot of pushback. People told me to think of them more like Red Hat instead of Microsoft. While their business model does indeed track more closely with Red Hat, I think much of this pushback comes from the negative connotations we have with Windows. Microsoft has essentially been the only game in the x86 market for a very long time. People forget what it was like to run BeOS or early versions of Slackware. Microsoft had almost total domination outside the hobby market.

Cumulus doesn’t have to unseat Cisco to win. They don’t even have to displace the second or third place vendor. By signing deals with as many people as possible to bring Cumulus Linux to the masses, they will win in the long run by being the foundation for where networking will be going in the future.

Editor Note:  A previous version of this article incorrectly stated that Cumulus created ifupdown, when in fact they created ifupdown2.  Thanks to Matt Stone (@BigMStone) and Todd Craw (@ToddMCraw) for pointing this out to me.

Hypermyopia In The World Of Networking

myopia

The more debate I hear over protocols and product positioning in the networking market today, the more I realize that networking has a very big problem with myopia when it comes to building products. Sometimes that’s good. But when you can’t even see the trees for the bark, let alone the forest, then it’s time to reassess what’s going on.

Way Too Close

Sit down in a bar in Silicon Valley and you’ll hear all kinds of debates about which protocols you should be using in your startup’s project. OpenFlow has its favorite backers. Others say things like Stateless Transport Tunneling (STT) are the way to go. Still others have backed a new favorite draft protocol that’s being fast-tracked at the IETF meetings. The debates go on and on. It ends up looking a lot like this famous video.

But what does this have to do with the product? In the end, do the users really care which transport protocol you used? Is the forward table population mechanism of critical importance to them? Or are they more concerned with how the system works? How easy it is to install? How effective it is at letting them do their jobs?

The hypermyopia problem makes the architecture and engineering people on these projects focus on the wrong set of issues. They think that an elegant and perfect solution to a simple technical problem will be the magical panacea that will sell their product by the truckload. They focus on such minute sets of challenges that they often block out the real problems that their product is going to face.

Think back to IBM in the early days of the Internet. Does anyone remember Blue Lightning? How about the even older MCA Bus? I bet if I said OS/2 I’d get someone’s attention. These were all products that IBM put out that were superior to their counterparts in many ways. Faster speeds, better software architecture, and even revolutionary ideas about peripheral connection. And yet all of them failed miserably in one way or another. Was it because they weren’t technically complete? Or was it because IBM had a notorious problem with marketing and execution when it came to non-mainframe computing?

Take A Step Back

Every writer in technology uses Apple as a comparison company at some point. In this case, you should take a look at their simplicity. What protocol does FaceTime use? Is it SIP? Or H.264? Does it even matter? FaceTime works. Users like that it works. They don’t want to worry about traversing firewalls or having supernodes available. They don’t want to fiddle with settings and tweak timers to make a video call work.

Enterprise customers are very similar. Think about WAN technologies for a moment. Entire careers have been built around finding easy ways to connect multiple sites together. We debate Frame Relay versus ATM. Should we use MPLS? What routing protocol should we use? The debates go on and on. Yet the customer wants connectivity, plain and simple.

At the recent Networking Field Day 9, two companies that specialize in software defined WAN (SD-WAN) had a chance to present. Velocloud and CloudGenix both showcased their methods for creating WANs with very little need for user configuration. The delegates were impressed that the respective company’s technologies “just worked”. No tuning timers. No titanic arguments about MPLS. Just simple wizards and easy configuration.

That’s what enterprise technology should be. It shouldn’t involve a need to get so close to the technology that you lose the big picture. It shouldn’t be a series of debates about which small technology choice to make. It should just work. Users that spend less time implementing technology spend more time using it. They spend more time happy with it. And they’re more likely to buy from you again.


Tom’s Take

If I hear one more person arguing the merits of their technology favorite again, I may throw up. Every time someone comes to me and tells me that I should bet on their horse in the race because it is better or faster or more elegant, I want to grab them by the shoulders and shake some sense into them. People don’t buy complicated things. People hate elegant but overly difficult systems. They just want things to work at the end of the day. They want to put as little thought into a system as they can to maximize the return they get from it. If product managers spent the next iteration of design focusing on ease-of-use instead of picking the perfect tunneling protocol, I think they would see a huge return on their investment in the long run. And that’s something you can see no matter how close you are.