I reached out to leaders in the field of network automation and asked them one simple question.
“What did you wish you knew before starting to learn network automation?” and or “Give me a tip on how you started to learn network automation.”
The responses I got below are listed literally in the order I received them and in no order of importance. I hope some or all of the tips help someone.
- 1. It’s not about tools or technology, it’s about the impact automation can have on a business and subsequently, on ones career.
- 2. Not spending more time on model-driven programmability earlier.
- 3. Commit to coding every day, even if this is just an hour, form this habit.
- 4. Different hardware versions, with different software, will have incredibly different results.
- 5. I wish Devnet had existed when I started!
- 6. I wish I had known about tools like Pylint.
- 7. There is more to Network Automation than just the tools.
- 8. If I could start again, I would tell myself to shift the focus from viewing automation as a tool to simply type CLI commands quickly, but rather to see it as a comprehensive solution to exact granular control over the network.
- 9. Don’t be afraid to make mistakes
- 10. Start small and build your automation as you go.
- 11. I wish I had started learning Python at the beginning.
- Frequently asked questions
1. It’s not about tools or technology, it’s about the impact automation can have on a business and subsequently, on ones career.
There are many people that want the BEST tool, BEST tool chain, and BEST process, but optimising and automating workflows is a multi-phase journey and it takes time.
So, make sure you do not have a tool/technology religion and do not think you can “learn network automation” over night.
Have a focus on network automation architecture. It’s one of the most sought after roles we have at Network to Code and is a role (network automation architect) our customers don’t even know they need.
You can write a script or a playbook – so what?
How does that fit into a company’s process and existing systems? How does it integrate into a tool chain? What operational models make sense for a given organization?
In summary, I wish I was aware of these items 7+ years ago when I started in the network automation space although the industry is still young and we’re all still learning by the day.
2. Not spending more time on model-driven programmability earlier.
I was fortunate to have made many smart, well-timed decisions during my entry into the network automation space. I spent a few weeks learning AWS so that I could maintain a globally-accessible development environment.
Afterwards, I moved into Ansible, then Python with Netmiko and NAPALM.
I became quite strong in Ansible within a year, and respectable with Python within two years
“My biggest regret is not spending more time on model-driven programmability and telemetry earlier.“
While I conceptually understood YANG, NETCONF, and RESTCONF, I could only do “hello world” type of tasks. It was not until last summer, more than two years after starting the journey, that I really dug into these critical topics.
They can be challenging for CLI-focused networkers, but once you overcome the initial learning hurdles, you’ll discover a much better way of programming networks.
3. Commit to coding every day, even if this is just an hour, form this habit.
I admit I was somewhat arrogant years back, when people spoke about network automation. I thought my fast CLI skills would see me through my career.
What I did not see was how I could use network automation to improve operational efficiency and free up my time to work on higher-value areas.
I wanted to learn network automation, but never knew how to start and what to learn first, as there is a lot of material and information out there, to say I was overwhelmed would be a vast understatement.
I started using the content on Cisco DevNet as it aligned both to what I wanted to learn and also my job.
It can also help to find someone who has mastered this already and then shadow them and pair program, don’t feel that you cannot ask someone to mentor you, a lot of more experienced engineers will jump at the chance to mentor someone and help them grow.
Commit to coding every day, even if this is just an hour, form this habit.
Soon you will be automating the boring or laborious task that takes up all your time, once you are in the flow you will be automating every task or looking at automation to solve problems.
I won’t lie, it can be hard. Some days it does not seem like you are making any progress and you will get stuck, lost or just confused. This happens to every engineer, give yourself a break.
So where to start, this is the most often asked question. Cisco DevNet has a lot of free curated content and sandbox’s, follow the start now link. https://developer.cisco.com/startnow/
4. Different hardware versions, with different software, will have incredibly different results.
Although there are no regrets because if the mistakes didn’t happen, I wouldn’t have learned from them, here are the two things I wish I would’ve known before jumping into network automation, or automation in general.
The first big thing was that different hardware versions, with different software, will have incredibly different results.
Let’s take a Cisco router running IOS for example. With older versions of IOS, say, 15.1, it requires you to SSH in specifying the cipher. Ansible, a configuration management language that many networking professionals use for automation, doesn’t like that very much and it makes the experience a bit painful.
If I knew that prior to buying a Cisco router with IOS 15.1, I would’ve saved $50.00 bucks. It’s certainly not a regret however because I wouldn’t have known otherwise.
The second big thing, and perhaps more on automation/writing code in general, is to understand why the code is being written.
Anyone can piece together some code with a few for loops and if statements, but the bigger picture is what impact does the code have?
From an architecture perspective, you must know why prior to implementing it. As we all know, no plan goes correct if there’s no plan at all.
Understand the why as to what network automation is being implemented and why it’s needed for either you or the organization as a whole.
5. I wish Devnet had existed when I started!
Honestly, when I began my Network Programmability journey almost five years ago, it would have been great to have what is now the http://developer.cisco.com content.
They have made getting started with all the architectures extremely easy with many walkthroughs and code examples.
Also, to have access to the many Sandboxes is fantastic as it is a resource to “try out the code” in a testing environment!
Patrick Rockholz – @patrickrockholz – Systems Architect at Cisco
6. I wish I had known about tools like Pylint.
Prior to learning network automation, I wish I had known about the importance of tools.
Over the years I’ve learned, first hand, how much time tools can save. For example, using a linter (such as pylint) to ensure your Python syntax is correct
Or a formatter such as Black to ensure your Python code is formatted against PEP8 standards. Always go out of your way to learn the available tools out there, tools will save yourself time and head space and speed up your journey in becoming a network automation Jedi.
7. There is more to Network Automation than just the tools.
My dawn of network automation was all about fancy tooling to get things done, less about structure and processes.
Only on the way I realised how important Infrastructure as Code and a NetDevOps mindset are to develop the full potential.
Source of truth, documentation, collaboration, pipelines, testing etc.
In short: Don’t aim to learn tools like Ansible only, but also how to handle a git repository and build upon that foundation.
8. If I could start again, I would tell myself to shift the focus from viewing automation as a tool to simply type CLI commands quickly, but rather to see it as a comprehensive solution to exact granular control over the network.
When I first began my journey into network automation, I had no understanding for the potential of concepts such as Infrastructure As Code.
In my mind, automation was all about creating loops to execute repetitive tasks faster. But ultimately, how useful was creating 500 loopbacks on a device, really?
I would see examples of people creating detailed host variable definition files written in YAML and, to me, it just seemed almost useless.
What time was being saved creating these files when you could just type them directly into the CLI and be done? #
It was through understanding Python data structures, such as Dictionaries & Lists – as well as realising the ability to return output in a structured format that really accelerated my learning and understanding of network automation.
9. Don’t be afraid to make mistakes
I’ve stared at a blinking cursor too many times trying to think of the right way to accomplish something.
I’ve learned the most by trying to get things working, and refactoring multiple times to get a snippet just right.
Learn your tools: There are a ton of libraries out there for whatever language you’re using. Reading through docs and discovering new libraries can be a great way to speed up your development (avoid re-implementing things that are already available!). I like websites like [PyMotW] https://pymotw.com/3/ and [PythonWeekly] https://www.pythonweekly.com/ to find inspiration.
Read other Code: When you discover new libraries and projects, dive in and read the code. Popular repos with many contributors tend to have high quality code because a lot of code review is happening, and the code needs to be clear enough for all the contributors to understand it.
Find projects that are solving similar problems to things you may be working on for ideas to borrow.
Revisit your Code: Glancing over code I’ve written years ago can be eye-opening. You can see how much you’ve improved and what battles you’re still fighting.
This is also a great opportunity to fit in new libraries that you’ve learned about.
10. Start small and build your automation as you go.
If I could start over, I would change earlier projects where I tried to “boil the ocean” by solving several large and complex problems at once (and failed).
Find a single, simple, solvable problem to learn NetDevOps and network automation best practices, then begin to tackle those larger problems when you’ve built up muscles and understand the common pitfalls and perils.
For example, I would not try to move the entire device configuration into an Infrastructure as Code model at one time.
I would start with a single element of the configuration, such as AAA.
Then when that is fully managed via your automation, grow to other sections of configuration.
You will be surprised by how fast your entire configuration becomes managed and standard, and you have done so without risking a larger outage by modifying the entire device configuration at once.
11. I wish I had started learning Python at the beginning.
When I first heard about network automation I thought this is something that I have to learn.
So I did some research and started to learn Ansible as it looked like an easy way to get started. All the time I was reading about Python but it always seemed like learning a new language. (Which it was!) I wish I had started learning Python at the beginning of my journey as I would know a lot more by now!
There is so much you can do with Python and as it is one of the most popular programming languages in use today, it is certainly a great language to learn.
Then when I heard Cisco talking about it so much at events like Cisco Live. I realised that it is going to become a core skill for any network engineer from now on.
My other tip is to make sure you do something every day. I dipped in and out of Ansible for a long time and each time I came back to it, things had changed new modules had been added or I had forgotten how to do a certain task. It was only when I started using it every day that I really began to grasp it’s power. Then bundle that with Git and you have a nice solution to start your automation journey.
There is so much more to learn and I think the other problem with the role of the network automation engineer is that you are being overwhelmed with tools.
So, my advice is to learn the methodology of treating your infrastructure as code and then as long as you have some good skills in Python and or Ansible you have the building blocks to take your career in whichever direction you want to.
You do not need to become a software developer to be a good network engineer in 2020 but any skills you have in this area will stand you in good stead for the future.
Once you understand the basic tools and code you need to automate network devices, you need to step back and look at why you want to automate network devices.
Anyone can automate a lab, persuading a business they need network automation and implementing a successful solution is a much bigger challenge!
Keep learning and stay safe!
Roger Perkin – @rogernperkin – Senior Network & Security Consultant
Frequently asked questions
How do I learn Network Automation?
There is no limit to what you can learn and getting started is the main thing. Watch a few videos on Youtube and start writing some basic code in Python or download Ansible and start finding out how it works. The key to all automation is firstly learning the technology but more importantly how it all fits together.
Pick a simple task you do every day and work out how you can do it with Python or Ansible?
Will Network Engineers be Automated?
This is a very common question and fear amongst network engineers, that in a few years they will not have a job as everything will be done by automation.
This is not the case, the industry will always need network engineers who understand how everything fits together, using automation is just a way to do more and to also make sure it is predictable and accurate. Network engineering is going to change but there will always need to be a human element. The scale of networks are increasing all the time and there is no way that it can be managed manually anymore, we have to automate but it does not mean you will be out of a job .
Why is Network Automation Important?
The most important reason to automation network devices is to remove human error. Most network outages are caused by human error estimates between 40-80% of outages are caused by human error. If you can reduce that by automating common tasks that run without error repeatedly then you can improve the uptime of your network infrastructure.