Ten clicks to set up a network -- it sounds too good to be true. But powerful engines of automation, abstraction and policy-based management in Cisco's SDN controller, the Application Policy Infrastructure Controller Enterprise Module, aim to make that kind of ultra-easy and automated network deployment and management a reality.
That's why we're recognizing APIC-EM as the latest winner of our Network Innovation Award. TechTarget spoke with Ronnie Ray, a senior director of product management at Cisco, who shares more about what's happening under the hood.
Note: This interview has been edited for length and clarity.
How does APIC-EM work?
Ronnie Ray: It abstracts out very complex network deployments and configurations -- things that have been done manually or device by device for many decades -- so you can start to move to a new level of policy-based automation. You used to talk to a device individually, give it a configuration to do a specific thing, and repeat that over a thousand or 10,000 devices. You built a network from the bottom up. Now, you can deploy and manage your network from the top down, because you're describing policy in business-like language.
For example, instead of having to do quality-of-service (QoS) deployments for every box -- which might be different depending on what platform they are on, how big they are and how much bandwidth they support -- now you can say, 'These applications are really business-critical for me. Those applications are business-relevant, but not as critical. And these are not things I need on my network.' APIC-EM accepts that input and automatically translates it into a language that the devices in the network understand.
We took the time to make sure APIC-EM could abstract out the base-level configuration capabilities and features for both legacy devices and future architectures. APIC-EM talks multiple protocols southbound, so what that means is when it talks to a device, it uses CLI, SNMP or whatever the mode is that the device understands.
Where the innovation comes is in the northbound [interface] of the controller, where it exposes open APIs. You have the entire network exposed -- not at a device level, but at a complete network level -- so you're basically able to build applications on top to provide a fully domain-centric solution.
The beauty of building an open software system is those APIs are available to us. There are teams within Cisco building applications, and they are available to our partners and third-party developers that want to use those APIs to build applications and a new rendering of a network service.
Network automation isn't a new concept. How is APIC-EM different?
Ray: In the past, network automation has been led by framework tools. You have a framework to do the automation, but you bring in the intelligence from the outside. You push specific configurations, which are designed by expert network engineers, and those are then applied device by device to construct the network.
The ability to build that network-wide service is already built into APIC-EM. You're not trying to add intelligence based on the expertise of your people. The controller knows what is in the network, its current state and what things need to change. So, it is a much more dynamically controlled system than a static deployment of configurations.
Ronnie Raysenior director of product management, Cisco
What's required for the policy to get translated from business intent to an actual instruction the device understands is that middleware of intelligence, which is built into this controller. That is the heart of automation; it knows exactly what to do.
Cisco just announced the controller's v1.1 release. What's new in this version?
Ray: We have added new capability, Easy QoS; it's in beta right now. Let's say there was a call happening between two endpoints on the network, and the call quality was not going well. The call manager knows about this, but it couldn't do anything, because it couldn't change the network. The only thing that could be done was, ex post facto, somebody could look at the number of dropped calls or calls with low MOS scores and say, 'How do we change the network to save enough bandwidth and give voice the right priority?'
With this new capability, which we call dynamic QoS, not only can it [automate] QoS, but it also can deploy quality of service across the entire network. That's already a humungous amount of time and effort saved. But the really cool feature is that the call manager can say to the automation controller, 'I want this call to be given priority.' And for that session, the automation controller, because it knows the paths the call takes on the network, could give it the right priority for that call duration while the call is in process. There's no manual intervention here; it's completely automated.
What problem was Cisco trying to solve with APIC-EM?
Ray: Data center automation started many years back. You could bring up a VM in minutes, maybe even in seconds in some cases, and you could do this with the click of a button. That kind of automation has not come into the WAN, branch or campus network.
In the past, you had to send a device to a site for it to be staged and preconfigured, and then there would be a tech person who would go to a branch to set up the device by hand. APIC-EM takes all of that work away. You can ship something directly to a branch. It automatically connects to the Internet, and it can go to the cloud to get its initial config. It talks to APIC-EM, which knows what needs to be deployed. It can go through that entire management cycle hands-free -- even upgrading the image on the device as it goes along.
We're trying to bring down opex and shrink time to deployment. This can be done by a few clicks. Before, it took thousands of lines of programming to input the configuration. Today, it's reduced to maybe 10 clicks per branch or 10 clicks per groups of branches if you apply the same template to them.
That sounds a lot like what the Cisco Meraki products do.
Ray: What APIC-EM does with zero-touch deployment in Plug and Play is start to Meraki-fy the Cisco infrastructure. Cisco devices have a tremendous amount of feature depth and breadth, and they have a broader set of use cases they are able to address. The journey we are on is looking at a future where the network can be managed from the cloud through policy.
So, what's next for APIC-EM?
Ray: We are looking at network management reimagined. For example, instead of having to do segmentation through archaic ways -- a VLAN construct or a subnet -- we are looking at completely new ways of policy-based, automated segmentation. Today, all of that is done at in the data center. It's not at the point in the network where the user is connecting. With the new kinds of segmentation approaches we can bring up with APIC-EM, we can move that policy-based approach of what connects to whom, when and where, and make very powerful policies that can program the network ... at the click of a button, network-wide.
You'll also see us doing a lot with the cloud. There's lot of roadmap activity going on at our end, as we look at how this infrastructure can be automated from the cloud.
Five SDN controllers you should know about
Using OpenFlow for SDN controllers and apps
Do you need a specialized SDN controller?