WHY ENTERPRISES WILL ADOPT NODEJS

I recently gave a presentation to a local meetup group on NodeJS. The group was an eclectic group of technologists from all over Southern California, and many seemed to be from larger, slower-to-adopt companies that rely on Java and .Net for their applications.

They’d heard about NodeJS and were intrigued to learn more. I gave them the overview I’d prepared that put Node in context of a full MEAN stack application, walked through control flow from front to back, and even took them through some example code.

At the end of it all, it became apparent that I hadn’t answered their main question: “Why would we use this?”

Unfortunately, I was asked a very similar question this past weekend when I spoke at SoCal Code Camp — albeit by one who was already a convert — but it was a question that hit the same theme: why would enterprise users want to switch to Node?

This post is intended to address this question and answer it once and for all. I’ll enumerate the concerns I’ve already heard as well as some that I know will come up when considering such a change, then answer each in turn, giving my best reasoning for why and when enterprise should use Node… and when it shouldn’t.

“We already use .Net/Java”

I get it. You’re invested… Microsoft/Oracle is entrenched and people’s careers are built on making sure they stay there. Changing technologies is scary and politically dangerous. To this, I say: don’t. Don’t change out your existing stuff. BUT, consider augmenting it.

Let each tool do what it’s best at doing.

• Java is great at multi-threaded, high-performance calculations.
• Microsoft is great at… working with Microsoft tools.
• Node is great at non-blocking I/O.

So, use each as appropriate.

“Why would I put code in production that some guy in his basement can edit?”

This is the existential question posed by many tech managers who have built their career on proprietary systems and who haven’t yet come to terms with open source. Yes, Node is open source, and yes, technically, anyone can edit the source. However, to this I have many things to say:

Why were you putting so much faith in closed systems in the first place?

• Were they bug-free and completely secure? Really?
• Even Microsoft has open sourced .Net
• Everyone in the world can check the validity of the author’s work… including you.
• Even if you don’t trust “some guy in his basement”… how about these guys? IBM, Intel, Google, Microsoft, SAP, and Redhat. All of these are members of the NodeJS Foundation.

“Finding developers for new technologies is hard and expensive”

True. Node isn’t simple to master, but at the end of the day, it’s still JavaScript and JavaScript is one of the most broadly used languages on the planet.

If you already have good front-end JavaScript developers who are interested in expanding their skill set and good back-end developers who know how to build RESTful APIs, why not send them over to NodeSchool, then put them in a room to see what they can whip up in Node?

What’s the worst that could happen? We take this approach at AktaryTech: we do hire seasoned Node experts for our most senior positions, but most of our developers are home-grown JavaScript coders who we train in the ways of Node… and yes, NodeSchool is an integral part of that curriculum.

Note also that the more involved in the community you get, the easier it is to find the developers you seek. AktaryTech sponsors two meetup groups, SoCal NodeJS and SoCal full stack developers [https://www.meetup.com/SoCal-Full-Stack-JS/] and both have been fantastic resources to help us find developers.

“No one ever got fired for buying IBM. I might get fired for trying Node.”

This is an understandable concern… but considering Apple, IBM, BMW, Capital One, Best Buy, AOL, Box, Cisco, Amazon, GM, GE, Goldman Sachs, HP, Comcast, and many, many more have taken the NodeJS plunge, you’re not alone… and you’re in pretty good company.

Another consideration is that just because you’re introducing a new technology to your ecosystem doesn’t mean you should forget good engineering practices. Most large enterprises have an evaluation process for doing these things, but if you’re in a company that doesn’t, just start small and go slowly.

Begin with a proof of concept in an isolated network on an application that isn’t mission-critical… but make sure to emulate your production processes as closely as possible.

• Consider how your new Node app will fit into your existing development, source control, build, testing, deployment, and other workflows.
• How will network security be affected if your Node app is consuming 3rd party APIs?
• Can you use existing logging solutions or should you roll a new one?
• How are you going to monitor the health of your Node app?

The more you can ask and answer these questions in an isolated proof-of-concept environment, the more secure you can feel about your job (although, if that’s really a concern, maybe you should reconsider your choice of employer).

“I need high-performance calculations and Node is only for I/O”

While it’s true that Node’s core strength is I/O, it’s not necessarily true that if you have a calculation-intensive application that Node can’t be part of the solution. Many newcomers to Node aren’t aware of the fact that it’s built on top of the V8 JavaScript engine, which is written in C++. Because of this, you can build add-on Node modules in C++ that will give you very high performance calculations without sacrificing the beauty of Node’s inherent I/O strengths.

Imagine the Future…

I think I’ve covered most of the objections I’ve heard so far. If you have other concerns about adopting Node, feel free to post your comment below. Only by getting past these misconceptions can we move forward to what promises to be a very exciting future for enterprise technology.

I envision a world where enterprise IT managers no longer feel beholden to paying ridiculously large licensing fees to entrenched software players that take advantage of their incumbency at every turn.

I picture a future where enterprises spin up and consume NodeJS microservices as they’re needed, no longer living in fear that the next big exploit will cripple them because a closed source vendor was an enormous, alluring target in the marketplace.

I think the time has come to stop worrying about “but what if?” and start embracing “and what if?”