Network Automation: a comfortable journey.
We all know how painful it is moving from a technology that we are well confident to work with, to a new one where we have zero experience. Think about the first time you change OS in your laptop or server, or when you started to work with a new vendor product: the learning curve was so steep, slow and full of pain. Now, try to imagine if a day you suddenly decide to move from your daily job, where you have decades of experience, to a totally different one. To make thing more difficult, the new job you are moving into, it his a compound of bleeding edge technologies, unexplored fields and uncertain results. Kind of a plumber wants to become part of SpaceX mission. Easy, uh? ( But not impossible: human being has the amazing power to get what he wants. Everything is possible if you really want it.)
After this philosophical parenthesis, I can tell you that for me, moving from my classic Networking job to a Network Automation, was a big step and I struggled (...and still I do) before to get where I am today. I made some “basic” mistakes and found a lot of obstacles along the way (either with technologies as well as with people and company mindset). It would have been much easier if someone could mentoring my journey through Automation. So I decided to share my thoughts hoping that someone can make the most of it and have a comfortable (…but not too much) journey through Network Automation.
What Automation Really Is
Automation is an ecosystem composed by different tools. Automation touches a long array of different technologies and tools. You will find yourself doing some coding, and manage some Networking tools. You will need to adopt DevOps strategies and you want your stuff to run on some platform. You might need to store data in some back-end database and for sure, you will run some provisioning tools. Obviously, life is never easy so do not expect someone doing that for you: get ready to face different worlds and cover different roles when needed. This is Network Automation.
A new creature is born: The Network Automation Engineer
Automation engineers are experts who have the knowledge and ability to design, develop and manage systems, for process and software automation. Automation engineering is the integration of standard engineering fields. Automatic control of various control system for operating various systems to reduce human efforts and to increase accuracy.
The main scope of automation, is to reduce human efforts (read errors), for doing so the Automation Engineer is required to design solutions, build a product and maintain it. So, be ready to be an Architect as well as an Ops guy.
Tell me why…should I need for Automation.
Let’s keep it simple and realistic. Is all about money: — OPEX +$$$. Embrace automation is difficult not just for engineers but also for companies, where most of the time they cannot see the real value behind it. As Automation Engineer is our duty to show them the way!
- Increasing in infrastructure complexity
If we think how the infrastructure was 10 years ago (or maybe 15? I am getting older and loosing track of it…), we had nn bare metal where today we have nnnn virtual instances. Before we could ctr+c / ctrl+v config files and change few things here and there, while today we need proper ad-hoc set-up. So, if a company does not want to be overwhelmed by OPEX costs for maintaining its infrastructure, it must adobt provisioning management tools and maybe think also to configuration template for reusability
- Enforcing compliance
How to enforce security compliance on an infrastructure? Login into every single server/device and changing the config manually? How can you make sure that someone did not reverted your change and punched a security hole into your configuration? What about patching a config file, or a library or simply, patch the patched patch gone in the last patch? Remember, we do not have nn bare metal servers, instead we have nnnn virtual instances/devices. Automation can indeed enforce security rule-set as well as implement auto remediation in your infrastructure if something goes terribly wrong.
- Unpredictable result vs. Expected result
How many times we broken something because a typo in config? Spending endless hours in looking for the error and fixing it just in 2 minutes. What about those naming convention or config blueprint never followed, trying to give a sort of consistency across our infrastructure? When you deploy Automation, you embrace the concept of test first, deploy after: all the work is properly tested before to release it in production, as well as, having (proper) config templates, let you have a predictable and consistent result, no matter of vendor type or OS version
- Ticket queue waiting time vs CI/CD
With a Network Engineer background, I still remember where we have the ticket queue filled with tickets, waiting for VLAN provisioning, ACL rule or crap like that, keeping on hold SysAdmins and DevOps. If the concept of infrastructure is shifted to IaC or NaC you can easily move all provisioning tasks to a CI/CD and let each team be responsible for their part of network.
Automation as product.
Nope, it is not a project,it is a P-R-O-D-U-C-T.
“ Automation should not be considered just another tool or project. Rather, it should be approached in the same way as any other flagship product critical to the success of your organization. Once launched and put into practice, review your automation processes, iterate upon them, and update and improve them. ”
[ Nick Hopman, Vice President, Red Hat ]
So, consider to allocate some budget for Automation, perhaps you want to start to think to build a team, and invest on trainings. You might want allocate resources, taking in account that Automation is a full time job (you do not want, for example, a Network Engineer with Automation skills, rather than you want a Network Automation Engineer). Automation has its own project, so it needs for a PM to manage them. Last but not least, is important to have the right mindset which include have a proper understanding of the values of the topics discussed so far.
Think before writing.
At the beginning of my experience (..and let’s be honest, still today), when I start a new automation project I think about how to achieve the end goal required by that project, as well as tons of cool features. Most of the time, this end up in loosing track of the original requirement as well as spending more time than expected. So, have a clear and simple goal in mind and think what you need, not what you want. Once your project is delivered, you can later take the necessary time to add some features.
Most of the time, you will find yourself working with new technologies, tools or coding languages, make sure to have solid understanding around it so you can get the most of it as well as not build up technical debt (more about that later). Time spent in Lab or POCs is never wasted time
Whatever you build, make sure is reliable. If it breaks, people will shout/cry/try to commit suicide (…I can tell you that). This seems pretty obvious. What is not obvious is that people will start to lose faith in automation if your crap fails and it will become harder and harder for you to convince them to embrace it.
Whatever you build, make sure it is accessible, easy to be used by people that do not have understanding of it. Think about the UI and UX of your system otherwise nobody is going to use it.
In general, keep things simple. Life is complicated enough.
Pay down your technical debt …or you’ll be soon covered from a pile of s….upper troubles.
First of all, what is technical debt? Technical debt, is something build up along the time, when you do not things properly. Easy.
There might be different reasons why things are not done properly, for example:
- Lack of skills or understanding of the technologies being used. Try to look back to a project you have done 1 year ago and then let me know what you think about it…
- Management pressure. Remember, Rome was not build in a day.
- Poor design. Did I already tell you to think before to write?
- Do not treat Automation as product. …Déjà vu? Again?!
- Considering test and documentation as “optional”. If you don’t test it, it will break (in production). If you don’t document, someone will break it (sooner or later)
- Poor enthusiasm and team effort. Love what you do and share the passion .
Open Source or Commercial. What to choose?
Let’s highlight some of not so obvious differences between Open Source and Commercial tools. This is specially for manager and company decision makers people.
Open Source vs. Commercial
- You can add features vs. You might request a feature (and pay for it).
- You can fix it vs. You must raise a ticket (and wait).
- You learn how to build stuff vs. You learn how to use a product.
- It s free and open vs. It is commercial and proprietary.
- You build an asset in your team vs. You gain a skill in your team.
- Your contribute to the community vs. Your contribute to someone else bank account.
- You are in control of the software vs. The software is in control of you.
“Who should I hire, a super smart guy?” “Well…not really ”
Network Automation is a fairly new kind of job, so is not always easy to find the right person with the right skillset. Moreover in the 99.99% + 0.01% of the cases, recruiters have no idea whatsoever about what is REALLY required to face the beast of Network Automation, so don’t look for:
- “Rockstar in database!”. Rockstar’s lived in the 80s and I doubt they were doing any code
- ”Ninja in Ansible!” Ninja? …like the mutant turtles?
- “Pirate in coding!”. I do not believe there is someone cooler than Jack Sparrow
- “Unicorn in designing systems”. Unicorns are too fabulous to do any kind of work
Look instead for:
- Someone really passionate about technologies. IT is a passion more than a job
- Someone paying attention to the details. Do we want to talk about technical debt? …AGAIN?
- Someone constantly willing to improve its own work. Technical debt, technical debt, technical debt, […]
- Willing to learn. Any idea of how many cool applications there are out there?
- Open mindset. It’s all about it.
End of story. Enjoy your ride and be ready to get some bumps along the way.