Blogs

Should you build or buy a network automation solution

Should you build or buy a network automation solution?

As networks grow in complexity, the demand for automation is ever increasing. Every network architect is looking for ways to eliminate tedious, error-prone manual operations and embrace automation to free time for more value-added activity. From onboarding multi-vendor, multi-domain devices to monitoring, troubleshooting, and remediating network issues – automation has the capability to revolutionize networking.

When do you require network automation?

Are you excited about an entirely self-driven autonomous smart car? Probably not. However, you probably appreciate automatic transmission as well as cruise control and other features that facilitate easy driving. Much like smart cars, the journey towards network automation will be gradual. Are network architects and network administrators ready for a self-driving network? Possibly, but most architects want some level of control in steering network operations and are unwilling to take the back seat. However, solutions that can automate mundane tasks are overwhelmingly welcomed.

In a network world of multi-vendor infrastructure and devices, on-boarding, maintaining configuration, and detecting and remediating compliance violations becomes a daunting task .  It is nearly impossible to monitor and troubleshoot a vast network manually or draw any insights given the lack of scalability.

Automation tools have been trying to solve this challenge and have been successful in providing some value to the administrators. Tools such as Ansible help you push configuration changes to devices automatically. Netbox, Github, and others help track configuration drifts, and Python is used to add intelligence into the automation framework. Collected network data can also be stored in open source time-series databases like Prometheus and Influx, which when integrated with Grafana help provide visibility and insights into the network. While you can get started quickly with these tools and achieve some level of automation, what is  required in the long run is a more robust and comprehensive automation solution.

What constitutes a comprehensive network automation solution?

Network administrators and architects have been test-driving various in-house, open-sourced and commercial automation solutions for quite some time. While some solutions are low code and easy to deploy, many lack the capacity and scalability for long term needs. On the other end of the spectrum, there are robust offerings equipped with shock absorbing and disaster recovery features, but they require a large footprint and have limited compatibility with only a small subset of vendors.

A comprehensive network automation solution automates the complete end-to-end device and service lifecycle. Moreover, it can scale to support a large number of vendors as well as provision devices, collect specific network information, and provide analytics distinct to particular use cases. An easily scalable solution with a small footprint, allows network operators to start small and grow with automation confidence. Constant monitoring of all devices anticipates possible configuration, compliance or other network issues and automatically remediates issues with known solutions. The solution also integrates with ServiceNow, Jira, and other ticketing and billing systems to provide you a complete end to end closed-loop automation platform.

Look before you leap

The first instinct towards automating your network is the confidence that it can be done in-house with standard tools or custom scripting. Some common pitfalls include:

Let’s try it ourselves. There is a ton of free automation tools. Many companies have done it internally. We have already automated a part of our network so why should we waste money by buying a packaged solution?

 While a homegrown automation solution might appear plausible initially, it may be wiser to ask the following questions:

  1. How many automation tools can we learn and handle? Each tool is specialized in its area – such as Ansible for configuration, Netbox for IPAM, Prometheus for database, and Python for intelligence. Comprehending and maintaining every tool can become cumbersome.
  2. How much integration support do we get? For a complete closed loop automation integration with ticketing/billing/OSS/BSS are the fundamental underlying requirements. If the tools do not comprehend these capabilities, is the support readily available or will it have to be built?
  3. How do I develop automation scripts? Developing an automation framework itself becomes a project on its own.  Significant resources will have to be allocated in order to plan for software versioning, maintenance, and upgrades of automation scripts.
  4. How do we handle scripting issues? You have to worry not only about your network but also your script bugs that can adversely impact your automation system. You will have to learn low-level OS integrations to optimally scale scripts.
  5. How many resources can I dedicate towards automation? A project of significant size and scope requires dedicated resources to create and maintain various automation scripts.
  6. How much risk am I willing to take? A project of this scale may take years to complete. Even then, it may not meet intent or expectations of the lines of businesses that are supported. Are you willing to risk failure?
  7. Will my network get locked to a single vendor? It’s easy to automate when there is uniformity. If all scripts are tailored towards a particular single vendor, it could become exceedingly difficult to move to other vendors that might bring a best of breed approach for a particular workflow or set of applications.
  8. What happens if key team members leave? This is perhaps one of the most challenging questions to answer. If your key team members that designed and developed the automation system leave the organization, how could it impact ongoing network operations?

When should you consider deploying a packaged automation solution?

Smaller networks might lend themselves to an internally developed automation solution, but maintenance and future scalability are still risk points. On the other hand, larger, more extensive multi-vendor and multi-domain networks will benefit greatly from a packaged, microservices based automation solution. 

The following checklist might provide insight into determining the fit of a packaged solution:

  1. Is there a need to automate more than 500 devices on a given network?
  2. Are there more than 2 vendors in a given network?
  3. Do network operations need to be tied to business operations? I.e. integration of network workflows with ServiceNow/Jira, etc.
  4. Is a single pane of glass desired to manage a given network, or can it be managed with multiple, distributed interfaces?
  5. Is efficient provisioning required to effectively scale an  automation framework as a network grows?
  6. Is network enhancement and future proofing a long term objective?

If the answer is yes to any of these
questions, consider Anuta Networks ATOM for your network automation needs. Want
to learn more?  Visit www.anutanetworks.com.

About Author

You will also like...