Rapid application development on Microsoft Azure

At NearForm we have done a lot of cloud deployments — Amazon Web Services, Google Cloud, and Red Hat OpenShift . Of late we have done more and more work on Microsoft Azure as well. In this series of 4 articles, we will show how easy it is to provision a Node.js application in Azure, with a focus on rapid application development.

We have chosen to focus on rapid application development, as it is critical to innovation. Innovation is a requirement for modern enterprise to survive and flourish. While inspiration is required for innovation. It is rapid application development, combined with lean methods, that allows inspiration to be iterated into a working product. Our litmus test is to deploy a simple ‘tow tier’ Node.js application (REST API built using Hapi , TypeScript , and PostgreSQL for the data store) to Azure.

We choose Hapi and PostgreSQL because these are solid proven technologies, which we use in the majority of our platform solutions.

We added TypeScript, because static type checking makes catching obscure bugs easier. It also speeds up the development cycle, e.g., if you integrate TypeScript with your editor it will catch argument mistakes as you type.

This Node.js application will run on the Web App platform in the Microsoft Azure cloud.We have chosen Azure Web App, because it can be setup to auto scale up and out . Azure also provides Postgres-as-a-Service which delivers high-availability without extra configuration, replication, or costs, and can be scaled without down time.

The glaring omission in the above architecture drawing is a load balancer. That is because is the load balancer does not need to be explicitly provisioned, as it is done as part of the Web App provisioning, and need never be administered.

All Microsoft online products works with one universal login per user. Your company administrator responsible for Microsoft can create a login for you. For those of you who want to just try out Azure, you can sign up as an individual at https://signup.live.com/signup .

We will be using the command line interface (CLI) as it allows us to easily script the infrastructure. Your provisioning script for this rapid prototype will come in very handy when deploying subsequent infrastructures for rapid application development.

The CLI is on version 2.0, works on macOS, Linux and Windows. Installation is very straightforward.

You can interactively login using az login, or stay in the command line using az login -u -p (with your Microsoft username and password).

Azure’s Web App looks like the simplest deployment option. The Azure team takes care of updating and hardening the server. When deploying to a Web App it uses the package.json information to build the application. Environment variables can be set, enabling Twelve-Factor App (12FA) style development. The Web App can also easily be scaled. High availability is as simple as provisioning at least 2 instances of our Web App.

There needs to be a single user created for all your company’s Web App deployments:

This needs only to be done once. You would need to share this username and password with your team members.

A resource group is a logical container into which resources like Web Apps, databases, and storage accounts are deployed and managed. Tip: Find a location near your clients with az appservice list-locations. If we create a group thus

we get a response back

I really love this about the Azure CLI – the default response to successful commands are json objects containing the successful information. This makes (bash) scripting very powerful. Since the cli is still maturing though, it is important to verify, using the return object, whether the command was completed as requested. E.g., on certain commands some flags on the cli can fail quietly, i.e., it returns a json object since it was successful, but certain flags were ignored.

Your group needs a service plan to provision the physical resources you need.

We created a free plan to be able to play around:

To create a Linux plan you need to add a --is-linux flag and upgrade your sku to at least Basic1 (B1).

For this post we won’t proceed with Linux, because when I deployed to the Web App (as below), I got a You don't have permission to access / on this server. error. However, Azure reported my app was working properly but I was unable to access any useful log information.

Luckily, the Node.js core team and partners have invested a lot of effort to ensure that Node.js works well on Windows. However, your mileage may vary based on the specific packages you use.

An empty server is easy to create

The only tricky bit being the name has to be unique, since it will be accessed as, e.g., https://ath.azurewebsites.net/ .

A simple example of Hapi app written in TypeScript (the basic branch) can be cloned from here . To link your locally cloned git repository to the Web App we use

If you are writing your own app, you would need to use the response from the above command to create a git remote target git remote add azure https://@ath.scm.azurewebsites.net/ath.git .

Now getting your Web App up and running should be as simple as

However, despite what appears to be a successful push, when you go to your equivalent of https://ath.azurewebsites.net/ you will encounter this (unhelpful) error message: The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

Trying to resolve this error brought me my first headaches:

Tip: logging is disabled by default. Enable it using az webapp log config -n ath -g winGroup --web-server-logging filesystem --application-logging true --level error. It turns out IISNode needs the (TypeScript) transpiling target to already exist. I.e., change your .gitignore to not ignore your build target. I stumbled across this solution when I ignored the Deployment successful. message, and looked through the details of the deployment trace and found:

Run psql postgress (assuming you have already installed PostgreSQL), and

Now, lets progress to adding a database. Grab the postgres branch from here . To test the code running locally run curl localhost:1337/tasks and it should return an empty array [] .

Provision a postgres server on Azure with

Tip: Pick an database passwords that do not include special bash characters, e.g., !, since it will complicate your ability to set that password via environment variables from the cli. Ideally the postgres server setup and update should be done via code run as part of npm run start , but to get started we will do this using psql . First we need to allow remote access:

Remember to revoke this rule later. As exposing your database to the internet is not a good security practice.

To setup the remote server rerun the SQL commands using:

If you log in to https://portal.azure.com you should see:

We can connect to our Azure postgres instance from the local machine:

This step isn’t strictly necessary, but it is a minimal change which allows us to check whether our postgres server was provisioned correctly.

Next we want to set these environment variables on our Web App, and deploy the new code:

In Azure under your Web App you should see:

Which passes the test by returning [] from curl https://ath.azurewebsites.net/tasks .

While this is better than storing secrets in Git, it is still poor security practice. In a future article we will demonstrate how to use Azure Key Vault to safeguard cryptographic keys and other secrets used by cloud apps and services.

Sometimes upon when doing a deploy it seems like IISNode does not install all the packages. I.e., it happened more than once that I got Error: Cannot find module 'pg' which resulted in Error - Changes committed to remote repository but deployment to website failed . Once that happens, the only way I found to resolve it, is to delete the Web App instance az webapp delete -n ath -g winGroup , and to re-provision it.

Now we have a Web App up and running which closely mirrors our local dev environment. However, deploying from local git makes no sense, since we are developing as part of a team. So, we will hook up our Web App to listen for changes on our GitHub repository master branch.

To provide Azure with access to the GitHub repository we need to generate a token . With the generated token we can point our Web App to our GitHub repository

Updating the Web App becomes as simple as pushing the cd branch

Tip: Until you have testing setup as part of your deployment pipeline, use pre-commit to ensure your test suite runs before every git commit.

Downtime during deployment can be eliminated using slots .

Slots are only available to standard and premium service plans, so we need to upgrade our plan first

Now we can create a staging slot, point our deployment at it, and auto swap it with production once it is hot

Note auto swap is not available on Linux. Instead you have to do manual swapping.

Since the group forms a lifecycle boundary for everything it contains, cleaning up is as easy as

We have only scratched the surface of what Microsoft Azure can do. But, we have shown that you can get a small Node.js application, including database, up and running for minimal effort and no cost. You can scale this architecture as the importance and requirements of your app grows (you would need to switch to a paying tier though).

The Azure CLI is a pleasure to use, but not without its quirks. E.g., sometimes silently ignoring flags.

Microsoft says it is working hard on making Azure operating system neutral. I look forward Linux Web App no longer being under the beta flag. Till then IISNode appears to work fine. Alternatively, Azure allows the deployment of Linux containers (which we will investigate in a future post).

In our next post in the series will see how to collect the log output from our Web App.