Author Archives: networkingnerd

Unknown's avatar

About networkingnerd

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

My Thoughts On The Death Of IP Telephony

Posted on by
2
A Candlestick Phone (image courtesy of WIkipedia)

A Candlestick Phone (image courtesy of Wikipedia)

Greg Ferro (@EtherealMind) posted a thought provoking article about collaboration in his Human Infrastructure magazine (which you should be reading). He talks about the death of IP Telephony and the rise of asynchronous communications methods like Slack. He’s got a very interesting point of view. I just happen to disagree with a few of his assertions.

IP Telephony Is Only Mostly Dead

Greg’s stance that IP Telephony is dead is a bit pointed to say the least. He is correct that the market isn’t growing. It is also true that a great number of new workers entering the workforce prefer to use their smartphones for communications, especially the asynchronous kind. However, desk phones are a huge part of corporate communications going forward.

IT shops have a stilted and bizarre world view. If you have a workforce that has to be mobile, whether it be for making service calls or going to customer sites for visits, you have a disproportionately large number of mobile users for sure. But what about organizations that don’t have large mobile populations? What about financial firms or law offices or hospitals? What about retail organizations? These businesses have specific needs for communications, especially with external customers and users.

Imagine if your pharmacy replaced their phone with a chat system? How about your doctor’s office throwing out their PBX and going to an email-only system? How would you feel about that? A couple of you might cheer because they finally “get it”. But a large number of people, especially more traditional non-technical folks, would switch providers or move their business elsewhere. That’s because some organizations rely on voice communications. For every millennial dumping their office phone to use a mobile device there is still someone they need to call on the other end.

We’re not even talking about the important infrastructure that still needs a lot of specialized communications gear. Fax machines are still a huge part of healthcare and legal work. Interactive Voice Response (IVR) systems are still crucial to handle call volumes for things like support lines. These functions can’t be replaced on mobile devices easily. You can fake IVRs and call queuing with the right setup, but faxing things to a mobile device isn’t possible.

Yes, services do exist to capture fax information as a TIFF or JPG and email it to the destination. But for healthcare and legal, this breaks confidentiality clauses and other important legal structures. The area around secure faxing via email is still a bit murky, and most of the searches you can do for the topic revolve around companies trying to tell you that it’s acceptable and okay to use (as long as you use their product).

IP Telephony isn’t far removed from buggy whip manufacturers. The oft-cited example of a cottage industry has relevance here. At some point after the introduction of the automobile, buggy whip growth slowed and eventually halted. But they didn’t go away permanently. The market did contract and still exists to this day. It’s not as big as the 13,000-strong market it once was, but it does exist today to meet a need that people still have. Likewise, IP Telephony will still have solutions to meet needs for specific customers. Perhaps we’ll contract down to two or three providers at some point in the future, but it will never really go away.

I’ll Have My People IM Your People

Contacting people is an exercise today. There are so many ways to reach someone via various communications that you have to spend time figuring out how to reach them. Direct message, Text message, Phone call, Voice Mail, Email, and smoke signals are all valid communications forms. It is true that a lot of these communications are moving toward asynchronous methods. But as mentioned above, a lot of customer-facing businesses are still voice-only.

Sales is one of these areas that is driven by sound. The best way to sell something to someone is to do it face-to-face. But a phone call is a close second. Sales works because you can use your voice to influence buyers. You can share their elation and allay their fears. You can be soothing or exciting or any range of emotion in between. That’s something you don’t get through the cold text of instant messaging or email.

It’s also much harder to ignore phone calls. Sure, you can send read receipts with emails but these are rarely implemented and even more rarely used correctly in my experience. Phone calls alert people about intent. Even ignoring or delaying them means being send to a voice mail box or to another phone in the department where your call can be dealt with. The synchronous nature of the communication means there has to be a connection with someone. You can’t just launch bytes of text into the ether and hope it gets where it’s supposed to go.

It is true that these voice communications happen via mobile numbers more often than not in this day and age. But corporations still prefer those calls to go through some kind of enterprise voice system. Those systems can track communications and be audited. Records can be subpoenaed for legal reasons without needing to involve carriers.

It’s much easier for call centers to track productivity via phone logs than seeing who is on the phone. If you’ve ever worked in a corporate call center, you know there are metrics for everything you do on the phone. Average call time, average wait time, amount of non-call time, and so on. Each of these metrics can be tracked via a desk phone with a headset, not so with a mobile phone and an app.

Tom’s Take

