Get Enterprise AppFog on Private Clouds and On Premises Today

Node.js is taking over the Enterprise – whether you like it or not

TL;DR: The question is no longer if Node is enterprise ready. The question now is the following: what major digital enterprises will end up being the last hold-outs?


 
There’s now no question whatsoever that Node is far more than a flash in the pan. The question nowadays is not whether or not Node will break out of its so-called “hipster hacker” bubble, but rather how much of the digital world it will conquer.

In spite of all of the early FUD directed at the Node community and arguments that you shouldn’t use Node for anything much less for enterprise-ready web development, a pretty sizable chunk of the corporate world has gotten on the train.

It turns out that the same things that made hackers fall in love with Node are more or less the same reasons why enterprises are turning to it. In a world in which we want information pipelined to us in real time and in which technological advancements like open APIs and distributed computing have made that possible in once-unprecedented ways, then it’s no surprise whatsoever that the contemporary digital marketplace would begin looking for tools to not just put their toes in the water but to dive in unabashedly.

Examples of Node in the enterprise abound already:

  • Last year, eBay released ql.io, an event-driven aggregation tool for API consumption.
  • I’ve written previously about Node at LinkedIn, but it’s worth a mention. LinkedIn has said publicly that they achieved massive performance gains with Node, which is impressive for a company that is one of the top 100 most visited on the web.
  • Voxer is using Node and Riak to build its walkie talkie-style mobile app (and have open sourced their in-house Riak client). They shot to the top of the Apple App Store last winter and drew heavy praise from Soulja Boy and Kevin Durant.
  • Yahoo has used Node to develop their Mojito platform and a handful of others.
  • WalMart Labs has been using lots of Node in mobile development.
  • I’ve also seen all kinds of promising game development done using tools like Node, socket.io, and Redis. I’m excited to see how far this goes and whether or not large gaming companies like Zynga will come to favor Node over ActionScript, Erlang, and other languages and frameworks.
  • AppFog has used Node extensively in our console and in other crucial parts of our application architecture after various flirtations with EventMachine turned out disastrously for us in testing. We’re a new company, but we’re making an investment in Node and we are not alone.
  • Even Oracle has gotten involved in the Node community. Last fall, they announced that they planned to develop Nashorn, a JVM-based JavaScript engine set to be available in late 2012. They’ve explicitly talked up the ability to use Nashorn to do crazy things like create Node.jar files and more generally to make the power of Node more readily Java-compatible.

Now, Node is not the only tool out there that does things like non-blocking I/O, of course. Python’s Tornado web server is non-blocking, as is Ruby’s EventMachine (mentioned above), as is the polyglot Vert.x server. There are a handful of others in highly variable states of maturity floating around out there. But what makes Node special is the Node community, which is not only incredibly vibrant but also, more important, the only developer community that was built from day one around asynchronous, event-driven application logic as a core principle.

This is one of the thing that makes Node a good choice for enterprises from an organizational perspective. Finding quality people who can make solid contributions to Node-based projects is vastly easier than finding people who can hack Erlang or Haskell or even C++ or Java. There isn’t a web-driven enterprise in the world that doesn’t already have a handful of solid JavaScript developers around. And more developers are becoming actively involved in the Node community every minute, and we all know that developers rule the world already, and you often have to meet them where they already are. This can make Node adoption a pretty sound HR decision.

In this context, it’s important to remember that Node has surprisingly deep pockets. With official corporate backing from Joyent, who has been a supporter not just on the financial end but also on the evangelism end, there is little to no risk that Node will stop having a core team that is actually paid good money to work on Node. While the vast bulk of the Node community is dispersed and autonomous and corporate backing from a company like Joyent isn’t all that important to hackers, it can often be the difference between convincing IT higher-ups and managerial types to bank on a technology.

So what does that mean for the future of Node? Well, first of all, I think it will mean that the demographics of the Node community will change. Thus far, your typical Node developer is still young, a resident of a small handful of urban areas in the U.S., and not very “corporate.”

That profile is changing already. Older hands are getting involved as Node loses its reputation as being intrinsically immature and unstable. A lot of former .NET developers, some of them as enterprise-y as anyone, seem to have developed a real affinity for it. And we seem to already be reaching a point where Node becomes as widely accepted and no-longer-scary as Ruby on Rails. Once that happens, those always on the lookout for the newest and baddest will have to start looking beyond the Node community (I, for one, am pushing for Scala).

