Benefits of controller-level automation vs. device-level automation

- [Instructor] As we have seen from previous sections, in infrastructure automation, we could have either a controller-level or device-level automation in management environment. Let's compare and contrast the two. Let's review what is a controller-base management automation environment. In this settings, we typically have a layer of device or devices called controllers that handles the operation on behalf of other devices. Therefore, when we need to instruct a lower level devices to do something, we could just communicate to the controller and the controller will handle the operation for us. Examples of controller based management includes the Meraki Dashboard API, Cisco DNA Center, Cisco Network service Orchestrator, short for NSO and many others. In the example of Cisco NSO that we could see on the screen, it handles the operations for many physical and virtual devices. So that our script or other DevOps tools could just communicate with the NSO controller when we need to make infrastructure changes. They term it NSO as a bridge, appropriately. So what are some the advantages of controller-based management network? The first advantage is that it gives us a more comprehensive holistic view of the network. Because the controller has information about many different devices at once, you can aggregate the information and present a more complete view of the network. The second advantage would be the abstraction of the controller provides. For example, when we only need to communicate to the NSO controller via API, we no longer need to worry about the low level commands of each of the devices. We just need to be familiar with the API for the NSO controllers. This is probably more advantageous in a heterogeneous environment for networks. For example, if we have multi-vendor networks underneath and we need to just have one set of API to communicate to, then providing obstruction will be very beneficial. The holistic view also means we have a centralized location for all of our management. For example, if we need to automate a device, traditionally we had to configure multiple devices on the device itself as well its neighboring devices to take it out of service. And that requires multiple device touches as well as multiple commands on each of the device. Now with the controller, we just needs to go to a controller and perhaps perform all these steps at once. In case we have less operation overhead, we might benefit from some operational savings as well. And we might also have potentially a more granular security control because there's a centralized policy that the controller could distribute to each of the device for us. What about device-level management? What are they? Essentially, device-level management is performing what we have done previously by using automation tool to do so. Example of it includes, instead of using CLI to control the devices, we can now use NX-API for Annex iOS devices and NETCONF or RESTCONF for iOS XE devices. On the screen, we have an example of the NX-API sandbox. In this case, we show that we could use the Jason RPC endpoint, to retrieve the output of the show version command of the device. There are also advantages of having device-level management. The first advantage is that it will give us total control over our operations. There's no obstruction layer that stands in the way between our management station and the device. So we have total control of the operation. The second advantage is a chance to optimize the device operations. If we were to have a controller perform our policy change, for example, it might have some predefined steps for the change. However, these steps might not be the most optimal step in our individual environment so we could choose to optimize it if we have device-level management control. Also customization, the ability to customize goes hand-in-hand with optimization as well as total control, because now we have some devices that we might want to optimize. We need that control in order to customize those steps in order to fit our individual environment the best. There might also be advantages of familiarity in device-level management. I mean, if we have to be managing that device individually, having device-level management, using automation tools, might give a more familiar ground to stand on. So which one is better? Should we have controller or device-level management? The answer is oftentimes it depends. It depends on how much operation controls we need. If we need precise control, we might want to choose device-level instead of a controller for management purposes. We should also ask if the controller has all the features that we need and if it does not how easy it is for us to expand the features of the controller. Essentially the choice often comes down to one consideration, which is if we want a more centralized, or if we're more comfortable in a distributed management of our network.