Introducing Azure App Service

A few posts ago, I mentioned that I’ll be introducing you to the Mary-go-round of the Azure Theme Park, namely, Azure App Service.

So, what the heck is Azure App Service anyway?

Well, at first brush, the name of this service is not very forthcoming. Most people won’t immediately guess what an “app service” is, however, it’s actually a lot more familiar than you think.

From web apps to mobile apps, we all know what an “app” is. Well, this is the area of Azure that helps bring your apps to life while keeping you focused on your application instead of worrying about underlying low-level details like the infrastructure, operation system, or even the app hosting platform itself.

Azure App Service currently encapsulates the following four main types of apps:

  • Web Apps
  • Mobile Apps
  • API Apps
  • Logic Apps

Related, but slightly different, are also Azure Functions, which are a more versatile incarnation of Web Jobs, and can be thought of as a light-weight web/API apps that are focused on a single task (written as essentially one function/method).

It’s important to note that Azure App Service makes up a large part of Azure’s PaaS offering, and is thus intended to be quite easy to get started with.

Over the next few posts, I plan to explore various aspects of Azure App Service, but for today, let me briefly introduce you to each of the four types.

Azure Web Apps

Well, this is where you normally deploy a web application, which could be built in .NET or other languages (Java, NodeJs, PHP…etc). In .NET, this is essentially where you deploy your ASP.NET MVC application, which will be accessible online immediately and without much fuss.

Azure Web App

Azure API Apps

This is where you deploy a REST API. While you could deploy your ASP.NET Web API (for example) as a Web App instead of an API App, you actually gain some advantages by choosing this type of App Service, for example, the ability to link to a Swagger definition for your API, available in the Azure portal, and a starter SDK for consuming your API.

Azure API App

Azure Mobile Apps

A very common scenario for deploying mobile applications is to have a client mobile application on some platform (e.g. iOS), and have it communicate with a REST API in the cloud. This type of setup gets its own App Service type. A client mobile application communicates with the the server using an Azure Mobile App as the backend. This setup provides a few advantages in this scenario, such as the ability to leverage a ready-made SDK for all the main mobile client platforms (iOS, Android, …etc). This SDK provides several mobile-related functionality out of the box, from integrating with Azure Active Directory for authentication/authorization, to enabling offline-usage of the mobile application without extra work.

Azure Mobile App

Azure Logic Apps

This is basically an orchestration app, which provides a flow-chart-like interface for configuring a number of actions/steps like retrieving data from a variety of data sources, as well as applying some conditional or custom logic, all in a WYSIWYG interface. You can get more customized functionality at each step by integrating with Azure Functions and writing your own custom logic.

Azure Logic App

Azure Functions

Why host an app when a single function will do? This is as PaaS as it gets. You simply write code that represents a method (not a whole app), and deploy it to Azure Functions awaiting some trigger before it executes and returns its result. You can easily combine Logic Apps and Azure Functions to orchestrate a number of custom steps to achieve your desired result.

Azure Function App

So, as you can see, Azure App Service is a major area of Azure, especially when it comes to its PaaS offerings. There are a few commonalities and concepts that are shared among all the Azure App Service types, which we will explore in upcoming posts.

Stay curious,

Author: MJ Alwajeeh

Passionate programmer and architect. Cloud Enthusiast. Lifelong learner.

Leave a Reply

Your email address will not be published. Required fields are marked *