Azure App Service is really 2 services, not 4

Azure App Service is comprised of 4 main Azure Services: Web Apps, Mobile Apps, API Apps, and Logic Apps. Each of these serves a very specific purpose, but they aren’t really as different as their name designations suggest. In fact among the 4 services that make up Azure App Service, there are really only 2 different services with branding around them to make them appear to be 4 completely different services. In this article I’ll explain the details of what I mean and which services are really just the same service wearing a different mask (ahem, icon).

API = Web = Mobile

When you think about the different types of applications to host within Azure App Service, it’s logical to separate them out as API’s, Web Apps, and Mobile Back-ends. Because of this Microsoft has released 3 different Azure services named API Apps, Web Apps, and Mobile Apps. These 3 “different” services aren’t really as different as Microsoft and the Azure documentation would lead you to believe.

Sure each service offers different features, and you can see this listed in the documentation. Here’s a short list of the features of each of these services for clarity:

  • Web Apps
    • Built-in Autoscale
    • Bult-in Load Balancing
    • High-Availability with auto-patching
    • Continuous deployment with Git, TFS, GitHub, and VSTS
  • API Apps
    • Get security support for Azure AD, single sign-on, and OAuth
    • Bring in existing APIs writtn with .NET, PHP, Node.js, Java, or Python
    • Consume APIs on any website with CORS support
    • Use Swagger to generate cross-platform client SDKs in Visual Studio
    • Integrate with API Management, Logic Apps, and many other Azure services
  • Mobile Apps
    • Broadcast push with customer segmentation
    • Enterprise single sign-on with Active Directory
    • Autoscale to support millions of devices
    • Apps can work offline and sync
    • Social integration with Facebook, Twitter, Google

Separated out like the above bullets, these 3 services (Web Apps, API Apps, Mobile Apps) look like very different offerings. However their differences are purely cosmetic within the documentation, Azure Portal, and through the use of their different icon images.


All the features of Web Apps, API Apps, and Mobile Apps are able to be used across all 3 “different” services. Web Apps can use Social Identity Integration, API Apps can Autoscale, Mobile Apps can host APIs that integrate Swagger with code generation capabilities, and so on.

API Apps, Web Apps, and Mobile Apps are really the same Azure service with different masks. The are really just Azure App Service Apps

Logic Apps

Logic Apps are built on the foundation of Azure App Service, but unlike the other 3 it’s really a different service on it’s own due to the zero-code nature of building out workflow automation. While Logic Apps can easily be integrated with Web Apps, API Apps, and Mobile Apps, it has a very different, visual designer experience to building out workflow automation.

With regards to the 4 Azure App Service services (Web Apps, API Apps, Mobile Apps, and Logic Apps) you can keep in mind one of the games played on Sesame Street, “Which on of these is not like the others?” Azure Logic Apps surely stands out on it’s own here.

Why does 2 = 4?

The reason Azure App Service icons, documentation, Azure Portal, etc. show the 3 primary services (Web Apps, API Apps, and Mobile Apps) as different services is really just for marketing purposes. It’s really a difficult sell to say, “Here’s this Azure Apps service that can host web applications, APIs, and mobile back-ends with these billion features included out of the box!” When something’s too big and all encompassing it looks too hard to believe. Additionally, if there’s too many features it can be very cumbersome or daunting to figure out how to build solutions using it.

By breaking out App Service into 4 “different” services (Web Apps, API Apps, Mobile Apps, and Logic Apps), rather than just 2, Microsoft has made the Platform as a Service (PaaS) offerings of Azure much more approachable by Developers, Architects, and Infrastructure Admins.

After all, it’s much easier to say:

  • Websites and Web Applications with a User Interface are hosted using Azure Web Apps
  • Web APIs and their needed functionality are available with Azure API Apps
  • Mobile web service back-ends and what they need can be built using Azure Mobile Apps
  • Business process and workflow automation can be easily implemented using Azure Logic Apps

