Are you tired of spending hours configuring network services, only to spend even more time tearing it down a short time later? Does your situation make it extremely difficult to have all the necessary information to achieve an optimal design? Do you wish you could empower your stakeholders to self-serve, instead of having them wait on your change request cycle? This interview talks about how you can address these problems and more...
*Begin interview*
Alex: What do people mean by “intent-based” in the context of network automation?
Ben: Intent-based networking is simply a methodology of defining the network state in terms of what the result should be, rather than specifying all of the steps to get there. A capable automation system can figure out and apply the low-level configuration steps required to reach this state for you, which removes a lot of potential for mistakes, speeds up deployments, and saves time for engineering staff.
Alex: Can you give us an example?
Ben: Sure. Let's say you're wrapping up a project that requires some temporary resources in the data center. Now you want to reuse the hardware in situ for another project, but there's a big pile of leftover VLANs, routing, link aggregates, and so on. In the traditional network, an administrator would walk through all of the devices and carefully clean this up, then start working on the new topology, which can be a very time-consuming and error-prone endeavor.
An intent-based approach would let you specify the new state of the network as you'd like it to be for the new project and the automation can make it happen, cleaning up the remnants of the old deployment along the way.
Alex: Why do enterprise companies look into building intent-based systems?
Ben: Simply, to save time and reduce mistakes, both of which translate to cost savings. In a perfect world, all networks would be meticulously documented with changes tracked and reviewed, but reality often presents challenges with short timelines or staff availability.
Networks are fluid, organic things, and that Friday afternoon priority change to accommodate a new server may not find its way into a manually populated DCIM. Any business, but particularly those with compliance requirements, will appreciate that all changes are tracked and reflected in the intent-based network state. This translates easily into diagrams and other documentation that's guaranteed to be accurate.
Another reason is accessibility. Because intent-based network automation presents the network in a logical way, personnel such as developers can implement changes without needing to know the nitty-gritty details and limitations of various network hardware vendors. With a system supporting RBAC, you can empower project stakeholders to build in their own pod, liberated from the network change request cycle.
Alex: Does this apply to service providers as well? How about campus environments?
Ben: Yes, absolutely. Service providers and campus networks are some of the most complex, with a large number of direct consumers compared to a data center. The potential for impact in an access network is huge, and outages are highly visible. This makes an intent-based approach very attractive since it can eliminate a lot of sources of configuration problems and decrease time to resolution with capabilities like zero-touch provisioning of switches.
Security is also more important than ever, particularly on campus networks. Finding a port in a closet where access controls were misconfigured with an unauthorized device attached is a real scenario that I think every organization wants to avoid.
Alex: How does MetalSoft do intent-based networking?
Ben: MetalSoft is unique in that it brings a holistic approach to automation. Servers, switches, and storage blend seamlessly to become infrastructure, which is expressed in terms of intent and comes without the penalties and overhead usually associated with virtualization. Once your infrastructure is deployed, you get a bird's eye view.
Behind the scenes, the intent-based network engine in MetalSoft evaluates the state of the network, the capabilities of the devices involved and builds an optimal topology that reflects the requested state. It incorporates different NVO strategies that are chosen based on their benefits relative to the physical topology and goal state. The network fabric is monitored for potential problems. We're always evaluating the latest technologies, techniques, and best practices in networking to identify anything that can improve reliability, and performance or add useful functionality, guided by user feedback.
*End interview*
So we see how valuable this shift in approach is to network engineering teams, freeing them up to work on more strategic and systemic improvement tasks. Contact MetalSoft to discuss how we can help you make the most of these new capabilities. We’d be happy to show you a demo and set up a POC to do some hands-on testing.