Network Automation Roadmap

Chapter 4. Planning Your Adoption of Network Automation

If going from manual to automated network management is surely good and worth the effort, the problem becomes selecting which kinds of products and management platforms should be used to achieve that goal. This is a problem that, paradoxically, has been complicated by the very importance and usefulness of network automation. Since the arrival of digital communication networks, so many solutions to automate components of network management have been developed, from monolithic platforms to full custom software to tiny shell scripts in many different languages, that it can be really hard to choose which way to go or how to integrate separate tools. Let’s then look at some practical considerations for teams who are wanting to implement or improve their automation practices.

A single console that can be supported by automatic scripts but lets the administrators issue any command that the network supports while always presenting one coherent, interlined view of all relevant data is an essential component of every network automation solution. Over the past few years, this assumption has led to a few “turnkey” graphical dashboards promising network automation. Although the convenience of such user interfaces is without question, we all know the value of a platform goes well beyond its looks, and looks alone do not guarantee that the platforms are all equally efficient and sustainable in the long run. The potential problem is not in the dashboard itself but in how the automation is implemented in the backend. If a network automation platform has (regardless of its license!) a monolithic architecture that is hard to expand or customize, it may be unnecessarily difficult to “attach” it to networks whose design principles were very different from those imagined by the developers of that platform.

Similarly, there have been a number of networking technologies that include an “all-or-nothing” platform requiring all network hardware to be homogeneous and locked into a specific vendor. Although these types of platforms have an appeal for some smaller, simplistic networks, they will severely limit their own real-world efficiency in the long run as the business grows, no matter how convenient and easy they appear to be today—unless, of course, the users could be confident that the network they have to manage with them will not undergo any significant changes for years, which is rarely the case.

As we have seen, almost any modern network must continuously evolve with its users. It must be always ready to support, for example, the addition of remote servers or entire offices, possibly with very different hardware, usage patterns, and automation capabilities than the existing ones. Accordingly, its automation-management system should support both its own initial installation and future events like these with minimal training of the existing network teams and without hiring external professionals every time a major change is needed.

The consequence is that, rather than monolithic platforms, it makes more sense to select a solution stack that fully supports both these expectations and the best practices summarized in the final part of this section: a solution stack that is flexible, easy to understand, and capable of providing an out-of-the-box experience from the first moment for most of your already existing needs but is also ready to grow and scale without restarting from scratch every time. It is important to note that looking for network automation solutions of this kind also makes it easier to trust them enough to get the most out of their adoption, as distrust of network automation vendors has been defined as “one of the primary reasons hampering the growth of the [network automation] market” and, consequently, of all the benefits automation can bring.

Best Practices for Network Automation

Every network is different, but whatever network you have or want to build, it is safe to say its automation must support the following best practices, or capabilities, which summarize the previous parts of this report:

Do things once

As obvious as it may seem, this bears repeating. As a very basic but adequate example, the full configuration procedure of a switch with one click or one command in a script is an activity that ideally should be taught to the system just once, by creating one template with sensible defaults that could then be applied to any make and model of switch (including future ones!) by just changing those default values when needed.

Choose solutions that adapt

Solutions should adapt to your existing network, budget, and capabilities and the experience of your staff instead of demanding that you adapt to them.

Make the best of your staff skills, without ever overloading them

Network automation must do more than minimize the mere number of total working hours required by the whole network support staff. It must make it easier to distribute both workloads and responsibilities among them, in the safest and most cost-effective way, while increasing their skills. At the same time, automation should give the peace of mind that comes from knowing that there are no critical dependencies on any single expert if some particular incident happens because the system can help whoever happens to be on call during that moment to do the right thing quickly. At the bare minimum, the automation system should support instant fallback to the previous working configuration of some device if some update did not leave it in a working state or generated a fault.

Choose solutions that are self-documenting

Self-documenting solutions should save and present all the data you need but not more. Diagrams or real-time animations are great for quickly understanding and documenting what happened in the network but cannot be the only resources of this kind. Audit trails and log entries automatically documenting what network changes are made, together with approval workflows with logged approval entries, are what enables an automation platform to be self-documenting and fulfill both industry best practices and some compliance requirements.

