Cloud Zone is brought to you in partnership with:

Technical Architect, experienced in leading tech professionals, Technical Evangelist, Technology Strategist and Technology Consultant at Microsoft Hanu is a DZone MVB and is not an employee of DZone and has posted 7 posts at DZone. You can read more from them at their website. View Full User Profile

The Top Benefits of Running Node.js on Windows Azure

08.13.2012
| 6063 views |
  • submit to reddit

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 a 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 the Microsoft cloud platform. Some of the benefits are unique to Windows 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 learned from http://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 a request for a web page, iisnode will spawn a Node.exe process. If that's not already done it will forward the http request through a named pipe. Node.exe will process the corresponding JavaScript file and send the response back to the web browser through iisnode and http.sys. When the request arrives into the Azure service instance, http.sys will pool 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.

image

The above diagram is an amalgamation of the static and dynamic architecture views that may confuse some; hopefully it conveys the essence of the Node.js request-processing flow.

Iisnode is very specific to Windows and Windows Azure. It combines the benefits of cluster, supervisor, node-inspector, forever, and node-static [source: Tomasz Janczuk’s blog]. Iisnode makes configuration of scale-up and scale-out scenarios 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:

image

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 the master process and the worker processes 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 hundreds 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 the 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.

image

The above diagram shows that each large web role instance (4 cores) spans 4 instances of Node.exe and 4 such role instances 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 a physical set up of the NoSQL database with respective to availability, scalability, networking, backup and recovery. Developesr 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 a service bus name space and start using the service for integration with other applications and services in a loosely coupled manner.

image

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: http://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 application. 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 moves 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:

image

Windows Azure allows the creation of multiple service 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 a mere IP address swap. Multiple service instances allows 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 a Node module like supervisor that monitors a list of .js files. If a JavaScript file were to change, the 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 that 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 a manual startup of the node-inspector process before debugging the application logic on a non-Windows OS. On Windows Azure and Windows OS, installation of iisnode automatically installs node-inspector. Accessing the debug moniker (e.g. http://<dnsname>/server.js/debug) for a given .js file will automatically start the node-inspector debug listener, which allows setting up breakpoints inside the WebKit-enabled web browser.

Once a 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 a node-inspector can be done in any webkit-enabled web browser including Google Chrome and FireFox. A step-by-step guide to debugging Node.js applications on Windows can be found at: http://tomasz.janczuk.org/2011/11/debug-nodejs-applications-on-windows.html.

Published at DZone with permission of Hanu Kommalapati, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)