I’ve been a fan of software-defined networking (SDN) since my first conversation about software-based firewalls for an application deployment in 2004. Our goal was to leverage the concepts of grid computing to grow and shrink the web and application server environments in response to load, and we got the idea to throw the firewall into the mix. What made our approach possible was the ocean’s depth of software development knowledge on our team tempered by a puddle’s depth knowledge of networking.
+ Also on Network World: Survey shows growing interest in SDN, where and how companies might deploy the tech +
Over the past five years, I’ve engaged in numerous conversations on software-defined networking (SDN), network function virtualization (NFV) and their relationship to cloud infrastructure, applications and management. The most common argument I hear in support of SDN/NFV is the anticipated cost savings from moving from proprietary hardware that has to be refreshed periodically to software that can be distributed and managed remotely.
I certainly understand there is a cost savings argument; a single pilot program can prove that point. However, some of the elements I see people counting as cost savings are really cost transfers, where the cost moves off the books of infrastructure. That cost has to land somewhere, but where? Let's consider the major cost buckets:
Hardware: In the SDN/NFV world, we still have servers, so although the margin on proprietary hardware may be under assault, there is still hardware to be acquired, managed and refreshed. Just because it’s part of a private or public cloud doesn’t make it free.
Software: Enterprises most often require a level of capability and support unavailable in the open source world. The same companies that provide today’s network hardware have the deep expertise required to develop equivalent software. The question is how well can they make the transition from hardware to software companies. Don't forget software vendors typically enjoy much higher margins. And what happens when software vendors begin incorporating SDN/NFV capabilities into their solutions and an organization ends up paying twice for the same capabilities? Software offers as many pitfalls as opportunities if not managed carefully.
People: Networking skills are in short supply already, and very few of those people have added software development skills to their CV. Networks are so large and critical to conducting business that it’s hard to accept hacking will suddenly become an acceptable development methodology. If the right resources can’t be bought in the market, the only other options are to train or start a talent bidding war. I have yet to meet a company that felt it had all the SDN/NFV expertise it needed.
Tools: This is the one area designed to save us from ourselves, but unfortunately tools features and functions lag capabilities by a generation or two. Existing tool sets will have to be updated and new tools adopted, which will require additional investment and training.
Three out of these four cost buckets could easily masquerade as additional costs in other areas. Hardware costs shift to the server and storage budget. Training costs slide over to HR. Tool costs cozy up with the software development team. While I expect SDN will drive tremendous capital and cost savings, such a narrow focus is likely to pinch teams needing to make investments as part of their transition.
Understanding the investment required to make the transition is important; however, equally important is defining how costs will be allocated to ensure they are tracked appropriately. Just like with SDN/NFV's big brother, cloud computing, the technology is the easy part.
This article is published as part of the IDG Contributor Network. Want to Join?