Infrastructure as Code

Back in 2013-14 there was talk in the network world of SDN (Software Define Networks), I would explain what SDN is but no RFC, IEEE or ISO standard was created so it ended up with vendors creating their own SDN solutions which are all different, most were proprietary and had some form of vendor lock in, ask any network engineer about vendor lock in and watch their face go red.

SDN was primarily trying to solve scale and consistency, as networks grow, they naturally become unwieldy and inconsistence creating complexity which then leads to longer fault repair times and changes that are unpredictable, this can damage the reputation of the network infrastructure with a loss of trust for the business and its customers.

From SDN, a new term has appeared named “Infrastructure as Code” which falls into the world of DevOps/NetOps, where device configuration is essentially code. Manual configuration of a device either copying/pasting or entering the commands doesn’t scale and is prone to errors, typos, and misconfiguration, Infrastructure as Code aims to solve these key issues. A few tools emerged for Infrastructure as Code, but Ansible appears to be the most popular in the network space, mostly because it’s the most user friendly as you don’t need to come from a programming background, is free/opensource (you can get paid versions) and is vendor neutral, so no vendor lock in. Ansible has modules which enable Ansible to interact with network devices, on the Ansible website (LINK) there are hundreds of modules from F5, Juniper and Checkpoint and is constantly growing. Should be noted that Ansible can also manage other IT Infrastructure such as Linux, Windows, KVM/VMware etc.

Some of the other benefits of Infrastructure as Code is that we can use tools and workflows used in the software development world such version control with GIT, GitHub, Bitbucket and CI/CD workflows to test and deploy configuring. Validation feedback is also a big advantage, imagine that you need to change the NTP settings on 100 routers, Ansible could make the change then run commands to check the NTP status then send a email with a report of every routers NTP settings and NTP status.

Although learning the DevOps tools can be steep and setting the environment for the Ansible can take time, benefits will appear in the long run. I suggest starting small, play in the lab with simple Ansible Playbooks, from this you can start to identify what you are wanting Ansible to achieve in your environment.