Network & Security Automation: When the Lego blocks don’t fit
Notice: This blog post was originally published on Indeni before its acquisition by BlueCat.
The content reflects the expertise and perspectives of the Indeni team at the time of writing. While some references may be outdated, the insights remain valuable. For the latest updates and solutions, explore the rest of our blog
The article discusses the fragmentation of vendor-specific automation in network and security infrastructure—vendors provide disparate APIs, SDKs and protocols that don’t interoperate—creating operational friction for enterprise engineers who must learn scripting to glue systems together. It introduces Indeni as a single platform that presents a consistent UI, API and integrations while handling vendor-specific APIs and device nuances beneath the surface, using a global community of experts to manage changes and non-API interactions (e.g., SSH). The key outcome is that Indeni makes automation more accessible, reduces time spent on tool integration, and lets engineers focus on policy, architecture and process improvements to support business priorities.
What operational problem does the article say enterprises face with vendor-provided automation tools and APIs?
The article explains that each vendor supplies its own automation building blocks—different API styles (REST, SOAP), proprietary protocols and varying feature sets—so these tools don’t interoperate. This fragmentation forces engineers to learn scripting or programming to glue disparate systems together, increasing complexity and consuming time that should be spent on core projects. The inconsistency also complicates implementing a single use case across different vendors because APIs often expose different capabilities or require device-specific commands via SSH rather than unified interfaces.
How does Indeni address the challenge of incompatible vendor APIs and device-specific nuances according to the article?
Indeni provides a unified platform with a consistent user interface, a single API, and prebuilt integrations (for example, ServiceNow) that face the user, while the platform itself interacts with each vendor’s exposed APIs beneath the surface. Indeni handles differences in protocols and feature exposure, and compensates for functions not available via APIs by using approaches like SSH. To identify and manage device-specific behaviors and API changes, Indeni leverages a global community of experts who collaborate to keep the platform current and ensure supported devices appear uniform in the Indeni UI.
What practical outcomes for network and security engineers does the article attribute to using Indeni?
The article states that by abstracting vendor-specific APIs and presenting a consistent management layer, Indeni makes automation more accessible to enterprise network and security engineers. This reduces the time engineers spend on integrating disparate vendor tools and writing glue code, freeing them to concentrate on policy, architecture and process improvements that advance business goals. In short, Indeni simplifies device management across firewalls, load balancers and other security devices so teams can be more productive and focus on higher-value work.
Who doesn’t love playing with Lego blocks? Colorful blocks of different shapes and sizes, all fitting so nicely together thanks to “the system”.
In the network and security world, vendors are now touting new automation capabilities. APIs of various kinds, SDKs and tools. Each of them, built by the vendor, for the vendor’s products. Cisco, Juniper, Check Point, Palo Alto Networks, F5 and many others are doing this. This is a fantastic advancement that will greatly help run infrastructure in large enterprises.
The catch? Each vendor is providing their own Lego blocks and they don’t fit with one another:
- Some vendors choose to use REST APIs, some use SOAP, and some invent their own protocols.
- The APIs don’t support the same features across the products, so it’s impossible to have one use case implemented in APIs across all of them.
- Users are expected to learn Python, or some other scripting language, to be able to glue it all together.
On top of all of this, users don’t have time to play with Lego at work. They need to get projects off the ground, support the business and focus on their top priorities.
That’s where Indeni comes into the picture. We’ve built a single platform that has one, consistent, interface facing the user – our UI, our API and our integrations (like the one we have with ServiceNow). Below this platform, we interact with the APIs that each of the vendors expose. We deal with these blocks that don’t fit well together, so you don’t have to. It can be hard work at times, as APIs change, and many functions are not even exposed through an API (but rather SSH commands). For identifying and understanding these device-specific nuances we rely on our global community of experts, working together to make the vision of a smooth and agile network and security infrastructure a reality.
Every firewall, load balancer and other supported security device looks the same through the Indeni UI – making your life of managing these devices whole lot easier.
The result? Automation is more accessible for enterprise network and security engineers, giving you more time to focus on policy or other architecture or process improvements to propel your business forward. I can’t wait to see what you build.