In part 4 of our series on SDN, I discussed some of SDN’s most commonly asserted benefits. In part 5 I’ll look at the drawbacks, the majority of which are organizational or financial and not technical. The most commonly cited reasons for actively not deploying SDN are:
SDN requires significant staff re-training or recruitment. There are very few staff with proven SDN deployment / management skills making recruitment difficult and therefore re-training of existing staff is necessary. Of course having retrained those staff, their retention with their new, highly desirable, scarce skills might prove problematic too!
To use SDN effectively there needs to be a sharing of knowledge between business requirements, applications, servers and networking teams. This might take the form of cross-discipline teams, or individuals with broad cross-discipline understanding. Without this, mapping services to application requirements and ultimately network requirements cannot occur effectively. This type of breakdown or merging of traditional ‘silos’ is already occurring – e.g., with the emergence of DevOps – albeit slowly!
Whilst proponents of SDN cite the real cost benefits of running a more highly utilized network and the less quantifiable benefits of a more agile network with more rapid application and service deployment, re-scaling, etc. they often fail to factor in the costs of retraining, reorganization, new hardware and software licenses and the hidden costs of loss of business continuity during initial deployment.
Whilst tighter, more dynamic security enforcement is recognized as an advantage of SDN, it is also a new, rapidly evolving technology with new protocols and new weaknesses and vulnerabilities. Such a lack of maturity and the possibilities for compromising the network control layers make SDN an appealing target for hackers, industrial espionage, etc.