I live on my mobile phone. I send emails and social media updates. I talk in Slack and Skype and other instant messaging platforms. But I still get on the phone at least three times a week to talk to someone. Most of those calls take place on a conference bridge. That’s because people want to hear someone’s voice. It’s still comforting and important to listen to someone.

Doing away with IP Telephony sounds like an interesting strategy for small businesses and startups. It’s a cost-reduction method that has benefits in the short term. But as companies grow and change they will soon find that having a centralized voice system to control and manipulate calls is a necessity. Given the changes in voice technology in the last few years, I highly expect that “centralized” voice will eventually be a pay-per-seat cloud leased model with specific executives and support personnel using traditional phones while non-critical employees have no voice communications device or choose to use their personal mobile device.

IP Telephony isn’t dead. It’s not even dying. But it’s well past the age where it needs to consider retirement and a long and fulfilling life concentrating on specific people instead of trying to make everyone happy.

 

 

It’s Time For IPv6, Isn’t It?

Posted on by
7

 

I made a joke tweet the other day:

It did get lots of great interaction, but I feel like part of the joke was lost. Every one of the things on that list has been X in “This is the Year of X” for the last couple of years. Which is sad because I would really like IPv6 to be a big part of the year.

Ars Technica came out with a very good IPv6-focused article on January 3rd talking about the rise in adoption to 10% and how there is starting to be a shift in the way that people think about IPv6.

Old and Busted

One of the takeaways from the article that I found most interesting was a quote from Brian Carpenter of The University of Aukland about address structure. Most of the time when people complain about IPv6, they say that it’s stupid that IPv6 isn’t backwards compatible with IPv4. Carpenter has a slightly different take on it:

The fact that people don’t understand: the design flaw is in IPv4, which isn’t forwards compatible. IPv4 makes no allowance for anything that isn’t a 32 bit address. That means that, whatever the design of IPng, an IPv4-only node cannot communicate directly with an IPng-only node.

That’s a very interesting take on the problem that hadn’t occurred to me before. We’ve spent a lot of time trying to make IPv6 work with IPv4 in a way that doesn’t destroy things when the problem has nothing to do with IPv6 at all!

The real issue is that our aging IPv4 protocol just can’t be fixed to work with anything that isn’t IPv4. When you frame the argument in those terms you can start to realize why IPv4’s time is coming to an end. I’ve been told by people that moving to 128-bit addressing is overkill and that we need to just put another octet on the end of IPv4 and make them compatible so we can use things as they are for a bit longer.

Folks, the 5th octet plan would work exactly like IPv6 as far as IPv4 is concerned. The issue boils down to this: IPv4 is hard-coded to reject any address that isn’t exactly 32-bits in length. It doesn’t matter if your proposal is 33 bits or 256 bits, the result is the same: IPv4 won’t be able to directly talk to it. The only way to make IPv4 talk to any other protocol version would be extend it. And the massive amount of effort that it would take to do that is why we have things like dual stack and translation gateways for IPv6. Every plan to make IPv4 work a little longer ends in the same way: scrap it for something new.

New Hotness

Fresh from our take on how IPv4 is a busted protocol for the purposes of future proofing, lets take a look at what’s driving IPv6 right now. I got an email from my friend Eric Hileman, who runs a rather large network, asking me when he should consider his plans to transition to IPv6. My response was “wait for mobile users to force you there”.

Mobility is going to be the driving force behind IPv6 adoption. Don’t believe me? Grab the closest computing device to your body right now. I’d bet more than half of you reached for a phone or a tablet if you didn’t already have a smartwatch on your wrist. We are a society that is embracing mobile devices at an increasingly rapid rate.

Mobility is the new consumer compute. That means connectivity. Connectivity everywhere. My children don’t like not being able to consume media away from wireless access points. They would love to have a cellular device to allow them access to TV shows, movies, or even games. That generation is going to grow up to be the primary tech consumer in the next ten years.

In those intervening years, our tech infrastructure is going to balloon like never before. Smart devices will be everywhere. We are going to have terabytes of data from multiple sources flooding collectors to produce analysis that must be digested by some form of intelligence, whether organic or artificial. How do you think all that data is going to be transmitted? On a forty-year-old protocol with no concept of the future?

IPv6 has to become the network protocol to support future infrastructure. Mobility is going to drive adoption, but the tools and software we build around mobility is going to push new infrastructure adoption as well. IPv6 is going to be a huge part of that. Devices that don’t support IPv6 are going to be just like the IPv4 protocol they do support – forever stuck in the past with no concept of how the world is different now.

Tom’s Take

