App Service allows a developer to focus on developing business requirements and not worry about compliance, operational overhead, and integration with other popular services. It allows a developer to target just about any platform or device, including Windows, iOS, and Android, with very little change to the source code.

As a developer, you can use existing services and APIs advertised in the Azure Marketplace as building blocks to build modern enterprise solutions quickly and simply, or you can contribute your own APIs for public or private use.

The agile software development methodology is supported using the features of continuous publishing and deployment slots that are available for a subset of App Service.

Security and resource contentions are the biggest concerns when hosting solutions in any cloud environment. Using App Service Environment, it provides a fully isolated and dedicated environment for your App Service. Security boundaries between your apps and backend services are possible using virtual networks and network security groups between different App Service Environment (ASE) that are in the same virtual network.

The key features and capabilities available as part of the Azure App Service framework are described here:

Developing complex Azure solutions normally consists of many resources, such as databases, storage artifacts, websites, and APIs. Managing the application life cycle, access control, and billing for these resources can be challenging at times.

Using resource groups which is only available in the Azure portal provides the capability to group the artefacts into a logical group. This gives you a much clearer picture of all the components that make up your solution and the ability to view the consumption and spending of the individual resources in a grouped manner.

Typically, you would group the resources according to your own requirements; this may be by region, capacity, business process, or administration, for example. All resources in the same group should share the same life cycle to deploy, update, or delete all together. If there is a need to manage the life cycle of a resource differently from the rest, then it should be placed in another resource group of its own.

Resources in a resource group can reside in different regions, but a resource cannot be shared across more than one resource group.

For our sample solution that we will be creating throughout this book, we have created three resource groups shown later, one for the business processing, another for predictive IoT monitoring and one for the product database.

You can move most resources from one group to another. See this link here for more information on which resources can be moved around: https://azure.microsoft.com/en-us/documentation/articles/resource-group-move-resources/ .

There is no recovery option available to recover the resources that have been deleted by the deletion of the resource group. Fortunately, Azure provides an option to lock critical resource groups and resources from accidental deletion. There are two lock options provided, CanNotDelete or ReadOnly, that an administrator can set through the portal. The CanNotDelete lock provides the capability to add or modify an existing resource but cannot delete, whereas the ReadOnly lock sets the permission to the resource as the reader role only. Be careful when applying ReadOnly locks as some operations require additional actions, for example, listing the access keys for a storage account.

See this link here for more information: https://azure.microsoft.com/en-us/documentation/articles/resource-group-lock-resources/ .