A while back, I read a Wall Street Journal article that reported that most new drivers don’t know how to change a tire, check tread depth, or properly inflate the tires on their cars. They take for granted that such an important part of their transportation “just works,” sometimes with disastrous consequences when things go wrong. This got me thinking about an analogous problem we have in IT today. Most network engineers have forgotten how to properly architect, build, and maintain networks. Don’t believe me? I’ll explain in a minute, but let me first discuss how we got here.
When I first started in IT infrastructure, well before cloud, enterprises routinely built their own wide-area networks from the ground up. It wasn’t easy. There were multiple competing technologies, routing was complex, and you had to fully understand the state of every packet. The network architects of that era needed the skills and experience to build high-performing, reliable, and scalable networks.
Then, in the early 2000s, multi-protocol label switching (MPLS) entered the picture. What a difference! MPLS reduced the complexity of building networks. By using labels for routing, MPLS made it far easier to build fast, reliable networks that just worked, with much of the complexity shifted from the enterprise to the service providers. Enterprises just connected to their provider’s MPLS network and enjoyed reliable, if not inexpensive, service without the complexity of building and managing their own private networks. No longer needed, the best network architects moved from the enterprise and continued building complex networks at service providers. Most enterprises simply lost this architecture muscle entirely.
But MPLS wasn’t perfect.
MPLS was increasingly expensive, especially when compared to commodity bandwidth. It was slow to provision, and it provided virtually no visibility or control to the enterprises that were consuming the service. This dramatically hampered our efforts to optimize performance and build-in security. This lack of visibility, security only by obscurity, and overly complex provisioning requirements created an opportunity for a revolutionary change, and that’s when SD-WAN was introduced.
When SD-WAN first hit the scene in 2014, it looked like a solution that would fix everything. MPLS is too expensive? SD-WAN can leverage commodity bandwidth for less important traffic, lowering costs. MPLS is slow to provision? SD-WAN deploys at the speed of software. Control? Enterprises own the control plane again and can segment, traffic engineer, and build and tear down networks with a few mouse clicks. Visibility? Well, that problem remained, but the allure of agility and affordability was enough to foster tremendous interest in SD-WAN and rapid adoption across the enterprise.
Except to make SD-WAN work optimally, meant we were back to building our own networks. Planning the underlay, building the overlays, designing traffic engineering policies. Sure, SD-WAN made the implementation easy, but designing the network required skills that had long been gone in the typical enterprise. As a result, enterprises have struggled to realize the full potential of their large-scale SD-WAN networks.
It gets worse. Networks have become more complex and distributed. Moving away from the traditional hub-and-spoke architectures of multiple branches and few datacenters, enterprise networks must now connect offices, multiple cloud providers in multiple regions, edge networks, remote workers, and large numbers of IoT devices. And, with SD-WAN, each of those requires a tunnel that needs to be designed and managed. That’s far more difficult and requires far more expertise than provisioning MPLS networks.
So, now what? MPLS provided easy consumption but was too expensive with little agility. SD-WAN is affordable and agile, but requires network expertise that enterprises lack. We could hire back all those skilled network architects from the early 2000’s. But that’s a tall ask in the midst of the “Great Resignation,” not to mention way too expensive. Even if we could hire these expensive experts, it’s the wrong approach. We need affordable agility; this approach gives us expensive gridlock.
We don’t need better network architects. We need a better network. The problem with SD-WAN is that it isn’t a better network; it’s a Band-Aid. It doesn’t replace MPLS; it kludges together a cheaper and more agile transport (commodity bandwidth) with an expensive, slow-to-provision private network (MPLS). In some ways, SD-WAN gave us the worst of all worlds.
What I want is a better network. Something that combines the reliable performance of MPLS with the affordable agility of the public internet. Something that doesn’t require me to hire experts and build my network from the ground up.
Is this even possible? I believe so, but to work, one thing must be true. It must be a private network, just as MPLS was, so we don’t have to manage an exponential number of tunnels over various public underlays. That’s the only way we’ll be able to build and manage the networks of tomorrow without maintaining a SWAT team of expensive network architects. But it also must finally deliver on the affordability and agility that SD-WAN promised. Translation: We need a private Network-as-a-Service.
It’s a little late for 2022 predictions, but I expect we’ll see precisely this kind of new private NaaS later this year.
Michael Elmore is Senior Vice President and Global Chief Information Security Officer of GlaxoSmithKline (GSK) Consumer Health.
NetOps teams, like Spider Man, have great powers and great responsibilities. Increasingly, they are adopting a Zero Trust approach to network operations to help fight their battles.
Senior stakeholders who want to hold on to their CISOs must ensure that they have sufficient incentives and, more importantly, support to cope with the burden of risk that they are carrying.
The most alarming takeaway from Cisco’s new Cybersecurity Readiness Index report is that even after decades of having the importance of cybersecurity driven home, cyber threats are still taken too lightly.
