In the last two sections of this chapter, I have given you the most important facts about the offers in the area Azure IaaS. Now, we are leaving this area in the direction of the PaaS area.

What is a PaaS solution? A PaaS solution is a service or a complete service environment that allows you to deploy and run your own applications.

Let's go to the actual subject of this section: the Azure App Services. Azure App Services are defined as a service environment and are also a part of the Azure Execution Models.

Let's take a look at the first diagram:

As you can see, the Azure App Services currently consists of the following elements:

• Web Apps: Web apps is simply the new name for the Azure websites execution model and does not really differ in its functionality from the previous component (by combining it with other app service elements, but there are extended possibilities).
• Mobile Apps: Mobile apps is the new name for the Azure Mobile Services execution model and does not differ in its functionality from the previous component (by combining it with other app service elements, but there are more possibilities).
• Logic Apps: With Logic Apps, you can easily build and deploy powerful integration solutions by automating business processes or integrating your SaaS and enterprise applications. A visual designer is available for creating the necessary workflows. Logic Apps are the next evolutionary step in the integration services and the BizTalk services and starting from 2018 they are only offered in this area.
• API Apps: First of all, I must have mentioned that the Azure API apps are the only truly new component of this model. API apps allows you to discover, host, manage, and market APIs and SaaS connectors in a modern, feature-rich, scalable, and globally available platform. API apps is a complete solution for enterprise developers and system integrators, which extends the development of web apps (mobile apps) with numerous useful features.
• Function App: Not really a component of the Azure App Services. Azure Functions uses the Azure App Services environment only to handle the functionality.
• Container Apps: Not really a component of the Azure App Services. Azure Container Services uses the Azure App Services environment only to handle the functionality.
• Microsoft PowerApps: Not really a component of the Azure App Services. Microsoft PowerApps is a SaaS variant of the Azure App Services and uses the Azure App Services technologies and the Azure App Services environment only to handle the functionality.

Now, we have a first overview, but to get a deeper insight, we should change the diagram somewhat. Attention: in this diagram, some elements (for example, Function apps) have been removed because they only fit to a limited extent in the overall concept:

Our image of the Azure App Services now consists of three areas:

• Frontend
• Logic
• API

The frontend area includes:

• Web Apps: Web apps are all kinds of websites and web applications based on ASP.NET, Node.js, Java, PHP, and Python
• Mobile Apps: Mobile apps gives you the ability to develop apps regardless of whether you want to create native iOS, Android, and Windows apps, or cross-platform Xamarin or Cordova apps (PhoneGap).

The Logic area includes:

• Logic Apps: Logic Apps enable the simple implementation of scalable integrations and workflows into the cloud. For this, a visual designer is provided with which you can model and automate your processes in the form of a workflow. Other components of the Azure Logic Apps are the Logic App Templates and the Connectors.
• Logic App Templates: A Logic app template is a pre-built logic app that serves as the starting point for creating your own workflows.
• Connectors: Connectors are the most important part of an Azure logic app. With the usage of these connectors, you can expand your on-premises or cloud applications to do different things with data that you create, or data you already have. The connectors are available in the following categories:
  • Standard Connectors: Standard connectors are out-of-the-box connectors and are automatically available and included when you use Azure Logic Apps. Some examples are:
    • Azure Service Bus
    • Azure Blob storage
    • Azure Functions
    • Microsoft Power BI
    • Twitter and many more
  • Protocol Connectors: Protocol connectors are a part of the standard connectors and include four examples:
    • HTTP
    • HTTP and Swagger
    • HTTP WebHook
    • Request/response (HTTPS)
  • EIP Connectors: EIP connectors are also known as integration account connectors: EIP connectors are available when you install the enterprise integration pack and create an integration account. Using these connectors, you can transform and validate XML, process business-to-business messages with AS2/X12/EDIFACT, and encode and decode flat files. These connectors are also good to expand BizTalk workflows into Azure.

• • Enterprise Connectors: With Enterprise connectors, you can connect your Azure Logic Apps within your enterprise applications. This category includes three examples:
    • IBM MQ server
    • SAP application server
    • SAP Message Server

Some connectors can also act as a trigger. A trigger starts a new instance of an Azure Logic App workflow based on a specific event, like a change in your Azure Storage account.

The following triggers are available:

• Poll triggers: These triggers poll your service at a specified frequency to check for new data. When new data is available, a new instance of your logic app runs with the data as input.
• Push triggers: These triggers listen for data on an endpoint, or for an event, and then triggers a new instance of your logic app.
• Recurrence trigger: This trigger instantiates an instance of your logic app on a prescribed schedule.

The API area includes:

• API apps: API apps give you the opportunity to host your own APIs in all supported programming languages (ASP.NET, C #, Java, PHP, Node.js, and Python). API apps provides support for the OpenAPI (Swagger) Metadata API and is, for example, a great way to create a custom connector for an Azure Logic App.

Now, we have won a deeper insight, and we should take a look at a typical basic architecture:

The architecture is relatively simple to explain:

You always have a resource group with the following required elements:

• One App Service plan
• One or more web apps and/or mobile apps

In addition, there are at least two storage accounts based on the storage blob service for:

• Log files (application logs or diagnostics logs)
• Static content (for example, images)

The following elements are optional:

• A storage account based on the storage queue service
• A SQL Database as a service solution like Azure SQL service and/or a NoSQL database as a service solution such as Azure Cosmos DB (formerly Azure DocumentDB)

Which of these optional elements is actually used depends on your individual scenarios.

Let's return to the phrase App Service plans, an App Service plan represents a collection of physical resources that are used to host your apps.

An App Service plan defines:

• Region (for example, North Europe)
• Scaling (number of instances)
• Instance size (small, medium, large)
• SKU (Free, Shared, Basic, Standard, Premium. Premium V2, Isolated)

In the SKUs, Premium, Premium V. 2.0, and Isolated is a special feature included, which we should explain:

Azure App Service Environment (ASE): An ASE is a feature that provides a fully isolated and dedicated environment for securely running all types of App Service apps at high scale.

An ASE is always created inside of a virtual network and more precisely, within a subnet of a virtual network. This enables apps to securely connect to other endpoints accessible only inside of a virtual network, including endpoints connected via Azure Site-to-Site or Azure ExpressRoute connections.

There are two deployment types for an ASE:

• External ASE: An External ASE exposes the hosted apps on an internet-accessible IP address.

•  Internal load balancer  (ILB) ASE: An ILB ASE exposes the hosted apps on an IP address inside your VNet. The endpoint in this case is an instance of the Azure ILB.

Apps running in an ASE also have even more scaling options, including the ability to run on up to 100 compute instances.

Is that all? There is a clear answer: no. Recently, the Azure App Services portfolio has been extended by two other offerings:

• Azure App Service on Linux
• Azure Web Apps for Containers

With the Azure App Service on Linux offer you now have the option to run .NET Core, Node.js, PHP, or Ruby applications natively on a Linux VM inside from Azure App Service.

Let's go to the second new offer, the Azure Web App for Containers. Again, this is about applications (container applications) running natively on a Linux VM. The difference between the two offers is with the Docker images used. While the Azure App Service on Linux option uses ready-made built-in images, the Azure Web Apps for Containers use so-called custom images. So, you have direct control over which packages are installed, which runtime frameworks are used, or which tooling is available.