Here at Bronto, we’re very proud to support the local community in many ways. One of the facets of that spirit of community support is in hosting a number of meetup groups. One of the meetup groups that we’ve been hosting for over a year now is Triangle DevOps. We love this group so much that two members of our engineering team, Doug Hairfield and myself, actively help to keep the group running smoothly along with Mark Mzyk of Chef, Mark Imbriaco of Digital Ocean, and Nathan Walls of WebAssign. We often host the group’s meetings in our Thunderdome, which has a maximum capacity of 200 people.
Back in May, before this Engineering Blog was live, we were very proud to host John Willis who is the VP of Customer Enablement at Stateless Networks. John is an early adopter of DevOps, and has made tremendous contributions to shaping the conversation about DevOps, and informing the community of many of its true roots in Lean manufacturing. You might call him a global influencer in the field. He’s contributed to books, podcasts, blogs, and is commonly sought as a speaker at conferences. More than anyone else, he’s probably most responsible for interpreting the wisdom of W. Edwards Deming for the software industry. For our audience, he talked a good bit about his take on DevOps, on Network Engineering, and made a strong case for why he believes that Network Engineers should adopt the DevOps model.
This subject really resonates with us at Bronto as we undergo major upgrades to our network infrastructure, in part for improving performance in our environments, but also in large part to facilitate SDN. If our infrastructure is a software project, defined by code, and if our network is part of our infrastructure, then why not treat our network as part of the infrastructure software project? We’re not there yet, but we’re on the way.
One of the great benefits for us in treating our infrastructure like a software project is that we can benefit from the myriad of tools and best practices of software development in managing our infrastructure. This is definitely a journey of kaizen, we have a long ways to go. But we’re using version control tools, peer review, pre-deployment testing, etc. to have a higher confidence in changes to our infrastructure before the changes are deployed into production. But a lot of the network management still involves ssh’ing into a switch, drilling down through the CLI, making a change (and holding our breath), and then committing it to the boot configuration. It’s fundamentally not much different than how we managed networks 15 years ago.
A lot of what is driving this change for us is rapid adoption of SOA, and being able to logically segregate hosts that fulfill different roles. As more and more SOA components emerge, the network configuration becomes ever more complex (and changes to it become riskier). Being able to version control our network configuration as easily as we version control our software and the rest of our infrastructure will go a long way towards letting us make frequent atomic changes that have been well-tested.
Tell us about where you are in your path to SDN today. We’d love to hear from you in the comments below.
Also, if you’re a Software Defined Networking-savvy Network Engineer, and thinking of a change in scenery, I’d love to speak with you directly.
Here’s a little video about what it’s like to be a Bronto Engineer.