Category Archives: Musing

Time For A Data Diet?

Posted on by
1
Embed from Getty Images

I’m running out of drive space. Not just on my laptop SSD or my desktop HDD. But everywhere. The amount of data that I’m storing now is climbing at an alarming rate. What’s worse is that I often forget I have some of it until I go spelunking back through my drive to figure out what’s taking up all that room. And it’s a problem that the industry is facing too.

The Data Junkyard

Data is accumulating. You can’t deny that. Two factors have lead to this. The first is that we now log more data from things than ever before. In this recent post from Chris Evans (@ChrisMEvans), he mentions that Virgin Atlantic 787s are generating 500GB of data per flight. I’m sure that includes telemetry, aircraft performance, and other debugging information that someone at some point deemed crucial. In another recent article from Jacques Mattheij (@JMattheij), he mentions that app developers left the debug logging turned on, generating enormous data files as the system was in operation.

Years ago we didn’t have the space to store that much data. We had to be very specific about what needed to be capture and stored for long periods of time. I can remember having a 100MB hard drive in my first computer. I can also remember uninstalling and deleting several things in order to put a new program on. Now there is so much storage space that we don’t worry about running out unless a new application makes outrageous demands.

You Want To Use The Data?

The worst part about all this data accumulation is that once it’s been stored, no one ever looks at it again. This isn’t something that’s specific to electronic data, though. I can remember seeing legal offices with storage closets dedicated to boxes full of files. Hospitals have services that deal with medical record storage. In the old days, casinos hired vans to shuffle video tapes back and forth between vaults and security offices. All that infrastructure just on the off-chance that you might need the data one day.

With Big Data being a huge funding target and buzzword source today, you can imagine that every other startup in the market is offering to give you some insight into all that data that you’re storing. I’ve talked before about the drive for analysis of data. It’s the end result of companies trying to make sense of the chaos. But what about the stored data?

Odds are good that it’s going to just sit there in perpetuity. Once the analysis is done on all this data, it will either collect dust in a virtual file box until it is needed again (perhaps) in the far future or it will survive until the next SAN outage and never be reconstructed from backup. The funny thing about this collected data cruft is that no one misses it until the subpoena comes.

Getting Back To Fighting Weight

The solution to the problem isn’t doing more analysis on data. Instead, we need to start being careful about what data we’re storing in the first place. When you look at personal systems like Getting Things Done, they focus on stemming the flow of data quickly to give people more time to look at the important things. In much the same way, instead of capturing every bit coming from a data source and deciding later what to do with it, the decision needs to be made right away. Data Scientists need to start thinking like they’re on a storage budget, not like they’ve been handed the keys to the SAN kingdom.

I would be willing to bet that a few discrete decisions in the data collection process about what to keep and what to throw away would significantly cut down on the amount data we need to store and process. Less time spent querying and searching through that mess would optimize data retrieval systems and make our infrastructure run much faster. Think of it like spring cleaning for the data garage.

Tom’s Take

I remember a presentation at Networking Field Day a few years ago when Statseeker told us that they could scan data points from years in the past down to the minute. The room collectively gasped. How could you look that far back? How big are the drives in your appliance? The answer was easy: they don’t store every little piece of data coming from the system. They instead look at very specific things that tell them about the network and then record those with an eye to retrieval in the future. They optimize at storage time to help the impact of lookup in the future.

Rather than collecting everything in the world in the hopes that it might be useful, we need to get away from the data hoarding mentality and trim down to something more agile. It’s the only way our data growth problem is going to get better in the near future.

If you’d like to hear some more thoughts on the growing data problem, be sure to check out the Tech Talk sponsored by Fusion-io.

 

A Bright And Happy 2015 Ahead

Posted on by
3

Welcome to a new year finally divisible by five! This is a year devoid of extra February days, Olympics, or anything else. It’s a chance for us to take a look at technology and make things better and easier for users and IT staff. It’s also probably going to be called the year of VDI, NFV, and SDN. Again.

Rather than writing a wrap up post for the end of 2014 like so many other sites, I like to look at what I said I was going to do 365 days ago and see if I followed through on them. It’s a way to keep myself honest and also to see how the year transformed around me and my goals.

Looking at 2014

Thankfully, my goals for 2014 were modest. I wanted to get more involved with the people in the IT industry. And I did that in a big way. I went to a ton of conferences and events through the year. Cisco Live, VMworld, and HP Discover Barcelona were all on my list this year, as well as all of the Tech Field Day events I took part in as an organizer. It was a grand opportunity to meets lots of people in the technology space. I got to interact with the old guard and see the rise of new stars. Jobs changed. People sought out new careers. And through it all I got a real sense that the people that are going to change the world in technology are passionate about what they do.