It’s no secret I’m an IPv6 champion. Even my distaste for NAT has more to do with its misuse with regard to IPv6 than any dislike for it as a protocol. IPv6 is something that should have been recognized ten years ago as the future of network addressing. When you look at how fast other things around us transform, like mobile computing or music/video consumption, you can see that technology doesn’t wait for stalwarts to figure things out. If you don’t want to be using IPv4 along with your VCR it’s time to start planning for how you’re going to use it.

 

 

Doing 2016 Write

Posted on by
2

 

calendar

It’s the first day of 2016 and it’s time for me to look at what I wanted to do and what I plan to accomplish in the coming 366 days. We’ve got a busy year ahead with a leap day, the Olympics, and a US presidential election. And somewhere in the middle of all that there’s a lot of exciting things related to tech.

2015 In Rewind

Looking back at my 2015 goals, I think I did a fairly good job:

  • Writing in Markdown – Read about it all here
  • Blog themes – I really did look at quite a few themes and tried to find something that worked the way I wanted it to work without major modifications. What I finally settled on was a minor font change to make things more readable. For me, form has never been more important than function, so I spend less time worrying about how my blog looks and much more time focusing on how it reads.
  • Cisco Live Management – Didn’t quite get this one done. I wanted to put up the poll for the big picture at the end and I managed to miss it this year! The crew got a chance to say hello to keynote speaker Mike Rowe, so I think it was a good tradeoff. This year for Cisco Live 2016, I hope we have some more interesting things in store as well as some surprises.

A hit, a miss, and a foul tip. Not terribly bad. 2015 was a busy year. I think I wrote more words than ever. I spoke a few times at industry events. I enjoyed participating in the community and being a part of all the wonderful things going on to move forward.

Looking Ahead to 2016

2016 is going to be another busy year as well. Lots of conferences in Las Vegas this year (Aruba Atmosphere, Interop, Cisco Live, and VMworld) as well as other industry events and a full slate of Tech Field Day events. I don’t think there’s a month in the entire year where something isn’t going on.

I’m sure this is an issue for quite a few people in the community as well. There’s a lot of time that gets taken up by doing things. The leaves very little time for writing about those things. I’ve experienced it and I know a lot of my friends have felt the same way. I can’t tell yo the number of times that I’ve heard “I need to write something about that.” or “I’m way behind on my blogging!”

Two Wrongs Don’t Make A Write

My biggest goal for 2016 is writing. I’ve been doing as much as I can, but I want to help others do it as well. I want to find a way to encourage people to start writing and add their thoughts to the community. I also want to find a way to keep the other great voices of the community going and writing regularly.

There’s been a huge shift recently away from blogging as a primary method of information transfer. Quite a few have moved toward non-writing methods to convey that information. Podcasts, both audio and video, are starting to become a preferred method of disseminating information.

I don’t have a problem with podcasts. Some of my friends have great resources that you should check out. But podcasts are very linear. Aside from using software that speeds up the talking, it’s very hard to condense podcasts into quick hit formats. Blog posts can be as short or long as they need to be to get the information across.

What I want to accomplish is a way to foster writers to write more. To help new writers get started and established writers to keep contributing. But keeping the blogging format alive and growing, we can continue to contribute great thoughts to the community and transfer knowledge to a new group of up-and-coming IT professionals.

I’ve got some ideas along these lines that I’ll be rolling out in the coming months. Be sure to say tuned. If you’re willing to help out in any way please drop me a line and let me know. I’m always looking for great people in the community to help make others great as well.

Tom’s Take

A new year doesn’t always mean a totally fresh start. I’ve been working on 2016 things for a few weeks now and I’m continuing great projects that I’ve been doing for a while now as well. But a new year does mean that it is time to find ways to do things better. My mission for the year is to make people better writers. To encourage more people to put thoughts down on paper. I want a world full of thinkers that aren’t afraid to share. That’s something that could make the new year a great one indeed.

My Markdown Adventure

Posted on by
4

markdown-512

It was almost a year ago that I set forth the idea to start writing all my blog posts in Markdown. I’ve been doing my best to keep up with that throughout the year and now I’m fifty Markdown posts into my goal. How is it working out so far?

Markdown Mindset

Learning to write in Markdown took some adjustment. Before, I had just used the web editor or the occasional HTML editing suite to write my posts. Most of the HTML was hidden. With Markdown, you have to think about what you’re going to do before you start writing it. Where are the links going to appear? How is your post going to be organized? Putting a bit more thought into your post gives you more structure to your thoughts. That’s something that’s helped my writing a bit.

The table layout for the 2015 Cisco Live Twitter List really wasn’t all that difficult either. Once I put the initial code together, it was just a simple copy/paste job after that. I’m toying with the idea of putting all my notes into Markdown as well. But given how terrible I am with taking typed notes that may not happen.

