One Framework to Rule Them All
November 28, 2018 |
Networks
The Dream of the Data Center
For me, it started with OpenStack. I was at a conference a number of years ago listening to Shannon McFarland talking about using OpenStack to bring programmatic Network Functions Virtualization (NFV) into the data center. My own applications are much more small-scale, but the idea was captivating from the beginning. Since then, many other approaches to this have come into play, but all of them share that single idea of programmatic control over large-scale installations.
The thing about data center architectures is that they need automation. It's not an optional thing or a nice-to-have item. The human resources required to maintain those systems the way most network engineers maintain our networks just don't make financial sense. They're not all that efficient in smaller networks and are particularly ineffective at scale. Necessity is the mother of invention and that is what built the network automation infrastructure we see in large-scale DC deployments.
For smaller deployments, automation makes things easier and takes the drudge work out of the job. It's something we want, but not something we can always justify. Still, a guy can dream.
Automation at the Device Level (NETCONF/YANG)
Meanwhile, back in the real world of smaller networks and device-centric configurations, we're trying to make things easier as best we can. We've got NETCONF interfaces for programmatic control, and YANG models to use as templates for how things should be. Some of us are using tools like Ansible and SaltStack to go beyond device-by-device configurations, but we're still focused on the devices.
I'm not sure if this is due to the unwillingness of network engineers to change our paradigm of thinking from the devices to the network as a whole, or if it's the vendors creating equipment that interacts with the network only from its own perspective. It may well be that each feeds the other, creating a vicious cycle that's difficult to break.
If the necessity isn't there, where's the need for invention?
Commoditization and Virtualization (NFV)
As virtual machine technology began to become more common in smaller enterprises, the option of virtualizing all of the things became more appealing. If we're saving money and making more efficient use of resources by virtualizing server loads, why wouldn't we consider virtualizing some of our network infrastructures, too?
With Network Functions Virtualization, we came full circle to the dream that began with that OpenStack presentation. If the network, or at least portions of it, could be addressed programmatically like the other virtual machines, we were getting closer.
Were we dreaming too small?
Systemic Networking (SDN)
Even with NFV and the ability to use cloud and DC automation tools to provision and configure our virtual routers and switches, we're still being traditional network engineering greybeards and thinking in terms of devices rather than in terms of the entire network.
Enter Software Defined Networking, where we theoretically see the network as a programmable whole. The virtual components and the physical components share a single southbound API from a set of central controllers and the whole thing can be programmed through there.
Of course, depending on whose definition of SDN our products are working with, this may or may not be a complete solution, but that's a topic for another article.
Once this becomes commoditized, we theoretically have all of the tools to automate the network from a holistic perspective, but do we have an automation framework that will work equally well for all of the components in the platform?
The Whisper in the Wires
We have what it takes to virtualize and automate most of the network, making automation via central controllers a workable option. We can use one framework to deploy, provision, and automate the lot, right? Here's where I'm not quite sure. Even if we have a good strategy for our NFV devices and/or SDN controllers and their satellite devices, do we have a single framework that we can use to handle the deployment and management of the lot?
Share:
Jody Lemoine
Network Greasemonkey, Packet Macrame Specialist, Virtual Pneumatic Tube Transport Designer, and Connectivity Nerfherder. The possible titles are too many to count, but they don’t really…
Read more
