DevOps is often touted as the next big thing in software development, and rightly so. DevOps encourages collaboration among different teams working on the product, aims to reduce products' time to market, and much more. But what if you are not developing software, per se? Do you have to miss this new wave of innovation? Of course not!
In his upcoming talk at All Things Open (ATO), Sean Cavanaugh of Cumulus Networks will discuss using DevOps tools like ONIE and Ansible for provisioning and modernizing the data center. I caught up with Sean to hear his thoughts on networking in open source, his other experiences with open source software, and a sneak preview of his talk.
You've done a lot of work with the US Federal government and military. How is open source adoption there? Are open source tools used for day-to-day activities?
My background as a Department of Defense (DoD) employee was with the Navy (as a civilian), and my background at Cisco was primarily U.S. Army focused, with me supporting the 106th Signal Brigade at Fort Sam. The Navy was very pro-open-source. Not only does it lower cost, but it also makes it easy to choose an operating system and then have several companies bid for hardware. I think sometimes people (wrongly) think that open source equates to "un-secure" since you can read the source code, but most people I came across were starting to see the advantage. There are lots of open source projects approved for use in the DoD.
One of the projects I worked on was migrating an internal DoD website from a proprietary, contractor-built system to an open source CMS tool with which many of you would be familiar. Obviously, the DoD is very secretive of exactly what they are up to, but they are pro-open-source since it saves them a lot of money, and you have the whole world constantly testing, contributing, and making the product better. For the Army account I was on, they were very pro-open-standards (as opposed to open source). For example, they would choose routing protocols like BGP or OSPF over Cisco's proprietary EIGRP. Where open source became important was testing, validation, and education. We couldn't get a Cisco box for every single soldier to train on, so I would use Linux to help them learn the basics, which eventually led me to the job I am at now with Cumulus Networks (Cumulus Linux on bare metal switches).
Networking is your forte. Can you name a few open source networking tools that you use daily?
- ONIE (Open Network Install Environment)
- Spanning tree, which uses the open source project mstpd
- Routing with OSPF and BGP (uses the open source project Quagga)
- Network configuration using the open source ifupdown2
- Network troubleshooting using the open source tool netshow
- Network connectivity testing (iperf, ping, traceroute, mz, scapy, all open source projects either built-in to Linux or a Google away)
What is your advice to anyone interested in learning networking?
One of our goals at Cumulus Networks is to make this easy. We just announced a new free product called Cumulus VX, which is a virtual machine you can run on your own laptop.
It's entirely community-supported, and we think this will lower the barrier to entry. This product also works with the open source projects GNS3 and Vagrant that many network engineers take advantage of to learn everything from basic networking concepts to recreating their own network environment.
We have various labs up on our website for free, and of course, just like most open source companies, we offer instructor-led training both online and in-person at very reasonable prices.
Why are open standards important in networking?
Awesome question! If Company A builds protocol Cat, and Company B builds protocol Dog, how do they get those protocols to talk? They can't! It's just like someone who speaks Japanese and someone else who speaks English would need a translator to communicate effectively. By embracing open standards, we can make pieces of network equipment talk to each other, servers, laptops, phones, etc. If we didn't promote open standards, we would be locked into solutions where everything is controlled by a single vendor from A to B. We have many customers at Cumulus Networks that run multi-vendor environments, and open standards are not just encouraged, they're crucial.
Imagine if the vendor you were using went out of business or had a supply chain problem and you couldn't get any more equipment. If you were using a proprietary protocol, you would be very stuck and have to migrate the entire network. Open standards are not just important, they are the lifeblood of network engineers.
How would you define DevOps with reference to networking domain?
DevOps is in its infancy for network nodes. For years network engineers were restricted to what their vendor would allow them to do, and usually this was with TCL or some other code or interface that would make you pull your hair out. Now that most vendors are realizing the huge value prop of open DevOps, you are seeing more and more "DevOps on network gear" or what some people are calling "NetOps."
I don't think we have even begun to scratch the surface of NetOps. Most people just think of "rapid provisioning," but the network is the piece that keeps everyone connected and talking to each other. There are many more functions for automation in the data center.
Without giving away too much, can you give us a glimpse of your session at ATO?
I think your previous question started this train of thought: What is DevOps in the networking domain and what does it mean? To me, DevOps is giving me a very easy programmatic way to configure network nodes easily, quickly, and dynamically.
My talk is going to briefly touch on several buzzwords used within the networking industry today (like SDN, open networking, and bare metal switching), but will also show how I personally consider DevOps a huge part of software defined networking and show several detailed examples of how you can have a next generation network fully automated using "off-the-shelf" tools that people are already using on their servers. I am very excited to show off some of the stuff we are doing for our customers.