Brian Jackson - Fotolia
In the first article of this two-part series, we explored the emergence of software-defined access networking and how the technology centrally controls network policies.
Another key benefit of software-defined access networks is mobility. Wired and wireless policies, for example, can be united, so users can move among mediums without a difference in their ability to work.
Users can also move among locations within the bounds of the network -- from desk to lunchroom to conference room, for example -- and never see a change in their equipment behavior. Security and quality-of-service (QoS) policies seamlessly attach to users as they move around.
With software-defined access, network engineering teams can also perform adds, moves and changes to the network much easier. A new device added to an existing network can inherit the same configurations and policies as another device.
Additionally, changes to global policy can be accomplished from a single place -- the controller -- as opposed to several different devices that might be in far-flung locations. End-to-end QoS and security policies may be updated without having to worry that some device might be missed or misconfigured.
Auditing becomes easier, as well, because you only need to look at one system to ascertain policy adherence. Backups and restorations of the network configuration are easier, too, and change management is easier to act on, as network maintenance time shrinks.
The drawbacks of software-defined access networks
So, software-defined access architectures are without fault or blame, right? And older designs are best left in the dirt as relics of the dark ages of networking, right?
Well, software-defined access networks have some issues, too, such as manageability, vendor choice and change itself. None of these are showstoppers. But blindly walking into a new network paradigm with nothing less at stake than the usability of the system is not in anyone's best interest -- even for the vendors selling the sizzle.
Manageability is not a challenge in software-defined access of greater or lesser import than in older designs. But it is different, and it is change. Along with change and difference come training and understanding. As a result, IT groups may need to overcome their existing biases.
Many network engineers have been at their jobs for a long time. They are very good at what they do. But changing their mindset -- and prying the command-line interface from their hands -- may raise some concerns.
Many folks won't make the leap, instead preferring the status quo. Those who are willing, or even excited for change, will need to learn new skills. That change, however, carries a financial cost that could be onerous in the short term.
Beware vendor lock-in
When examining any new technology, vendor choice, vendor lock-in and vendor prejudices always manifest. These issues are magnified when looking at technologies that are significantly different than previous, well-established methods.
New technologies, like software-defined access networks, are usually disjointed at inception and fragmented among vendors. Consequently, the potential for vendor lock-in is high. Or, you might select a vendor's product that falters before gaining a substantial following.
If the appropriate technology groups develop software-defined access standards and certain vendors become compatible -- and your vendor does not -- a couple of things can happen. Your vendor could pull the plug on its product because of a lack of support or sales. Then, you're left with a product that probably won't be expanded or even patched. Alternatively, you might get locked in with a vendor and feel compelled to continue to buy its product unless you forklift your entire infrastructure.
These things can happen with established systems and vendors, as well, but the risk is much higher with developing technology.
Heed business goals
Software-defined access certainly seems to be how we'll build out access-layer networks from now and into the foreseeable future. But, as with all new technology, be vigilant when forking over a large chunk of your IT budget.
Make sure your plans and purchase align with both your IT and business goals. Also, ensure your vendor will support its product throughout its lifecycle. Don't buy the new and shiny object simply because it's new and shiny.
You and your team have to manage whatever you put in place. And you have to answer to the rest of your organization as to how or why you can or cannot meet its needs. If you can do that, you'll be ahead of the technology curve and stay there comfortably for some time.