For many, Ansible is the answer they’ve been waiting for: It provides automation that empowers a single admin to do the work of a whole team—deploying, updating, provisioning, configuring, and orchestrating all with custom-designed settings. For others, Ansible—or its advantages over OEM-specific network management tools—is still a mystery.
To clear things up, we dug in with an experienced, senior network engineer with over 18 years of experience working in enterprise-level environments. Here’s what we learned.
Convenient, Flexible, and Familiar
Because Ansible is agentless and open source, it can “easily fit into most network environments without exhausting operational or capital budgets. For engineers that are exposed to the command line and Linux, the structure and interactions feel very familiar.”
Playbooks: Usability Combined with Versatility
Playbooks, written in YAML, give instructions to the managed nodes being controlled by the control node. Users often don’t have to write their own playbooks because “many of which are prepared by vendors.”
However, if you want, you can dig in and make your own. “The playbooks I have written were used for parallel discovery over hundreds of routers and switches. The results were then used to generate needed configuration changes to better align them with our best practices.”
Comfortable, Yet Different
Familiarity with Linux “is a big plus, as Ansible is written by RedHat and often used via the command line.” However, even for seasoned Linux users, Ansible introduces a different mindset: “There is a paradigm shift in how one looks at configuring a network – going from scripting to declarative statements and understanding idempotency.” Idempotency involves running the same functions repeatedly without negatively impacting the system.
Even though Ansible is renowned for its usability, it’s best to take a step-by-step approach:
“When I was introduced to Ansible, it was by a veteran who stated, “Ansible is best-learned bit by bit: learn to crawl, then walk, then run!” Ansible is flexible and one can start with existing knowledge and build off that. If you can configure a device via SSH, you can replicate that in Ansible easily using the same syntax, so I found the risk low. From there, the user will learn more complex functions and can alter code to better fit into API driven playbooks instead of SSH/CLI driven playbooks.”
Dry-Running Architectures Reduces Risk
Because Ansible enables you to perform tests of your ideas before rolling them out, an element of risk is reduced: “Ansible gives you the ability to dry-run your playbooks (scripts) without applying them to devices which helps. Once the playbooks are validated, if you are lucky enough to have a test lab, that is the place to start.”
However, those without a testing environment can still mitigate risk by introducing the automation in phases. “If you do not have a test environment (most of us!), then start with a small subset and validate. Once you are comfortable that the code matches your intent, expand out to the larger set of devices.”
Even though “most of what you do in a live environment can be tested in a lab, virtual or physical,” that’s not always the case. “Discovery of an existing environment, for example, needs to be done live and can’t be done ahead of time.”
Cisco DNA vs. Ansible: Ansible Provides More Flexibility
While Cisco DNA is a potentially powerful network management option, the fact that users have to commit to Cisco’s products presents challenges.
“Vendor lock-in is always scary, especially if the terms of licensure extend years into the future. Some risks of DNA, for example, are cost and not using the platform to its fullest capability – you want the Civic but can only get the Mercedes. Since Ansible is open source, it can be implemented without licensing or lock-in. Once one knows Ansible fits the environment, licensing and support can be purchased later. DNA licensing models do not allow for such flexibility.”
It is amazing what 18 years of experience can teach you. To dive in more, check out our ebook focusing on Ansible, network automation, SD-WAN, and more within various industries.
Pros and Cons of Using Open-Source Tools
Pros of Open-Source
- Zero software costs (it is all free).
- A big learning curve (although this would be considered a con, the benefits of having staff trained in a network automation tool may benefit future endeavors).
- Customizable capabilities tailored to specific environments.
- Multi-platform integration.
Cons of Open-Source
- Increased deployment time (usually not user-friendly).
- Lacks solid support teams.
- Command-line interfaces require extensive input of commands.
- Lacks reporting capabilities.
Integrated Security With Smart Network Capabilities
At PivIT, we want to ensure you get the best value for money and the information you need to make the right decision. Whether you decide to commit to a Cisco product or go the Ansible route, we are here to help through the entire journey.
Contact PivIT for further advice on network automation options. Our focus is to examine your CAPEX/OPEX limitations and present you with options to free up your budget and achieve your goals.