Finding Your Solution on the Open Source Versus Proprietary Spectrum

Automation does not necessarily mean giving up control or ending up locked into a monolithic platform that becomes more difficult or expensive to maintain each year! The contrary is true, actually. Automation means gaining and maintaining over time not just full control of your network but also the freedom to change your automation practices.

As true as it is, this definition needs careful consideration and further qualification, or its results might be a bit misleading. At first glance, it may even give the impression that the best, if not the only, “true way” to effective network automation goes through doing everything in-house.

Instead, what really matters is to find and adopt solutions so good that you do not want to abandon them but that still leave you free to do so without unnecessary complications if you choose to, no matter who provided the solutions.

At a lower, more pragmatic level, automation must also mask the differences between equipment providers. The natural answer to such a concern is to build a network based as much as possible on open standards for network configuration and automation. This guarantees that networking equipment from different vendors does not expect different configuration commands to perform the same function (such as opening a firewall port), as this would make things unnecessarily difficult while increasing the probability of misconfigurations and network outages. Although many network vendors strive to support open standards, not all do—so naturally, when selecting a solution stack for automating network functions, you need to ensure the solution is flexible enough to support proprietary standards in the future.

A very important quality of open standards is that, if chosen properly, they avoid reinventing the wheel. Open standards often have community support that drives development of functions relevant to your network as well, so you don’t have to write scripts and code from scratch in-house every time. From this perspective, as a reference for evaluating how open standards can and should help your adoption of network automation, the rest of this section briefly mentions some high-level general concepts that constitute foundations on which it is possible to build automation that is both easier and free of lock-in. We’ll briefly explore network functions virtualization (NFV), software-defined networks (SDNs), and the Open Network Automation Platform (ONAP).

NFV is the decoupling of network functions from proprietary hardware appliances and running them as software in virtual machines on whatever host platform may be most convenient. The specific functions provided by an NFV environment are called virtual network functions (VNFs) and include, but are not limited to, firewalls, traffic control, and virtual routing. Thanks to them, NFV brings benefits similar to those of server virtualization: increased hardware utilization and flexibility at lower costs.

SDNs can use NFVs, but they go a step further. They abstract the control and management planes from the underlying hardware with a software layer that can be managed through physical or virtual controllers. Rather than simply making automation simpler and cheaper, this separation enables things that would not be possible otherwise, by making the networks both hardware agnostic and programmable—that is, capable of being partitioned with great precision with a few simple commands from either a script or a graphical console.

These concepts are enshrined in open standards under ONAP. This platform, under the governance of the Linux Foundation, enables VNFs and other network functions and services to be interoperable in an automated, policy-driven, real-time environment. This provides everyone (as ONAP is fully open sourced and the code is free for everyone to see and consume) the ability to fully create, design, and deploy for automated network services.

Conclusion

Open standards can play a crucial role in your path toward network automation. When exploring the market for vendors to assist you, look for vendors that have embraced those standards, together with the other concepts and best practices described in this report, as opposed to reinventing the wheel in proprietary solutions. Network automation is still a relatively new and evolving field, so while there may not be an out-of-the-box solution that perfectly matches your network today, vendors that align with these concepts will converge on a solution that works for your business as the network automation market matures.

Align with network automation platforms and vendors that allow you to focus on your goals without wasting countless hours in low-value, low-level, and error-prone operations. Remember, network automation is an ongoing process. Therefore, whatever the structure of your network and your expectations about it are, it’s important to keep some key considerations in mind:

• Identify where you’re at in your automation journey, and partner with solution providers that will support you at every stage along your journey toward a fully automated network.

• Make sure that you can always really count on reliable, affordable support (either inside or outside your organization).

• Put together a realistic plan to get you to a more “automated” state, and stick to your plan.

• Execute the plan, setting concrete milestones and ensuring that you pause to measure progress against your success parameters.

• Continuously evaluate the network automation market, watching for changes and new developments in this evolving field that can help you on your journey.

At this level, perhaps the only guideline that is always valid is that incorporating open standards and automation will nearly always benefit your business.