Passion is the key to making sense out of what we do. I’m not saying that you have to be so in love with your job that you are blinded to the world. What I mean is that you need to have passion about the things that matter to you. For me, it’s about seeing new technology and exposing people to it. I love Tech Field Day. It warms my heart when people come to me during and after the event and tell me that they were able to see so much more than they imagined. When a delegate tells me they finally had a chance to meet one of their tech idols or had a game changing conversation during the limo ride between presenters I genuinely smile. Those are the kinds of moments that make everything worth it for me.

What’s In Store For 2015?

For now, the major things aren’t going to change any time soon. My Bruce Wayne job is still going to be Tech Field Day. My Batman job is going to be writing on this blog. But I’m going to try a few new things and see how they work out.

Markdown

I’ve played around with the idea of writing in Markdown for a while now. It’s a simple language that turns thoughts into HTML with out needing to remember some of the more irritating code sections. I’ve never really committed to it before, looking at it more as a hobby or a thing I would eventually get to. Well, for 2015 I’m going to commit to writing all of my posts in Markdown. There’s no better way to learn than a trial by fire. I don’t think the regular posts are going to be a big deal, but the 2015 Cisco Live Twitter List could be fun.

If you’d like to see a great reference sheet for Markdown, check out Greg Ferro’s (@EtherealMind) page on Markdown Reference.

Blog Themes

I wanted to retheme my blog for 2015. I investigated several options and ultimately abandoned all of them because I could never find the right combination. I’m picky about many things I work with every day, including my blog theme, my backpack/messenger bag, and my computer desk. Since I’m hosted on WordPress.com, I can’t just install any theme I want or make modifications to it as I would like. I’m going to keep investigating some ideas and may try them out now and then. Just don’t be surprised if things look slightly different one day in the near future.

Cisco Live Managmement

One of the ideas that I’m going to float out here six months early for Cisco Live is a poll/form for picking the best time to take the Twitter photo. Every year for the last four years we’ve taken a huge photo with all the social media crew at Cisco Live. In the past couple of years we’ve had some issues getting everyone in the picture due to scheduling. This year, Jeff Fry (@FryGuy_PA) and I want to make sure that no one is left out that wants to be in the big photo because of their schedule. I’m going to put up a poll in the next couple of months to pick the best possible time for the photo. And we’ll make sure to publish the results and work with the Cisco Live Social Media staff to get the photographer for that time.

I’m also looking at creating some other spreadsheets to keep track of other information during the event, so if you get a random email from me about it keep in mind that I’m trying to keep myself sane this year.

Tom’s Take

I’m excited for 2015. There’s going be a lot of technology to write about. Tech Field Day will be in Austin, Boston, and Silicon Valley. We’re going to be talking about wireless, networking, storage, and event Big Data! I’m also looking forward to reconnecting with my friends and peers this year and meeting new and exciting people. Through it all, I’m going to be writing away here as well to put my thoughts down about trends and ideas in the industry. There may be the occasional technical piece now and then, since explanation of complex tech subjects is something I think there needs to be more of.

To my readers, thanks for helping me realize how important blogging is the community. Keep posting comments and sharing my thoughts with the world. And in 2015 we’ll have more fun that we’ve had in a long while.

Q And A Should Include The E

Posted on by
3

The IT world is cyclical for sure. I’ve seen trends and topics repeating themselves over and over again in my relatively short time here. I find it interesting that we keep solving similar problems over and over again. I also find it fascinating that this particular issue leads to the reason why blogs are so important.

Any Questions?

Questions abound in IT. It’s the nature of the industry. However, it’s not just new questions that we create when technology leaps past us. We keep asking the same questions over and over again. This is the field of study that created the FAQ, remember?

In recent memory, I find the same questions being asked over and over again:

  • What is SDN?
  • How can SDN help me?
  • What makes this different from what we’ve done before?

You’ve probably asked those very same questions. Perhaps you found the answers you were looking for. Perhaps you’re still trying to figure it out. The problem is that those questions are still being asked. The industry should have evolved to the point where the simple questions have been answered with simple answers. Complex questions, or those questions that need more in-depth discussion, should be treated as such. Yes, the question of what SDN really is would take more than a cursory paragraph on a blog, but we should be able to at least answer it with enough specificity to make the user not feel like they been slighted.

Questions will never stop coming in IT. But how should we handle them?

Any Answers?

Questions may abound in IT, but the answers drive IT. People make a career out of being the person with the answers. It’s in all the marketing jargon. It’s why we create blogs. Even though most of my writing in the last year has been focused on industry trends or non-technical focused posts, the top three posts on my blog are still answers to simple questions:

  1. When Is A Trunk Not A Trunk?
  2. Switchport Voice VLAN – What Does It Do?
  3. Why Is My SFP Not Working?

These posts are far and away the most popular. I even saw this a few months ago and it made me smile:

This would make it seem like people are in need of answers. Any blogger can look at the incoming search terms for their blog and see all the things that brought readers to them. People want answers and they will keep looking until they find them. But why?

Explain It

I never understood why people kept searching for answers until I thought about satisfaction. I think Randall Munroe summed up the satisfaction (or lack thereof) angle here:

Who are you, DenverCoder9?!? (Thanks XKCD)
Who are you, DenverCoder9?!? (Thanks XKCD)

People can find answers easily. But they won’t stop looking until they are satisfied with the answer. It’s easy to find people saying things like “That’s not supported” or “RTFM” when you’re looking for an answer to a particularly difficult problem. And if you’ve ever called a tech support line, you know how unfulfilling the unsupported answer can feel.

That’s when explanation comes into play for me. First, an admission: I’m a chronic explainer. If you’ve ever met me and had a conversation with me for more than three minutes, you know I explain things. I talk about comic books and movies and technical topics in more depth than I should. That’s because I want things explained to me. Explaining how OSPF area calculations are done is as important as explaining how Captain America ended up wielding Mjolnir.

Think about the following answers:

This is unsupported.

or

This is unsupported on that platform because the CPU doesn’t have enough horsepower to process the packets in real time. We tried cutting down on the processing time but it just overwhelmed the unit no matter how much we tried. So rather than dealing with poor performance, we marked it as unsupported.

Both answers are technically correct. But the second is much more satisfying because the explanation is there instead of just the distilled answer.

The IT world needs more explanation. We need to know why things work the way they do instead of just getting a response of a few words. The explanation has the keys to understanding the answer to the question in its totality. It prevents us from asking the same questions over and over again. It leaves us fulfilled and ready to seek out the next question that needs to be asked.

Expiring The Internet

Posted on by
Reply
Embed from Getty Images

An article came out this week that really made me sigh.  The title was “Six Aging Protocols That Could Cripple The Internet“.  I dove right in, expecting to see how things like Finger were old and needed to be disabled and removed.  Imagine my surprise when I saw things like BGP4 and SMTP on the list.  I really tried not to smack my own forehead as I flipped through the slideshow of how the foundation of the Internet is old and is at risk of meltdown.

If It Ain’t Broke

Engineers love the old adage “If it ain’t broke, don’t fix it!”.  We spend our careers planning and implementing.  We also spend a lot of time not touching things afterwards in order to prevent it from collapsing in a big heap.  Once something is put in place, it tends to stay that way until something necessitates a change.

BGP is a perfect example.  The basics of BGP remain largely the same from when it was first implemented years ago.  BGP4 has been in use since 1994 even though RFC 4271 didn’t officially formalize it until 2006.  It remains a critical part of how the Internet operates.  According to the article, BGP is fundamentally flawed because it’s insecure and trust based.  BGP hijacking has been occurring with more frequency, even as resources to combat it are being hotly debated.  Is BGP to blame for the issue?  Or is it something more deeply rooted?

Don’t Fix It

The issues with BGP and other protocols mentioned in the article, including IPv6, aren’t due to the way the protocol was constructed.  It is due in large part to the humans that implement those protocols.  BGP is still in use in the current insecure form because it works.  And because no one has proposed a simple replacement that accomplishes the goal of fixing all the problems.

Look at IPv6.  It solves the address exhaustion issue.  It solves hierarchical addressing issues.  It restores end-to-end connectivity on the Internet.  And yet adoption numbers still languish in the single digit percentage.  Why?  Is it because IPv6 isn’t technically superior? Or because people don’t want to spend the time to implement it?  It’s expensive.  It’s difficult to learn.  Reconfiguring infrastructures to support new protocols takes time and effort.  Things that are better spent on answering user problems or taking on additional tasks as directed by management that doesn’t care about BGP insecurity until the Internet goes down.

It Hurts When I Do This

Instead of complaining about how protocols are insecure, the solution to the problem should be two fold: First, we need to start building security into protocols and expiring their older, insecure versions.  POODLE exploited SSLv3, an older version that served as a fallback to TLS.  While some old browsers still used SSLv3, the simple easy solution was to disable SSL and force people to upgrade to TLS-capable clients.  In much the same way, protocols like NTP and BGP can be modified to use more security.  Instead of suggesting that people use those versions, architects and engineers need to implement those versions and discourage use of the old insecure protocols by disabling them.  It’s not going to be easy at first.  But as the movement gains momentum, the solution will work.

The next step in the process is to build easy-to-configure replacements.  Bolting security onto a protocol after the fact does stop the bleeding.  But to fix the underlying symptoms, the security needs to be baked into the protocol from the beginning.  But doing this with an entirely new protocol that has no backwards compatibility will be the death of that new protocol.  Just look at how horrible the transition to IPv6 has been.  Lack of an easy transition coupled with no monetary incentive and lack of an imminent problem caused the migration to drag out until the eleventh hour.  And even then there is significant pushback against an issue that can no longer be ignored.