Second, I think there’s a possibility that the biggest qualitative leaps in Node development might someday come from the enterprise rather than from the vast ecosystem of autonomous developers. This is an uncomfortable thought for plenty of Node hackers, but if we see more of what we’ve seen so far from Yahoo, Voxer, and others is any indication, this could well turn out to be the case. There will always be thousands of developers contributing modules to NPM and providing incremental improvements and additions to Node, but big leaps often require larger projects demanding whole teams of developers. Big shake-ups in the database space, for example, have often followed on the heels of working papers publicized by Google (like this one on its Spanner architecture, which could also have a huge impact outside Google). The Node community could come to function in a similar fashion.

In short: Node is already in the enterprise, and it’s set to expand there. But that doesn’t mean that you have to delete your Node-related GitHub repos and tear down your Ryan Dahl poster. It’s simply the run of things in tech. There will still be plenty of Node hacking to be done for the foreseeable future. But a lot of the most interesting stuff might be at a Walmart or an Oracle.

Share this post
Facebook Twitter Google
Try AppFog: The new PaaS Hackers love
  • http://twitter.com/Tyler_Power Tyler Power

    I can’t help but think if it is gaining traction in the enterprise it’s at least ~10 years away from gaining widespread adoption… most enterprise devs I’ve had the pleasure of working with are near the limits of their capabilities working in a synchronous environment with a statically typed language. JavaScript scares these people. I think being so close to the cutting edge (I’m commenting on an AppFog post!) we often forget how far behind the enterprise in general is and more importantly how most enterprise devs just don’t care.

  • Anonymous

    Node is gaining traction in the enterprise? Like ActiveX, Corba, SOAP, XML-for-configuration and J2EE have had in the past? Must be great for Node.js, must mean it’s just as good as those technologies.

  • Carsten

    you think that dynamic langs. (or JavaScript) are cutting edge technologies? Or that statically typed languages are synchronous by nature? … sorry but ROFL
    Yeah – we are working with JS as we have to – but as soon as there will be viable (aka widespread) alternatives JS will go down like the Titanic – no one with a CS or language background (or even no one knowing any other languages) likes to work with JS – it’s just a pain.
    You want to see great languages? Try something like Haskell, Clojure, Scala, …

  • Carsten

    BTW: enterprise people are not “behind” – but they tend to have to “get work done” … and often beeing a bit older and having some life beside coding don’t make JS more attractive … I guess you will get there (BTW: I’m not your typical enterprise guy and I do code for fun – but JS … bah – only if I really have to)

  • http://twitter.com/lucperkins Luc Perkins

    I agree about those languages that you mentioned being impressive technologies (although I do like JS–I find its quirks to be usually charming, occasionally exasperating). Learning Scala is already my next Big Project, for example. But my claims are not about JavaScript. My claims are about Node. JS is not a cutting-edge technology, but the Node community is committed to solving certain kinds of problems that others are not (or they’re late to the party). Others are doing Node-like things, but those things are appendages attached to communities that are not committed to making the so-called “real-time” web a reality. Enterprises are taking a serious look at Node because the Node community has the real-time web as their project and horizon of thinking.

  • http://twitter.com/lucperkins Luc Perkins

    You could very well be right that something like Scala or Erlang is already capable of doing the real-time web better than Node in a lot of respects. But good luck assembling whole teams of developers that can use those languages without breaking the bank.

  • http://profile.yahoo.com/Z5DQCE7YHKZZWEDZIZLDYUUW5M ninja

    Eh, JavaScript the language will keep a lot of “Enterprise” developers away. You don’t have to do much JavaScript if you’re using JSF or ASP.Net WebForms(IIRC). You don’t have to delve much into “real” JavaScript if you’re using JQuery and similar libraries.

    The language may be fixed soon with ES.Next, but until then it’s not worth talking about Node.JS taking over. It will be interesting to see the competition between Node/JavaScript and Google Dart.

  • http://twitter.com/lucperkins Luc Perkins

    Just because sucky things have gained traction in the enterprise before doesn’t mean that anything that gains traction there becomes sucky by osmosis. That sounds like a logical mis-step.

  • adi

    I think you are confusing Enterprise with enterprise vendors, these are trying to adopt.
    All of your given examples have a strong engineering teams or are selling SW and trying to adopt . Lets see the examples from Boeing, Visa & city bank.

  • http://twitter.com/lucperkins Luc Perkins

    That’s a good point. I think you’re right that I haven’t made a sufficiently strong demarcation between enterprise types. Node would have to become WAY more mature if it was to make an imprint in banking or aerospace, and even then it would be unclear what the benefits would be.

  • zorg

    > I’m excited to see how far this goes and whether or not large gaming companies like Zynga will come to favor Node over [...], Erlang, [...]

    Node over Erlang ? Ha ha, you have no idea what you’re talking about!
    Erlang is so much more than asynchronous IO…

  • russd

    concurrency and distributed programming is hard… using node.js does not make it easier. Sorry but you do have to break the bank. (and none of these are real-time anyway)

  • http://twitter.com/mogrim I R JIm

    It might be fashionable to knock J2EE (and Java), but given the vast amount of technology it covers it’s also pretty stupid. For every failure (ejb 2.1, for example) there are plenty of success stories (JDBC, JMS, Tomcat et al). I’d say Node’s got a way to go before it can match the /proven/ stability and performance of a modern JVM stack.

  • http://twitter.com/mogrim I R JIm

    Not sure about the “having some life” comment, but being a bit older I’ve seen a lot of technology come and go, and I’m certainly not betting the house on node.js just yet…
    It doesn’t help that I’m hearing exactly the same world-saving message applied to Scala, Clojure, Haskell and Erlang, not to mention there are some very clever people working on the new JDK8 and 9 releases, and they will certainly do what they can to keep Java competitive.

  • http://twitter.com/lucperkins Luc Perkins

    Of course Erlang is much more than asynchronous I/O. Of course it does a vast variety of things that Node will never even attempt to do. I would never dispute that.

    My point was not that Node is a wholesale “replacement” for languages like Erlang but rather that there are a variety of reasons why many companies might opt to use Node in the WEB DEVELOPMENT and gaming sphere instead of languages like Erlang. Why? Well, I’ve already enumerated those reasons. Solid Erlang devs are incredibly difficult to find and there simply isn’t the same mindshare behind Erlang (in sheer quantitative terms) that there is behind Node and JS more broadly. I don’t think it’s at all ridiculous to think that Node could mature to a point where it could replace Erlang for game development at SOME companies for SOME purposes.

    I’m sure that Facebook will continue to use Erlang for their chat architecture and I highly doubt that Ericsson will switch their telecom infrastructure to JavaScript. You missed my point.

  • http://www.steveperkins.net Steve Perkins

    TL;DR: This post’s title is exaggerated click-bait. Java and .NET probably won’t dominate the enterprise space forever, but they have such momentum that displacing them will take much more time and corporate backing than the author describes. Also, he is seriously glossing over the differences between developer experience on the client-side vs. the back-end enterprise domain.

    I started my career in the late 1990′s, in a wave of young Java guys who were seizing enterprise space from C/C++ and midrange/mainframe languages. Having been on the other side of that coin myself, I’ve always looked over my shoulder for the next wave creeping up behind me. When the Rails hype exploded 6-7 years ago, I started using Ruby in my personal projects. When Google hired Guido van Rossum and got behind Python in a big way, I started looking for excuses to sneak that language into my company. Also, while I mostly work on the back-end professionally, I’ve maintained enough of other people’s JavaScript to build a secondary skillset in that area.

    So I keep myself (and my resume!) prepared for any of these languages to “take over the enterprise”, like the Java wave that brought me here. However, it just doesn’t work that way. Rails carved out a niche for itself, but nobody *fears* Ruby anymore… its good ideas were quickly copied by everyone else, and its hype settled down. Most of the early cloud work that Google did with Python was eventually adapted to Java-based offerings. As the author hints at here, the core concepts in Node.js are already being co-opted in the enterprise Java world too (e.g. Scala, JBoss Netty, Apache MINA, etc).

    The consistent real world pattern is that “community” languages produce exciting trends, and then the “corporate” languages (i.e. Java and .NET) absorb them. There are a few reasons for this:

    [1] INDUSTRY MOMENTUM: I would wager that total worldwide investment in Java and .NET over the past 15 years has easily reached the multi-**trillion** dollar range. Given the explosive growth in IT that started in the 1990′s, there has probably been investment in these two platforms than in all previous languages combined. I don’t think these two platforms will last forever, but there is literally no precedent for guessing how long it will take that kind of staggering momentum to wane.

    [2] DEVELOPER MOMENTUM: With most jobs, it’s usually pretty easy to “sneak in” another language for small tasks, to get it on your resume as a secondary skillset. However, until you have extensively worked with it as your primary tool, you will rightfully be seen as junior-level with the secondary language.

    To be blunt about it, senior-level Java developers generally make tens of thousands of dollars a year more than junior-level “dynamic” language devs. So why would any enterprise developer *voluntarily* slash their job market leverage, by switching their primary platform before the need was clearly inevitable? This is not the kind of move that most people make when they reach their 30′s, start families, etc. Moreover, what if you make the wrong bet? If I had made a professional shift toward Ruby during the 2006 wave of Rails hype, my enterprise career might NEVER have reached its current level.

    Because dramatic career change is prohibitive, the inclination is to borrow cool concepts and apply them incrementally in your current career path. I can use Groovy instead of Ruby… Scala or Netty instead of Node.js… and my resume looks more coherent, because these things are considered part of the Java ecosystem and use many of the same API’s.

    [3] ECOSYSTEMS ARE MORE IMPORTANT THAN LANGUAGES: As a 15-year Java veteran, I will freely admit that even I find it painful to write Java code. The effort needed to simply read the contents of a file is staggering compared to other languages. However, the wider “ecosystem” around a language is more important than the language itself!

    The Java world figured out packaging and dependency-management standards over a decade ago, while useful Ruby tools (i.e. RVM and Bundler) emerged recently and seem inspired by Maven. The closest thing that Python has to an enterprise-class persistence framework (i.e. SQLAlchemy) resembles the state of Hibernate from five years ago. Etc, etc, etc… I’m not sure if an ESB that isn’t based on Java or .NET even *exists*.

    “Community” languages are awesome for prototyping cool programming concepts (e.g. functional style, asynchronous event-based logic, etc). However, the “corporate” languages have ecosystems better geared toward the types of issues found in the enterprise domain. The corporate side has been very good at copying the community (e.g. Groovy, Scala, etc)… but the community side is less equipped to copy the enterprise stuff, because a lot of those guys don’t have experience dealing with those issues. What Luc suggests here, that you can take a front-end AJAX guy and magically declare him a back-end enterprise guy overnight, is naive to the point of being flatly ridiculous. The programming language may be the same, but the domains are *worlds* apart… and frankly, it’s easier to learn a new language than a new domain.

    Admittedly, many of these issues are mitigated through PaaS hosting such as AppFog. However, I can’t help but point out that “the cloud” was barely even a novelty in the enterprise world, until these providers all started supporting Java. :) The industry and developer momentum that I talked about are just too great.

  • http://twitter.com/boydbischke Boyd Bischke

    I actually think the JavaScript language has a very good chance of breaking into the Enterprise server-side, especially for components of mobile or web applications. Consider that as mobile technologies converge with desktop technologies, it’s likely that most client-side development is going to happen in JavaScript (Web Apps, Appcelerator, PhoneGap, etc). Since client-side development is so Javascript heavy, it would be a natural extension to do mild server-side development in Javascript as well, rather than teaching multiple skill-sets. Also consider that the wave of newcomers are heavily versed in Javascript, perhaps as much as any language.

    As a separate anecdote, I was actually surprised to learn that the server-side portions of IBM Worklight applications are implemented in Javascript.

  • Umer Hasan

    Why wouldnt i like it,,,I LOVE IT

  • http://www.facebook.com/castadena Johnny Phan

    Mr. Perkins hit the nail on the head many times over. I just want to talk about what Node.js is.

    Node.js is a runtime for Javascript, like Adobe Air is for Actionscript, like the JVM for Java. Every language and its runtime go through the same evolution, where they become more mature: optimized, faster, and have more 3rd party packages. Node.js is now just going through the same evolution the JVM had many many years ago. In time, it will be head-to-head with the JVM, possibly outperforms it in specific routines and trails in others. However, to think that node.js will significantly outperform the JVM, and make the choice of technology based on that, is not wise.

    Given comparably fast runtimes, the choice of whether to write your program in Javascript or in Java, really is about programming language rather than performance. A hand-coded ultra-optimized NIO implementation in Node will perform comparably with one in Java, because they both will translate to roughly the same underlying system routines being called. If one significantly under-performs another, just means it’s not ultra-optimized yet.

    In the end, it’s about whether you want loose-typing, closure, and prototype or you want uber-strict OOP. Javascript is surely shorter and easier to write; but the uber-strictness of Java is intentional. Strictness allows you to enforce paradigms and patterns, which is especially important in very large applications. Java has tons of enterprise experience; Javascript has a lot to prove itself.

    In summary, node.js simply allows Javascript to be an alternative to full-fledged programming languages for writing any kind of application, that’s all.

  • http://twitter.com/bousquetn Nicolas Bousquet

    Honestly what you really say is that some companies are starting to use Node.js. This is great. But this just put Node.js as the same level as other hundred technologies out there. And to be more precise, at the level of the least used of theses technologies.

    But hey, haskell, or ocaml have their sucess story too. And you can find as many company working on it. Communities working on clojure or scala to are already bigger.

    Community working on python or ruby are definitely on another level. And don’t try to even compare to Java or .NET… I think that more companies bet on JavaFX than node.js… And JavaFX was dead from the begining.

    Now maybe node.js will make it despite its flows (JS quirks, callback driven spaghetti code, poor echosystem, monothreaded runtime…). But from what we see now, this isn’t quite here yet. And it will not make it a good stack anyway.

Powered by Olark