Azure Webjobs

During the past Dutch Microsoft Techdays 2014 I did a session about Azure Cloud Services. A recording (in Dutch) can be found on Channel 9. In the beginning of Azure, Cloud services were the “way to go”.

Cloud Services is a very powerful concept, but it had some small cons. Existing applications could not moved to the Cloud via a Lift and Shift method. Mostly because the application wasn’t well designed itself. Most applications were not pure stateless, a-synchronic in base and most applications were not able to run in concurrent identical instances.

In the past years the Azure platform has become much richer with lots of different services. In stead of making something new or copying something from others, Microsoft takes existing products or tools makes it available/better suitable for Azure (like Hadoop, Docker, etc).

Also IT development itself became more mature. Developers and architects realize that Scale up doesn’t support availability, services/servers will break down and an internet application has the potency of a big audience.

Standard dogma’s like SOA architecture, Servicebusses or SOAP webservices are losing their power, Microservices looks more promising and are getting better tooling. About this I will blog in the near future.

Back to my Techdays demo. It looked something like this:

The solution looked like this. The code can be downloaded or ask me. As said I exists of a WebRole and a WorkerRole. The WebRole is used for uploading and viewing the pictures.

The flow of the application looked like this.

As you see besides uploading the WebRole has to add a message to a queue for the WorkerRole. The WorkerRole needed a mechanism to read the queue. Like I told in my session, you have to handle the Busy waiting problem. Reading from the queue is a transaction and a transaction costs money. An important part of the architecture on Azure is Cost Based design. So reading from for example a queue has to be efficient and effective with costs in mind.

Nowadays on Azure there is the possibility of Webjobs. With these webjobs it is possible to let it be triggered after a new blob is added to your storage. In my case this reduced the usage of a message on a queue and a own check on the queue in the WorkerRole. This part (checking new blobs on storage) is handled and controlled by the platform. And what I don’t have to do, save time and the platform can do this much more efficient. So the WorkerRole can be released by a Webjob. The WebRole can be replaced by an Azure Website. Did I need special skills for the WebRole, like reading the configuration settings. With an Azure Website I can use the technical skills I always used. And about the settings you can read about it in my previous blogpost.

The process looks like this.

After a little redesign the website looks like.

The code of the Webjob is only this, some 55 lines of code.

The WorkerRole used double lines of code, of which the most was used for processing and not the real deal.

As I always tell during presentations, we can focus on the functionality and the real work, the rest is done by the Azure platform.

Ok, now the part of the web Client to get a message of the queue to see the job is done should be done otherwise.

NB In this blogpost I am not telling Cloud Services are useless. In the scenario above the extended possibilities of Cloud Services are not necessary. Look at this page for a detailed comparision.