Editing In Style

I’ve also gone back and forth with editors for my particular style of Markdown writing. I started off with Lightpaper, which was a nice way to ease into writing. It was easy enough to figure out, but I didn’t like the lag in the preview pane and the tendency of that pane to lose position and scroll back in my writing. Add in the fact that Lightpaper was free during beta and is now a paid app and I can’t see myself recommending it now.

Most of my writing this year was in Mou. Mou is a lot like a traditional text editor. It’s powerful and extensible. I found it suited a lot of my Markdown needs. The preview pane worked like I thought it should and the theming allowed me to customize things to meet my writing needs. Mou did the lion’s share of the work during the year for me. But as I started to explore the gamut of distraction free Markdown writing apps, I felt that Mou was a little rough around the edges. The author has done a great job of keeping up with things so far, but the Indegogo campaign to produce a 1.0 version hasn’t really come to fruition yet. And 1.0 will be a paid release. So take a look at Mou, and if it meets your needs you should definitely get it now and take a look to decide if you want to pay for it later.

The editor that I’ve settled on to in the past couple of weeks is Typora. I like the way that the preview pane is in-line instead of separately. I realized as I wrote more with Markdown editors that seeing the actual code was much less important that the finished result. Moving to a in-line style was much cleaner. Add in support for different fonts in the editor and I got much closer to my actual blog posting style as opposed to plain text. Typora just looks cleaner and nicer. Like a modern word processing app compared to a text editor. If you don’t need the polish and feature set, the text editor works just fine. Typora is free during beta and will be a paid app when it comes out. Try it now and see if it suits your writing tastes before you have to pay.

Tom’s Take

Markdown has helped my writing. I’m faster and better now that I was at this time last year. I like the way things look when I write. My thoughts are more coherent. Markdown has improved my writing so much I use it for all my posts. It takes some acclimation over the course of a few weeks. I found myself going back into the web editor on accident more than once before scolding my muscle memory and going back to my Markdown experiment.

Part of that is finding the right editor. Don’t just take my word for it. Try out some of the distraction-free options or the text editor style programs as well. There are a ton of options out there for you to try. Just download one and start writing. I think you’ll find that Markdown will give you a lot of power in your writing and you’ll be a happier person for it!

 

Keeping IT Up With The Joneses

Posted on by
Reply

 

Keeping-Up-With-The-Joneses

We’ve all been in that meeting. We’re learning the important facts about a company and their awesome technology. We think we’ve got a handle of the problem they’re solving and how we can apply it to our needs. And then…BAM! Our eyes are assaulted by a billboard full of company logos. We’re told how every one of these companies think that this product or solution is awesome. And because they think it’s awesome and bought it, you should think it’s awesome as well and buy it too.

Do As They Do

This particular exchange in a presentation has a term: the NASCAR slide. When I came up with the term years ago during a Tech Field Day presentation, I referred to the fact that the slide was covered by all of the logos of customers and sponsors, not unlike the side of a NASCAR race car or the coveralls worn by the drivers. It turned the presentation into a giant neon sign signaling all the companies that bought the solution.

Vendors love to tell you who their customers are. They love holding those solution bidding wins over their competitor’s heads and informing the populace that a company like Victoria’s Secret uses their servers or an institution like the University of Oklahoma uses their wireless access points. Even when they can’t legally say if a company uses their equipment due to some clause in a contract, you’ll see language like “a large financial firm” or “a large sports media provider”, usually with enough context for you to figure out who they’re talking about without explicitly saying it. Wink wink, nudge nudge indeed.

The problem with this kind of marketing is that it never works. I’ve conducted some informal polling both in-person and through Twitter and the response was overwhelming: IT professionals don’t make purchasing decisions based on who else bought something. It seems kind of obvious, doesn’t it? People will base a decision on things like cost or suitability to the requirements of the project. They even do it for reasons like the user interface or the code name of the project. But not one person said they bought something because of the list of companies that use it.

That’s not to say that prior purchasers don’t figure into the process. People who bought a product and have provided feedback, either through a review process or through a stream of angry tweets have influenced purchasers. People told me that they would listen to a trusted voice telling them to buy (or not buy) something based on their experience. It would seem that what customers are looking for is not a list of purchasers, but those purchasers’ opinions about the solution.

I Won’t Do What You Tell Me!

Perhaps the heart of the problem comes down to the way that consumer products are marketed. Air Jordan shoes, Rolex Watches, and expensive cars all have the same idea behind them. You, as the customer, should buy these things because other people that are famous and important have them and you want to be like them, right? Buying an expensive pair of shoes is just like buying a storage array or a data center switch, right?

