A common scenario for many web applications running in the cloud is to integrate with existing systems through web services (no matter the messaging style they use). Although in these scenarios, an SLA is typically used as an agreement between the two parties to assure certain level of availability, many things can still fail. Therefore, it is always a good idea to have a mechanism in place to handle any possible error condition and retry the execution when it is possible.

Moving to the cloud can represent a big challenge for many organizations when it comes to reusing existing infrastructure. For applications that drive existing business processes in the organization, reusing IT assets like active directory represent good part of that challenge. For example, a new web mobile application that sales representatives can use for interacting with an existing CRM system in the organization.

In case you are developing a new web application with Node.js for Windows Azure, you might notice there is no easy way to debug the application unless you are developing in an integrated IDE like Cloud9. For those that develop applications locally using a text editor (or WebMatrix) and Windows Azure Powershell for Node.js, it requires some steps not documented anywhere for the moment.

Faye is a simple Http Pub/Sub server initially implemented by John Coglan in Ruby, and also later ported by himself to Node.js. The version for Node.js implements the Bayeux protocol, which at first glace, many of us known as http long polling.

Deployment is considered today as one of the major pain points in the Windows Azure platform. A simple application deployment today can take around 20 or 30 minutes to complete, and to make the things even worse, there is not support for partial updates meaning that a simple change requires a complete upgrade or deployment. The Windows Azure team has recently introduced the support for web deploy in the platform to deal with this issue. Using Web Deploy, you can deploy a complete application or part of it in an existing web role instance in a matter of seconds, which is a huge improvement to what we had so far.

Moving your application to the cloud might not be easy as it sounds. The typical sample we always see in documentation or demos about an ASP.NET application created from the Visual Studio template and deploy it in Azure as a package is definitely very far from reality. There are multiple factors that can affect the response time and availability of your applications in the cloud but you can not easily see until you embark on a real project. Application distribution and deployment is one of those factors, and the one we are going to discuss in this post.

A hosted service in azure is typically assigned with two public addresses, one for the production environment with a DNS name ending in cloudapp.net such as [your name].cloudapp.net and an auto generated DNS name for the staging environment such as 4969aae4e18f4699aa88223e1e73ba8e.cloudapp.net. There are multiple reasons you might want to map your custom domain name to these public names in Azure, but these are the most common ones I can imagine,

Publish/Subscribe in the cloud has became relatively important lately as an integration pattern for business to business scenarios between organizations. The major benefit of using a service hosted in the cloud as intermediary is that publishers and subscribers don’t need to be publicly addressable, be in the same network or be able to talk each other directly. The cloud infrastructure allows this intermediary service to scale correctly as the number of publishers or subscribers increase, and also to act as a firewall for brokering the communication (Publishers or subscribers need explicit permissions to connect, send or receive messages from the intermediary service).