The Event-Driven Data Center

#sdn #node.js Like the planets aligning, dev and the network sync up on architectural foundations so infrequently that it should be a major event

One of the primary reasons node.js is currently ascending in the data center is because of its core model: event-driven, non-blocking processing.

Historically, developers write applications based on connections and requests. It's blocking; it's not asynchronous; it's not fire and forget until some other event reminds them that something needs to be done.

If the underlying network fabric worked like applications today work, we'd be in a heap of trouble. A switch would grab an incoming packet and forward it and then... wait for it to return. You can imagine what that would do to traffic flow and just how much bigger and beefier switches would have to be to support the kind of traffic experienced today by enterprises and web monsters alike.

Luckily, the network isn't like that. It doesn't block waiting for a response. It grabs an ingress packet, determines where it should go next, forwards it and then moves on to the next packet in line. It does not hang out, mooning over and writing bad love poetry about the packet it just forwarded, wondering if it will ever come back.

That, in part*, is why networks scale so well, why they are so fast and able to sustain a significant order of magnitude more concurrent connections than a web or application server.

So imagine what happens when a web or application server adopts a more laissez-faire attitude toward processing requests; when it fires-and-forgets until it is reminded by the return of a response?

Exactly. It gains phenomenal network-like speed and much better scalability. 

That's what node.js is bringing to the data center table - an event-driven, non-blocking application infrastructure that aligns with the event-driven, non-blocking nature of the network fabric. Louis Simoneau sums it up well:

Node.js is the New Black

Here’s where some of that jargon from before comes into play: specifically non-blocking and event-driven. What those terms mean in this context is less complicated than you might fear. Think of a non-blocking server as a loop: it just keeps going round and round. A request comes in, the loop grabs it, passes it along to some other process (like a database query), sets up a callback, and keeps going round, ready for the next request. It doesn’t just sit there, waiting for the database to come back with the requested info.

And it's a quite capable platform based on the numerous benchmarks and tests performed by developers and devops interested in understanding the differences between it and the old guard (Apache, PHP, etc...)

Developers deploying on off-the-shelf operating systems have scaled node.js to 250000 connections. (See chart)

On a purpose-built operating system, node.js has been clocked at over 4 million simultaneous connections. It scales, and it scales well.

Suffice to say that the application and network infrastructure is starting to align in terms of performance capabilities and, interestingly enough, programmability. What the network is taking from development is programmability, and what development is taking from the network is speed and capacity.

They're aligning in so many ways that it's almost mind-boggling to consider the potential.

It's not just like Christmas - it's like Christmas when you're five years old. Yeah, it's that awesomesauce. I haven't been this excited about a technology since application switching broke onto the scene in, well, quite some years ago now.

Counting Down

This is not to say that the entire network fabric is truly event-driven. It's not quite Christmas yet, but it is close enough to taste ...

Network components, individually, are event-driven, but the overall data center network is not yet. But we're getting closer. You may recall that when we first started talking about Infrastructure 2.0, when cloud was in its infancy (almost pre-infancy, actually), we talked about event-driven configuration and policy deployment:

Infrastructure 2.0: As a matter of fact that isn't what it means

The configuration and policies applied by dynamic infrastructure are not static; they are able to change based on predefined criteria or events that occur in the environment such that the security, scalability, or performance of an application and its environs are preserved.

Some solutions implement this capability through event-driven architectures, such as "IP_ADDRESS_ASSIGNED" or "HTTP_REQUEST_MADE".

Today we'd call that SDN (software-defined networking) or the SDDC (software-defined data center). Regardless of what we call it, the core principle remains: events trigger the configuration, deployment, and enforcement of infrastructure policies across the data center.

Now couple that with an inherently event-driven application infrastructure that complements the event-driven network infrastructure. And consider how one might use a platform that is event-driven and isn't going to bottleneck like more traditional development languages. Exactly. All the capacity and performance concerns we had around trying to architect an event-driven data center with Infrastructure 2.0 just evaporate, for the most part. 

The data center planets are aligning and what's yet to come will hopefully be a leap forward towards a dynamic, adaptable data center fabric that's capable of acting and reacting to common events across the entire network and application infrastructure.

 

* Yes, there's hardware and firmware and operating system design that also contributes to the speed and capacity of the network fabric, but that would be all be undone were the network to sit around like a lovesick Juliet waiting for her Romeo-packet to return. 

---