The next time you use or consider using Azure App Service, think about this and keep in mind what’s really possible. If you have an Azure Web App that exposes an Web API for use within the App and want to expose that out to a new native Mobile App, or integrate it with API Management, remember you can do it without needing to separate out or re-architect your application unless you really need to.

Happy app building!

Big Data and IoT Lambda Architecture

In the realm of Big Data and Internet of Things (IoT) solutions there are concepts of Fast and Slow processing, or Hot and Cold data paths respectively. The architecture pattern derived to handle both of these data paths simultaneously within a software system is know as Lambda Architecture. It’s a rather simple architecture pattern on the surface, but it enables some very powerful data processing in both Big Data and IoT systems. This articles explains the difference between these two data paths and exactly what Lambda Architecture is.

Slow / Cold Path – Batch Processing

The Slow / Cold data path is the usual path data goes through in most software systems. The ingress of data passes to the system and gets persisted to some kind of data store. Once the data is stored it can then be queries and manipulated as necessary.

The processing of Slow / Cold path data in the system is often used for the following purposes:

  • Batch Processing / Analysis
  • Historical Lookup
  • Auditing

Due to the uses of data in the Slow / Cold path it’s common that ALL data in the system is stored, rather than a summary or some other computed version of it. This enables the ability to historically process or report on the data in full. As a result the Slow / Cold data store is typically read-only.

Fast / Hot Path – Real-Time Processing

With thousands, possibly millions, of event messages flowing into the system there needs to be a way to handle the scale of a high volume of data ingress. The Fast / Hot data path provides a means of handling this level of ingress in a way that enables the ability to process and analyze the full set of data in real-time.

The real-time processing of data enabled through the Fast / Hot path is often used for the following purposes:

  • Real-time Analytics / Machine Learning Analysis
  • Real-time Reporting
  • Notifications

With analysis and reporting performed on the Fast / Hot path data, it’s not imperative that the full ingress data stream be saved into storage. The results and predictions of Real-time Analytics and Machine Learning can be saved for later lookup or be used to trigger some other kind of real-time actions to be performed.

Lambda Architecture

Generally it’s not practical to use either Cold or Hot paths for data processing. Many legacy or traditional systems only use a Slow / Cold path approach to data ingress. As a result of only using Cold path, these systems don’t offer the real-time reports or instant feedback and predictions that is often desired by modern enterprises. Also, these “cold” systems usually only offer day-old reports and summaries, at best.

To fill the Real-Time needs of modern Big Data and Internet of Things (IoT) systems, as well as retain the usefulness of the more traditional Cold path uses, Lambda Architecture was derived to handle both Hot and Cold data paths within the same system.


In order to accommodate both Hot and Cold paths, Lambda Architecture needs to employ some kind of Queue or Data Serving Layer that copies and directs ingress data events off to both Hot and Cold data paths.

With Big Data and Internet of Things (IoT) systems generally having a very high volume of data ingress, the full stream of data is directed towards the Data Serving Layer. This layer must implement a component that can scale appropriately to handle the large stream of data. Here’s a list of some of the components that can be implemented within the Data Serving Layer of Lambda Architecture to handle the Queueing of the ingress data stream:

  • Azure Event Hubs
  • Azure IoT Hubs

Implementing a Queue to handle the ingress stream of data is not the only thing that needs to be implemented to fill the requirements of the Data Serving Layer. There also needs to be a Real-Time Stream Processor that can process the ingress data stream in real-time and delegate data off to the Hot and Cold paths as necessary. Here’s a couple options to choose from to handle this real-time stream processing:

  • Azure Stream Analytics
  • Apache Storm

The complete Data Serving Layer can be implemented by utilizing the combination of a Queuing mechanism and Real-Time Stream Processing mechanism together. With layer in place, the data stream can be analyzed in real-time and the data can be delegated off to Hot and Cold paths appropriately.

Asynchronous Data Processing

As you can see the use of the Lambda Architecture is for a distributed style system; not a monolithic application. The data stream flows into the system and data flows to both the Hot and Cold paths simultaneously and is stored, processed, and handled subsequently in an asynchronous fashion.