Vendors need to move away from the customer name dropping and instead focus on the solutions that they provide. Talk about problems that are solved instead of mentioning that a company in a totally unrelated industry bought a few switches from you three quarters ago. The idea is to make you happy with the solution that meets your needs and not with the fact that your 20-person retail outfit is using the same data center switches that a hospital two states away is using.

If you constantly sell your solutions based on who is buying them instead of the value they bring to the organization you will eventually find out that customers are buying solutions from cloud providers based on the same rationale. It might be a bit harder to convince your customers to keep their on-premises solution once they find out that Company X went with AWS or Company Y is moving to Microsoft Azure. Because at that point any attempt to bring solution feasibility or features into the discussion is as useless as the logos on your NASCAR slide.

Tom’s Take

I blasted an executive at HPE Discover a couple of weeks ago about this very subject. I get so tired of hearing the name dropping during keynotes or sales presentations. To me, there’s no difference between saying the following:

So, I was talking to Mark Zuckerberg the other day about networking…

Or

Facebook is a great customer of ours and they love our switches.

Either way, you’re just telling people that you “run in those circles” and they should buy your gear because of it.

I would rather you sell your products based how they can help me make money or reduce costs or make my data more secure. And should I have a wild hair that I want to know who else uses your product, I can ask for a list of companies with references that can speak directly to me about it instead of hearing you drone on about how cool it was that Nike started using your analytics solution last year. Because odds are good they’re going to dump you in another two years for the next better thing.

 

 

Share And Share Alike

Posted on by
2

ShareArrows

Every once in a while, I like to see who is clicking through to my blog. It helps me figure out what’s important to write about and who reads things. I found a recent comment that made me think about what I’m doing from a different perspective.

The Con Game

I get occasional inbound traffic from Reddit. The comments on Reddit are a huge reason to follow threads on the site. In one particular thread on /r/networking linked back to my blog as a source of networking news and discussion. But a comment gave me pause:

https://www.reddit.com/r/networking/comments/3mpjpz/networking_websites/cvgyfye

And I quote:

Cons : they almost all know each other and tend to promote each other content.

This was a bit fascinating to me. Of the people in that particular comment, I’ve only ever met one in person. I do know quite a few people in the networking space as part of my career, both related to Tech Field Day and just through writing.

It is true that I share quite a bit of content from other writers. My day job notwithstanding, I feel it is my duty to identify great pieces of writing or thought-provoking ideas and share it with the rest of the community. Ideas don’t live unless they can be shared. Without calling attention to important things and giving them a wider audience, we can’t hope to affect change and increase knowledge and learning.

People that write in a vacuum never become better writers. They never learn to express their ideas and defend them from questions and criticism. It’s not only important to share ideas with those that would agree with them, but also to share them with people that would disagree. Learning how to defend your thoughts and understand different viewpoints is a crucial step to becoming a better writer.

Pro Tips

If you’re a writer or blogger or speaker that follows other people, make sure to share what they write with your audience. Even if the two groups are 95% similar, there’s still that 5% that doesn’t overlap. Make sure you share their ideas with an extra thought of your own. Do you agree? Or, more importantly, do you disagree? Be cautious on that last part. You want to disagree professionally and raise objections, not tear someone down and attack the messenger. And yes, I realize that I started out that way in my career. But I’m feeling much better now.

Don’t hesitate to share something from someone you don’t know, either. I’ve made quite a few new friends by reaching out to someone writing great things and telling the world about it in my own way. People appreciate seeing their thoughts being disseminated to new audiences. Someone that sees you sharing and discussing ideas is more willing to approach you and start a dialog about new ideas as well.

And lastly, don’t let someone else tell you that sharing other people’s ideas is a bad thing. If you’re doing it for all the right reasons then it’s a great thing to want to show the community what people are doing. It’s not blatant promotion if there is substance behind what you’re sharing. If you’re shining a spotlight to enrich the knowledge base of the greater whole, then you should feel obligated to call attention to something good.

Tom’s Take

The world is a better place when we reinforce each other and do our best to make everyone better and smarter. Sometimes that comes in the form of sharing content and giving ideas. Other times it comes from helping friends by challenging what they say and assisting them in the completion of thoughts. In the end, we should feel honored to be able to take part in this great learning experiment that is the community. We can all come out winners by making everyone better than the were at the beginning.

undefined

Build Slides Are Evil

Posted on by
1

 

HammerAndSaw

