For decades, enterprises have relied on the public internet for business-critical SaaS applications and data traffic. The reason why is pretty simple: it’s cost-efficient, it’s easy to use and it’s already there. Compare that to the logistical, financial and implementation challenges of installing an alternative private network, and it’s clear why enterprises have been pretty content with the internet for their entire digital lives.
But, it’s 2017. And, if there’s one thing clear about the public internet today, it’s that it no longer cuts it. Rampant DDoS attacks and other cyber threats posed by hackers, rogue employees and nation-states have not just revealed the security, reliability and transparency cracks in the public internet — they’ve blown them wide open.
For enterprises concerned about secure and consistent network performance, the public internet cannot be the default solution anymore. Enterprises need to look beyond the public internet to their own private WANs — and specifically, to SDN.
The current state of SDN
Software-defined networking was conceived in the 1990s as part of active networks research, proposed as a radical alternative to the traditional internet stack. But, it ended up falling through because there was no clear path to deployment.
Fast forward about 20 years, and the explosion of digital content today — and, consequently, the need for greater, flexible bandwidth support — has made network agility a top concern for enterprises. That concern has brought SDN back to the forefront.
But, expectations have changed. Virtualization has made server migration as simple as point-and-click; networking needs to be just as simple. Research done over the past 15 to 20 years on network management, scaling techniques for distributed routing protocols and OpenFlow and Network OS have helped to bridge the gap between fully programmable networks (i.e. SDN) and practical, real-world deployments.
SDN in action
Wide-scale SDN deployments are not some far-flung fantasy; we see them taking shape in many ways today.
Google uses many networking protocols in conjunction with each other — OpenFlow, BGP, PCE-P — to support an SDN infrastructure built on white box switches and commodity hardware, creating what is effectively a completely homegrown network.
REANZZ, the New Zealand national research network, is also running one of its enterprise networks on an SDN switching system based on OpenFlow, with a goal of providing an open networking environment.
The open source frontier
SDN has also crossed the threshold into open source, although the Venn diagram relationship between SDN, open source and open networking is a very compartmentalized one.
You can have open source SDN, open networking SDN and open-source open networking that is not SDN, but finding crossover between the three is still less common than it should be. Creating a network where there’s no vendor lock on the software, no vendor lock on the hardware and software orchestration can be manipulated to control your network in the same manner you would control your servers is not just achievable, it’s something that network engineers should be aspiring to achieve.
SDX, SDN and the forces shaping the network
There has been some pushback against SDN, fearing that it means complete centralization, but this is a misperception.
Nothing about SDN inherently implies centralization; and, in fact, the broader trend that SDN is a part of — i.e. software-defined everything (SDX) — is focused on just the opposite: decentralized distributed decision making. Think of real-world SDX examples you encounter in your day-to-day life: services like Uber and Airbnb, smart home devices like Nest and, eventually but not too far off in the future, self-driving cars. These all take automated, software-driven and decentralized approaches to real, tactile services.
SDN does the same for the network. And, it gives enterprises the opportunity to build their own networks with private connectivity. As enterprises move more of their workloads into data centers, and look to connect to business-critical apps and SaaS providers over the public internet, they’re putting themselves increasingly at risk of the internet’s public — and insecure, unreliable — nature.
We’re already seeing how SDN manifests in successful WAN deployments – Microsoft Azure Express Route and Amazon’s AWS Direct Connect are forms of SDN that use private address space, waiving the need for public address space, to connect to resources in data centers.
The public transit of the internet is failing enterprises who rely on it for mission-critical services and data traffic. Enterprises need to be able to control their networking experience, with their own private WANs. As the challenge of how to securely and easily directly access cloud infrastructure from multiple vendors and SaaS providers becomes increasingly top of mind for today’s enterprises, SDN offers a bright and viable path forward.
This article is published as part of the IDG Contributor Network. Want to Join?
<< This article was originally published on blog here. >>