Infrastructure as Code, Proprietary OEM Automation, and NetBrain

Paul Campbell
By Paul Campbell January 22, 2019 3 minute read
Paul Campbell is a seasoned technologist who has designed, architected, and implemented networks for SMBs to large enterprise Fortune 1000 companies. Paul is the CEO & Founder of Quaversal, a consulting group out of Charlotte, NC.

Automation, orchestration, DevOps, scripting, and more dominate my social media feeds. Automation is the act of doing manual tasks in a repeatable fashion with the push of a button for simplicity, scalability, and record keeping. Depending on your OEM, there are many ways to accomplish this — but what’s right for you?

Infrastructure as Code vs. Proprietary Automation
What we’ve seen so far is that OEMs keep coming out with their own individualistic ways to perform their automation. Then you have OEM-agnostic approaches like Ansible, where you view the infrastructure as code, regardless of OEM. With infrastructure as code, you execute specific queries that are handled appropriately depending on which OEM is underneath. There is nothing inherently right or wrong about either approach. From my standpoint, I’ve seen great success with OEM automation tools. I’ve seen similar success with third-party approaches to infrastructure as code.

The point of automation is to help you achieve a variable return today that yields exponential results tomorrow.

What’s lacking in either method is a blended approach. I believe this is where NetBrain stands out. Does it go as deep as a full-blown Ansible Tower installation? No. But that is the point when we discuss automation. Far too often I hear people say, “You can’t automate my <insert job, function, action> tomorrow!”

Know what? They’re usually correct. The point of automation is to help you achieve a variable return today that yields exponential results tomorrow.

 Automation Delivers Bottom-Line Results — If You Use It
Take, for example, one hour of time that can be saved per week for “Bob” or “Cheryl” at their job. Doesn’t seem like much at face value.  However, 1 hour a week is 52 hours a year, or 1 week and 1.5 days a year. What if Bob and Cheryl’s team has six people on it, and this first automation step does the same for everyone? The business sees 7 weeks and 2 days of productivity back. This was just one hour. What if we did two, three, or four hours per person? Staggering, and not as much of a fantasy as people think.With this, I say why not invest in something that will provide more value than just “automation”? Infrastructure as code is great, but do you have people who understand the code? OEM-specific approaches are great, but do you have the talent today to run it? Or can you re-train them to be up to date?

The same argument could be made about NetBrain, and I’ve been on both sides: learning how to use it, and trying to convince people to acquire it. Any new technology requires additional training, ramp up, and adoption. I believe the difference is an amalgamation of scope and ease of use. No one will adopt new technology if it is harder to use, regardless of how great it is. Is anyone still rocking a Zune? No, I highly doubt it. (For the one guy in the back, I get it — you love it.) But as a business, we must look towards the bar we’re setting for our individuals.

Automation Beyond “Net New”
NetBrain automation affords you the opportunity to automate not only provisioning (change management) but also your operations. Most discussions around automation seem to be centered on “net new” rollouts versus what you have today and how you’re going to manage the “net new” after it is implemented.  More often than not, they’re separate teams.  We should take care to understand the benefits to both teams, not only one.  For when we talk about a development engineer who loves infrastructure as code and builds a support pipe for it while the support engineers don’t understand it – you’re hitting a bottleneck and a detriment to your business.

See NetBrain’s Adaptive Network Automation in 2 Minutes