PowerPoint is a necessary evil. No program allows us to convey as much information in a short amount of time. PowerPoint is almost a requirement for speaking in front of groups. Information can be shown in a very effective manner for audiences of five or five hundred. But PowerPoint also allows presenters to do some very silly things that impact our ability to learn.

Not Built In A Day

The biggest offense in the land of PowerPoint is the build slide. Build slides are those that have elements that must be layered together in order to show the complete picture. In some cases, build slides have complex graphic overlays with many different elements. They may have clip art overlays. But build slides can also be simple bullet points that appear one at a time in a list. The key is that all the parts of the slide must progress in series to “build” the whole thing.

Build slides look very awesome. They provide the appearance of motion and give a movie-like quality to a static presentation. And they often take up a large amount of time during the creation process. But they are almost always unnecessary.

When built properly, a slide conveys a single idea. It may have one or two supporting ideas, but overall it should be pared down to the minimum necessary to get the idea across. Having a page full of bullet points confuses and distracts the reader. It doesn’t matter whether those bullet points are unveiled all at once or sequentially. Each additional piece of information runs the risk of the entire message or idea being forgotten.

Worse yet, the elements of a build slide can be a mystery to everyone, even the presenter. How many times have you watched a presentation where a presenter gets ahead of themselves and reveals a bullet point before it’s on screen? Or perhaps the presenter lost track of how many points were on the slide?

Another strike against build slides is what happens when you’re forced to deal with them outside of presentation mode. Build slides break down when you can’t project them properly in a mode that simulates a projector. Like over a web presentation or screen sharing program. Build slides are also a bad idea when presenting on video. If your slide deck doesn’t come across well, there are options to insert slides into the video recording. But if you have build slides, those slides can’t be inserted without either using the completely built slide, which ruins the suspense of a build up, or looks crowded and complex in many cases.

One Slide At A Time

A build slide is needlessly complicated. If you have four bullet points on a slide, you have an opportunity to make each of those into a separate slide with different information conveying the idea. Like a single supporting fact or statement. Or a picture to help visual learners internalize the idea. There are a multitude of ways to make a slide stand out without pointless animation.

You’re probably thinking to yourself that adding slides to your presentation will make it longer than it needs to be. In fact, the opposite is true. By paring your deck down to a single idea per slide, you can effectively communicate that idea and move on to the next slide. If your original slide had five ideas and took five minutes to talk about, then it follows that one idea per slide spread over five slides should take the same amount of time. In a few cases, it may take less thanks to the reduction in tendency to wander through a long slide.

If you must have bullet points supporting an idea, make each of those bullet points a new slide. Just copy and paste the existing text into a new slide with a new bullet. That allows you to add to what you’ve said previously while still capturing the progression easily. You may also find that you’re adding unnecessary steps that can be removed along the way.

Tom’s Take

I don’t give presentations to amaze people with my PowerPoint skills. People come to hear me talk, not see what transitions I built between my deck. To that point, I don’t use a lot of bullets or make them fly in to wow the people reading my slides. Instead, I stick to the ideas of using lots of pictures and keeping the text short.

When you look at some of the most public presentations from well-regarded speakers, you find that they follow these same guidelines. They keep their presentations simple and focus on ideas and not text. They try to keep all members of the audience focused, but aural and visual learners. They realize that build slides don’t actually offer anything to the audience aside from showing mastery of esoteric aspects of PowerPoint wizardry. Keep it simple and build your audience’s knowledge, not your slides.

 

The Marriage of the Ecosystem

Posted on by
1

 

marriage

A recent discussion with Greg Ferro (@EtherealMind) of Packet Pushers and Nigel Poulton (@NigelPoulton) of In Tech We Trust got me thinking about product ecosystems. Nigel was talking about his new favorite topic of Docker and containers. He mentioned to us that it had him excited because it felt like the good old days of VMware when they were doing great things with the technology. That’s when I realized that ecosystems aren’t all they are cracked up to be.

Courting Technology

Technology is a huge driver for innovation. New ideas are formed into code that runs to accomplish a task. That code is then disseminated to teams and built upon to create toolsets to accomplish even more tasks. That’s how programs happen. Almost every successful shift in technology starts with the courtship of focused code designed to accomplish a simple task or solve a quick problem.

The courtship evolves over time to include other aspects of technology. Development work extends the codebase to accept things like plugins to provide additional functionality. Not core functions though. The separation comes when people want to add additional pieces without compromising the original program. Bolting additional non-core pieces on to existing code causes all kinds of headaches.

That’s how ecosystems start. People build new functions to augment and support the new problems the crop up around those solved by the original tool. Finding new problems is key to driving the ecosystem forward. Without problems to solve, the environment around a particular program starts to contract and disappear.