Building the next generation of secure Internet protocols is going to take time and transparent effort.  People need to see what’s going into something to understand why it’s important.  The next generation of engineers needs to understand why things are being built the way they are.  We’re lucky in that many of the people responsible for building the modern Internet are still around.  When asked about limitations in protocols the answer remains remarkably the same – “We never thought it would be around this long.”

The longevity of quick fixes seems to be the real issue.  When the next generation of Internet protocols is built there needs to be a built-in expiration date.  A point-of-no-return beyond which the protocol will cease to function.  And there should be no method for extending the shelf life of a protocol to forestall it’s demise.  In order to ensure that security can’t be compromised we have to resign ourselves to the fact that old things need to be put out to pasture.  And the best way to ensure that new things are put in place to supplant them is to make sure the old things go away on time.

Tom’s Take

The Internet isn’t fundamentally broken.  It’s a collection of things that work well in their roles that maybe have been continued a little longer than necessary.  The probability of an exploit being created for something rises with every passing day it is still in use.  We can solve the issues of the current Internet with some security engineering.  But to make sure the problem never comes back again, we have to make a hard choice to expire protocols on a regular basis.  It will mean work.  It will create strife.  And in the end we’ll all be better for it.

The Trap of Net Neutrality

Posted on by
1

net-neutrality

The President recently released a video and statement urging the Federal Communications Commission (FCC) to support net neutrality and ensure that there will be no “pay for play” access to websites or punishment for sites that compete against a provider’s interests.  I wholeheartedly support the idea of net neutrality.  However, I do like to stand on my Devil’s Advocate soapbox every once in a while.  Today, I want to show you why a truly neutral Internet may not be in our best interests.

Lawful Neutral

If the FCC mandates a law that the Internet must remain neutral, it will mean that all traffic must be treated equally.  That’s good, right?  It means that a provider can’t slow my Netflix stream or make their own webmail service load faster than Google or Yahoo.  It also means that the provider can’t legally prioritize packets either.

Think about that for a moment.  We, as network and voice engineers, have spent many an hour configuring our networks to be as unfair as possible.  Low-latency queues for voice traffic.  Weighted fair queues for video and critical applications.  Scavenger traffic classes and VLANs for file sharers and other undesirable bulk noise.  These plans take weeks to draw up and even longer to implement properly.  It helps us make sense out of the chaos in the network.

By mandating a truly neutral net, we are saying that those carefully marked packets can’t escape from the local network with their markings intact.  We can’t prioritize voice packets once they escape the edge routers.  And if we move applications to the public cloud, we can’t ensure priority access.  Legally, the providers will be forced to remark all CoS and DSCP values at the edge and wash their hands of the whole thing.

And what about provider MPLS circuits?  If the legally mandated neutral provider is administering your MPLS circuits (as they do in small and medium enterprise), can they copy the DSCP values to the MPLS TE field before forwarding the packet?  Where does the law stand on prioritizing private traffic transiting a semi-public link?

Chaotic Neutral

The idea of net neutrality is that no provider should have the right to decide how your traffic should be handled.  But providers will extend that idea to say they can’t deal with any kind of marking.  They won’t legally be able to offer you differentiated service even if you were wiling to pay for it.  That’s the double-edge sword of neutrality.

You can be sure that the providers will already have found a “solution” to the problem.  Today, quality of service (QoS) only becomes an issue when the link becomes congested.  Packets don’t queue up if there’s bandwidth available to use.  So the provider solution is simple.  If you need differentiated service, you need to buy a bigger pipe.  Over provision your WAN circuits!  We can’t guarantee delivery unless you have more bandwidth than you need!  Who cares what the packets are marked?  Which, of course, leads to a little gem from everyone’s favorite super villain:

SyndromeEF

Of course, the increased profits from these services will line the pockets of the providers instead of going to build out the infrastructure necessary to support these overbuilt networks.  The only way to force providers to pony up the money to build out networks is to make it so expensive to fail that the alternative is better.  That requires complex negotiation and penalty-laden, iron-clad service level agreements (SLAs).

The solution to the issue of no prioritized traffic is to provide a list of traffic that should be prioritized.  Critical traffic like VoIP should be allowed to be expedited, as the traffic characteristics and protections we afford it make sense.  Additionally, traffic destined for a public cloud site that function as internal traffic of a company should be able to be prioritized across the provider network.  Tunneling or other forms of traffic protection may be necessary to ensure this doesn’t interfere with other users.  Exempt traffic should definitely be the exception, not the rule.  And it should never fall on the providers to determine which traffic should be exempted from neutrality rules.

Tom’s Take

