At Datalicious, we maintain quite a few systems that need to handle serious network activity loads while working with some fairly large data sets. Often we're simply gluing existing components - such as Splunk - together, but we still need some pretty serious performance.
Traditionally if you want some major performance out of your software without some serious hardware up-scaling, you'd basically write your programs in a "low-level" programming language like C (or C++ if you're a masochist).
This has a couple of problems, though:
- we want our code to be 'portable' - to work across platforms without writing 'glue code'
- we need to code to tight deadlines
- I'm not a computer scientist!
An alternative approach is to use programming frameworks that behave asynchronously. This has allowed us to build systems that handle huge amounts of data and staggering loads of traffic on our clients' websites.
I've always been interested in the 'asynchronous' programming model. Like Ryan Dahl, creator of node.js and until recently an employer of the cloud computing provider Joyent, I'm partly driven by an anxiety about the inefficiency of the most popular model of web development: spawning a process to handle each request, which dies as soon as the response is sent to the client. This works well for simple atomic web applications, but we have some complex requirements that don't suit this well: we need to be able to handle hundreds of requests per second on small, relatively weak machines, and log information from those requests without slowing down the response time at all. The only effective way to do this is to decouple the process of writing data to disk or into a database from the process of sending data to a user's web browser.
Developing web services this way is challenging, and it requires a different mode of thinking, it has significant rewards. It's possible to write a program where a single process can handle all of these responsibilities with barely any impact on the CPU, where an equivalent solution written (for example) in PHP had to be sharded across multiple heavier machines and still required attention when there was a spike in website traffic.
Event-driven and asynchronous programming have a simple concept at there core: instead of making your programs wait around for some data to come off the network, the disk or from user input, the program asserts that it needs to wait for something and registers some instructions that will occur when the data arrives, without blocking in between.
As I mentioned, this does carry a cost - generally in the complexity of a program. The benefits can be immense, though:
- handling many disk operations or network connections in a single process allows the
state of a system to be shared more effectively, providing greater interoperability between systems
- having a single process handle many incoming network connections avoids the expense of spawning threads or new processes o handle connections, which is the traditional network programming approach
- programming with an asynchronous model gives the developer access to network protocols at a low level that represents the reality: they they are
streams of data, not necessarily just atomic request and response objects
- asynchronous systems generally run in long-lived processes and can integrate far more effectively with other services and processes, as they have the ability to store state over time and to communicate with other processes or systems, whether on the same machine or over the internet
There's a long-running argument in computer science over different models for asynchronous programming. The current node.js craze has revitalised this debate
The prevalent dichotomy is between threads and event loops (also referred to as reactors. It's an ancient argument and I don't have much to add to it, except that as someone who is constantly trying to find a balance between 'correctness' and 'efficiency' in my software, I find programming with threads to be difficult and sometimes tedious.
Many developers find it counter-intuitive to deal with event-driven models in programming, but I think this is mainly an education problem: most people are raised on the 'imperative' approach in languages like C++ and Java, with some coverage of object-oriented concepts. This is already changing: the current generation of self-taught programmers is overwhelmingly focused on JavaScript, which strongly emphasises functional programming and often deals with an asynchronous approach when communicating between a web browser and a server. I don't believe that asynchronous programming is necessarily more difficult than traditional programming.
Our own lessons lately have involved the stability of node.js. I do think it's a great project. It's raised awareness of a programming approach that was neglected, and it's made systems development a little more accessible to front-end programmers. It's also looking to be a popular alternative to Ruby on Rails for the development of truly hypermedia-based RESTful APIs.
That said, the project's immaturity has to be recognised. We've found that it's challenging to deploy node.js as a HTTP server without encountering stability issues. Node is constantly improving in this regard, but there are no established standards for maintaining and monitoring a process, nor for integrating with existing tools popular with system administrators. At the moment it's very difficult to run node.js as a daemon, which is deal-breaker for some system administrators.
For this reason, we've started to explore alternatives, such as Python's Twisted framework. It turns out there are a range of solutions similar to node.js which are much easier to "productionise", which have stable releases and a lot more experience in the community.
- Daniel Bryan