The Old Ball And Chain

Ecosystems eventually reach the point of stagnation, however. This usually comes when the ecosystem around a product becomes more important than the actual program itself. Think about the ecosystem around Microsoft Office. Office was originally a word processor. That drove additional programs to solve spreadsheets and presentations. Now, people buy the Office productivity suite for more than the word processor. More than a few buy it for the email program. But very little innovation is going into the word processor any longer. Aside from some UI design changes and few minor function additions the majority of the work is being driven around other programs.

This is also the problem with VMware today. The development around the original hypervisor is mostly moot. That problem has been solved completely. Today, all of the marketing hype around the VMware is on other things. Public cloud architectures. Storage virtualization. Networking virtualization. None of these things have anything to do with they hypervisor beyond tying into the ecosystem created around it.

Ecosystems can’t exist without recognizing the original problems being solved and why they are so important. If you build an environment around a product and then leave that product to wither on the vine, your ecosystem will eventually collapse. When your company pivots away from what makes it successful in the first place you run the risk of disaster.

Note that this doesn’t include what happens when the technology landscape forces you to shift your focus. Token ring networking doesn’t solve a big problem today. Companies focusing on it needed to pivot away from it to solve new problems. As such, there really isn’t a token ring ecosystem today.

Now, look at tape backup units as a counterpoint. They still solve a problem – backing up large amounts of data at low cost. Quite a few of the old tape backup vendors have moved away from the market and are concentrating on new solutions. A few of the old vendors, such as SpectraLogic, still support tape solutions and are continuing to drive the tape ecosystem with new ideas. But those ideas still manage to come back to tape. That’s how they can keep the ecosystem grounded and relevant.

Tom’s Take

New technology is like dating. You get excited and giddy about where things are going and all the potential you see. You enjoy spending time together just talking or existing. As you start to get more serious you start to see issues crop up the need to be solved. Eventually you take the plunge and make things super serious. What you don’t want to have happen at this point is the trap that some people fall into. When you concentrate on the issues that crop up around things you start to lose focus. It’s far to easy to think about bills and schools and other ancillary issues and lose sight of the reason why you’re together in the first place.

Ecosystems are like that. People start focusing on the ecosystem at the expense of the technology that brought everyone together in the first place. When you do that you forget about all the great things that happened in the beginning and you concentrate on the problems that have appeared and not the technology. In order to keep your ecosystem vibrant and relevant, you have to step back and remember the core technology from time to time.

 

 

A Voyage of Discover-E

Posted on by
1

 

hpe-logo

I’m very happy to be attending the first edition of Hewlett-Packard Enterprise (HPE) Discover in London next week. I say the first edition because this is the first major event being held since the reaving of HP Inc from Hewlett-Packard Enterprise. I’m hopeful for some great things to come from this.

It’s The Network (This Time)

One of the most exciting things for me is seeing how HPE is working on their networking department. With the recent news about OpenSwitch, HPE is trying to shift the way of thinking about a switch operating system in a big way. To quote my friend Chris Young:

Vendors today spend a lot of effort re-writing 80% of their code and focus on innovating on the 20% that makes them different. Imagine how much further we’d be if that 80% required no effort at all?

OpenSwitch has some great ideas, like pulling everything from Open vSwitch as a central system database. I would love to see more companies use this model going forward. It makes a lot of sense and can provide significant benefits. Time will tell if other vendors recognize this and start using portions of OpenSwitch in their projects. But for now it’s interesting to see what is possible when someone takes a leap of open-sourced faith.

I’m also excited to hear from Aruba, a Hewlett-Packard Enterprise company (Aruba) and see what new additions they’ve made to their portfolio. The interplay between Aruba and the new HPE Networking will be interesting to follow. I have seen more engagement and discussion coming from HPE Networking now that Aruba has begun integrating themselves into the organization. It’s exciting to have conversations with people involved in the vendor space about what they’re working on. I hope this trend continues with HPE in all areas and not just networking.

Expected To Do Your Duty

HPE is sailing into some very interesting waters. Splitting off the consumer side of the brand does allow the smaller organization to focus on the important things that enterprises need. This isn’t a divestiture. It’s cell mitosis. The behemoth that was HP needed to divide to survive.

I said a couple of weeks ago:

To which it was quickly pointed out that HPE is doing just that. I agree that their effort is impressive. But this is the first time that HP has tried to cut itself to pieces. IBM has done it over and over again. I would amend my original statement to say that no company will be IBM again, including IBM. What you and I think of today as IBM isn’t what Tom Watson built. It’s the remnants of IBM Global Services with some cloud practice acquisitions. The server and PC business that made IBM a household name are gone now.

