I have been involved in automation since around 2004, when I was managing nearly 200 nodes on the AlphaServer. Specifically, I was responsible for the hardware aspect. It may seem straightforward, but it’s important to consider that there was a mini operating system running under Unix that checked the connected components, detecting both critical and non-critical errors. Identifying non-critical errors as soon as possible meant being able to plan a shutdown to replace the failing component, thus saving a night of work.

The automation I had created at that time was a script that, via SSH, accessed various instances of Tru64 Unix, executed diagnostic tools, retrieved detected errors, categorized them according to their criticality, and made them available for review.

Later, around 2007, I found myself frequently managing Linux system installations. Replacing DVD installations with an automatic system meant saving several hours of work on a weekly basis. So, I decided to use PXE, through which, upon system boot, physical or virtual, the Linux installer was loaded, installing the base of the operating system according to some predefined “standard” parameters (we’ll understand the meaning of the quotation marks later).

These Linux systems then needed to be customized based on their role, by installing specific packages and configurations. After trying CFEngine and Puppet, I chose the latter, which, although newly released, seemed less complicated.

Later on, I shifted to network management, handling dozens of Cisco routers. These routers contained access lists used to filter and classify traffic based on required QoS. There were some small modifications to these access lists to be made weekly. The automation I created was based on Expect, which, via SSH, connected to the various routers and replaced (updated) the access lists. Netmiko and Ansible were still dreams of those who would develop them.

In 2011, for personal study needs, I needed to automate the creation of network laboratories, which led to the birth of UnetLab, now managed under the name of EVE-NG, which forms the basis of our laboratory.

Subsequent experiences in automation include:

• Automating PANW firewall policies to enable remote access to industrial devices during specific maintenance windows (the project was then entirely rewritten as FWAdmin, a plugin for NetBox);
• Automating network discovery and generating part of the documentation (the project evolved over time and is now released as NetDoc, a plugin for NetBox);
• Migrating a data center to Cisco ACI technology (I developed Python scripts that directly invoked the APIs);
• Generating a draft remediation plan from Nessus outputs;
• Provisioning lines for a service provider using Cisco XR technology (I chose Ansible to allow the network team to autonomously modify the playbooks);
• Migrating a backbone for a service provider to Cisco XR technology (I chose Ansible for device provisioning and PyATS + Genie for validating around 140 devices).

All of these projects can be grouped into two categories which I call:

• Single task automation;
• Process automation.

The difference between the two is substantial.

Single task automation

I call single task automation an activity that arises from a purely personal need, aimed at automating a series of activities (tasks) of the individual themselves. In most cases, automation in a company starts like this: there are repetitive tasks, and if the person performing them is particularly creative, they will write a small software to automate those tasks. Let’s look at its characteristics:

• One-shot;
• Based on procedural scripts, written to solve a task, and generally not reusable;
• Aimed at personal use;
• Does not involve the team but remains confined to the individual;
• Not included in any procedure;
• Closely linked to the person who developed it.

In short:

• Easy to implement (pro);
• Does not scale, causing a proliferation of scripts, and is limited to specific tasks (con).

What characterizes this type of automation the most is its short lifecycle: born out of the individual’s need and almost never reaching the level of a process, once the author changes roles or companies, the automation ceases.

I can affirm that, despite the very high number of hours saved, 80% of my automation projects died as soon as I changed roles or companies.

Process automation

I call process automation the automation, possibly arising from single task automation, which is accepted at the company level and therefore becomes the way to perform one or more specific tasks. The scripts are documented, maintained, and used by a team of people. But not only that: the scripts are the only authorized way to perform associated tasks. Let’s see its characteristics:

• Automation is based on company-approved and vulnerability-monitored frameworks;
• People cannot act except through approved scripts, and in emergency situations, this could be a problem;
• Compared to total freedom, scripts offer little or no freedom of movement, and in emergency situations, this could be a problem;
• Script changes are only allowed with prior authorization and testing;
• Automation is approved by the company and defined as a standard.

In short:

• The process is defined, standardized, less subject to human errors, and, especially thanks to some frameworks, self-documented (pro);
• Automation development is generally slower due to the number of people involved in defining the process, standardization, and development. In the long run, automation removes expertise, as people get used to using scripts and lose sight of the underlying world.