But what to look for when you are selecting a network automation solution? When you see all the options in the market today, it can be overwhelming. The best approach, in my opinion, is to take a step back and first take a look in the mirror before considering any solutions out there.
What kind of organization are you and what kind of solution fits best? Do you have the people and skills in house to build solutions yourself? Are you allowed to deploy open source software in your company’s network? Do you prefer an off the shelf application? What way of working aligns best with your culture? Or are you ready for a platform approach with more flexibility and freedom to grow?
In this blog I will zoom in on what options to consider when selecting a new network automation solution. Or when considering to replace your existing one like for HPNA users as I described in my recent blog: 10 things you need that HP NA cannot offer.
The build or buy decision
Every organisation, in due time, asks the question “would we be better off building our own solution, rather than trying what’s commercially available?” However, do you have the right people and skills in house to pull this off and also maintain it? Building software is generally a lot more involved and complex than companies believe, and the hidden costs, risks and complexities often emerge when you’ve already chosen a direction, and it’s too late for change. Even a simple solution, which may start off as an in-house script can lead to unforeseen consequences in the areas of risk, compliance, security and support.
When you’re building an in-house solution beyond individual scripts, you need three different disciplines:
- network engineers who define what should be developed,
- software developers to build and maintain the solution, and
- users who work with the solution (and may or may not need automation knowledge depending on the solution)
When going for a commercial solution, you don’t have to develop yourself, however you need knowledgeable network engineers who can decide what’s needed for their network and what has to be automated. With these things in mind, I have listed the pros and cons of the main categories you can choose from to determine what suits you best.
1. Open source
“How about open source software?”, people ask me. I agree, with tools like Python and Ansible you can implement some things really fast. The main challenge however is that, as Ansible's key focus historically was on server automation, you need serious programming skills to make it work for network automation.
Of course, there is now support for network devices that allow you to easily automate simple device changes. But this is very much limited, as these solutions didn’t originate from the network domain; all network specific things are not available out of the box. I am talking about IP management, port information, topology, relationships, etc. But also your companies’ design specifics need to be incorporated somehow. This is needed if you want to move from ‘device’ automation to ‘network’ and ‘service’ automation. All this is typically stored in a ‘source-of-truth’ database that should work seamlessly together with all the other tools that deal with config generation, network jobs, automated workflows, validation and many more.
With open source, you need to stitch all this together yourself. I am not saying it can’t be done, but you need serious programming skills and time to build what you want. Even if you end up buying a commercial version like Ansible Tower, you still need 3rd party solutions like Netbox, Infoblox, or additional functions like templating engines (e.g. Jinja) and many others. This means you have to think about integration and how it can work for your organization. You can read more about this subject in the blog that my colleague Pieter wrote: Why Ansible and Python are not enough to automate your network.
Still, there’s so much good out there and you should be able to use it in one way or another if you have the people in your organization to make it all work. Let’s look at the pro’s and con’s:
Pro:
- No vendor lock in
- Lower initial software costs
- Agility, flexibility
- Open source community
Con:
- Security restrictions to deploy open source in your organization
- Lack of overall solution support from 3rd parties
- Need to integrate with multiple other solutions
2. Network vendors
The second obvious thing is to look for what your network vendors have to offer. This might seem like a good idea but a closer look reveals that you will likely end up with (multiple) element management applications with limited network automation capabilities as their main focus is on monitoring and configuring vendor specific hardware/software.
This can work if you have a single vendor- or single domain network, but once you get into multi vendor and hybrid networks, you have a problem: You first want to unify and centralize your configuration changes. Second, you need something to automate jobs across your vendors and thirdly, at some point you may need a ‘source-of-truth’ as I mentioned above.
Pro:
- Lots of functionality for monitoring and configuring vendor specific devices
- Optimized for vendor’s own hardware devices
- Network engineers might already know these tools
Con:
- Network automation capabilities
- Multi vendor support
- Flexibility
- Integrations and open API’s
- Need for multiple tools
4. Application vendors
A third category are vendors whose core focus is to offer network automation applications. Typically, these vendors have a special focus; either on certain markets like DataCenter networks, (Managed) Service Providers or Enterprise networks, or on specific solutions like Service Provisioning, Lifecycle management, Security or Compliance. Examples are e.g. Anuta, Apstra, Gluware, Packetfront and several others.
The good thing is that this may work really well for specific customers and situations. However, when you choose an application like this, you also choose for the vendor’s way of thinking and logic, limiting your flexibility and room for growth. The vendor made certain choices when developing the application, and you have to live with those. When evaluating this option you should ask yourself: “If we want to change our network design or add more functionality in a year, could we?” And: “If we want to integrate with other applications and processes, how easily could we do this?”
Pro:
- Specialized solutions for specific domains
- Out-of-the-box functionality
- Less configuration needed to get started quickly
Con:
- Flexibility. You need to accept the vendor’s way of working.
- Transparency. The logic used by the vendor is coded somewhere under the hoot
- Vendor lock in. If you want changes, you are dependent on the vendor, adding extra cost.
- Multiple tools in case the vendor does not offer all the functionality you need.
5. Platform vendors
The last category are vendors that offer a network automation platform. The difference with application vendors is that platforms allow much more room and flexibility to build use cases that reflect your own design choices, add your own scripting logic and define your own way of working.
As every network is unique, two organizations looking to solve the same challenge may have very different requirements and preferences, even if they have the same hardware and network designs (which is very unlikely). There are simply too much variations, integrations and technologies to consider. That’s why platforms can be a good choice for you if you want the flexibility and agility with lots of room to grow.
Most platforms come out of the box with lots of built-in functionality for configuration management, compliance and standard automation use cases. But they also offer the flexibility to implement your own logics, design rules, scripts, templates, processes etc.
Basically it combines the best of both worlds as all come with enterprise features like role based access, redundancy, scalability, security, systems management and many more. Vendors that fall in this category are e.g. Cisco NSO, Ansible Tower, Ciena Blueplanet and NetYCE. The main differentiator between each has to do with the level of programming skills that is required to get what you want. Some need advanced programming skills, while others have added a far less complex scripting language to make it easier for network engineers to use.
Pro:
- Flexibility
- Room to grow
- Ease of integration
- Application support from the vendor
- One platform for all your automation needs
Con:
- Some vendor dependency, although not a full lock-in as platforms allow room to do many things yourself.
- DevOps skills needed (vs application vendors)
Concluding thoughts
Look in the mirror first and determine what best fits your network and organisation. Do you want the flexibility and room for growth? Or would a more out-of-the-box solution work better for you? And of course, where are you on the skills scale? Do you mainly have network engineering skills? Did you already train your network engineers to be NetDevOps guys? Or do you have dedicated software developers with at least basic networking skills? Hopefully these things will guide you in making the right decisions with the highest rate of success.
In the next blog we will discuss a customer that migrated from HP NA to NetYCE. We will show you the steps they took. In the meantime, I am curious what your experience is. Let me know via wim.gerrits@netyce.com
Can't wait?
Just schedule a meeting with me! I love to hear about your specific questions.