Net neutrality is key to the future of society.  The Internet can’t function properly if someone else with a vested interest in profits decides how we consume content.  It’s like the filter bubble of Google.  A blind blanket policy doesn’t do us any good, either.  Everyone involved in networking knows there are types of traffic that can be prioritized without having a detrimental effect.  We need to make smart decisions about net neutrality and know when to make exceptions.  But that power needs to be in the hands of the users and customers.  They will make decisions in their best interest.  The providers should have the capability to implement the needs of their customers.  Only then will the Internet be truly neutral.

Twitter, Please Stop Giving Me Things I Don’t Want

Posted on by
1

new-twitter-logo

Last week, Twitter confirmed that they will start injecting tweets from users you don’t follow into your timeline.  The collective cry from their user base ranged from outrage to a solid “meh”.  It seems that Twitter has stumbled onto the magic formula that Facebook has perfected: create a feature the users don’t care about and force it onto them.  Why?

Twitter Doesn’t Care About Power Users

Twitter has an interesting mix of users.  They reported earlier this year that 44% of their user base has never tweeted.  That’s a lot of accounts that were created for the purpose of reserving a name or following people in read-only mode.  That must concern Twitter.  Because people that don’t tweet can’t be measure for things like advertising.  They won’t push the message of a sponsored tweet.  They won’t add their voice to the din.  But what about those users that tweet regularly?

Power users are those that tweet frequently without a large follower base.  Essentially, everyone that isn’t a celebrity with a million followers or a non-tweeting account.  You know, the real users on Twitter.  The people that make typos in their tweets and actually check to see who follows them.  The ones that don’t have a “social media team” tweeting for them.  Nothing wrong with a team tweeting for a brand, but when they’re tweeting for a person it’s a little disconcerting.

Power users keep getting screwed by Twitter.  The API changes really hurt those that use clients other than the official ones.  Given that Twitter has killed most of it’s “official” clients in favor of pushing people to use the web, it makes you wonder what their strategy might be.  They are entirely beholden to their investors right now.  That means user signups and ad revenue.  And it means focusing on making the message widespread.  Why worry about placating the relatively small user base that uses your product when you can create a method for reaching millions with a unicast sponsored hashtag? Or by injecting tweets from people you don’t follow into your timeline?

The tweet injection thing is like a popup ad.  It serves the purpose of Twitter deciding to show you some tweets from other “users”.  Anyone want to bet those users will quickly start becoming corporate accounts? Perhaps they pay Twitter to ensure their tweets show up in a the timelines of a specific demographic.  It makes total sense when your users are nothing but a stream of revenue

Making Twitter Usable Again

I mentioned some things the other day that I think Twitter needs to do to make their service usable for power users again.  I wanted to expand on them a bit here:

The Unfollow Bug – Twitter has a problem with keeping followers.  For some reason, your account will randomly unfollow a user with no notification.  You usually don’t figure it out until you want to send them a DM or notice that they’ve unfollowed you and mention it.  It’s an irritating bug that’s been going on for years with no hope of resolution.  Twitter needs to sort this one out quickly.  As a side note, if you run a service that monitors people that have unfollowed you, consider adding a digest of users that I have unfollowed this week.  if the list doesn’t match those that I purposely unfollow, at least you know when you’ve been hit by this bug.

Links in Direct Messages – Twitter disabled the ability to send a link in a direct message a few months ago.  Their argument was that it cut down on spam.  The real reason was Twitter’s attempt to turn DMs into a instant message platform.  Twitter experimented with a setting that enabled DMs from users you don’t follow.  They pulled it before it went live due to user feedback.  One of the arguments was that spam accounts could bombard you with URLs that led to phishing attacks and other unsavory things.  Twitter responded by disabling links in DMs even though they removed the feature it was intended to protect.  It’s time for Twitter to give us this feature back.

Token Limits – This “feature” has to go.  Restricting 3rd party clients because they exist destroys the capabilities of your power users. I use a client because it gives me easy access to features I use all the time, like conversation views and muting.  I also don’t like sitting on the garish Twitter website and constantly refreshing to see new tweets.  I’d rather use some other client. Twitter has a love/hate relationship with non-official clients.  Mostly because those clients strip out ads and sponsored tweets.  They don’t let Twitter earn money from them.  Which is why Twitter is stamping them out for “replicating official client features” left and right.  Curiously enough, I’ve never heard about HootSuite being hit with user token limits.  But considering that a lot of Twitter’s favorite celebrities use it (or at least their social media teams do), I’m not shocked they’re on the exempt list.

Tom’s Take

