What Is the Azure App Service?

azure remoteapp
In this post, I will discuss the Azure App Service, the heart of Microsoft’s platform-as-a-service (PaaS). This is the first bucket of things that I have started learning as an IT pro that is expanding their knowledge beyond the comfortable world of infrastructure-as-a-service (IaaS).
 

 

The Service Fabric

In our comfortable world of IaaS, when we need a new web server, we deploy a virtual machine, log into it, and set up something like nginx on Linux or IIS on Windows Server. Deploying such an application comes with the implied responsibility of managing that virtual machine, making it highly available, patching it, updating the operating system, and keeping the web service binaries patched and up to date too.
The idea of PaaS is that we spend our time managing the application; the infrastructure exists, certainly, but we stop caring about it because it is no longer our responsibility. Microsoft Azure accomplishes this by using an abstraction called the Service Fabric.
The Service Fabric presents the capabilities of Azure virtual machines to users of Azure as “simple” services. For example, if you want a web server, you do not deploy a web server. Instead, the Service Fabric uses a virtual machine to make web server functionality available to you and you manage the web server through a portal experience (PowerShell, Azure CLI, Visual Studio, etc).

A representation of the Azure Service Fabric [Image Credit: Aidan Finn]
A Representation of the Azure Service Fabric [Image Credit: Aidan Finn]

The App Services

The Service Fabric makes several services available to you. Some of these services are depicted in the image below. Note that this is the newest image I could find and it is missing some important elements. The services to know are:

  • Web Apps
  • Web Jobs
  • Mobile Apps
  • API Apps
  • Logic Apps
  • Functions

The Azure App Service [Image Credit: Microsoft]
The Azure App Service [Image Credit: Microsoft]
 
Note that many other PaaS services exist. Some of these, such as Content Delivery Network, enhance some of the above services.

Web Apps

Web Apps are probably the most familiar of the App Services to IT pros. Most of us have deployed a web site with a hosting company such as WordPress or GoDaddy. Web Apps takes that concept and turns it into an enterprise service. You can deploy simple/free websites for test/dev but you can step that up:

  • Scaled-out/load balanced web apps
  • Continuous deployment to deploy new code using services, such as GitHub or Visual Studio Team Services
  • Slot management to enable dev/test/production deployment but can also be used for staged deployment where x percentage of clients hit a new version of the code

Web Apps is the first piece of Azure PaaS that I have focused on, but in trying to learn more about the architecture of the service, I have stumbled into learning more about the Service Fabric.

Web Jobs

Strictly speaking, Web Jobs are not really a service of its own. If they are deployed (more on this later), then Web Jobs are often deployed on its own for better performance and scalability. Web Jobs can be found in Web Apps.
Imagine that you have a need to process a background task behind a web app. This task, a program, or a script, can run on demand, continuously, or on a schedule. For example, your web app might allow a client to upload an image for processing. The image is stored in a blob storage account and the web job finds the image, processes it, and marks the image as ready for download. This may be by emailing the client.
The web job runs on the same virtual machine as the web app that it is a part of. This means that the job is contending with the website for CPU and RAM from the underlying virtual machine. Microsoft recommends that web jobs run in dedicated Web Apps, away from the Web Apps that are hosting the sites:

  • It prevents resource contention because the website and the web job are running in different virtual machines.
  • The web site and web job can be scaled up/out independently of each other.

Mobile Apps

Modern applications are often what we call mobile applications. These might be apps running on iOS, Android, or on the Universal Windows Platform (UWP). Mobile Apps are essentially lightweight client apps that connect to a web-based service, leveraging the processing power, storage, and other capabilities of the cloud.
Like most of the Azure App Services, Mobile Apps makes it easy to build in user authentication. Services such as Microsoft Account, Azure AD, and Google are a few mouse clicks away. I laughed out loud when I saw how easy it was to enable Google authentication for a Web App that I deployed on Azure. Such a service makes it easy to secure your company’s services and data for access via mobile apps.
Devices can be registered with the Mobile App and platform specific notifications can be sent out to the apps. That might be a number count on an iOS app, a toast on Android, a Live Tile on Windows, or more. You can enable data sync too, enabling the user of an app to work offline, if necessary.

API Apps

At this point, we are reaching the outer edges of my knowledge (so far). An API provides a developer with a programmable way to access services and data. You can share your services and data with other programs (internal or external) using API apps and secure this access using the previously mentioned authentication services.
Things such as Swagger and Swashbuckle are available for API discover and metadata. I have to admit that I could have just told you anything there because that sounds like a pirate rapper to me. I apologize if you are a pirate rapper!

Logic Apps

A great description that I heard recently was that Web Jobs allow small pieces of orchestrated workflows to take place but Logic Apps allow larger workflows to be managed. Logic Apps allows developers to model more complex processes, connecting in other services and data, and using the combined capabilities together. This workflow can include decision making.
An example of a Logic Apps might be to monitor tweets. If a tweet about the company is detected, the sentiment (using Machine Learning) can be determined, an action can be raised, and marked for follow up by a team.

Functions

Welcome to the world of server-less computing. Earlier, I stated that the Service Fabric abstracts virtual machines. Functions take PaaS one step further. There are no virtual machines. Instead, you write some code or a script, save it as a function in Azure, and the function is triggered based on an event.
Functions are like Web Jobs v2.0. In my limited reading so far, Functions appear to be taking the place of Web Jobs in Microsoft text. To be honest, Function and Web Jobs appear to do the same things except:

  • You must size the service plan (virtual machines) for Web Jobs.
  • There are no virtual machines when you use Functions.
  • You must pay for that service plan on a continuous basis.
  • Functions are paid for based on execution time.

Learning App Services

I have accidentally fallen into the Service Fabric world by learning about Web Apps but it has been useful. I have started to learn how to build out a real application. Microsoft’s reference architectures mentioned these various components that I previously knew little-to-nothing about. As a tech-junkie, I have found this stuff interesting. I am looking forward to diving a little deeper.