Hello, Network Automation World

Network engineers are facing the daunting task of automating the network while business leaders are trying to understand the costs, risks, and benefits of allocating resources and the budget to do so. The industry has been quick to promote the idea that network engineers need to automate the network. Putting aside the topic of buying commercial products, network teams are questioning where to focus their training and development efforts and how to get started.

The answer is not to start with automating the network. Instead, the focus is on small tasks that are currently causing operational friction between teams.

The first step for network engineers is to identify the tools used by stakeholders on the various teams and become competent with systems that have APIs designed for automation. Perhaps your organization shares information using spreadsheets that expose an API, such as Google Sheets. Learn to interact with such system APIs and you’re well on your way to reducing inter‑organizational operational friction and delivering higher quality network service.

Recognizing Value

For business leaders to see value in network automation, it must be directly tied to metrics used by the business to measure success, not the metrics used by the network team. This is a crucial concept for network teams to recognize. Networks exist for two essential reasons: delivering services that generate revenue and providing IT services. Operational friction is anything that delays a business outcome that has a material impact. A simple example is having to wait on another team, whether it is for information or for them to complete a task that is blocking progress.

The measure of success for automation is not how much it benefits the network team, but how much it benefits the business. The marketplace measures businesses by the agility, velocity, and stability of their service offerings. Business agility and velocity are optimizing the “ah-ha!” to “cha-ching!” effort it takes to launch and deliver services. Business stability is optimizing the “oh no!” to “all clear!” effort it takes when those services are down or at risk. Any tools that reduce time or risk and improve service delivery are valuable to the business.

Understanding Stakeholders’ Systems

Every team in an organization uses tools in its day-to-day work. A network team needs to catalog these systems to understand if they can be automated and if so, how. The goal of this analysis is ultimately to remove as much operational friction as possible.

The most common tool is spreadsheets. Server teams, for example, may produce and share spreadsheets containing information such as servers, switchports, VLANs, and IP addresses . Many other teams consume this spreadsheet – the network team, the voice team, the multimedia team, and so on – and every time the server team updates the spreadsheet, all the other teams might need to update their systems in response.

As a network engineer, you can ensure consistent use of the data by extracting information from the spreadsheet programmatically rather than with traditional copy-and-paste methods. You can use the data to create device configurations, as well as programmatically instrument network monitoring systems. The amount of benefit you get from applying automation via APIs is a function of the rate of change to the spreadsheet. If the spreadsheet changes on a frequent enough basis, then automating the use of the spreadsheet data yields considerable business value.

Different teams also use specialized tools that have well‑defined APIs because these software systems were designed to be automated. One category is commonly referred to as a controller. A security vendor may sell a controller that manages firewall devices. The controller provides an API that gives the network team access to specific items of information. When troubleshooting a service issue, the network engineer can use the API to determine whether specific firewall rules are in place.

A second category of API‑enabled tools is public clouds like AWS, Google Cloud Platform, and Microsoft Azure. Networking engineers can use the APIs exposed by cloud network services to (for example) learn which routing prefixes are configured for a particular cloud routing instance, and then configure the on‑premises routers connecting to the cloud for correct interoperation..

Network engineers also need to examine their own infrastructure for automation purposes. Setting aside vendor controller products and focusing on network device APIs, the unfortunate reality is that automating network devices is by far the most difficult and complex endeavor an engineer faces. Some network vendors provide a robust device API with 100% functional coverage, while other vendor APIs cover only a subset of functionality. And there is always legacy infrastructure that does not have APIs at all. For devices with limited or no APIs, the network engineer is faced with writing natural language processing (NLP) tools for “CLI scraping“.

Learning to Learn APIs

Learning how to use a new API is becoming the next critical skill for a network engineer. This is a specific skill that enables someone presented with a new API to determine how to begin using it effectively. The learning process consists of a series of specific steps, and is independent of the underlying protocol (REST vs. NETCONF) or the encoding of the data (JSON vs. XML). Once you’re comfortable with learning how to use an API, you’ve achieved the first step in your automation journey and can take on any API‑based system. You know how to get started, what pitfalls to look out for, and can begin to explore tangential tools, such as Postman, that reduce the friction in their tool development.

Some systems are easier to learn than others. Network vendors, unfortunately, have made many of them very challenging to learn. They have focused on providing a catalog of all of the APIs they support, but without supporting documentation on how to use them, colloquially referred to as “cookbooks”. Lacking a cookbook is analogous to walking into a grocery store with many aisles of food, but without any knowledge of how to cook a meal. Learning to use the Google Cloud API or Google Sheets API, by comparison, is a completely different experience. Companies such as Google that develop software systems designed for automation generally provide significantly better API onboarding documentation because these APIs are consumed by software developers that business services rely on.

Conclusion

Network engineering teams are looking for how to begin the automation journey, the “hello, world!” of network automation. They want to identify the low‑hanging fruit, the quick wins to show value to the business without introducing risk or boiling the ocean with scope and complexity.

Even though it may seem like the most logical starting point, don’t start with the difficult task of automating the network directly. Start by making a complete list of tools that your stakeholders use. The objective is to meet them half‑way using their tools’ APIs to reduce operational friction and demonstrate a two‑way benefit. The more the network team can increase the benefit radius beyond the network team, the greater the value to the business.

The post Hello, Network Automation World appeared first on NGINX.

Source: Hello, Network Automation World