ONUG Fall Conference 2019

I truly enjoyed attending the ONUG Fall Conference in New York last month. If anyone needed to validate that SD-WAN is hitting its stride and making it into the mainstream, being there would have provided proof: high attendance, great discussions on the floor, many enterprises sharing their experiences with SD-WAN deployments. Moreover, the dawn of discussions about industry standards and reference architectures for SD-WAN driven by ONUG and MEF shows that the technology is reaching maturity.

As you can imagine, we were discussing many different topics on the crowded show floor as well as in the Proof of Concept presentations (you can see my 10min live Aryaka demo here). But if I had to summarize the topics that we discussed the most, I’d pick the following – and invite your own views, of course.

SD-WAN Complexity

While SD-WAN was originally pitched as the technology that would end network complexity, many users are now reporting that their initial SD-WAN deployments did not live up to the initial promise of network simplification. In fact, I talked to at least 3 enterprise users that had stopped their SD-WAN projects and were re-evaluating their approach to SD-WAN implementation. The main pain point I heard about was the same problem that has haunted the Enterprise WAN and driven complexity in the past: Application performance, user experience and QoS (they are all interwoven). In theory, SD-WAN was supposed to address this by defining “simple” policies centrally and orchestrating/automating distribution to all locations. Lo and behold, it seems that neither are the policies that simple, nor do they seem to be universally applicable. So what ends up happening is that network engineers spend a lot of time creating the initial “universal” policies in a way that often still harkens back to the maligned 600+ CLI commands of the past. Moreover, often these policies need to be tweaked for many locations given the peculiarities of last mile behavior, basically resulting in the same type of node-by-node operations that made enterprise networking inefficient in the past. You will not be surprised if I tell you that this issue was particularly prevalent with enterprises that had embarked on “Do-It-Yourself” SD-WAN projects.

You will also not be surprised if I tell you that Aryaka’s approach solves this problem. And before you say “Well, because it is a Managed Services model and you just implement it all for me, giving me little control over my SD-WAN implementation”, I urge you to watch my ONUG POC demo. We do have a configuration portal that allows you to create and modify global and local policies. It is very intuitive to navigate. Furthermore, our control over the last mile means that, in the vast majority of cases, universal QoS policies simply work. You may create more than just one global policy to accommodate a few different application mix patterns, but if I navigate through our customers deployments, I see that your typical 200 branch network only has 2 or maybe 3 QoS policies, no more.

Visibility and Troubleshooting

The showcase floor in New York highlighted the fact that SD-WAN has become a very fertile playground for Network Performance Monitoring (NPM) companies. Don’t get me wrong, I know that there are many very good reasons for enterprises to adopt NPM tools. If I managed my own network, I’d make sure to pick at least an additional, vendor neutral tool to provide me with high level visibility and troubleshooting capabilities. That said, what seems odd is that it seems that it has become a mandatory requirement to deploy yet another NPM tool as enterprises embark on their Day 0-1-2 SD-WAN journeys. The main reasons are to help define working traffic policies in Day 0, and to reconcile overlay and underlay network behavior when operating/troubleshooting in Day 1 or 2 scenarios with Do-It-Yourself SD-WAN. In Day 1, you want to establish why traffic policies may not be performing as expected, and in Day 2 you need to troubleshoot application performance issues. In either case, having fractured visibility into the virtual overlay and the physical underlay most certainly does not help.

And once more, I can tell you -and prove to you- that this problem does not arise with the Aryaka approach. The MyAryaka customer console provides customers with complete, end-to-end visibility across the first, middle and last mile. There are no overlay and underlay split visibility issues to reconcile, because Aryaka has complete ownership of the middle mile (our Global Layer 2 Core), and the closed-loop approach that closely connects Aryaka’s PoPs with the edge devices (Aryaka Network Access Points aka ANAP) provides deep, real-time visibility into first and last mile performance. If there’s an issue anywhere, the troubleshooting process is very straightforward (again, see my ONUG demo). I should also mention that our SLAs just work from Day 1. It’s that easy.

The Role of The Network Engineer

While there were also many other discussion topics, one I saw myself addressing very regularly was the future of the role of the network engineer. I guess it’s because my background reveals me as a little bit of a network gray beard (perhaps I should shave off my beard :-D) and also because I work for a Network-as-a-Service company like Aryaka that network engineers ask me “well, what am *I* going to do all day if I buy your service? Am I not making myself redundant?”. It’s not an easy discussion, but we all know that the role of the network engineer is changing, and has been changing for a while. Here’s a blog I ghost-wrote over three years ago on the topic (although some of my opinions have changed!). Network engineers need to look at how the role of the server/application engineer changed. DevOps must become our new battle-cry in networking. In a nutshell, that means constant, rapid alignment of infrastructure with business needs, and a state of continuous operational change. I must also make it very clear that Aryaka’s major customers *are* network subject experts, as you can easily tell every time they participate in our webinars, perfectly aware of the technology and its capabilities. But they are also network engineers that early on decided that their priorities were shifting and that they needed to join the IT business discussion and move out of the networking ivory tower. In the WAN router era, one network model fit almost every enterprise, and connectivity was the key service. Network engineers didn’t have to be aware of overarching business models or priorities. In the digital, cloud-first era, the network must constantly and rapidly adapt to business needs – or it stands in the way and will get bypassed and/or outsourced. The Aryaka deployment model helps network engineers by freeing them from troubleshooting over 70% of their times (according to several studies) and allowing them to spend more time planning for business success.

Please contact us to get a demo from one of our experts!

About the author

Paul Liesenberg

Paul is a Director in Aryaka’s Product Solutions Team. Paul has over 20 years of experience in product marketing, product management, sales engineering, business development and software engineering in Cisco, LiveAction, Bivio Networks and StrataCom. Paul enjoys scuba diving, motorcycles, open software projects and oil painting.