- 3 lucrative side hustles you can start right now with OpenAI's Sora video generator
- How to use Microsoft's Copilot AI on Linux
- I tested Samsung's 98-inch 4K QLED TV, and watching Hollywood movies on it left me in awe
- Apple is working on a doorbell that unlocks your door Face ID-style
- 5 biggest Linux and open-source stories of 2024: From AI arguments to security close calls
DIY or commercial network automation? Most network teams choose ‘all of the above’
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.