Security and compliance requirements drive IT pros to commercial automation tools, while the prospect of more customizable functionality lures teams to DIY automation.
The first question most IT organizations ask when they kick off network automation projects is: Do we build or buy? In reality, most network teams end up doing both.
“We have a hybrid strategy,” an IT tools architect at a Fortune 500 media company recently told Enterprise Management Associates (EMA). “We can buy some commercial tools where it makes sense. But we are also developing tools internally where we can’t get the capabilities we need from vendors. Commercial tools can meet about 80% of our needs.”
Network teams often perceive a binary choice with network automation. Some lean toward a vendor-centric approach, purchasing proprietary software or adopting an open-source solution supported by a vendor or managed service provider. Others will take a do-it-yourself approach, installing unsupported open-source software or developing internal software with a team of network automation engineers who have a mix of networking and coding expertise.
EMA recently surveyed 354 IT professionals about their network automation strategies and interviewed another 10 one-on-one for our recently published research report, “Enterprise Network Automation: Emerging from the Dark Ages and Reaching Toward NetDevOps.”
Our survey found that 100% of IT organizations use commercial network automation tools, and 94% use DIY tools. In other words, they don’t make a binary choice. They’re using a mix of commercial and DIY tools.
This all-of-the above approach makes sense when one realizes that network automation strategies are rarely about implementing a single tool. Network automation strategies are often composable, with networking teams pulling together multiple solutions to address key use cases and different types of requirements. In fact, only 9% of IT professionals told EMA that their network automation is covered by a single tool. Instead, 42% claimed to have three tools. Another 23% claimed to have four or more.
Drivers of DIY network automation
Survey respondents identified three top drivers of DIY automation. First, they need functionality that is aligned to their specific networks. For example, they may have specific business requirements that make their networks idiosyncratic.
“You can’t get all the features you want [from a commercial vendor], said a network automation engineer at a Fortune 500 manufacturer. “Usually, they do some subset of things. It’s about a level of customization. [With DIY], can get what we want when we need it.”
The second leading driver is security and compliance requirements. For example, an organization might evaluate a commercial tool that is available only as a SaaS offering, but the cybersecurity group objects, saying that the company can’t store network data in the vendor’s SaaS cloud.
The last major DIY driver is cost. “Some of the [commercial] tools we looked at buying are too damned expensive,” said a network engineer at a private gaming company. “The price is way more than the value when we compare it to writing the code ourselves.”
Drivers of commercial network automation
The top driver of commercial tools is security and compliance requirements, which may surprise readers given that it was cited as a driver of DIY tool development, too. There is a nuance to consider here. In the case of DIY tools, many cybersecurity organizations ban the use of open source. This may also be a question of use case. A tool that serves a source of truth may have different set of security requirements than a second tool used for automated change management.
The second driver is general platform requirements such as resiliency and scalability. An internal development team might build a tool that can easily make dozens of changes on a network, but it may struggle to scale to thousands of changes. One network automation engineer told EMA that his homegrown tool would take hours to push a change across all the routers on his network. He described a situation where he noticed an error in the change that he pushed, but he had to wait hours for the tool to finish the change before he could tell the tool to revoke it.
Finally, many respondents told EMA that they chose commercial tools for their breadth and depth of functionality. In EMA’s experience, DIY network automation teams usually tackle one or two important use cases with their initial work. Once they demonstrate success, upper management grants them the resources to expand into other use cases. A commercial tool offers the opposite, with a suite of features that can address multiple use cases out of the box. If implemented in a timely manner, a commercial tool can deliver more value more quickly.
Flexibility over rigidity
Adopting a build and buy approach to network automation is really about being flexible and making things work with the resources one has. For instance, a switching vendor typically bundles a network automation tool with its hardware. This tool might come cheap, but with only a subset of the functionality a network team needs. To fill the gaps, the network team might adopt an open-source tool or write some internal software to address specific needs. Multiple IT managers have told EMA over the years that they developed homegrown software specifically to automate certain workflows in a switching vendor’s automation tool.
In other cases, network teams might have a multi-vendor network and only a subset of those vendors are covered by their commercial automation tools. They may adopt an open-source tool to address those gaps.
None of these scenarios may sound perfect to the average reader, but network teams make it work. And they’re always looking to do better. The key consideration is to maintain flexibility and to know when you need to make a change in strategy. Taking an all-of-the-above approach can grant one that flexibility.
