Automation has dominated the Information Technology industry for many years providing the ability to run environments at-scale with lower costs and less issues than traditional non-automated methodologies. However, as SD-WAN, SD-Data Centers and SD-Campus technologies have emerged, I've experienced resistance within the network engineering communities to software-defined and to automation in general and I've been asking myself 'why' lately.
Before the software-defined craze hit the industry, many tools hit the market over the years touting their ability to automate changes and ensure config consistency. These tools were great for cookie-cutter environments providing they worked properly, but rarely could they handle changes in business-critical parts of the environment such as core and data center networking.
Engineers by nature don't trust their work and reputations to others, especially to tools where they cannot watch what is happening. No doubt you either agree or ask why, and generally the answers boil down to either a lack of proper labs to test in or a lack of true network redundancy due to cost. Dual control and data planes through an entire network is expensive!
Automation requires some level of understanding programming, whether using Ansible, Python, NSO or other automation tools. Many (most?) network engineers don't have a programming background or vaguely remember a COBOL class from college. (A bit generalized, but you get my point).
Without a lab that fully mimics production, changes often go in as best-effort in most enterprise environments. Therefore, engineers want to slowly implement the configs and monitor to ensure nothing breaks -- or they can react quickly if something does. Traditional automation tools tend to be viewed as 'fire-and-forget' -- which is not comforting when you are avoiding resume-generating events.
So where does that leave us as automation and software-defined is not going away? As good as automation is for businesses looking to reduce costs, improve uptime and provide services at-scale, I believe automation benefits engineers as well:
We all know the best engineers are the ones that are continuously learning. Learning the basics of a programming language or an automation methodology ensures you as an engineer are not complacent.
For automation to work, enterprises must implement standards - both in process and in implementation methodologies. This reduces the complexity of the network and often introduces needed redundancy into the network.
Automation tools have improved significantly over the years helping ensure consistency, accounting for possible change failures and the need to back out, and providing a structured approach to implementing changes. Proper Preparation Prevents Poor Performance.
Automation is here to stay - both in on-prem and cloud environments. As network engineers and architects, we need to adapt and understand how these tools can help us do our job better and improve our personal growth opportunities.
(For those who say 'but I like my CLI", I ask when is the last time you used CLI to configure your home router? Some will say 'all the time', to which I have no rebuttal. But I believe most will say they don't remember. I challenge you to contemplate why - the answers to that question provide insight into why the industry as a whole is embracing automation.)
Комментарии