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.
Thanks to Ivan Pepelnjak (see source)