SD-WAN and other network trends: hype vs reality

Skipping out on SD-WAN, designing big IT projects, and what’s worth reading

Every industry has its pervasive false narratives, and networking is no exception. In fact, IT media and eager vendors could give the Kardashians a run for their money for stoking notions like the cloud’s surefire financial benefits, or that anyone who hasn’t yet mastered Python is about to become obsolete.

On this episode of The Phonebook, BlueCat rung up a friend from around IT to chat about:

• The misleading hype surrounding automation and other solutions
• How to approach major architecture and design projects
• The career implications of not using the latest and greatest
• What it means to accept your specific business context and make un-trendy decisions, like passing on SD-WAN
• A list of people giving really responsible advice

THIS MONTH’S GUEST

Name: Chris Cummings
Position: Network Engineer
Employer: A publicly-traded mining company with ~2,000 employees worldwide.
Responsible for: WAN connectivity between sites, architecture design implementation, commissioning and decommissioning sites, M&A-related network organization.
Connect: Twitter | LinkedIn 

The original conversation has been edited for clarity, length, and organization.

Chris, what have you been working on these days?

We’re in the middle of redesigning the entire WAN. That’s been my big project, implementing segmentation between sites. Part of that has also been redesigning our WAN—moving from expensive private MPLS [Multiprotocol Label Switching] links that connect everything and moving towards just internet-based VPNs.

It’s 2020, why not SD-WAN?

We did go heavily down the path of SD-WAN, and looked really hard into it. I’m a big SD-WAN fan. I’ve been using SD-WAN for 10 years. I used Talari since they first came out, which was pretty much one of the earliest SD-WAN vendors.

However, about two years ago or whenever we were looking into it, the market was really starting to consolidate. So, we did not feel comfortable buying into a technology with all of the chaos of consolidation. Dealing with vendors was one of those things where we would get like five new sales reps in a couple months.

In reality, none of the cost savings of SD-WAN around circuits would have paid for the amount of engineering cost that it would have taken to completely be in downtime to be ripping out our WAN and dealing with all these new things.

P.S. Want to connect with more IT pros like Chris? Join us over in the Network VIP Slack group for some great conversation.

Back to your WAN, why not continue using private circuits?

Internet circuits have, in our context, the same reliability as private circuits. This absolutely would apply more generally, in my opinion. You have better SLAs on your private circuits, which means you can yell at somebody more, but yelling doesn’t get you your circuit back up.

Advice for approaching any big architecture project?

Try it first. If you’re trying to compare technologies, marketing speak is good, vendor-provided labs are good. But get your hands on lab equipment and build it yourself. It’s the only way to know, hands down, whether or not it’s going to work. Data sheets are full of what varies from inaccuracies to lies, or “it’ll be in the next version”-isms.

It’s hard if you’re a smaller organization to get access to those things. But once you’re doing something with any potential significant volume, you can at least get access to VMs to lab certain parts of things. If you have a good VAR, they can help you navigate those waters. If you’re a smaller business, yes.

Don’t get caught up in marketing hype and buzzwords. Everybody talks about the next new thing as if everybody’s doing it. But in reality, not a lot of people are. While it’s really good that we talk about new technologies, like SDN, you can get caught up in the hype if you aren’t careful.

Always try to take something away if you can. It was Pete Welcher who said that if a design requires a CCIE [Cisco Certified Internetwork Expert] on an obscure protocol at 4 a.m., it’s a bad design. It’s very easy, as engineers, to lean towards complex and cool designs because they’re more fun, it builds your resume, you can talk about it with your networking buddies. But a design isn’t complete until you’ve pulled away as much as you can.

Think about things from a business context. The network’s not there to be a good network. The network’s there to help the business do what the business does. And that’s how you should design, in that context. Otherwise, you’re just designing a cool network, but it may not meet the needs of the business.

Using my WAN design project that I’ve been on as an example, SD-WAN is really sexy. But what does it get you, right? Sub-second failover? That’s awesome. That’s really cool, technically superior. Only, don’t need it. All of our traffic is HTTP-based. If one of our customers in the business is unable to access an application for two or three seconds while something fails over, nobody’s going to even notice. So, it’s understanding the business requirements. If the business doesn’t require sub-second failover, don’t do it. The amount of work that you’re going to have to put into getting it that way may not be worth it to the business.

Now, there are examples, of course, that I can think of where it has helped the business. Mining technologies are moving more digital. And they’re moving to be more real-time. But that’s a very slow transition.

Do you worry that your career will suffer if you aren’t working with the trendy stuff?