I still find Twitter a very useful tool.  It’s not something that can just be set into automatic and left alone.  It takes curation and attention to make it work for you.  But it also needs help from Twitter’s side.  Instead of focusing on ways to make me see things I don’t care about from people I don’t want to follow, how about making your service work the way I want it to work.  I’m more like to use (and suggest) a service that works.  I barely check Facebook anymore because I’m constantly “fixing” their Top Posts algorithm.  Don’t turn your service into something I spend most of my time fixing.

The Great Tech Reaving

Posted on by
Reply
Embed from Getty Images

It seems as though the entire tech world is splitting up.  HP announced they are splitting the Personal Systems Group into HP, Inc and the rest of the Enterprise group in HP Enterprise.  Symantec is forming Veritas into a separate company as it focuses on security and leaves the backup and storage pieces to the new group.  IBM completed the sale of their x86 server business to Lenovo.  There are calls for EMC and Cisco to split as well.  It’s like the entire tech world is breaking up right before the prom.

Acquisition Fever

The Great Tech Reaving is a logical conclusion to the acquisition rush that has been going on throughout the industry for the past few years.  Companies have been amassing smaller companies like trading cards.  Some of the acquisitions have been strategic.  Buying a company that focuses on a line of work similar to the one you are working on makes a lot of sense.  For instance, EMC buying XtremIO to help bolster flash storage.

Other acquisitions look a bit strange.  Cisco buying Flip Video.  Yahoo buying Tumblr. There’s always talk around these left field mergers.  Is the CEO looking for synergy? Is there a hidden play that we’re unaware of? Sometimes that kind of thinking pays off.  Other times you end up with Zimbra.  More often than not, the company ends up writing down the assets of the acquired company and taking very little from the purchase.  Maybe not as big as the Autonomy write down, but even getting rid of Flip can make waves.

It makes a person wonder what the point of an acquisition is if it’s just going to wind up being an accounting charge later.  Is it a tax shelter?  A way to use up outstanding cash?  Maybe even a way to buy a particularly good developer and fold them into your organization to keep them out of a competitor’s hands?  The reasons are myriad but it appears that the fever is dying down.  And that might end up hurting innovation in the long term.

This Is Not An Exit Strategy

Think about the startup out there making a hot new technology.  They had their heart set on getting bought by a bigger company in the market.  Now, they just watched that company split off half of their business into a new company.  Cash is hard to find for a new acquisition.  Now the startup has to find a different way to monetize things.  Should we redouble our efforts to market the product? Get new investors? Go public?

I’ve said before that pinning your hopes on getting purchased isn’t the best way to run a business.  It’s like betting all your hopes on getting the winning numbers in the lottery.  It might happen, but the odds are against it.  Perhaps the end result of a market full of split companies will be a reevaluation of the idea of an exit strategy.  Rather than building a business for the sole purpose of being bought entrepreneurs will start building businesses to make products and sell them.  It’s a radical idea, but not so radical as to be unbelievable.  Just ask Hewlett and Packard.  Or Jobs and Wozniak. Or anyone else that didn’t have an exit strategy instead of a business plan.

Tom’s Take

Companies can be too big.  IBM has sold off most of what made it IBM.  Symantec and HP are in the process.  The next domino to fall will be EMC.  Then Cisco.  After that, the landscape will look much different.  But in a good way.  It’s like a stock split.  The same amount of knowledge is out there.  It’s just held differently.  That’s good for the industry because it forces the status quo to change.  New alliances, new partnerships, and new synergies can be found by upsetting the apple cart now and then.

Rome Wasn’t Software Defined In A Day

Posted on by
Reply

Everywhere you turn, people are talking about software defined networking.  The influence can be felt in every facet of the industry.  Major players are trying to come to grips with the shift in power.  Small vendors are ramping up around ideas and looking to the future.  Professionals are simultaneously excited for change and fearful of upsetting the status quo.  But will all of these things happen overnight?

Not Built In A Day, But Laying Bricks Every Hour

The truth of SDN is that it’s going to take some time for all the pieces to fall into place.  Take a look at the recent Apple Pay launch.  Inside of a week, it has risen to become a very significant part of the mobile payment industry, even if the installed base of users is exclusive to iPhone [6,6+] owners.  But did this revolution happen in the span of a couple of days?

Apple Pay works because Apple spent months, if not years, designing the best way to provide transactions from a phone.  It leverages TouchID for security, a concept introduced last year.  It uses Near Field Communication (NFC) readers, which have been in place for a couple of years.  I even talked about NFC three years ago.  That means the technology to support Apple Pay has been in place for a while.

That kind of support structure is needed to make SDN work the way we want it to.  There’s no magic wand that will convert your infrastructure to SDN overnight.  There is no SDNecronomicon to reference for solving scaling issues or interoperability concerns.  What’s required is the hard work of taking the ideas and processes around SDN and implementing them today.

