During Interop 2014 I got involved in numerous interesting conversations revolving around SDN and new operations models (including the heretic idea of bundling appliances with application stacks and making developers responsible for network services).

During one of those discussions someone said “I think I get the ideas behind DevOps, but I don’t think we should configure our network devices with Puppet or Chef” to which I replied “Puppet or Chef are just tools, DevOps is a lifestyle.”

So What Is DevOps?

The definitions of this hot term are (not surprisingly) very vague, but most of them agree that it’s a new approach to software development and deployment process that allows you to deploy new functionality way faster than traditional “throw my garbage across the ops wall” approach (see Adrian Cockcroft’s Netflix presentations for a pretty radical example of DevOps approach)

If you want to deploy new applications (or software releases) on a daily basis, you can’t have any of the regular SNAFUs that crop up during the regular application development and deployment process – the applications have to be developed in a way that makes them easy to deploy, and the infrastructure has to be ready for rapid iterative changes and rollbacks (should a new deployment fail).

It’s pretty obvious you can’t get to the above nirvana without serious reengineering of your practices and processes – CLI monkeys won’t cut it any longer; you have to automate as many operations as possible, and make them as repeatable and testable as possible.

There are two fundamental ways toward this goal from the networking infrastructure perspective:

• If you have to touch network devices to deploy new services (or applications), automate the network device configuration as much as possible, and cut out the need for manual CLI work during service deployment. Tools like Tail-F’s NCS can help you get there;
• Decouple the hardware infrastructure from the virtualized services using overlay virtual networks (where you can deploy new segments without touching network gear), and use small per-service (or application) virtualized appliances.

Needless to say, I prefer the second approach because it has fewer moving parts (and thus fewer potential failure points).

Also, you have to get rid of “my network is a unique snowflake supported by ever-growing heap of kludges” mentality; you have to simplify your network- and network services design as much as possible, get rid of all the unnecessary features (which also reduces vendor dependency), and standardize the minimum viable design that meets your company’s business goals, not crazy whitepaper-inspired wish lists of IT engineers.

And What Is Puppet?

Oh, Puppet… it’s a nice tool that you can use to deploy new servers, virtual machines, or services. I would definitely use it (or another similar tool) for deployment of Linux-based solutions. Would I use it to configure my network devices? I may (or not)… but the actual tool doesn’t really matter. You do need something that will allow you to automate device configuration whenever possible – whether it’s Puppet, Chef, Ansible, or something totally different is irrelevant.

Need more information?

Check out my new SDN Resources web page