More Information

If you’re interested in learning more about Big Data, Internet of Things (IoT), or Lambda Architecture in Azure then you want to check out these on-demand, streaming courses:

If an instructor-led class is more what you’re looking for then check out these links as well:

Written by Chris Pietschmann

Routing Network Traffic to Stateful Services in Service Fabric

As you start building applications within service fabric clusters, you should take advantage of the new stateful service options such as stateful services and reliable actors. When you do this, you will notice that none of the project templates for these stateful services are pre-enabled as web servers. Your only choices for web servers are the .NET Core web site template or the stateless Web Api template. If you want a web server project that is also stateful, you might think that you have to build some custom project that can do both, but it turns out that the solution is simpler than that. But to understand the solution, you should first understand the problem. In my opinion, this isn’t easy to discover within the Azure documentation so I’ll lay it out below based on my own experience.

The Problem

When you build an application for a service fabric cluster, you have to define all of the endpoints that the cluster must expose so that your application can receive communication from the outside world. These endpoints can specify a specific protocol and port number so that you know how to connect from a client application, such as a web browser. For the stateless service options, you can specify something normal for a web server like the HTTP protocol and port 80 (or some common derivative like 8080). Once you do that, you can use the address of your cluster plus the app root value of the service and hit an instance of your web server just like you would expect.

But how does this work? For stateless services specifically, it is common to indicate a value of -1 for the instance count which means that every “node” (i.e. VM) of the cluster will have one running instance of the service on it. As I was building and testing applications locally like this, I would be working on some stateless service that hosted a web app of some kind and, once it was running, I could use my localhost address and that service’s name and port to communicate with the application on my cluster. I naturally assumed there was some kind of load-balancing feature of the service fabric platform that was magically routing my traffic across the various nodes on my machine: wrong. By default, the local development cluster is configured to host only a single instance of the stateless service on your machine (the local configuration setting is an instance count of 1, not -1; look in the Local.5Node.xml file to see what I mean). This means that when you type the localhost address plus that service’s port plus that service’s name, it is the only service running on localhost with that address so it will always respond, no load balancing required. However, when you deploy a service fabric cluster to Azure and configure it from the portal, it provisions a separate load balancer for the cluster nodes so that traffic to the service fabric address will be balanced across those nodes as a backend pool. Again, the fabric itself is not doing any load balancing. This only works because there is only ever one instance of the service per cluster node, therefore you can use the same route when connecting to any random node and you will always get that node’s running copy of the service.

Stateful services, on the other hand, do not work this way at all. Unlike a stateless service which can happily assume that it has exclusive rights to a particular service name on a cluster node, stateful services are partitioned across the cluster in such a way that it is very likely that more than one instance of the same stateful service is running on every cluster node. For example, if I have a cluster of 5 nodes and a stateful service with 25 partitions, I can expect that each of those 5 nodes is running about 5 instances of that same stateful service and each of those is going to have a unique route within the fabric. In other words, that stateful service has 25 unique routes, and those routes are probably randomized with Guids. Not only that, but I don’t have any external way of knowing which nodes are hosting which partitions so I can’t just give them fixed names and manually load balance them. The only system that knows all of those addresses and which nodes are hosting them is the fabric runtime itself.

The solution

So how can you route external traffic to the various partitions of a stateful service at all, not to mention in a load-balanced manner? The simplest solution is to use a stateless service as a proxy to that stateful service. The stateless service has a common route and can be easily load balanced across a cluster so communicating with it is easy and consistent. Additionally, since that stateless service is running within the cluster, it has access to the fabric runtime and can ask the fabric services for the current addresses of the various partitions of the stateful service. In order to load balance traffic across the partitions, you need to generate an even distribution of partition keys and you can either do this through some random number generator (i.e. new Random()…) or by using some value you may already have that comes in on the requests that could possibly correlate to parition ids. Either way, that stateless service will be responsible for selecting the partition of the stateful service that should handle each request, the stateful service just receives the traffic.

