Yesterday was an interesting day in that I attended a full day ONUG academy session that was all about writing SDN applications. Big thanks to Matt Davy and Chuck Black for leading the session. While we weren’t hacking on code, there was a lot of discussion around APIs, network programmability, and the approach to take when building SDN applications [that leverage northbound APIs of a controller]. I’ve made it pretty public that I’ve been working with onePK building my own controller (using the term controller very loosely here) communicating directly with network devices as opposed to natively integrating with an existing controller like OpenDaylight, Floodlight, etc. and leveraging their northbound APIs.
There are definitely different schools of thought on programming to a device directly (ala onePK) vs. solely programming to northbound interfaces on a controller --- that is a conversation for a different day, but please remember they are two different models. I’m using onePK development as a foundation and an example to articulate northbound API requirements for controllers. Combining the material from yesterday with what I’ve been doing with onePK has made me think on how to marry the two together in what I’d call an ideal platform to develop on in controller networks.
onePK High Level
With onePK, you are able to build an application and leverage native C or Java libraries. These libraries, call them APIs if you wish, allow you to extract data from a device. You can extract what you want when you want. For example, you can extract things like interfaces on the devices, interface status, serial numbers, CPU utilization, routing tables, and literally a plethora of other things. This may seem trivial and some may say, how is that different than SNMP or screen scraping? Well, the result is the same of course, but it is a programmatic interface working over a persistent TCP connection between the onePK application and the onePK agent loaded on Cisco network devices. Does it matter it’s a persistent connection? Maybe, maybe not, and it depends on the application consuming the data. But remember APIs and programming are great for machine to machine interaction and CLI was meant for user interaction, so screen scraping will not scale, but for basic polling --- SNMP could work just fine. Of course, onePK also allows you to make changes to the network device (not just extract/get data) although I’m not going to focus on that any more in this post.
We now know onePK offers the ability to extract data, make changes to the network, but what about real time events that are needed to create this feedback loop everyone talks about?
Real Time Events
In the example I gave, the application is pulling or extracting data as needed. It is pulling real time state information when the application needs it, but it’s still a pull model and a pull model is not event driven. Ideally, the network device is also able to communicate real time state based on events back to the application. Just so happens onePK is able to do this as well. I was able to test this leveraging the Java libraries by configuring “listeners” on the network devices. Example I tested included CLI, CDP, and Interface listeners. If a “CLI listener” is deployed and a command is entered on the device, a CLI event is generated and the event is sent in real-time back to the application. The event message sent to the application also carries the command that was executed so the application knows a command was executed, but also knows the command itself the user entered. This data can be used for further processing throughout the application. Same holds true for the other types of listeners – I only listed three, but onePK supports many more than three listeners. In general, there will be events that are generated with listeners and associated metadata sent back to the application about that event. The bottom line is that listeners, or an equivalent, will be very important going forward (in my opinion) for looking at and building applications that require real time state of the network.
Proactive vs. Reactive Applications
Up until now, there has been a lot of discussion around proactive vs. reactive flows, i.e. punting packets to the controller and all of that fun stuff, but what about proactive vs. reactive applications that leverage the network? Have you ever thought about what type of API is needed to build a particular type of application? Maybe you aren’t thinking about writing an application just yet, but if the foundation of your network is a particular device or SDN controller, starting to think about what is possible couldn’t be more important.
RESTful APIs vs. Listener APIs
As an aside, if you are reading this and you’re a hard core developer, I may not be using the correct software development vocabulary, but hope my points get across. Feel free to write in and correct me. Anyway, these listener APIs would be leveraged through a platform like onePK, but more abstract, it would insinuate that a native programming language was being used to communicate to the network controller. The dilemma that I see is having a RESTful APIs seems like, or is being touted as gold when controllers are talked about these days, and right now, I would say “so what?” to that.
RESTful APIs are making web calls into a controller and seem to be great for two things --- pulling the data or extracting the data when you want from the network AND making a configuration change to the network. Both of these would be categorized under the umbrella of a Proactive application. These are proactive in the sense you know what you want to get or configure in the network.
On the other hand, Listener APIs by means of a native programming language allow you to gain the advantage of leveraging real time events like I’ve described. These events can be processed and then you can have an action be taken on the network creating the holy grail of a feedback loop. The action, or change to the network, can actually be sent back to the controller via native language API or REST. These types of APIs allow for reactive SDN applications.
Don’t controllers offer native language APIs?
Yes and No. I would argue no right now, but I haven’t looked at every controller. Don’t forget I could also be totally off base and wrong :). So, does your controller of choice simply allow you to add your own classes and methods or is it really a de-coupled SDK or development environment in that you don’t have to be hacking on controller code ON the controller? It’s my understanding at this point you would be hacking on controller code.
While my example with onePK is being used as reference, I am advocating for that model to be integrated northbound of the controller, not just southbound or as a standalone application. This means we should be able to write an application in Java (as an example) de-coupled from the controller where the application would reside on a separate server. Said a different way…there would be an “agent” on the controller and the SDN application would create a persistent connection to that agent to get the benefits gained from real time event driven notifications through the use of listeners, and also have the application be de-coupled from the controller to allow for a more modular and scalable application/controller design.
I do acknowledge there are other ways for applications to receive real time events, i.e. from data sources “other” than the controller. In that design, a REST only API would work just fine --- the application would receive events from the “other” application and then program/make changes to the controller via REST. I am not advocating against this because that may be required to leverage alerts and to integrate into 3rd party systems, but I do not think that’s the way it should have to be to get real time events from the network that the controller natively manages.
To sum it all up, there is more to APIs than just REST, and if I were ranking controllers, those that offered RESTful APIs, but ALSO a solid framework and SDK to build applications, that can be de-coupled from the actual controller code base would score higher than those who could not. Going a step further, imagine these kits or libraries working cross-controller as well --- this could be another layer of abstraction to make it easier to interact in real time across different controllers (and port between them).
Thanks,
Jason
Twitter: @jedelman8
onePK High Level
With onePK, you are able to build an application and leverage native C or Java libraries. These libraries, call them APIs if you wish, allow you to extract data from a device. You can extract what you want when you want. For example, you can extract things like interfaces on the devices, interface status, serial numbers, CPU utilization, routing tables, and literally a plethora of other things. This may seem trivial and some may say, how is that different than SNMP or screen scraping? Well, the result is the same of course, but it is a programmatic interface working over a persistent TCP connection between the onePK application and the onePK agent loaded on Cisco network devices. Does it matter it’s a persistent connection? Maybe, maybe not, and it depends on the application consuming the data. But remember APIs and programming are great for machine to machine interaction and CLI was meant for user interaction, so screen scraping will not scale, but for basic polling --- SNMP could work just fine. Of course, onePK also allows you to make changes to the network device (not just extract/get data) although I’m not going to focus on that any more in this post.
We now know onePK offers the ability to extract data, make changes to the network, but what about real time events that are needed to create this feedback loop everyone talks about?
Real Time Events
In the example I gave, the application is pulling or extracting data as needed. It is pulling real time state information when the application needs it, but it’s still a pull model and a pull model is not event driven. Ideally, the network device is also able to communicate real time state based on events back to the application. Just so happens onePK is able to do this as well. I was able to test this leveraging the Java libraries by configuring “listeners” on the network devices. Example I tested included CLI, CDP, and Interface listeners. If a “CLI listener” is deployed and a command is entered on the device, a CLI event is generated and the event is sent in real-time back to the application. The event message sent to the application also carries the command that was executed so the application knows a command was executed, but also knows the command itself the user entered. This data can be used for further processing throughout the application. Same holds true for the other types of listeners – I only listed three, but onePK supports many more than three listeners. In general, there will be events that are generated with listeners and associated metadata sent back to the application about that event. The bottom line is that listeners, or an equivalent, will be very important going forward (in my opinion) for looking at and building applications that require real time state of the network.
Proactive vs. Reactive Applications
Up until now, there has been a lot of discussion around proactive vs. reactive flows, i.e. punting packets to the controller and all of that fun stuff, but what about proactive vs. reactive applications that leverage the network? Have you ever thought about what type of API is needed to build a particular type of application? Maybe you aren’t thinking about writing an application just yet, but if the foundation of your network is a particular device or SDN controller, starting to think about what is possible couldn’t be more important.
RESTful APIs vs. Listener APIs
As an aside, if you are reading this and you’re a hard core developer, I may not be using the correct software development vocabulary, but hope my points get across. Feel free to write in and correct me. Anyway, these listener APIs would be leveraged through a platform like onePK, but more abstract, it would insinuate that a native programming language was being used to communicate to the network controller. The dilemma that I see is having a RESTful APIs seems like, or is being touted as gold when controllers are talked about these days, and right now, I would say “so what?” to that.
RESTful APIs are making web calls into a controller and seem to be great for two things --- pulling the data or extracting the data when you want from the network AND making a configuration change to the network. Both of these would be categorized under the umbrella of a Proactive application. These are proactive in the sense you know what you want to get or configure in the network.
On the other hand, Listener APIs by means of a native programming language allow you to gain the advantage of leveraging real time events like I’ve described. These events can be processed and then you can have an action be taken on the network creating the holy grail of a feedback loop. The action, or change to the network, can actually be sent back to the controller via native language API or REST. These types of APIs allow for reactive SDN applications.
Don’t controllers offer native language APIs?
Yes and No. I would argue no right now, but I haven’t looked at every controller. Don’t forget I could also be totally off base and wrong :). So, does your controller of choice simply allow you to add your own classes and methods or is it really a de-coupled SDK or development environment in that you don’t have to be hacking on controller code ON the controller? It’s my understanding at this point you would be hacking on controller code.
While my example with onePK is being used as reference, I am advocating for that model to be integrated northbound of the controller, not just southbound or as a standalone application. This means we should be able to write an application in Java (as an example) de-coupled from the controller where the application would reside on a separate server. Said a different way…there would be an “agent” on the controller and the SDN application would create a persistent connection to that agent to get the benefits gained from real time event driven notifications through the use of listeners, and also have the application be de-coupled from the controller to allow for a more modular and scalable application/controller design.
I do acknowledge there are other ways for applications to receive real time events, i.e. from data sources “other” than the controller. In that design, a REST only API would work just fine --- the application would receive events from the “other” application and then program/make changes to the controller via REST. I am not advocating against this because that may be required to leverage alerts and to integrate into 3rd party systems, but I do not think that’s the way it should have to be to get real time events from the network that the controller natively manages.
To sum it all up, there is more to APIs than just REST, and if I were ranking controllers, those that offered RESTful APIs, but ALSO a solid framework and SDK to build applications, that can be de-coupled from the actual controller code base would score higher than those who could not. Going a step further, imagine these kits or libraries working cross-controller as well --- this could be another layer of abstraction to make it easier to interact in real time across different controllers (and port between them).
Thanks,
Jason
Twitter: @jedelman8
RSS Feed
