Intent-Based Networking is a Logical Next Step for SDN
For years, many have been talking about the future of IT in terms of software, prefixing every resource with “software-defined” as a way to help end users understand that emerging products are different than their predecessors in some fundamental ways. A lot of jokes have been launched as this prefix expanded to more and more resources. For those that have legitimate software-defined offerings, though, the potential for excellent customer outcomes is very real. And, as the software-defined data center market has continued to mature, we’re seeing new discussions take place that, not all that long ago, would have been the stuff of dreams.
One of the things that software-defined networking has brought is a great deal of choice. We can far more build enterprise-class networking systems based on commodity or white box switching and routing hardware than we could in the past. If we want a more traditional solution, we can buy one, but the point is that we don’t have to. Further, traditional networking companies have jumped into SDN in a big way over the years, offering solutions that enable the kinds of flexibility that people are expecting more often from enterprise IT solutions. SDN enables streamlined management capabilities, easier deployment of new hardware, and, in some cases, more flexibility in hardware choice as compared to more traditional fixed-device configurations.
The real power of SDN comes into focus once all, or a critical mass, of the network is able to make use of a centralized SDN controller – the part of the control plane that is split from the data plane in a software defined world. It becomes possible to do some interesting things. For example, suppose you have a traditional network that has equipment from a variety of vendors and you’re supporting a video calling application. You may run into a situation in which there is too much other traffic on the network for that application to work properly, so you create QoS rules to address it. Often, though, this is a reactionary step – at least initially – and it’s not always dialed in just right.
In many ways, SDN can be equated to software defined servers, or what we typically call server virtualization. Close to two decades of substantial server virtualization deployment has provided something of a roadmap for other resource virtualization efforts. For example, prior to virtualization, it could take days to provision servers, a process that can how happen in seconds, or one that can be completely automated based on rules defined by administrators. Consider a traditional network infrastructure. New hardware deployment isn’t necessarily onerous, but mass changes can be, and can result in projects that take days, weeks, or months to complete. Moreover, as network conditions change or events occur, many network administrators are notified reactively by alerting and monitoring systems. At that point, administrators spring into action in an attempt to correct whatever underlying issue created the alert or out-of-whack monitoring condition.
We used to do that with servers, too. Today, if a server fails, we have rules in place in the hypervisor management tool that automatically restarts failed services or moves workloads to alternate hosts if the original host fails. We can even define rules that say things like “if the host begins to experience congestion, proactively move workloads to different hosts to clear things up.”
Similar benefits are being brought to the network via network virtualization and things like SDN. By decoupling the brains of the network from the plumbing and centralizing the brain, we gain far more visibility and capability than is often possible with traditional distributed architecture. In an ideal world, we should be able to provision new network services as quickly as we can provision virtual machines, as long as the underlying hardware can support those services. If you think about SDN in terms of your car’s GPS, the control plane is your navigation and the data plane is the system of roads.
What’s Your Intent?
As a driver, you don’t want to have to constantly reprogram that GPS as you see road blocks or experience traffic delays and you might want to avoid toll roads. Your intent is to get to your destination. To this end, you plug an address into your GPS, which then creates a route for you.
If you have a GPS device that just calculates a static route and doesn’t take in information from other sources along the way, you, as the driver, are left to work your way around obstacles as they appear. This is what life is like in a traditional network paradigm. Administrators are notified of obstacles and have to clear them. Now, SDN itself doesn’t necessarily fix this. At the most basic level, SDN just separates the brains from the brawn.
As we move forward, though, we want and need more. There is rich data out there to be exploited and as our SDN-based systems gain access to more information sources from other devices on the network, we can start to use that information to do more.
Let’s go back to the GPS analogy. Most modern GPS devices allow you to set rules. These rules might include “avoid toll roads” and “reroute around heavy traffic” and the like. Behind the scenes, your GPS builds you a route that takes you to your destination while respecting these rules. However, not all of these rules are created equal. Avoiding toll roads is pretty easy. Every road in the GPS map database is flagged with whether or not it’s a toll road. Roads don’t just randomly change back and forth between free and toll, at least under normal conditions. Traffic, though, is a different story. This requires real-time data from another source beyond the GPS. And then, the GPS has to make a decision about the impact of what it’s learning to make a decision about whether or not to suggest an alternate route that works around obstacles.
Your navigation experience is a dynamic one, with obstacles thrown in your path along the way. Your GPS, based on the overarching rules you dictate, makes recommendations about what you need to do.
Now, let’s take things one step further to autonomous vehicles. Here, intent is critical since a human may not be making operational decisions. Instead, based on all of the data that the vehicle is receiving from GPS and from other enabling sources, it needs to make decisions about how to handle obstacles, while also ensuring that your intent—getting to your destination—is satisfied in a way that respects the general rules you’ve put in place.
Intent-based networking is similar in practice. The network is designed to focus on what you want to get done rather than how. You tell it what you want and the controllers that manage the network make it happen. As networks continue to scale and become more cloud connected and intertwined than ever before, it’s important that organizations have ways to mitigate against the potential downsides of that increased complexity. In addition, as new security threats emerge—and they are happening more frequently—there needs to be a mechanism in place that can identify such threats and take action, all a part of an intent to maintain a secure posture.
One way that intent-based networking takes SDN to a new level is through machine learning. In a traditional SDN deployment, the controller is still acting on strict rules that administrators put into place to dictate how a network operates. By adding machine learning capabilities to this environment, intent-based networking can imbue that SDN controller with the intelligence that it needs to make proactive decisions as new conditions warrant. And this can happen in real-time. That’s the biggest benefit, frankly. Personally, while intent-based networking may be a relatively new term, I see it as an expression of the desire that most organizations have had for years as they’ve considered SDN.
It’s a logical progression from centralizing control (SDN) to allowing a pseudo-AI to handle some of ongoing maintenance of the network with a focus on meeting the business objectives that are assigned to it. Such objectives may include maintaining certain levels of performance for critical applications. If there’s an outage, it’s up to the controller to then reconfigure the underlying infrastructure to route around it while still attempting to meet the performance SLA. By operating like this, organizations are able to be far nimbler and able to work around issues as they arise. When it comes to security, there is great potential for machine-learning based systems coupled with SDN to be able to protect organizations more completely than with alert-based tools. We’re already seeing these machine-learning basis security tools on the market as well.
In short, intent-based networking is the next logical progression of SDN and it enhances the network with automation capabilities that go beyond simple rules. By providing overarching parameters and goals to the controllers, companies can more easily scale their networks and, even as they add complexity, keep the manageable and working to meet the needs of the organization.