How can the stateless service act as a proxy? One straightforward way is to use the stateless web api project and use it’s controllers and actions as the “api” into the stateful service. Each of those action methods will then locate a stateful service address and call that stateful service from within the fabric. It can then relay the response (if there is one) back to the caller on behalf of the stateful service as the action method completes. Naturally, the stateful service can also be self-hosting an OWIN web api just like the stateless service is doing so that the stateless service can communicate with the stateful service across normal REST routes.

This is not a hack, this is the correct way to communicate with stateful services externally. As an alternative to this, you could use a messaging system, such as the Azure Service Bus, to communicate with a stateful service. In this case, the stateful service instances (partitions) will act as competing consumers on the queue and this will create a natural load balance across them automatically. The main difference here is that this communication method is strictly asynchronous and would not operate as a web portal. This alternative solution is much more appropriate for a system of back-end worker services.


Stateful services have unpredictable names and are simply not natural candidates to be external web servers. For every service fabric application that you want to have a web portal or REST Api surface, create a stateless service as the web server that will communicate with all of the stateful services within the fabric on behalf of the user.

John Adams

Fix Cloud Services “IISExpress Development Certificate is Not Installed” Error on Localhost

The Azure SDK includes tools to help with both development and testing of Azure Cloud Services. One of the neat features of the Azure SDK is the inclusion of Azure Compute and Storage Emulators that allow for Cloud Service development to be done complely from Visual Studio on the Local Machine (localhost) with full Debugging support. When the Azure SDK is installed, it sets up the local machine with a number of prerequisites required for the emulators to run. However, as with any other SDK, sometimes errors do occur.


One of the errors that can occur when attempting to Run a Cloud Service from Visual Studio in Debug mode is:

“Microsoft Azure Tools: Error: IISExpress Development certificate is not installed.”


Simply running the Cloud Service on Localhost will cause the Error occur if the “unknown” circustances arose to cause the system to be in the required state to exhibit this particular error.

Here are steps to duplicate:

  1. Install Visual Studio 2015 and the latest Azure SDK
  2. Open Visual Studio, and create a new Cloud Service project that includes a Web Role
  3. Set the Cloud Service project a the Startup Project
  4. Debug the Cloud Service by pressing Ctrl-F5 or click on the Debug menu, then Start without Debugging

As can be seen in the above steps, it’s nothing that the developer can do to specifically cause this error to occur when creating / editing the Cloud Service code within Visual Studio.


The steps to fix the “IISExpress Development certificate is not installed” error a bit obscure, but luckily they aren’t to difficult to implement. Basically, the cause of the error is that certain prerequisites have failed to be installed on the Local Machine being used for Development. These prerequisites need to be verified and installed if they are missing.

The most common feature missing to cause this error is the HTTP Activation feature; which is a Windows Feature. Here are the steps to install it:

  1. From the Start Menu, choose Control Panel | Programs | Programs and Features
  2. Choose Turn Windows Features On or Off.
  3. Under .NET Framework 4.x Advanced Services, expand WCF Services, then select HTTP Activation
  4. Click OK

Once the HTTP Activation feature has been installed, re-open the Cloud Service and run it from localhost. The Local Machine shouldn’t need to be restarted, but it is possible. If the Cloud Service still exhibit the error after installing the HTTP Activation feature, then restart the machine and try again.

Additional Resources

In case the installation of the HTTP Activation feature doesn’t fix the issue, there are a number of other prerequisites that need to be installed as well. The Microsoft Azure SDK for .NET download page includes a list of Install Instructions. Step 14 of the Instructions include different versions for installing the prerequisites to setup IIS for different versions of Windows.

Introduction to the Opsgility Cloud Sandbox

Announcing the upcoming preview of our new Cloud Sandbox service for Microsoft Azure.

The Cloud Sandbox will help you stop overspending on development, test and training with Azure and will allow you to provide access to Azure at scale WITHOUT losing control.

Watch our new video for details or you can sign up for the preview here!