Configuration management tools like Ansible have played a key part to enable network engineers for their automation journey. They are very popular for provisioning heterogeneous resources in data centers, backbones or clouds. As long as they don’t interact too much with each other.
Why do we struggle to use configuration management tools to deliver end-to-end automated provisioning of modern network services? Let’s find out!
Multi-domain service automation is the new normal
The real value of automation stems from use cases that include multiple resources across different domains, and with dependencies between those resources. Such a multi-domain orchestration use case is for instance typical for 4G/5G mobile networks. The following chart depicts such a use case. The automation of end-to-end service delivery involves a large number of resources dealing with vEPC, cloud platforms, SDN controllers,…
Let’s take a simpler multi-domain use case: the configuration of a virtual firewall. It requires to wait until the virtual machine (VM) is up and running and fully operational. Using “static timers” in Ansible playbooks is just a workaround as the deployment time of a VM may differ. For instance it depends on the load of the cloud platform and other external factors. This dependency among different resources (this is a frequent situation) cannot be easily solved unless a desired state approach is supported. However, Ansible does not support the concept of intent or desired state. Ansible users can only sequentially execute playbooks. This is the imperative or procedural approach as opposed to the declarative approach. If the sequence fails, Ansible will just stop the automation process. Even if the environment may allow to achieve the end goal (intent) once some changes have occurred a bit later.
One tool to orchestrate them all
Ansible alone cannot really deliver end-to-end service provisioning for the previous cross-domain use cases. Network and DevOps engineers need other software or tools to achieve this goal. This increases the complexity of the overall automation solution. For instance, to configure cloud platforms and cloud public services Red Hat and HashiCorp advertised a joint approach to manage VMs. Hashicorp focuses with its Terraform orchestrator on cloud environments, but Terraform does not include any configuration management features. Hence it needs to be complemented with Ansible to configure operating systems and applications. In the same vein, Ansible requires a domain orchestrator like Terraform to handle VMs. Similarly Cisco NSO needs Ansible to offer multi-domain vEPC orchestration.
From our experience with service providers, only a holistic, multi-domain service orchestrator can truly enable cost-effective automation. Such an over-arching orchestrator should provide a single, unifying solution to support data centers, backbones, NFV, cloud interconnect services etc. This also requires a rich domain-specific language (DSL) that can handle different types of resources and dependencies. Key is that it does not necessarily depend on other automation tools (with their own language and practices) to be present. This holistic approach decreases a lot the complexity of deploying and maintaining orchestration use cases, especially in the mid and long term.