Interview: Benefits of Network Automation (Part 2)
As promised, here’s the second part of my Benefits of Network Automation interview with Christoph Jaggi published in German on Inside-IT last Friday (part 1 is here).
What are some of the challenges?
The biggest challenge everyone faces when starting the network automation is the snowflake nature of most enterprise networks and the million one-off exceptions we had to make in the past to cope with badly-designed applications or unrealistic user requirements. Remember: you cannot automate what you cannot describe in enough details.
The next roadblock is the mindset: network engineers never had to program (or even think in terms of detailed step-by-step procedures). Data models, decomposition and abstraction, common building blocks… concepts well understood by software engineers and architects are a total mystery to most network engineers and architects.
Then there’s the obvious “I will lose my job” and “I don’t want to become a programmer” nonsense. Every single technology change introduced in the last centuries increased (not decreased) the amount of work that needs to be done, and we should strive to get rid of boring mindless manual work anyway. As for “should everyone become a programmer” myth just look around. Did accountants become programmers when accounting was automated decades ago? Did pilots become programmers when autopilot was added to airplanes?
Last but not least, networking vendors aren’t making things any simpler by still shipping devices that are really hard to automate.
Note to ipSpace.net subscribers: some challenges we’re facing when interacting with network devices are described in Network Automation 101 webinar. Data models and related topics are covered in details in in Building Network Automation Solutions online course.
Can network automation cover all network devices?
In the ideal world it should, but if you make that your first goal you’ll never get there… and some things like soon-to-be-obsolete devices are simply not worth automating.
Start small, pick a simple process that’s taking too much time and automate it… and keep doing that until you’ve automated most of your infrastructure. It will take years, but you’ll eventually get there.
Can network automation be implemented across sites and across private and public cloud?
Absolutely. Consistent deployment of new sites is one of the early benefits you can gain from network automation. For example, UBS deployed around 20 new data centers worldwide at a pace of a data center a month with a really small team, and they were only able to pull it off because they fully automated the deployment process.
Also, the only sensible way to deploy workloads in the cloud is to use repeatable processes using infrastructure-as-code tools like Amazon CloudFormation, HashiCorp Terraform or Docker Compose.
Note to ipSpace.net subscribers: you can find several data center fabric deployment use cases in Network Automation Use Cases webinar. Some of them include full-blown Ansible playbooks… and you can learn how to use Ansible for network automation in Ansible for Networking Engineers webinar or Building Network Automation Solutions online course, which also includes a presentation by Thomas Wacker describing automated data center deployments at UBS.
How does an IT department best approach network automation?
It depends on whether your company treats IT as a strategic resource, or as an unnecessary expense. As I pointed out in my keynote during the last SIGS Technology Conference, you must control the evolution of your infrastructure if your management thinks IT could be a strategic resource for your company’s growth or competitiveness. A logical consequence is that you should have your engineers trained in network automation tools, and that you should eventually have a team that will develop or extend a network automation solution that you adopt.
If however your top-level management treats IT as unnecessary expense your best long-term option would be to move your workload into a public cloud and let someone else handle the automation. Failing that, you could start small, get baseline knowledge needed to automate simple tasks, and slowly grow the set of tools that help you automate common procedures. I’ll demonstrate a few of these tools that you could start using immediately during the Lean Start into Network Automation workshop in Zurich on August 30th.
If you can’t make it to Zurich: we covered similar use cases in Building Network Automation Solutions online course.
Does network automation save money?
Usually not in the way IT managers expect it would. Don’t expect reduced headcount, and don’t expect to get rid of your networking engineers – after all, they are the ones who know best how to design, operate, extend, and troubleshoot your network, so they should be heavily involved in designing, building and deploying your network automation solution.
Properly implemented network automation/orchestration system will definitely increase the reliability of device- and services deployments, reduce the wait time caused by change management processes, reduce post-deployment troubleshooting caused by random operator errors, and (by eliminating tedious repetitive work) make it possible to reassign network engineers to work that adds real value to networking infrastructure.
Where can one learn more about network automation?
It depends on whether you want to master individual tools, or start designing and building automation solutions.
Some network automation products (example: Ansible, Salt) have really good documentation, and are available in open-source format, significantly lowering barrier-to-entry. You’ll also find plenty of simple how-to guides on the Internet.
When you’re ready to move past kicking-the-tires, you should make an investment into a more structured training like Building Network Automation Solutions online course that gives you the bigger picture and helps you design systems, not use tools.
Finally, there’s a significant community of networking engineers trying to help their peers understand the benefits of network automation. We’re organizing meetups and workshops, like the Lean Start into Network Automation workshop in Zurich on August 30th, in which we’re demonstrating how easy it is to solve real-life challenges with simple tools
We tried doing the YANG approach, but this is way to much information for a normal person, since the big vendors have completey different models for the same thing. What about openconfig you say? We tried looking into that, but these are really plain, but never the less a good starting point for your mindset. For instance we want to deliver a single router with a connection to a PE. Where to start?? Sofar we modelled ethernet-interface, ip-interface, tunnel-interface, ha-interface, bgp-config, inet-ipv4/v6 etc. All this stuff is placed into a DB with key, value pairs, where the KEY is the object name and the value is the variable. This variable needs to transform into the correct configuration that resides on the box.
Next up is the question if your network model should be represented in the Database model equally. You could say well put everything in one big table and provision from there. But wait you also want to deliver 2 routers.. hmmm damn.. i need to model everything apart so we can use the network model as lego blocks to provision my service. Oh wait... sales has put in another vendor... What to do now? create a new models for this new vendor or augment the standard model with vendor like models... so many questions. We are getting there for sure but that is only because we have 3 people and we pretty much agree fast over how to do it. In BIG enterprise IT, i would say impossible with all the politics around. just my 2 cents :)