Automate when you can, program when necessary
Hello dear readers
Another interesting crocodile book is about to be published by O'Reilly
This weighty compendium comprehensively discusses the extent to which a sysadmin should be a “network engineer,” how optimally the automation and programming of such a specialist works. The book provides the basics of Linux and Python, and it is also expected a lot of interesting things.
')
To make it more interesting for you to vote, we suggest reading a short article by one of the authors (Jason Edelman), in which he tells you what thoughts prompted him to collaborate with Matt Oswalt and create this book.
Thoughts that I share with you in this article, for a long time did not give me rest. I wanted to write about it a long time ago, but when I read Matt Oswalt’s article Learn Programming or Perish (?) , I had a picture in my head, it only remained to publish my own article. Here I wanted to talk in detail about the automation of network tasks. I put the main message in the title: “automate when you can, program when necessary”.
After reading Matt's article, I would even clarify this wording: “automate when you can, write scripts when necessary.” Such a formulation is addressed specifically to network engineers (note: it is this thought that I put in the heading wording, but the word “script” specifies it a little). In this case, I paraphrase the old adage of network engineers: “switch when you can, route when necessary.”
Automate when you can
This formulation implies that you should use the right tools when network automation is possible. Why reinvent the wheel if you already have one? Now I am judging a bit biased, but I recommend using any extensible tool, better open source, which provides network automation. Currently I prefer Ansible from Red Hat and Extreme StackStorm. However, with the same success you can use other free tools, for example, Puppet, Chef or SaltStack, or even commercial solutions from manufacturers such as Cisco, VMware, Arista - add your favorite manufacturer . Ideally, you (your network team) should be 80% involved in automation.
Program when necessary
Program when necessary, now it is more correct to say - write scripts when necessary, that is, when the tool used is too complicated to perform some operation. Then we write a script to solve this problem, and by creating this script, you may be completing the tool of your choice. In Ansible, scripting refers to creating your own module or modifying an existing one, or programming your own Jinja2 filter. This is NOT zaboristoe programming, requiring years of training and practice. You can program very interesting things in the form of a script, and 30-40 lines of code (maybe a little more or a little less) will be required for everything about everything. It's not about writing 1000 lines of code. Ideally, you (or your team of networkers) should spend on programming 20% ​​of the time.
Please note: in the last sentence, I just mentioned “programming”, because if you have full-time scriptwriters in your team, then they should definitely try to grow to real programmers .
Rule 80/20 with network automation
If we consider the modern team of network engineers, then in the bottom line we return to the 80/20 rule. If you have 10 people in your team, then 8 of them should use the main working tool every day. If there are ~ 7 of them, it is also quite normal. The task of mastering the tools for managing the production environment is not in itself easy , so all the more it is impossible to require all team members to write a full-fledged production code. Naturally, among these 7-8 people there will be those who will write scripts more actively than their colleagues - this is the reality.
However, the remaining 2-3 people in a team should write scripts much more actively than their colleagues. They can be engaged both in a scripting, and full-fledged programming. At the same time, it should be noted that the more the script writer writes, the more obvious he becomes that he needs to improve his own code. Such people are self-taught and may soon pay attention to practices such as code review and automated tests. That is why they can in the long run become real programmers. However, this does not happen overnight.
The morning to become an expert?
Did anyone manage to prepare for a difficult network certificate certificate overnight? Yeah, no one. I often equate them with CCNA, CCNP and CCIE. Did anyone teach BGP as CCNA? I bet: if you ask a BGP question to someone who has just passed the CCNA, he will give you everything he knows about BGP - in full confidence that this is enough. After that, your interlocutor can open the CCNP routing guide and realize that he is still learning and learning; in preparation for CCIE, the same thing awaits him. By the way, the most interesting things will start when you have to manage the production environment using the BGP protocol.
So, are you a system administrator who wants to learn automation and programming? Great idea! Take and learn, but do not try to prepare for the CCIE for tomorrow morning. Begin with scripts, sort out data types and formats!
Findings about automating network tasks
First of all, keep in mind that there is no definitely right or wrong path. Just need to make some key conclusions:
Memo network engineer.
Conclusion
Try not to mix your own self-study and work on managing production environments. It makes no sense to write a FULL tool from scratch (all except the API and / or client part), if you don’t have a few full-time programmers who will do this full-time work. And even if there is - is this the best approach? If such thoughts have already been visited, then why not use (ready) open source instruments?
Good luck with automation!
Jason
Another interesting crocodile book is about to be published by O'Reilly
This weighty compendium comprehensively discusses the extent to which a sysadmin should be a “network engineer,” how optimally the automation and programming of such a specialist works. The book provides the basics of Linux and Python, and it is also expected a lot of interesting things.
')
To make it more interesting for you to vote, we suggest reading a short article by one of the authors (Jason Edelman), in which he tells you what thoughts prompted him to collaborate with Matt Oswalt and create this book.
Thoughts that I share with you in this article, for a long time did not give me rest. I wanted to write about it a long time ago, but when I read Matt Oswalt’s article Learn Programming or Perish (?) , I had a picture in my head, it only remained to publish my own article. Here I wanted to talk in detail about the automation of network tasks. I put the main message in the title: “automate when you can, program when necessary”.
After reading Matt's article, I would even clarify this wording: “automate when you can, write scripts when necessary.” Such a formulation is addressed specifically to network engineers (note: it is this thought that I put in the heading wording, but the word “script” specifies it a little). In this case, I paraphrase the old adage of network engineers: “switch when you can, route when necessary.”
Automate when you can
This formulation implies that you should use the right tools when network automation is possible. Why reinvent the wheel if you already have one? Now I am judging a bit biased, but I recommend using any extensible tool, better open source, which provides network automation. Currently I prefer Ansible from Red Hat and Extreme StackStorm. However, with the same success you can use other free tools, for example, Puppet, Chef or SaltStack, or even commercial solutions from manufacturers such as Cisco, VMware, Arista - add your favorite manufacturer . Ideally, you (your network team) should be 80% involved in automation.
Program when necessary
Program when necessary, now it is more correct to say - write scripts when necessary, that is, when the tool used is too complicated to perform some operation. Then we write a script to solve this problem, and by creating this script, you may be completing the tool of your choice. In Ansible, scripting refers to creating your own module or modifying an existing one, or programming your own Jinja2 filter. This is NOT zaboristoe programming, requiring years of training and practice. You can program very interesting things in the form of a script, and 30-40 lines of code (maybe a little more or a little less) will be required for everything about everything. It's not about writing 1000 lines of code. Ideally, you (or your team of networkers) should spend on programming 20% ​​of the time.
Please note: in the last sentence, I just mentioned “programming”, because if you have full-time scriptwriters in your team, then they should definitely try to grow to real programmers .
Rule 80/20 with network automation
If we consider the modern team of network engineers, then in the bottom line we return to the 80/20 rule. If you have 10 people in your team, then 8 of them should use the main working tool every day. If there are ~ 7 of them, it is also quite normal. The task of mastering the tools for managing the production environment is not in itself easy , so all the more it is impossible to require all team members to write a full-fledged production code. Naturally, among these 7-8 people there will be those who will write scripts more actively than their colleagues - this is the reality.
However, the remaining 2-3 people in a team should write scripts much more actively than their colleagues. They can be engaged both in a scripting, and full-fledged programming. At the same time, it should be noted that the more the script writer writes, the more obvious he becomes that he needs to improve his own code. Such people are self-taught and may soon pay attention to practices such as code review and automated tests. That is why they can in the long run become real programmers. However, this does not happen overnight.
The morning to become an expert?
Did anyone manage to prepare for a difficult network certificate certificate overnight? Yeah, no one. I often equate them with CCNA, CCNP and CCIE. Did anyone teach BGP as CCNA? I bet: if you ask a BGP question to someone who has just passed the CCNA, he will give you everything he knows about BGP - in full confidence that this is enough. After that, your interlocutor can open the CCNP routing guide and realize that he is still learning and learning; in preparation for CCIE, the same thing awaits him. By the way, the most interesting things will start when you have to manage the production environment using the BGP protocol.
So, are you a system administrator who wants to learn automation and programming? Great idea! Take and learn, but do not try to prepare for the CCIE for tomorrow morning. Begin with scripts, sort out data types and formats!
Findings about automating network tasks
First of all, keep in mind that there is no definitely right or wrong path. Just need to make some key conclusions:
Memo network engineer.
- If you are just starting to engage in automation - experiment with several tools and choose one of them. Next, work with him.
- Regardless of which tool you work with, you need to understand the data types. This is not programming. It’s good if you notice curly braces, but it’s still not programming.
- Regardless of what tool you work with, you must understand data formats, for example, understand JSON.
- You need to understand how scripts are written if a) you need to perform some operation that your tool does not cope with normally, or b) fix the problem (consider the stack trace), or c) expand the capabilities of your tool so that it can cope with a new task, which previously could not perform, and this task is easily implemented in your workflows. This kind of work is valuable because now your teammates will be able to use your plugin without programming anything for themselves.
Conclusion
Try not to mix your own self-study and work on managing production environments. It makes no sense to write a FULL tool from scratch (all except the API and / or client part), if you don’t have a few full-time programmers who will do this full-time work. And even if there is - is this the best approach? If such thoughts have already been visited, then why not use (ready) open source instruments?
Good luck with automation!
Jason
Source: https://habr.com/ru/post/348176/
All Articles