The lesson to HPE during as they try to find their identity in the new world post-cleaving is to remember what people liked about HP in the enterprise space and focus on keeping that goodwill going. Create a nucleus that allows the brand to continue to build and innovate in new and exciting ways without letting people forget what made you great in the first place.

Tom’s Take

I’m excited to see what HPE has in store for this Discover. There are no doubt going to be lots of product launches and other kinds of things to pique my interest about the direction the company is headed. I’m impressed so far with the changes and the focus back to what matters. I hope the momentum continues to grow into 2016 and the folks behind the wheel of the HPE ship know how to steer into the clear water of success. Here’s hoping for clear skies and calm seas ahead for the good ship Hewlett-Packard Enterprise!

 

 

A Stack Full Of It

Posted on by
1

pancakestack

During the recent Open Networking User Group (ONUG) Meeting, there was a lot of discussion around the idea of a Full Stack Engineer. The idea of full stack professionals has been around for a few years now. Seeing this label applied to networking and network professionals seems only natural. But it’s a step in the wrong direction.

Short Stack

Full stack means having knowledge of the many different pieces of a given area. Full stack programmers know all about development, project management, databases, and other aspects of their environment. Likewise, full stack engineers are expected to know about the network, the servers attached to it, and the applications running on top of those servers.

Full stack is a great way to illustrate how specialized things are becoming in the industry. For years we’ve talked about how hard networking can be and how we need to make certain aspects of it easier for beginners to understand. QoS, routing protocols, and even configuration management are critical items that need to be decoded for anyone in the networking team to have a chance of success. But networking isn’t the only area where that complexity resides.

Server teams have their own jargon. Their language doesn’t include routing or ASICs. They tend to talk about resource pools and patches and provisioning. They might talk about VLANs or latency, but only insofar as it applies to getting communications going to their servers. Likewise, the applications teams don’t talk about any of the above. They are concerned with databases and application behaviors. The only time the hardware below them becomes a concern is when something isn’t working properly. Then it becomes a race to figure out which team is responsible for the problem.

The concept of being a full stack anything is great in theory. You want someone that can understand how things work together and identify areas that need to be improved. The term “big picture” definitely comes to mind. Think of a general practitioner doctor. This person understands enough about basic medical knowledge to be able to fix a great many issues and help you understand how your body works. There are quiet a few general doctors that do well in the medical field. But we all know that they aren’t the only kinds of doctors around.

Silver Dollar Stacks

Generalists are great people. They’ve spent a great deal of time learning many things to know a little bit about everything. I like to say that these people have mud puddle knowledge about a topic. It covers are broad area, but only a few inches deep. It can form quickly and evaporates in the same amount of time. Contrast this with a lake or an ocean, which covers a much deeper area but takes years or decades to create.

Let’s go back to our doctor example. General practitioners are great for a large percentage of simple problems. But when they are faced with a very specific issue they often call out to a specialist doctor. Specialists have made their career out of learning all about a particular part of the body. Podiatrists, cardiologists, and brain surgeons are all specialists. They are the kinds of doctors you want to talk to when you have a problem with that part of your body. They will never see the high traffic of a general doctor, but they more than make up for it in their own area of expertise.

Networking has a lot of people that cover the basics. There are also a lot of people that cover the more specific things, like MPLS or routing. Those specialists are very good a what they do because they have spent the time to hone those skills. They may not be able to create VLANs or provision ports as fast as a generalist, but imagine the amount of time saved when turning up a new MPLS VPN or troubleshooting a routing loop? That money translates into real savings or reduced downtime.

Tom’s Take

The people that claim that networking needs to have full stack knowledge are the kinds of folks further up the stack that get irritated when they have to explain what they want. Server admins don’t like knowing the networking jargon to ask for VLANs. Application developers want you to know what they mean when they say everything is slow. Full stack is just code for “learn about my job so I don’t have to learn about yours”.

It’s important to know about how other roles in the stack work in order to understand how changes can impact the entire organization. But that knowledge needs to be shared across everyone up and down the stack. People need to have basic knowledge to understand what they are asking and how you can help.

The next time someone tells you that you need to be a full stack person, ask them to come do your job for a day while you learn about theirs. Or offer to do their job for one week to learn about their part of the stack. If they don’t recoil in horror at the thought of you doing it, chance are they really want you to have a greater understanding of things. More likely they just want you to know how hard they work and why you’re so difficult to understand. Stop telling us that we need full stack knowledge and start making the stacks easier to understand.