Not really. It’s all transferable. If you learn the fundamentals, and you learn what problems need to be solved in networking, any new technology that comes along is solving those same problems, just in a different way.

Ethan [Banks] and Russ [White] wrote this book, Computer Networking Problems & Solutions. It is absolutely one of the best networking books out there, because it covers common problems and solutions from a non-technology standpoint. Obviously, it’s a very technical book. But it doesn’t talk much about how to set up or configure BGP, OSPF, IS-IS, etc. Rather, it talks about generic networking problems and how the various protocols available (again, BGP, OSPF, IS-IS, etc.) can solve those problems. I think that this approach is very helpful career-wise. It teaches you to solve problems in a very objective manner.

How has the transition to WFH gone for you guys?

For me, my day to day is really the same. Network engineering for a mining company versus for a financial services firm, you’re dealing with the same technology. And the truth of the matter is, very rarely am I physically touching a piece of equipment. I’m always logging into it remotely over the network, right?

From an IT standpoint, it’s been just fine. We had already designed our VPN infrastructure to be large enough to handle the capacity of our entire knowledge worker force. Our infrastructure was not a problem when we all went remote. I know a lot of companies were trying to buy new firewalls and VPN concentrators and stuff, and were scrambling when work-remote happened. We developed our VPN at the very onset to be able to handle everybody remote if we had to.

Why?

Because we’re all doomsday worst-case-scenario engineers. We’ve got a good leadership who understands that it’s worth it to pay upfront, just a little bit of licensing costs. I think a lot of companies were not that way.

What communities in networking do you recommend to be part of? What have you participated in? Who’s giving really responsible advice?

Ivan [Pepelnjak] who runs IPspace.net… The subscription IP Space is phenomenal. I’ve learned so much on there. I think he provides a really good perspective, from someone who understands it all really well and brings a lot of experience to the table and does not take any BS whenever people start to try to BS him.

Nick Buraglio is one of those guys because he’s always on Software Gone Wild. I talk to Nick a lot and he’s one of those dudes that’s always just fairly presenting things, in my opinion, and not getting into the hype. Nick’s blog, forwardingplane.net, I think is really good. I’m always on there.

Jordan [Martin], and Network Collective. I view Jordan as one of those guys that has a very even-keeled approach to networking, doesn’t fall into the hype cycle, and is very knowledgeable. And he does a great job of sitting back and listening and letting people talk, even when he has a ton to bring. If you listen to the podcasts, he always lets smart people talk and does a good job of facilitating it. And then asks really meaningful questions. Editor’s note: Network Collective was shut down in September 2022; its past podcast and livestream content remains available on YouTube.

Honestly, just following people on Twitter, too. Absolutely everybody that does anything network-related, obviously.

Packet Pushers is always great. I love Packet Pushers. Ethan is the chill yin to Greg [Ferro]’s very out-there yang, which I love. I love that. Greg did a post about Thunderbolt for networking in the campus LAN, which was one of the things that was like, yeah, no, nobody’s ever going to do this. But he took the time to explore it as if it would be the next big thing. And it won’t. But it’s good to do that. Because otherwise, whatever might be the next big thing, you might miss it if you’re not giving it an actual chance. And that’s what I look for when I’m looking for an hour of content—are the people creating it willing to explore things that ultimately might be a failure? It’s just a more scientific approach.

[Editor’s note: there’s one more community that Chris is part of: Network VIP, in which IT pros are trading notes about critical infrastructure topics like DDI, network automation, and more. We’d be thrilled for you to join us in there.]

It’s interesting that you brought up ‘scientific’. Even in science, there’s this pressure on an individual researcher level to avoid being the one who contributes to the body of knowledge by finding a dead end.

Creating that freedom to fail is actually really hard. My wife’s a scientist and so I totally understand the publication bias in stuff. And I think we totally see that in network media.

That’s why I like Network Collective so much, the Slack channel. It’s a place I can ask stupid questions. And I’m with a bunch of really smart people who have done a lot of really cool stuff.

It’s one of those places where I can experiment with ideas in networking, which is harder to do elsewhere.

Even with the cloud and SD-WAN, there’s a pressure to prove that it’s valuable.

Yeah. Network programmability and automation are absolutely a big thing. But, four years ago, if you listened to the hype, everyone would have told you that if you don’t know Python, you won’t be a network engineer in five years.

It’s not true. Because I think we were talking about the beginning. Things go slower, generally.

And I think that good engineers are learning Python. However, that doesn’t mean that you literally are worthless as an engineer if you haven’t yet. But it kind of comes across that way when you listen to a lot of media.

For more great insights from your peers in IT, join the conversation in our Slack community, Network VIP.