This is the latest in a series of posts featuring partner success stories where partners share how they’re helping customers achieve their goals by using Cisco technology. This week we’re featuring Colin McNamara, Nexus IS Director of Cloud Practice and Chief Cloud Architect.
Software Defined Networking (SDN) is gaining serious steam in our industry. Early adopters have been in production for a couple years now, and the first wave of “enterprise” SDN applications are making their way into the market.
One of the key benefits of SDN applications is that they provide a consistent view of the complete, end-to-end network topology (versus a per hop view commonly found in legacy routing protocols). This enables enterprises to implement a consistent policy across multiple hardware platforms and pass control of the network to the applications themselves. SDN also facilitates slicing (network partitioning), enhanced Network Access Control and multi-tenant data center networking – capabilities that are driving adoption and motivating vendors like Cisco and others to evolve their product lines to support this new technology.
Managing Network Applications vs. Engineered Networks
The new SDN applications that are being built on OpenDaylight, such as Cisco One and others, are just that – applications. However, the teams and methodologies that we have traditionally used to support our networks are not staffed and aligned to support network-based application development. Instead, they are staffed to serve the traditional stateful network systems that require network engineering skills.
Of course, the reality is that network engineering teams are being asked to support both methods of networking at once: Stateless SDN systems, and the stateful networking systems. Emerging best practices however are demonstrating that using modern (Agile) software development methods such as Test Driven Development, and Continuous Integration and Delivery for network systems can help teams bridge the gap between the old and new worlds of networking.
What the future state of Network Engineering and Operations looks like
It’s hard for me to say this, (as a CCIE myself), but many network engineering teams around the world, and the CCIE’s that staff them may want to consider acquiring software development skills. Although not ultimately necessary, CCIE’s that do decide to learn these skills will need to become educated on programming languages like Java and Python to leverage the features in OpenDaylight and OpenStack Neutron (OpenStack Networking). Skill with systems and network automation tools like Puppet would also be beneficial. For those that decide to go down this path, these tools aid in the transition to SDN by providing network engineers to manage the underlying stateful systems programmatically.
Many modern CCIEs (Network Application Developer) will want to learn these new programming languages, they’ll also have to achieve a level of competency with modern Agile software development methods and tools. Another portion included in this is that CCIE’s will want to learn how to write a test or a feature, manage an entire network via source control, and structure network code correctly. Not all may choose to travel this road, but for those CCIE’s that do, Cisco available to serve as a resource and provide guidance.
What you can do to help your teams with this transition
At Nexus, we’re fortunate that roughly one half of the company is engineers. But that also means that during any technology shift or transition we have to figure out how to transform ourselves before the market transforms around us. I believe that we are at the start of a significant transition from traditional system and network engineering to engineering based on software development.
Because we value our associates, we’ve been running some experiments on how to transition individuals and organizations to software development based engineering. Following is a sample of some of the ways we’re transforming our systems and ourselves:
1. Identify and develop software development skill sets within your organization – Raspberry Pi
This may sound like a Silicon Valley nerd fest, but one of our most successful experiments has been to hold internal, Raspberry Pi hacking contests. The goal of these contests has been to encourage our engineers to write functional applications in Python. The contests have not only altered their perception of programming as “not in their job description”, but have also fostered an even higher level of teamwork within our engineering team.
2. Provide an opportunity for engineers to be part of a modern software development team – OpenDaylight and OpenStack
I can’t recommend this enough. The experience they’ll gain by contributing to an Open Source project that uses Agile tools and methodologies is priceless. It maps directly into the skills they’ll need to manage a Software Defined Network. As a bonus, the skills they’ll acquire will enable them to extend SDN functionality into your company’s or your customers’ networks.
3. Start with last mile automation (Puppet) and work your way back
Every journey starts with a single step. A great first step in the transition from network engineer’s to network application developer, is to automate manual network configuration tasks. While there are many automation tools available, Puppet is gaining great support in among major network platform vendors. It also fits quite nicely into the Continuous Integration / Deployment pipeline used in advanced network application development environments.
4. Understand that this is a journey of continuous improvement, not a destination
The networks we work on, and the tools we use to define and manage them are changing. Embarking on this journey with the spirit of Kaizen, or Continuous Improvement for both the networks you manage, and the skills that you use to manage them is very important. By maintaining a positive spirit and continuously improving the People, Processes and Technologies that you use to define and manage your networks, you’ll discover that success in the world of Software Defined Networking is within reach.
Nice job Colin!
Thanks Roger
Great post Colin! These are excellent points that need to be shared around. People are starting to get more in tune with what orchestration and DevOps methods can bring back in value and efficiency. I’ll definitely use this article for a reference doc for people I’m trying to bring into better processes like TDD, CI and Agile.
Let the hackfests begin! 🙂