Azure App Service – Orchestrating business processes


When it comes to Azure App Service, I haven’t followed what was going on to be 100% honest. Based on the first details released in March, it sounded like a cloud-based version of Visual Studio LightSwitch. Able to manage different types of Azure abstractions by click-building and publishing applications into Azure. However, this isn’t the case.


NOTE: I have only played around with the Azure App Service and this for just only a couple of hours. I’m still new to the offering and trying to see where it fits within the Azure eco-space.

Azure App Services

Probably the most important thing to notice is that Azure App Service will allow you to host different types of related offerings within a single hosting container. For example, you are able to combine an Azure Web Application and a Mobile Services Application and therefore able to save some costs.

Previously build Web Applications now support a Web App hosting plan which should take care of the billing and grouping logic, however, have to say that this is somewhat unclear. You will have to start with a Web Application, and afterward, you will able to add a Mobile Services App into the same Web Application Hosting plan. Besides, how this affects scaling out options isn’t clear either. PS. When opening the auto scale Blade, I run into the following error.

Unable to locate blade 'Autoscale' in extension definition. Search path:'[0]WebsitesExtension-[1]Autoscale'.


To my understanding, it’s also possible to host several API Apps within the same hosting container/plan. This is needed because Azure Logical Apps will only shine when it’s possible to communicate with numerous Azure API Apps. Requiring a separate container for every API App would end up very costly, or companies are consolidating many API’s within one mega API service. Not something I’m looking forward to build, deploy and monitor. At this point, you might have been wondering; what are API and Logical Apps? Well, keep on reading!

New Azure Services

As briefly mentioned above, Azure App Service also introduces two new Services called API App and Logic APP. I will cover some of the details within the sections below.

Azure API App

The API App is, as the name is stating, an application exposing a custom build API. However, it contains a bit of additional metadata allowing other services to consume them readily. By default Azure Logic Apps understand this format, and by using Visual Studio (having the latest Azure SDK installed), it’s possible to generate clients as well instead of using System.Net.Http.HTTPclient

An API App can be written in any of the Azure supported languages, and the platform is taking responsibility for some of the ugly plumbing, including versioning, authentication (including OAuth), and access restrictions. Azure App Services currently supports the following access levels:

  • Available to Anyone
  • Public Authenticated Access (Azure AD etc.)
  • Available only to other API’s in the Resource Group


Existing Web API Apps can be easily “upgraded” given that only a metadata file called apiapp.json, written within the Swagger specs, needs to be provided. More information about Swagger can be found right here


Azure Logic App

The Logic APP can be used to orchestrate (log running) business processes and introduces a new section within the administration portal for Workflow orchestration. By default Azure includes helpful building blocks allowing connectivity with or over BizTalk, Salesforce, DropBox, Office 365 FTP, HTTP SQL Server, and of course Azure API Apps. In addition, 3 th party vendors will be able to publish new “Logic” within the Marketplace or you could use your own logic by consuming a custom API App as covered above.

To be honest I’m a bit skeptical when I see HTTP and SQL Server building blocks because we all know that those will be abused by the lazy people among us. Yes, those who like building Rube Goldberg routines and leave the company/division… I would recommend staying away from “do it all” type of connectors / Logic building blocks. The only cases I can imagine them being useful is when dealing with legacy application. It might not be worthy or even possible to alter an existing app and therefore using a SQL server block to gather data and follow-up logic might be helpful.


A Logic App can make use of a reoccurring logic block or started manually. What’s great is that you will be able to see the execution details for every run within the portal, somewhat similar as with Azure Automation. This also includes all “Logic”/building block steps as well as the input and output data used in each step.

What’s also good to know is that in case of a technical failure, the process will be able to resume from the last saved step including all data gathered along the way. Now if you are dealing with services that maintain state, you might want to make sure to have some error logic in place.


I personally believe that Azure Logic App will allow us (Developers and DevOps teams) to get rid of the non-interesting plumbing if implemented correctly. The Azure API App should be designed as a self-contained microservice, ignoring the generic Logic building blocks with the exception of legacy applications.

Apart from business logic, it also possible to orchestrate interesting processes responsible to very specific application monitoring purposes. This would have been rather expensive when using separate offerings for exposing management APIs, Dashboards, Long running processes, and the like.

Azure App Service announcement

Post Navigation