Top Benefits of Running Node.js on Windows Azure
Introduction
This post is inspired by Tomasz’s Hosting Node Applications on IIS write up that focused on the benefits of running Node.js on Windows server through iisnode. In this post, I wanted to focus on giving it a Windows Azure color and list the benefits of running Node.js on Microsoft cloud platform. Some of the benefits are unique to Widows Azure while the others are applicable to both on-premise Windows as well as Windows Azure. This post is targeted towards Node.js developers who are not familiar with running node programs on Windows Azure. Fundamentals of Node.js development on Windows Azure can be learnt from https://www.windowsazure.com/en-us/develop/nodejs/.
Node.JS Deployment Architecture on Windows Azure and Kernel Mode HTTP Request Buffering
Iisnode is the enabling component that wires up http.sys (the kernel mode HTTP listener) on Windows with the collection of Node.exe processes through named pipes. At run time, Windows Azure Web Role gets translated to a Windows Server instance and hence it uses the same iisnode for enabling the automated running of Node applications on Windows Azure.
When a Node.js web site receives request for a web page, iisnode will spawn a Node.exe process if not already done and will forward the http request through a named pipe. Node.exe will process the corresponding JavaScript file and sends response back to the web browser through iisnode and http.sys. When the request arrives into the Azure service instance, http.sys pools them in a kernel mode request buffer before forwarding them to the node.exe instance.
Since node.js itself doesn’t do any buffering, http.sys request buffering architecture will help with fewer server errors on high traffic web sites. The following schematic shows the request processing architecture of Node.js with http.sys buffering.
The above diagram is an amalgamation of the static and dynamic architecture views that may confuse some; hopefully it conveys the essence of Node.js request processing flow.
Iisnode is very specific to Windows and Windows Azure which combines the benefits of cluster, supervisor, node-inspector, forever, and node-static [source: Tomasz Janczuk’s blog]. Iisnode helps setting up of scale-up and scale-out scenarios a lot easier on Windows compared to non-Windows platforms.
Node.JS Scalability on Windows Azure
Scale-Up: Iisnode on Windows Azure spawns multiple Node.exe processes on high traffic web sites automatically. This allows Node.JS to take advantage of the multiple cores in a web role which can range from 1 core (small instance) up to 8 cores (Extra Large instance) allowing scale up of the web application in a given service instance. The following diagram shows that Iisnode spawned 4 Node.exe instances on a 4-core Windows Azure service instance:
Without iisnode on Azure, one has to use a Node module like “cluster” and write code to fork child processes and manage the master/worker ecosystem. However “master” process can be a single point of failure; if master goes down, eventually a manual intervention will be necessary to bring up the master process and the worker processes back to the level that match the number of cores.
Iisnode on Azure manages the Node worker processes based on the instance count set in the Node configuration file. Iisnode itself is managed by IIS which in turn is looked after by Windows OS. Consequently there will be fewer opportunities for a systematic failure of Node.js processing. Essentially, with iisnode, you don’t need a mater process and you don’t need to write code to fork and manage child processes.
Scale-Out: Windows Azure allows Node.js web applications to scale out automatically to a web farm of 100s of Azure service instances as needed. This can be accomplished through mere service configuration edits as shown below:
<?xml version="1.0" encoding="utf-16"?>
<ServiceConfiguration>
<Role name="Node_JS_WebRole">
<Instances count="4" />
<Certificates />
</Role>
</ServiceConfiguration>
Once the above configuration changes are saved on Azure.com portal for a Node application, Azure fabric controller automatically spawns service instances so that the final count matches the number specified in the configuration. Windows Azure also gives Service Management APIs for scripting autoscale aspects into the deployment.
Above diagram shows that each Large web role instance (4 cores) spans 4 instances of Node.exe and there are 4 such role instances which are automatically added to the load balancer by Windows Azure Fabric Controller. Within a given Azure role instance, Http traffic to Node.exe process collection is managed by iisnode through load balancing.
Development Agility with Managed Services
Develop NoSQL based Node.js solutions with ease
Windows Azure offers Azure Tables – NoSQL database as a service. Since Azure Table capability is a managed service, the developer doesn’t have to worry about physical set up of the NoSQL database with respective to availability, scalability, networking, backup and recovery. Developer can become productive right away with JavaScript bindings available as a part of the Azure NPM for persistence operations against Azure Tables. The following is the excerpt of an example of accessing Azure Tables in Node.JS from Programming Table Storage Service in Node.Js:
var tableService = azure.createTableService();
var tableName = 'tasktable';
http.createServer(function serverCreated(req, res) {
tableService.createTableIfNotExists(tableName, tableCreatedOrExists);
function tableCreatedOrExists(error)
{
res.writeHead(200, { 'Content-Type': 'text/plain' });
if (error === null){
res.write('Using table ' + tableName + '\r\n');
res.end();
} else {
res.end('Could not use table: ' + error.Code);
}
}
}).listen(port);
Develop distributed Node.JS cloud solutions with ease on Windows Azure
Windows Azure NPM contains Node.js bindings for building message oriented applications using Service Bus queues. Since Service Bus is a managed service, the developers need not worry about the infrastructure setup, clustering, and any other networking related configurations. Developers simply need to create service bus name space and start using the service for integrating with other applications and services in a loosely coupled manner.
Node.JS developers often struggle with libraries like ZeroMQ for the types of integration shown above. Service Bus and Azure Queue storage can free developers from client side development complexity as well as server side infrastructure management.
Following is the code sample: [source: Service Bus support in azure npm 0.5.2 ]
var serviceBusService = azure.createServiceBusService();
serviceBusService.createQueueIfNotExists('taskqueue', function(error, created){
if(!created){
// Queue exists
}
});
Here is how you send a message with a specific topic [source: https://codebetter.com/glennblock/2012/02/14/servicebus-support-in-azure-npm-0-5-2/ ]
var serviceBusService = azure.createServiceBusService();
serviceBusService.sendTopicMessage('taskdiscussion', 'Hello world!', function(error){
if(!error){
// Message sent
}
});
And finally this is how you poll the queue for a message.
var serviceBusService = azure.createServiceBusService(),
topic = 'taskdiscussion',
subscription = 'client1';
serviceBusService.createSubscription(topic, subscription, function(error1){
if(!error1){
// Subscription created
serviceBusService.receiveSubscriptionMessage(topic, subscription,
function(error2, serverMessage){
if(!error2){
// Process message
}
});
}
});
Supports Heterogeneous Application Environments
Node.JS on Windows Azure can run side-by-side along with ASP.NET, PHP, RAILS and any other app server environments the programmer wishes to use for delivering a complete applciation. Iisnode will be in the execution path for only preconfigured .js files. The rest of the content will bypass iisnode and hence can peacefully coexist on the same virtual server. Let us illustrate this through a simple example… in a given virtual directory, I have webform.aspx, clientutil.js and productservice.js.
The following simple web.config will make sure productservice.js will be processed by Node.exe while webform.aspx is processed through asp.net engine on the server. ClientUtil.js will be treated by IIS as a client-side Javascript and hence passes it through as a script file.
//web.config file that maps .js files to node.exe
<configuration>
<system.webServer>
<handlers>
<add name="iisnode" path="productservice.js" verb="*" modules="iisnode" />
</handlers>
</system.webServer>
</configuration>
Management & Operations
Multiple Node.JS Environments
Windows Azure automatically supports a pair of environments for each Azure service instance that hosts Node.js application – Staging and Production. After deploying and testing the Node application on a Staging environment, a mere VIP (virtual IP) address swap will make it available in production environment. Of course, one has to make sure that any dependencies like databases also switch to production environments before such VIP swap.
Many real world applications require more than two environments; Azure enables one to create multiple Azure service instances and move deployment from one environment to the other as necessary. Here is the schematic that gives an idea of a typical Node.js deployment environment on Azure:
Windows Azure allows the creation of multiple services instances that represent a typical ALM environment. In the above diagram, there are 3 service instances defined in Azure. Each service instance will have a staging and a production environment between which one can switch the deployments by the flick of a switch. Among many cloud platforms this is unique to Windows Azure; this set up allows unrolling a build that has regression errors through mere IP address swap. Multiple service instances allow the developer to sandbox the application dependencies so that it allows streamlined configuration management.
Auto Update
Iisnode on Azure automatically manages Node.exe process lifecycle during the code updates. If a JavaScript module is changed, iisnode allows the current requests to be served from the existing Node.exe instances while it redirects new requests to a newly spawned Node.exe process. The old processes will eventually be killed when there are no more in-flight requests.
Without iisnode, one has to use Node module like supervisor that monitors a list of .js files. If a jsavascript file were to change, supervisor kills the current process and restarts it for executing the changed code. To get the same behavior as Windows Azure’s automatic process management with iisnode, a combination of “cluster” and “supervisor” are needed. Cluster and supervisor create two extra processes for traffic management and file change monitoring, which adds additional points of failure.
Supportability
Remote server debugging often involves console.log writing to the stdout and/or stderr. Iisnode on azure redirects these logs to a file which can be accessed as regular text files. This can be enabled through mere configuration; iisnode creates a special directory for each .js file and can obfuscate files to hide them from prying eyes. Securing log files through traditional internet security is a key for preventing unauthorized access of these log files. No additional NPM modules are needed for log access over http.
Node.js log file access on other operating systems, will require additional NPM modules like log.io to facilitate easy log file access when you don’t have access to the server through remote desktop or SSH.
Zero Setup Debugging through node-inspector
Debugging JavaScript applications requires manual startup of the node-inspector process before debugging the application logic on non-Windows OS. On Windows Azure and Windows OS, installation of iisnode automatically installs node-inspector. Accessing the debug moniker (e.g. https://<dnsname>/server.js/debug) for a given .js file will automatically start node-inspector debug listener which allows setting up breakpoints inside the WebKit enabled web browser.
Once debug session is prepared this way, subsequent application debugging can start by accessing the respective .js file in a different browser window. As mentioned above, Windows Azure debugging through node-inspector can be done in any webkit enabled web browser including Google Chrome and FireFox. Step-by-step guide to debugging Node.js applications on Windows, which is similar to Windows Azure, can be found at: https://tomasz.janczuk.org/2011/11/debug-nodejs-applications-on-windows.html.
I hope this helps.
-Hanu
Technorati Tags: node.js,node.exe,Node.js on Windows Azure,Azure NPM for Node.js,Microsoft Cloud,Node.js and Table Storage,Node.js and Service Bus
Comments
Anonymous
May 09, 2012
Thank you, Hanu for the write-up. The comination of IIS and Node.js provides great benefits with with regards to enabling scalability. Hosting Node.js apps in Azure makes it really easy to develop and host Node applications.Anonymous
October 29, 2014
Great article. Can you point me to some documentation on how to configure a node.js Azure Website to support Scale-Up. You mentioned Iisnode on Windows Azure can spawn multiple Node.exe processes. Where do you configure the number of allowed instances?Anonymous
November 21, 2014
This seems so very complicated to me! Is it really necessary to use Azure when you can use https://www.apponfly.com/en/ ??