It is interesting, as the triplet new waves of hype evolve – cloud, SDN, and DevOps – that we are repeatedly hearing The Voice of Reason say things like “All network engineers need to be programmers”. While this is certainly not the only voice that demonstrates what I’m talking about, an example of it is Kirk Byers’ commentary on Network Computing’s site. (http://www.networkcomputing.com/data-centers/programming-an-essential-skill-for-network-engineers/a/d-id/1297898) I do not know Mr. Byers, and want to be clear, he’s not the only one portraying this wisdom, so the reference is merely that – a reference to the syndrome I discuss here.
In DevOps, certainly having staff members that understand both application development and network engineering is a bonus. Being one of those fabled unicorns, I also know that they’re few and far between. I’ve worked with some great ones over the years that “just get it”, and they certainly add value to an automation project that involves networking. But there is a reason that there are few of us that understand both.
I’m a programmer. I’m a very good programmer. In the course of my career, I’ve also become very good at strategy and even technical marketing. I learned networking because of my career path. When I chose to gear my career at new challenges, there were many. From datacenter administration to IT management, from storage and servers to networking to security, from cloud to embedded. I’ve enjoyed every aspect of my career, but I’m still ‘a software guy’ at heart… Just one that knows about networking, storage, and servers at a deep level.
The thing is, my knowledge is not some magical formula. There are people in your enterprise that know all of this, and not all of them are software people.
I’m just suggesting we stop and think about it. When making the move to DevOps, there is a need for a certain set of skills. Those skills absolutely do not have to be vested in a single individual. There’s more overhead if you’re coordinating efforts, but think about what is going into place – automation scripts (of one form or another, no matter what tools you use) that have to have a big initial push to get developed, and then, unless your environment is in perpetual flux, just get used and occasionally modified.
This does not require retraining of the entire networking staff. In fact, in maintenance mode, those scripts are not generally going to require regular work. Indeed, the largest changes to these scripts will occur as part of a pre-planned project that can take them into account.
Looked at another way, developers sometimes need to deal with networking issues… Does that mean all application developers need to be retrained as network engineers?
And there’s a risk. If you decide all of your network staff needs to learn how to code effectively in whatever language and/or tool you settle upon, some of them are likely to leave. Because they’re network engineers and not application developers for a reason. Just as I am at heart a developer, they consciously chose network engineering. For the amount of maintenance required after the initial push to get the automated portion of DevOps into place, one network engineer who is also interested in development is plenty. It doesn’t have to be the whole team. If it did, then all network engineers would need to be security engineers also, no?
It’s a wave. It will wash over your IT shop in stages, cresting with the workload required to get the automation part of DevOps running, then receding, leaving ripples, but not a ton of water behind. Treat it as such. Get the help necessary to fill the gaps, put a team together that can address all the issues, then let them all go back to their roles, with added (and reduced) responsibilities that DevOps brings. Let developers do the development, working in tandem with network engineers. Find the network engineer that is most interested in development, and have them sit with the developers, working it out, getting everything right and learning what the scripts do. Then let that person handle maintenance, and let the developers roll back until the next major project needs teamwork.
In the context of network engineering, system engineering, and application development, it’s a project, not a lifestyle change, to automate things. We know how to do projects, they don’t generally involve upheaval and retraining of entire teams.
But if you’re still convinced you need the unicorn that can do it all, give me a call. That is, after all, what my firm does – bring knowledge both broad and deep to the table to help you solve problems – but honestly, most organizations don’t need someone like me nearly as much as they need a process, a list of attainable goals, buy-in from IT management for the manhour investment, and a plan.