SDN feels like a radical shift to traditional networking because it’s a foreign concept.  If you had told the first generation iPhone users their device would be a application computer with the capability to pay for purchases wirelessly they would have laughed at you and told you it was a fantasy.  That sufficiently advanced technology was beyond their understanding at the time.

SDN is no different.  The steps being taken today to solve traditional networking problems will feel antiquated in four to five years.  But that foundation must be laid in order to make SDN work in the future.  SDN won’t transform the industry overnight, but we have to keep making advances and pushing forward to make the important gains no matter how small they are.

Not Built In A Day, But It Burned In One

The fear of SDN leads to the dark side of standards adoption.  Arguments. In-fighting. Posturing. Interests making decisions not because they are right for customers but because they protect market share.  If SDN fails in the long term, it will be because of these dark elements and not a technological constraint.

Nothing is immune to politics.  Linux has been more or less standardized for years.  Yet tech advances are still hotly debated.  Go mention systemd to your local Linux hacker and prepare for the onslaught of discussion.  Linux has had much less pressure from these kinds of discussions by virtue of the core kernel being very stable and maintained by a small team.  SDN is very different.

The competing ideas around SDN drive innovation, but also threaten it.  The industry will eventually standardize on OpenDaylight for their controller, much like the server industry standardized on Linux for appliances.  But will that same consensus lead to stagnation? Will innovation simply happen as vendors attempt to modify ODL just enough to make their offering look superior?  Before you say that it’s impossible go and find a reference TRILL implementation.

SDN will succeed because the momentum behind it won’t allow it to fail.  But much like Rome, we need to build SDN with the proper architecture.  Simply laying bricks haphazardly won’t fix our problems.  If the infrastructure is bad enough, we may even need our own Nero to “fix” things again.  Momentum without direction is a useless force.  We need to ensure that SDN is headed in the right direction where it benefits customers and users first.  Profit margins are secondary to that.

Tom’s Take

An idea can transform an industry.  A simple thought about making things better can drag the community out of stagnation and into a Renaissance.  That we are witness to an industry shift is undeniable at this point, especially given that so many things are becoming “software defined”.  However, we must face the truth that this little hobby project won’t produce results overnight.  Hard work and planning will win the day.  Rome went from being a village among hills to the largest power in the Western world.  But that didn’t happen overnight.  The long game of SDN needs to be played one move at a time.  And the building of the SDN empire will take more than a single day.

Moscone Madness

Posted on by
9

moscone1

The Moscone Center in San Francisco is a popular place for technical events.  Apple’s World Wide Developer Conference (WWDC) is an annual user of the space.  Cisco Live and VMworld also come back every few years to keep the location lively.  This year, both conferences utilized Moscone to showcase tech advances and foster community discussion.  Having attended both this year in San Francisco, I think I can finally state the following with certainty.

It’s time for tech conferences to stop using the Moscone Center.

Let’s face it.  If your conference has more than 10,000 attendees, you have outgrown Moscone.  WWDC works in Moscone because they cap the number of attendees at 5,000.  VMworld 2014 has 22,000 attendees.  Cisco Live 2014 had well over 20,000 as well.  Cramming four times the number of delegates into a cramped Moscone Center does not foster the kind of environment you want at your flagship conference.

The main keynote hall in Moscone North is too small to hold the large number of audience members.  In an age where every keynote address is streamed live, that shouldn’t be a problem.  Except that people still want to be involved and close to the event.  At both Cisco Live and VMworld, the keynote room filled up quickly and staff were directing the overflow to community spaces that were already packed too full.  Being stuffed into a crowded room with no seating or table space is frustrating.  But those are just the challenges of Moscone.  There are others as well.

I Left My Wallet In San Francisco

San Francisco isn’t cheap.  It is one of the most expensive places in the country to live.  By holding your conference in downtown San Francisco, you are forcing your 20,000+ attendees into a crowded metropolitan area with expensive hotels.  Every time I looked up a hotel room in the vicinity of VMworld or Cisco Live, I was unable to find anything for less than $300 per night.  Contrast that with Interop or Cisco Live in Las Vegas, where sub-$100 are available and $200 per night gets you into the hotel of the conference center.

Las Vegas is built for conferences.  It has adequate inexpensive hotel options.  It is designed to handle a large number of travelers arriving at once.  While spread out geographically, it is easy to navigate.  In fact, except for the lack of Uber, Las Vegas is easy to get around in than San Francisco.  I never have a problem finding a restaurant in Vegas to take a large party.  Bringing a group of 5 or 6 to a restaurant in San Francisco all but guarantees you won’t find a seat for hours.

The only real reason I can see for holding conferences at Moscone, aside from historical value, is the ease of getting materials and people into San Francisco.  Cisco and VMware both are in Silicon Valley.  Driving up to San Francisco is much easier than shipping the conference equipment to Las Vegas or Orlando.  But ease-of-transport does not make it easy on your attendees.  Add in the fact that the lower cost of setup is not reflected in additional services or reduced hotel rates and you can imagine that attendees have no real incentive to come to Moscone.

