03/16/2026 | Press release | Distributed by Public on 03/15/2026 23:03
Image generated with AI.
As always, when I encounter an interesting question or challenge at work that could add value for readers, I can't resist sharing it on the APNIC Blog. Recently, while training a team of IT professionals in the heart of Europe on network automation tools, I was asked a particularly thought-provoking question that prompted me to dive deeper and do some additional research: What is the best strategy for implementing network automation in an enterprise network?
It's a simple yet thoughtful question, which I'll address in this post.
Automation vs legacy (manual)
There is no doubt that automation offers benefits such as speed, accuracy, reliability, and efficiency, and goes far beyond simple configuration management tasks, including resource provisioning. However, it may not be a good fit for every infrastructure environment. One must evaluate and compare the pros and cons before adopting automation.
For example, if your environment demands an economical solution with no short-term automation setup costs, requires continuous human oversight (where human judgement is mandatory due to concerns about vulnerability exploitation), or needs to avoid error propagation across the entire infrastructure (as automation-based errors can impact systems at scale beyond a single managed node), these may be convincing reasons to stick with a legacy approach rather than opt for automation.
On the other hand, automation can save time, reduce effort and complexity in network infrastructure, enable a centralized architecture, and lower labour costs for routine tasks.
Automation enthusiasts like myself enjoy diving into scripting and experimenting, even without a strong coding background. Most automation tools do require solid Linux skills, as well as familiarity with human-readable data serialization languages such as YAML and HashiCorp Configuration Language (HCL), which are widely used for sharing data and defining structured configurations in Infrastructure as Code (IaC). Playbooks - essentially lists of actions executed in sequence - act as blueprints for automation, written in these languages.
Selecting an automation tool
There are many automation tools available, including Terraform, Ansible, Salt, Puppet, and Chef. These can be chosen for your infrastructure environment based on several factors, including whether they are agent-based or agentless, declarative or imperative, focused on orchestration or configuration management, open-source or vendor-specific, as well as considerations such as network scalability and support for diverse platforms.
Declarative tools are the most common. They focus on the 'desired end state' and execute tasks as a complete package. Imperative tools, by contrast, are interactive in nature and execute tasks step by step. The type you choose depends on various factors. Although declarative approaches are often preferred due to their focus on 'what' should be achieved and typically deliver the expected outcome after a few runs, they may become complicated when the underlying logic is complex and greater step-by-step control is required. In such cases, an imperative approach, which focuses on 'how' tasks are executed, may be the better choice.
Similarly, when considering deployment models, one must decide between an agent-based or agentless automation tool. An agent refers to a small piece of software that serves its controller (master). Depending on your infrastructure requirements - whether you prefer pushing configuration to managed devices or require managed devices to pull configuration from a controller - you will choose the appropriate tool. Although agentless solutions are generally simpler to operate, they may encounter scalability and compatibility challenges as your infrastructure grows or hosts increasingly diverse workloads.
Strategy for implementing network automation
So, what should be the strategy for implementing network automation in an enterprise environment for the first time?
Several approaches are possible. The first that comes to mind is automating every resource and workload in your infrastructure - from switches and servers to routers, firewalls, and other network or security appliances - all under a single automation umbrella.
However, for a brownfield infrastructure, this approach seldom makes sense. It assumes you have trained personnel who are not only proficient in automation but also capable of debugging and managing misconfigurations or errors that could propagate at scale with serious consequences. Poorly designed automation solutions can be expensive, and implementing full-scale automation in a brownfield environment often entails a significant upfront investment. I consider this approach quite risky, so let's explore partial implementation options instead.
Another approach is partial implementation - combining automation with legacy (manual) methods. This means continuing to configure appliances manually while limiting automation to operational changes only, thereby reducing risk compared with a full-scale rollout. For example, automation might be restricted to tasks such as adding or removing users, managing IT support tickets, software patching, backups, monitoring, alerting, and security scanning.
However, this does not fully realize the benefits of automation. In this scenario, automation merely assists with routine operational tasks, whereas its potential value extends far beyond day-to-day activities.
In my opinion, the best strategy is gradual implementation. Unlike the previous approach, this does not restrict automation to routine tasks. Instead, it begins with careful analysis to identify bottlenecks and recurring issues that consume time and effort and keep technicians occupied. Conduct an assessment of your deployed resources, appliances, devices, and workloads. Identify what changes frequently, where most errors occur, and which processes consume the greatest effort. These areas should be your starting points for automation.
You can then progressively expand automation according to your priorities and processes by reviewing your complete workflow and determining where it delivers the greatest value at each stage of implementation.
I hope you enjoyed reading this blog. In my next post, I will share typical playbooks along with simple steps to deploy resources using an open-source tool in a cloud-hosted environment.
Please keep learning and broadening your knowledge using the resources and training offered by APNIC.
Azhar Khuwaja is a Telecom/IT Trainer with over 20 years of industry and training experience.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.