Recent years have seen a sharp increase in the number of automation scripts used by network engineers to streamline the service provisioning process. In addition, configuration management software has been very instrumental in the successful roll-out of automation projects. Network operators are now convinced about the benefits of decreasing the usage of CLI for normal operations. But why is there still a large backlog of semi-manual network engineering and service provisioning tasks?
Playbooks are fun
Among configuration management software, Ansible got very popular due to its short learning curve. Ansible playbooks are using YAML encoding. This language is quite easy to grasp even for engineers without any software programming experience. Hence network engineers can quickly deliver basic automation use cases by developing simple playbooks.
Ansible playbooks typically require modules to provision resources:
- They aim at collecting facts, parsing command outputs and issuing commands on network devices. The scope of these modules covers most network vendors, cloud platforms, operating systems, …
- Their validation for existing and future device versions and network operating systems is a must. This is why many community members and some vendors maintain modules. For instance, Arista maintains modules each time a new EOS release is available.
There are many Ansible playbooks available to quickly configure servers, network elements and to deploy specific VNFs. All in all, Ansible usage has continuously grown over the previous years for automating many “atomic” and well-contained tasks in the IT and networking domain.
YAML is a great language … for input purposes
However, while Ansible users have significantly increased their Ansible skills, they have also been able to learn about some major weaknesses. A typical pitfall encountered by IT and service providers is the lack of standard implementations and compliance with company best practices. Indeed, any engineer can quickly develop playbooks without “thinking too much”. YAML does not make it easy to enforce good software development methodologies. There is nothing wrong with YAML. It was just never intended to be a programming language, leveraging on all the software engineering goodies invented during the last 50 years.
The difficulty of enforcing software engineering best practices has the following consequences:
- It is quite hard to take over previously developed Ansible playbooks for instance during staff turnover. In case of emergency, the engineering staff has to quite quickly understand, update and later on maintain these playbooks. Any delay can result in strong business impact as manual processes have to be used.
- The high number of different playbooks written for the same domain makes it difficult to consistently and systematically update them.
So even if in the short term there are significant benefits, network engineers should also identify the boundaries of this approach. If not, it may be quite difficult to entangle it. Long story short: most configuration management tools do not offer real capabilities to design and model end-to-end services as they usually don’t include a powerful domain-specific language (DSL). Without such a DSL, the network programmability will stay limited to simple automation use cases. Learn more in our next posts.