Tom’s Take

The Moscone Center is like the Cotton Bowl in Dallas.  While both have a history of producing wonderful events, both have passed their prime.  They are ill-suited for modern events.  They are cramped and crowded.  They are in unfavorable areas.  It is quickly becoming more difficult to hold events for these reasons.  But unlike the Cotton Bowl, which has almost 100 years of history, Moscone offers not real reason to stay.  Apple will always be here.  Every new iPhone, Mac, and iPad will be launched here.  But those 5,000 attendees are comfortable in one section of Moscone.  Subjecting your VMworld and Cisco Live users to these kinds of conditions is unacceptable.

It’s time for Cisco, VMware, and other large organizations to move away from Moscone.  It’s time to recognize that Moscone is not big enough for an event that tries to stuff in every user it can.  instead, conferences should be located where it makes sense.  Las Vegas, San Diego, and Orlando are conference towns.  Let’s use them as they were meant to be used.  Let’s stop the madness of trying to shoehorn 20,000 important attendees into the sardine can of the Moscone Center.

Do We Need To Redefine Open?

Posted on by
4

beer-mug

There’s a new term floating around that seems to be confusing people left and right.  It’s something that’s been used to describe a methodology as well as used in marketing left and right.  People are using it and don’t even really know what it means.  And this is the first time that’s happened.  Let’s look at the word “open” and why it has become so confusing.

Talking Beer

For those at home that are familiar with Linux, “open” wasn’t the first term to come to mind.  “Free” is another word that has been used in the past with a multitude of loaded meanings.  The original idea around “free” in relation to the Open Source movement is that the software is freely available.  There are no restrictions on use and the source is always available.  The source code for the Linux kernel can be searched and viewed at any time.

Free describes the fact that the Linux kernel is available for no cost.  That’s great for people that want to try it out.  It’s not so great for companies that want to try and build a business around it, yet Red Hat has managed to do just that.  How can they sell something that doesn’t cost anything?  It’s because they keep the notion of free sharing of code alive while charging people for support and special packages that interface with popular non-free software.

The dichotomy between unencumbered idea software and no cost software is so confusing that the movement created a phrase to describe it:

Free as in freedom, not free as in beer.

When you talk about freedom, you are unrestricted.  You can use the software as the basis for anything.  You can rewrite it to your heart’s content.  That’s your right for free software. When you talk about free beer, you set the expectation that whatever you create will be available at no charge.  Many popular Linux distributions are available at no cost.  That’s like getting beer for nothing.

Open, But Not Open Open

The word “open” is starting to take on aspects of the “free” argument.  Originally, the meaning of open came from the Open Source community.  Open Source means that you can see everything about the project.  You can modify anything.  You can submit code and improve something.  Look at the OpenDaylight project as an example.  You can sign up, download the source for a given module, and start creating working code.  That’s what Brent Salisbury (@NetworkStatic) and Matt Oswalt (@Mierdin) are doing to great effect.  They are creating the network of the future and allowing the community to do the same.

But “open” is being redefined by vendors.  Open for some means “you can work with our software via an API, but you can’t see how everything works”.  This is much like the binary-only NVIDIA driver.  Proprietary programming is pre-compiled and available to download for free, but you can’t modify the source at all.  While it works with open source software, it’s not open.

A conversation I had during Wireless Field Day 7 drove home the idea of this new “open” in relation to software defined networking.  Vendors tout open systems to their customers. They standardize on northbound interfaces that talk to orchestration platforms and have API support for other systems to call them.  But the southbound interface is proprietary.  That means that only their controller can talk to the network hardware attached to it.  Many of these systems have “open” in the name somewhere, as if to project the idea that they work with any component makeup.

This new “open” definition of having proprietary components with an API interface feels very disingenuous.  It also makes for some very awkward conversations:

$VendorA: Our system is open!

ME: Since this is an open system, I can connect my $VendorB switch and get full functionality from your controller, right?

$VendorA: What exactly do you mean by “full”?

Tom’s Take

Using “open” to market these systems is wrong.  Telling customers that you are “open” because your other equipment can program things through a narrow API is wrong.  But we don’t have a word to describe this new idea of “open”.  It’s not exactly closed.  Perhaps we can call it something else.  Maybe “ajar”.  That might make the marketing people a bit upset.  “Try our new AjarNetworking controller.  As open as we wanted to make it without closing everything.”

“Open” will probably be dominated by marketing in the next couple of year.  Vendors will try to tell you how well they interoperate with everyone.  And I will always remember how open protocols like SIP are and how everyone uses that openness against it.  If we can’t keep the definition of “open” clean, we need to find a new term.