Network Automation Is More than Just Ansible

One of the attendees of my Building Network Automation Solutions online course sent me this suggestion:

Stick to JUST Ansible - no GitHub, Vagrant, Docker or even Python - all of which come with their own significant learning curves.

While I understand how overwhelming the full-blown network automation landscape is to someone who never touched programming, you have to make a hard choice when you decide to start the learning process: do you want to master a single tool, or understand a whole new technology area and be able to select the best tool for the job on as-needed basis.

Using a networking analogy: do you want to know how to configure interface addresses and OSPF on a Cisco router, or do you want to understand how to build networks?

It makes perfect sense to start with a single tool, and if that’s what you want to do we have you covered - you can get Ansible for Networking Engineers materials as part of Standard ipSpace.net subscription, or enroll in self-paced online course which includes support and hands-on exercises. The one thing you should not do though is to stop after getting somewhat familiar with Ansible, or you’d risk becoming another Expert Beginner trying to turn every problem into a nail because you happen to own a shiny new hammer.

In the network automation online course we try to help you move beyond a single tool. We start with topics like “what are the challenges of network automation”, “how do I get started” and “what components would I typically need in an automation solution”, then cover various scenarios from simple reports to full-blown configuration management, dive deep into data models, data stores and data model transformation, and spend a lot of time on organizing your code, testing the code and validating input data, and integrating your automation code with front-end orchestration systems and back-end databases (or whatever you happen to use for your source-of-truth).

Obviously we cannot do all that with a single tool. We’re trying to encourage the attendees to use Git and GitHub/GitLab/... very early in the process - maintaining everything you work on in a code repository should be as obvious in 2018 as washing your hands or using sunscreen - and while you can use whatever environment you wish to set up your lab, we’re mentioning Vagrant because it’s one of the best tools to set up an on-demand test environment.

Finally, you’ll eventually hit the limits of whatever high-level tool you decide to use, and will have to resort to lower-level programming language to overcome those limits. Python happens to be that language if you decide to start with Ansible… and when you grow beyond what Ansible can reasonably handle, you’ll have to change your tool - and that’s why I invited David Barroso to talk about Nornir in autumn 2018.

Sounds interesting? Why don’t you join hundreds of other networking engineers who already started their automation journey and register for the course?

Recent posts in the same categories

2 comments:

  1. Matthew Schwen 08 January 2019 17:48
    For many network engineers, unless you learn during personal time, you will not be able to learn the full scope of what DevOps or Automation really means. I have gone through this transition myself. I have worked at large enterprise companies for many years, and It was not until I quit and joined a startup that was fully focused on DevOps that I really started to understand the culture and what it meant. Now, I am back at a large enterprise company and it is the same issues all over again. I try to change the culture, I've held training on Python, Git, Ansible, Jenkins, etc. However, nobody on my team seems to fully grasp it. And I do not blame them, it is very hard to speak a new language when you take night classes to learn it; also, you will never be fully fluent in another language unless you speak it every day with others who are already fluent, even more, you need to immerse yourself in the culture to fully understand it. For traditional network engineers, who don't want to spend nights and weekends learning and who don't work in a DevOps culture, I would say to just focus on Ansible until you are an expert, then move to the next thing. This can be done one tool at a time over a few years, no need to rush. Start with Ansible because the learning curve is mild and it can have a large impact.
  2. Salman Naqvi 09 January 2019 13:57
    Seconding Matt's comment, I would suggest learning Ansible on its own as a starting point, then moving on to Git, Python, Vagrant at later more advanced stages. The blog makes a good point about learning all the tools together, but, like Matt, it simply has not been practical for me at a large enterprise. With just Ansible alone to start, I could however see picking some low hanging fruits to start on the automation process and then move on to more complete automation projects using more advanced tools.
Add comment
Home
Sidebar