We talk a lot about automation and how network engineers need to return to programming. The vision is that we will all have to do some programming in the future to glue various parts of our systems together. This was certainly the case in the late 90’s and faded away in the early 2000’s.
Large networking in late 1990’s relied heavily on scripting to perform failover, monitoring, management, configuration backups and even code updates to devices. There was no SNMP and certainly no management products. This was the era of DOS 6.2 and Windows 3.1. Linux required weeks or months of effort to learn and install and Solaris was the king of Unix. (cough, cough)
In the late 90’s the language of choice was Perl with TCL. Today, there are dozens of new languages and there is a lot of weight behind “using what we know” with Perl but many are turning to Python. I know people using Ruby too.
In 2013, everything is pretty much the same. Network Management tools are much improved but stuck with second-rate protocols/APIs for accessing data such as SNMP. We have plenty of nasty hacks to get configurations backed up and device performance, but very few usable APIs. Enter Software Defined Networking.
The Rise of the Application Programmable Interface
In my view, an Application Programmable Interface(API) is the fundamental change that makes Software Defined Networking (SDN) a “thing”. It’s the single most important thing to change in networking since RIP was deprecated in favour of OSPF/EIGRP. We need to realise that the CLI is a “power tools” for specialist tradespeople and not a “knife and fork” for everyday use.
The second most vital change is that users want to have a quality interface. Users expect more than a Windows interface or an ugly HTML text page with data on it. Where once getting anything onto a web page was acceptable, users expect to see dials, charts, rounded corners and luscious menu transition.
Many people turn to web frameworks like Ruby on Rails, Django (Python), or one of the dozens for PHP like Laravel to provide the web interface. You need to solve a problem like “web interface” go and get a tool that does.
If/when you attempt to design a management software system, you quickly realise that you need tol collect data, poll status and present the information to a user interface. Ultimately, its inevitable that you will base your software architecture on Model-View-Controller (MVC) because you want to decouple the presentation code (HTML interface or a View) from the polling engine (View) from data routing (controller) and database (model). And because that’s what you do when you architect a software application (it’s like a vendor design guide)
MVC promotes decoupling your system into three functional components:
- Model – A structure containing the data that is being read or acted upon
- View – An interface through which the user interacts with the model
- Controller – Delegates user actions from the view to the underlying model
It’s reasonably common to use a PHP or Ruby framework for the web view, Perl or Python for the network polling and a SQL Database to store the data. You will need to use dozens of modules to provide the enhanced functionality plus some syslog, CRON jobs, Apache, Apache modules. Maybe you dropped a memcached for performance ….
Except about six months later you realise the decoupling process has made things way more complicated. Now you have the a fleet of different systems:
- Web framework and it’s libraries
- Scripting languages (Perl, Python, PHP, Ruby) for core logic (likely, at least two or three).
- SQL (gods, I hate SQL syntax)
- Shell scripts, Linux (no one uses Windows for this work, are you mad ? )
- Linux – CRON jobs, syslog, log rotation, etc
- Probably another scripting language plus any number of supporting software programs in Linux driving all the tangential parts (sysadmin, deployment, back-end services, etc etc)
- and probably a bunch of C library/extension for one or more of your scripting languages. (If not today then you will because your polling agent will have to be in C for any sort of scale for multithreaded scripting languages.).
Now your head hurts and you have forgotten why you started in the first place since all you do is read websites & man pages to work out what the hell is going on.
So I’m a networking guy & you are asking me to develop skills in all of this non-core knowledge of a dozen or so languages ? And lets not forget testing, IDE’s, deployment & upgrades of each of these system ? And the tools to write these languages. And test them.
What is node.js ? From the website:
Modules like backbone.js and underscore.js solve code coupling with abstracted frameworks in the web browser.
Backbone.js gives structure to web applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing API over a RESTful JSON interface.
So there are three key aspects of node.js that really interest me.
- widespread adoption at web scale companies.
- Event driven programming.
The technical aspect of event driven programming is key. In a network management system, everything is driven by events.
- polling is an event that occurs every five minutes.
- SNMP-trap is an inbound event that requires handling.
- An API message from an external application
- making an API call in response to user action.
It seems to me that using an event-driven language is well suited to network management. I’ve spent some time working on Perl scripts that attempted to handle events and it’s was really complex. Global namespace in multithreaded scripts is complex and prone to failure.
Scaling – Vertical vs Horizontal
And I’ve had been involved with enough failed projects with multithreaded languages that are hard to scale. Horizontal scaling is typically done using a database and attempting to build coherency between multiple threads, or to split the program flow into smaller pieces. Vertical scaling with bigger machines (CPU/Memory) and large amounts caching is usually the only practical option for Perl/PHP.
Compare the multi-threaded PHP/Perl/Python of :
with the event driven model of node.js where the server is waiting for inputs and spawns internal processes to handle the requests.
This feels “natural” to me. I like it.
The EtherealMind View
So, here is where I am now.
The Case For:
- node.js is an event-driven environment looks well suited to network management.
- Good to excellent HTML template and dynamic content generation and support for funky HTML toolkits.
- Excellent support for APIs
- Tight integration from HTML – Logic – Database
- Lots (and I means LOTS) of textbooks and reference material to learn from.
- Lots of networking specific networking code modules available for Perl / Python.
I worried a while about the module availability for protocols like SNMP, sFlow and other. Then I realised – they don’t fundamentally matter. I’m not building for current generation of networking, I’m building for the next generation of SDN products. And they won’t be using legacy protocols. And even if I need them, I can build scripts to act as API translators using the languages that have the support.