Node.js and PaaS: Changing the Development & Operations World

Node.js can provide parsing, processing, and hosting of JavaScript and hypermedia content in a number of ways. Node.js behaves in a very different way than other web servers. Apache, IIS, NGINX, and related web servers all have tons of options around configuration, static and dynamic pages, processing content, and security features. This makes these servers vastly more complex, but with their longevity have come lots of how-to’s, documentation, and tooling around their setups. Node.js is vastly more simple and straight forward than these other servers. But even with the simplicity the how-to’s, documentation, or tooling around the Node.js server isn’t always easily found.

This makes Node.js hosting a little confusing, at least when doing it yourself. There are several key issues:

*Node.js needs to run under an service or related account to ensure a secure and stable execution on a server. This means Node.js can’t use ports below 1024, but it generally needs to run on port 80 for standard HTTP hosting.

* Node.js can be run as root to give it the ability to directly communicate on port 80, but that leaves security concerns and stability issues.

*If the Node.js thread crashes it needs restarted. There isn’t a resilience or self-healing nature to Node.js. It needs helper tooling to be able to recover.

There are a number of ways to resolve these issues and get Node.js up and running. These solutions include:

Providing a redirection via the iptables is pretty simple and becoming one of the common ways to host Node.js via port 80. Issue the following command to redirect the traffic for the server. This is one of the most direct methods of allowing Node.js to provide on responses to traffic without loading the instance up with other servers such as Apache or NGINX. In some situations, this is ideal since Node.js is generally an extremely low overhead server and can be put on a very small instance.

iptables -t nat -A PREROUTING -p top --dport 80 -j REDIRECT --to 8080

The other way to get Node.js up and running is to use a proxy via Apache or NGINX to direct traffic accordingly. This requires more overhead on the server but also provides more functionality and configuration based on how hosting will be done. Sometimes this is exactly what is needed and sometimes it’s overkill. Check out these entries for more information regarding routing via NGINX and Apache:

* Provide a mapping via iptables. What are these things?
* Another idea is to run two IPs, port forwarding appropriately between servers.
* Nodejitsu’s Node HTTP Proxy

But really, most of these solutions leave us right back where we are with the other frameworks. We have a server to maintain, infrastructure to deal with to manage the IPs, the routing, and other concerns. Overall, this doesn’t advance us beyond running a traditional Rails, Sinatra, .NET, PHP, or Java application.

Node.js is a Technology for Fast Development

Node.js is super easy to use, easy to install, and develop against in a dev environment. If your’e using Cloud 9 IDE, Visual Studio, JetBrains WebStorm or TextMate doing development is very straight forward. Node.js provides what is probably the simplest path from nothing to development of any technology stacks and frameworks in existence. With that in mind, it is kind of frustrating needing to play around with all these hosting options, configurations and other issues. Ideally, we’d just be able to deploy our Node.js code and whatever else and have it run. Fortunately there are solutions available in PaaS offerings. With this combination Node.js development goes from really fast, and cumbersome to deploy to really fast and easy to deploy.

A Real Solution for Building Node.js Applications

The real solution is running this on a PaaS which us beyond the infrastructure and to a clean platform. The PaaS provides just this abstraction. Utilizing a PaaS instead of direct infrastructure moves us beyond the traditional hosting issues and concerns and into a much faster deployment cycle all with lower overhead. Let’s take a look at a one of these options right now. (I’ll step through some of the others in a subsequent post.)

Cloud Foundry (see my previous posts for more information) is an open source software solution for building a PaaS. You can run it locally with a Micro Cloud Foundry instance for development and you can then deploy to a number of available service providers including;

To get running on Cloud Foundry first get an account setup (at one of these sites listed above) and install the appropriate vmc command line interface. For some, like AppFog they have a custom command line, but fear not all the functionality is there. At this point, with Node.js installed, the vmc client installed, we’re ready to deploy.

Create a Node.js application and navigate to the directory in which the application is located. After that, target the Cloud Foundry Environment and then push. The following is an example of the commands for deployment.

$ vmc target api.cloudfoundry.com
$ vmc login
$ vmc push

With that anyone can see how absurdly simple deployment is with a PaaS solution. This removes all of the overhead of managing servers, deploying Node.js to the server, administering NGINX or Apache, and all the appropriate iptables and related routing. We’ve just stepped from “oh dear we have lots to configure” to “we can get back to adding business value again!”

Node.js + PaaS = Huge Win Win

In subsequent entries we’ll dive into some of the other services and discuss the differences between each of the providers and what their currently aiming for. In addition, we’ll dive into the massive open source and huge community support that Node.js is receiving right now.