The way that we design data centers has radically changed in the last 30 years. In the 90s, a typical data center was full of physical machines, each with a very specific purpose. In many companies, the servers were bought by different vendors based on the purpose of the machine. This meant that there was a need for machines, network devices, and storage devices and that those devices were bought, provisioned, configured, and delivered.

The big drawback here was the significant lag between identifying the need for the machine and its delivery. In that period, this was acceptable, since the majority of companies had very few systems and they tended to change very rarely. Also, this approach was very expensive as a lot of devices were under-utilized.

With the progress of society and companies in the world of technology, we know that today, it has become important for companies to cut their infrastructure deployment time and costs. This opened the road for a new idea: virtualization. By creating a virtualization cluster, you do not need to have physical hosts that are of the correct size, so you can provision a number of them up front, add them to a resource pool, and then create the right-sized machines in your virtualization platform. This means that when a new machine is needed, you can create it with a few clicks and it will be ready in seconds.

This shift also allowed enterprises to move from a per-project infrastructure, with each project being deployed with its own unique data center requirements, to one large central infrastructure that can have its behavior defined by software and configuration. This means that one single network infrastructure can support all projects, regardless of their scale. We call this a virtual data center infrastructure, and in this infrastructure, we try to make use of generic design patters as much as possible. This allows enterprises to deploy, switch, and serve infrastructure at a large scale to enable a multitude of projects so that they can be successfully implemented by simply subdividing them (for example, by creating virtual servers).

Another big advantage that virtualization brought is the decoupling of workloads and physical hosts. Historically, since a workload was tied to a physical host, if the host died, the workload itself died, if not properly replicated on different hardware. Virtualization solved this problem since the workload is now tied to one or more virtual hosts, but those can be moved freely from a physical host to another one.

This ability to provision machines quickly and the ability of such machines to move from one host to another created an issue with networking configuration management. Before, it was acceptable for a human to tweak the configuration details while installing the new machine, but now, machines move from one host to another (and therefore from one physical switch port to another) without any human intervention. This means that the system needed to update network configurations as well.

In the same time period, VLANs affirmed their presence in networking, which allowed the utilization of network devices to be dramatically improved, and therefore optimize their costs.

Today, we work at an even larger scale, where virtual objects (machines, containers, functions, and so on) move in our data centers, fully managed by software systems, and where humans are less and less involved in the process.

In this kind of environment, automating networking is a key part of their success.

Today, there are some companies (the famous "cloud providers") that work at a scale where manual network management is not only impracticable but impossible, even when employing huge teams of network engineers. On the other hand, there are many environments where it would be technically possible to manage network configurations (at least partially) manually, but it's still impractical.

Aside from the time required to configure a network device, the biggest advantage – from my perspective – of network automation is the opportunity to drastically reduce human errors. If a human has to configure a VLAN on 100 devices, chances are, they are going to make a few errors in the process. This is absolutely normal, but still problematic since those configurations will need to be fully tested and amended. Often, the problem doesn't stop here, because when a device breaks and therefore needs to be replaced, a human has to configure the new device in the same way the old one was configured. Often – over time – the configurations change and – very often – there is no clear way to trace this, so while replacing a faulty network device, there might be problems for some rules that were present in the previous device but are not present in the new one.

Now that we have discussed the need to automate network management, let's look at how to manage networking devices with Ansible.