A Quick Tour of Microsoft Azure App Service

In a nutshell, Microsoft App Service is a Hypertext Transfer Protocol (HTTP)-based web application hosting service. Think of Microsoft App Service as GoDaddy, but with much more power. The idea is that if you're willing to surrender full control app’s underlying infrastructure (which is what Azure Virtual Machines is for) you’ll receive in exchange

• Global replication and geoavailability
• Dynamic autoscaling
• Native integration into continuous integration/continuous deployment pipelines

Yes, App Service uses virtual machines (VMs) under the hood, but you never have to worry about maintaining them; Microsoft does that for you. Instead, you focus nearly exclusively on your source code and your application.

Microsoft App Service development frameworks and compute environments

Microsoft App Service supports several development frameworks, including the following:

• .NET Framework
• .NET Core
• Java
• Ruby
• js
• Python
• PHP

You can use any of the following as your underlying compute environment in App Service:

• Windows Server VM
• Linux VM
• Docker container

Web apps

The static or dynamic web application is the most commonly used option in App Service. Your hosted web apps can be linked to cloud- or on-premises databases, API web services, and content delivery networks.

API apps

An application programming interface (API) is a mechanism that offers programmatic (noninteractive) access to your application by using HTTP requests and responses — a programming paradigm known as Representational State Transfer (REST). Nowadays, Microsoft supports API apps from App Service and the API Management service.

Mobile apps

A mobile app provides the back end to an iOS or Android application. Azure mobile apps provide features most smartphone consumers have grown to expect as part of the mobile apps they use, such as social media sign-in, push notifications, and offline data synchronization.

Azure Logic apps

A logic app provides a way for developers to build business workflows without having to know all the underlying APIs in different services. You might create a logic app that triggers whenever someone mentions your company’s name on Twitter, for example. Then this app may perform several actions, such as posting a notification message in your sales department’s Slack channel or creating a record in your customer relationship management database.

Azure Function apps

A function app allows developers to run specific code at specific times without worrying about the underlying infrastructure. That’s why function apps are called serverless applications, or Code as a Service (CaaS) solutions. One company has a function app that sends a confirmation email message to a prospective customer whenever that user creates a new account on his website.

Function apps support the C#, F#, and Java programming languages.

Both logic apps and function apps operate on the basis of a trigger. This trigger could be a manual execution command, a time schedule, or a discrete operation that occurs inside or outside Azure.

Azure App Service logical components

The following image shows the components that make up App Service. An App Service web app is powered by an associated App Service plan. This plan is an abstraction layer; you control how much virtual compute you need to power your application or applications, and you dynamically scale vertically to suit your performance requirements and budgetary needs.

The App Service plan is the only required component. You can extend the app’s capabilities by integrating it with any of the following:

• Storage account: An App Service plan has persistent storage, but many developers like to use a flexible storage account for additional space.
• Virtual network: You can link an App Service app to a virtual network — perhaps to connect your web app to a database running on a VM.
• Databases: Most web apps nowadays use relational, nonrelational, and/or in-memory databases to store temporary or persistent data.
• Content delivery network: You can place static website assets in a storage account and let Azure distribute the assets globally. This way, your users get a much faster experience because their browsers pull your site content from a low-latency, geographically close source.

App Service plans are organized in three increasingly powerful (and expensive) tiers:

• Dev/Test: F- and B-series VMs with minimal compute and no extra features. This compute level is the least expensive but offers few features and shouldn’t be used for production apps.
• Production: S- and P-series VMs with a good balance of compute power and features. This tier should be your App Service starting point.
• Isolated: Called the App Service Environment and very expensive; Microsoft allocates hardware so that your web app is screened from the public Internet

You can move within or between tiers as necessary. This capability is one of the greatest attributes of public cloud services. Here, you see an App Service plan.

Azure uses the Azure Compute Unit as a standardized method to classify compute power. You see it referenced in Azure VMs, App Service, and any other Azure resource that uses VMs. Having a standardized performance metric is crucial, because Microsoft uses several types of hardware in its data centers.

Just because you can associate more than one web app into a single App Service plan doesn’t mean that you should. Sure, you can save money (the App Service plan incurs run-time costs based on instance size), but the more apps you pack into a single plan, the greater the burden on the underlying VM.

Want to learn more about Microsoft Azure? Check out these ten Azure educational resources.