Event-Driven Platforms Critical for Next-Gen Network

#SDN #devops #Node.js is awesomesauce for the network, too.

I recently stumbled across an article discussing node.js and devops in the same breath. Yes, I was in heaven, why do you ask?

In any case, the article notes two primary reasons why node.js is an excellent choice for devops tools:

Node.js has a couple distinct advantages for infrastructure maintenance:

1. It has a small footprint
2. The event-based nature of Node.js helps keep servers from getting bogged down handling time consuming tasks.

-- Why So Many DevOps Tools are Written in Node.js

While I'm not discounting the value of the first point, I think the second is much more important not just to devops but to the data center (and in particular management of) in general, especially given the trend toward centralized management planes across the entire network stack (think SDN).

The funny thing is that if you take a step back and look at DevOps and SDN you'll see that we've had this discussion under the Infrastructure 2.0 umbrella in the past. One of the core components of the idea of Infrastructure 2.0 (which is really the pre-cursor to SDN, if not its parent) was that some centralized controller (sound familiar?), mediator, whatever you want to call it, would be responsible for accepting and distributing events across the network infrastructure stack. It grew out of concerns around IPAM (IP Address Management) and the increasingly volatile rate of change occurring there thanks to virtualization and cloud computing.

But these controllers would be software, necessarily, and thus concerns regarding scalability and performance quickly become a sticking point. It should be no surprise that one of the primary arguments against OpenFlow-enabled architectures is that the controller does not scale or ultimately perform well. Clustering is an attempt to address both issues in large-scale networks, but this is just rehashing the same "how do we scale web applications" that's been going on since the dot com era began.

BLOCKING versus NON-BLOCKING. SYNC versus ASYNC.

That's because traditional models of development were thread-based, synchronous and ultimately blocking. Modern scalable frameworks are non-blocking and support asynchronous modes. The modern non-blocking, asynchronous model is geared toward long sessions with intermittent communication between client and server. Which is exactly the kind of model laid out to support a more dynamic, event-driven network architecture. Network components need to know right now when an event happens, but they can't waste cycles opening and closing connections to "check" every x-seconds. That mode of operation doesn't scale and the overhead from TCP session management on both the component and the server would be devastating.

So asynchronous, high-capacity is what's necessary and node.js fulfills those requirements.

Can you write async, non-blocking servers in other languages and on other platforms? Yes. Java and Erlang and a variety of other languages have frameworks that support such a model. But they are ultimately still encumbered by the underlying platform (application server). The impact on performance and scale still exists, albeit it occurs at a much higher threshold than traditional applications.

Node.js eliminates the platform impact, thus providing DevOps (and developers, for that matter) with a high-capacity, high-performing, highly programmable platform upon which to deploy... well, whatever they want. And because so many devops-related tasks that need to be automated are driven by events (provision, launch, shut-down, add, remove, stop, start) it starts to make a lot of sense to look at node as a platform for DevOps upon which they can build tools. (Etsy has a great blog on the use of node.js for devops tools, if you're interested)

The gravitational pull toward node.js is, likely, because it is inherently event-driven. It isn't that you can do event-driven, it is. That's it. With Java you can write event-driven daemons, yes, but it's not the primary model for Java (or its underlying platforms) and it takes more work than writing a traditional application.

The network (and by "network" I mean the whole stack from L2 to L7) is driven by events - packet in, packet out, connection made, response received, IP address assigned, IP address released - and thus a lightweight, highly scalable event-driven framework fits naturally as a platform upon which to build tools that help manage the network.