This post is a first of sorts – as with my review of RESS: The Essentials that opened my Reviews category, it will be the first in the Events. In this context, plural is actually justified because it covers not one but two events: Node.js on the Road on Feb 27th in San Francisco’s hosted by New Relic and NodeDay on Feb 28th in San Jose hosted by PayPal. Both are now available – you can read the NodeDay post here.
I ended up at ‘Node.js on the Road’ by a stroke of luck. Ever since the days when EclipseCon was being hosted in Santa Clara Convention Center, my preferred travel plan was to fly to SFO, then drive down 101 South for the event. The 11:45am Air Canada YYZ-SFO flight is just perfect for this, and it gives me a free afternoon and evening in San Francisco. Just when I was trying to figure out what to do with the available time, along came a tweet about ‘Node.js on the Road’ to be held 6-9pm PT in the New Relic’s downtown SF location on Feb 27th. Seemed like a perfect way to spend the evening before heading South.
Looking for parking on a work day in downtown San Francisco is not for the faint of heart. I ended up parking in an the underground garage of the nearby building. I arrived a bit ahead of time but it turned out that 6pm was ‘when the food was about to arrive, and also the people’, not the actual start of the event. Just as well, because my jet-lagged mind welcomed some time to pipe down and also solved my dinner problem.
The even was opened by Bryan Cantrill, SVP Engineering of Joyent, the corporate steward of Node.js. It was a welcome introduction, explaining the format of the evening which was a bit vague to me. He also said something counter-intuitive for many people skeptical of ‘JavaScript on the server’: “Node.js is the most debuggable dynamic environment”. Veterans of Java and JVM would love to disagree, but everybody knows that huge VM dumps created when a real-world production Java program gives up the ghost are a nightmare to analyze, so it is not hard to imagine where he is coming from.
First on the list of presenters was TJ Fontaine, the newly minted Node.js Core team lead, replacing Isaac Schlueter who left to become the CEO of the new NPM startup (short for ‘Node Package Manager’, a registry largely responsible for the thriving Node.js ecosystem). His talk was centered around the road ahead – what is left to finish in Node before it can be declared v1.0, how companies and individuals using it can contribute and inform the process. There are multiple ways to make Node better at this point: reporting bugs as we are hitting them in production, contributing source for either enhancements or bug fixes, helping with the documentation (Node currently has a bit of a documentation problem). There are also multiple ways to ensure the community continues to thrive – Stack Overflow, IRCs, mailing lists, meetups. Not all of these options are equally appealing to all (TJ is not a fan of mailing lists or IRCs) – YMMV.
TJ also spent some time to announce what is coming in Node 0.12 which is ‘very immanent’. It was largely a rehash of what was already mentioned in a related blog post. Some are expected (performance improvements), some are too detailed for my current knowledge of Node.js (TLS enhancements, buffers, streams) although I am sure there are developers which are expecting them with anticipation. And then some are controversial. Take execSync – after all the effort to explain that Node.js is asynchronous to the core, being able to run blocking execution seems like a compromise with the devil (to TJ’s defense, he recommended extreme caution when using this function for all the easily understandable reasons).
Next on the agenda was Dav Glass, Node.js architect from Yahoo!. In my chat with the presenters prior to the event, I learned that the idea is to bring different presenters at each stop to tell the story of their own use of Node.js in real world projects. Yahoo! seems to be turning into a massive Node.js shop, and Dav illustrated it with the ‘We love Node’ slide. Yahoo! runs Node both in production and internally, using a huge Continuous Integration (CI) system called Manhattan. At the moment, some of the boxes in Yahoo! pages are served by Node (others use Java or PHP). As expected, transition to Node in running systems is often a gradual transition, not a big switch.
Dav’s war stories? In his experience, it is rarely Node’s problem – most of the time issues end up being caused by downstream modules deep in the bowels of the running system. Again, since the system needs to keep going, Node needs to be inserted into the giant old infrastructure. Yahoo! is using Node largely unmodified – the only minor changes being done around security and authentication.
Another common theme is the use of NPM to serve internal modules – not all the Node modules are open sourced, requiring a way to serve them internally. One of the internal code quality requirement is that you are not allowed to share a library unless it has 80% test code coverage.
Dav demonstrated some impressive throughput numbers, from processes serving > 1000 rps (requests per second), to some extreme examples of hot rod modules hitting insane figures of 25000-36000 rps.
Jeff Harrell is a new hire who came to PayPal 2 years ago as a new Director of UI Engineering to ‘disrupt the PayPal system’. His story has already been somewhat familiar to me due to the write up on the Project Kraken. Jeff added new observations to this story, explaining that the goal of their wholesale move from Java to Node was every bit as driven by developer performance as app performance. In a what is turning into a familiar pattern, their topology has Node front end hooked up to the legacy infrastructure that is either difficult to change, or is not a good fit for Node. PayPal is currently running 20+ Node apps, written by 200 developers (both new hires and Java converts).
According to Jeff, converting Java developers was an interesting process. He observed stages not very different from Kubler-Ross stages of grief, from denial, anger and bargaining to acceptance and finally enthusiasm for Node at the end of the curve. Of course, not everything was perfect: PayPal, being a payment processing company, is a heavy user of SSL, and in Node v0.10, SSL cipher time left much to be desired. This was just a point in time problem, however: in v0.11 and the upcoming v0.12 SSL performance is much improved, and will continue to be a high priority.
The last part of the event was a Q/A panel with all the participants. A lot of questions were for Jeff Harrell – it seems that audience uses PayPal as a good model of a traditional Java shop moving to Node with a clear head, with a desire to improve productivity and make Lean UX real and practical, whereas they have a harder time identifying with the more complex Yahoo!’s systems (a lot of participants work for startups that are years away from reaching Yahoo! scale). Some participants expressed the familiar concern about type safety (or lack thereof) in JavaScript. According to panelists, smaller modules in Node tend to make type safety less of an issue. In fact, Node.js inherits from Unix philosophy – it forces you to think small and combine (and write tests – smaller components are more testable).
As for real-world robustness, Yahoo! has provided Open Source launchers (they are on GitHub) which run one process per core, and restart process if there are problems.
Some participants wanted to know how to get Node introduced into a skeptical organization. Panelists agreed that doing it instead of asking for permission is the way to go (and also making it provable – you can argue technology all day long, but when business people realize you can do it faster, they like the outcome).
Yahoo! is definitely not in that phase right now – Yahoo! has thousands of engineers that all know JavaScript, so convincing them is an easier task. With such a brain power, it is easy to go crazy with inter-process communication and try to squeeze the last ounce of performance using binary protocols, but the recommendation is to start with HTTP and see if anything else is needed.
All in all, it was an enjoyable and not over-long evening, and a perfect prequel to the NodeDay on Friday. Read about NodeDay in my next post.
© Dejan Glozic, 2014
Dejan Glozic 