In case you don't know, Riot Games runs League of Legends, a team-oriented game that deployed on their worldwide infrastructure. It's so popular that they have contests and championships, and 32 million people logged into watch the championship series last year. (For a reference point, theNBA has 17 million viewers.) Needless to say, people want the network to be fast and reliable. Why? If the network has high latency, you can shoot an arrow at an opponent who you think is in front of you, but you will miss, since the player actually moved out of the way, and you didn't notice it. Big fail.
To create a good gaming experience, they need to deploy game server data centers around the world, close to where the players are. Those who had >80 ms ping had a bad experience.
Adam used to fly around to set up the data centers, but since these devices are (a) computers, and (b) on the net, you'd think they can (c) automate it and (d) stay home instead. He uses Ansible (a popular configuration platform) playbooks and Jinja2 templates, and also spoke about this at Ansiblefest San Francisco but the lessons apply to those who use other scripting systems, such as Chef, Puppet or plain old Python (Juniper devices support PyEZ microframework, for example). Most modern Juniper switches support automation either via NETCONF or console access, but some extra work needs to be done for older devices. I believe that time will solve this problem as people update their devices but Adam thinks we need to push more vendors to adopt standards for automation or backport if possible.
Another example for Ansible in network automation is that you can use these automation techniques not only on a conventional network but also for a network managed by an SDN controller, which is the topic of a talk at the Ansiblefest by Don Clark of NEC. It sounds odd, since you may think that SDN eliminates the need for automation scripts. That's not true.
He showed how they provision the infrastructure for NEC unified communications (UC = small PBX) customers using Ansible. They used APIs on their ProgrammableFlow controller for their OpenFlow based switches for the UC system. They too saw a provisioning time reduced from many weeks down to 10 minutes. You can create a virtual network lab in MiniNet to test them out, so you can really test the scripting without setting up lots of hardware.
So in the case of Riot Games, they used classic VLANS, and in the case of NEC, they used OpenFlow based virtual tenant networks, which are quite different. In either case, they benefited from automation.
Our research shows that although tools such as Ansible are cool, people are looking at traditional scripting languages such as Python, so you don't have feel forced to adopt Ansible modules to get these benefits.
So it's not just a matter of making life easier for network engineers but one can see actual benefits for the end users and higher level goals too.
Our survey respondents told ESG that they like the consistency in using automation tools, but they also enjoyed higher level benefits such as compliance, meeting SLAs, and improving security. I think the takeaway is that DevOps is a great way to achieve network automation, but DevOps is not the primary reason for doing network automation.
If you can learn these methods, you may see benefits beyond the plain configuration speed, as shown above (which alone is great) and can justify spending the time learning about these tools. I wrote a few articles in the past about network automation, such as this one on Infrastructure treated as code, how it can benefit everyone and one in Network Computing on general benefits.