At the Developer Days conference we saw some excellent examples of NSO use cases including device onboarding, configuration compliance, and device software upgrade. If you were not there, I recommend that you check out the slides and watch the videos. In addition to being called 'NSO use cases’, in the introductions we also heard them called ‘higher level applications’. Furthermore, the device software upgrade use case even had the additional tag line “NSO Expansion - Looking beyond configuration”. The point is that many of us are already moving beyond basic configuration services - and using NSO to get there.
When you think about higher level applications that do more than configuration, do you think about applications that you may have built for Tomcat, JBoss/WildFly, or GlassFish? These frameworks fall into the general category of application servers (or "app servers") and to me, NSO is just another, albeit proprietary, app server. I don’t want to have the religious debate about whether app servers need to support this or that Java paradigm so I’ll just stick to what I believe are the key characteristics of an app server - and assert that NSO provides them. NSO has a standard application structure (the packages), metadata describing them, primitives for an application lifecycle including startup and reload, tightly and loosely-coupled APIs for performing various functions, data persistence, and then the general ability to do whatever else you want to do as an application or data provider type. Hooking your own UI in is a little tricky, but having NSO start up your own proxy server (or telling linux to do so) is not. To me, this makes NSO an app server whether Tail-f meant it to be or not, and other applications that have rich ecosystems have similar custom application environments (e.g. Splunk).
So, when I think about NSO-enabled applications, I look way beyond configuration and think about what can be done with custom Java/Python, other open source software, a UI, and, of course, the NSO device catalog. Even though we are thinking beyond configuration, a network’s set of devices and the ability to make changes to them based on user input or application logic will always be the reason to use NSO as your app server. This is a tremendous advantage that NSO-based applications have over similar applications that have to build in device operations from scratch or just can’t do them at all.
This should get everyone thinking about all the things that are possible if we look beyond configuration as the Developer Days presenter suggested. For other examples of NSO-based solutions that have started down this path, you can check out the videos we’ve posted on YouTube at https://www.youtube.com/channel/UCleHT4-PRDRTDnAbGcmqylg - and start building your own!
