The Azure App Service is Microsoft’s Platform-as-a-Service, a fully-managed offering for building and deploying enterprise-grade web, mobile and API apps without the need to manage infrastructure. This means you can focus all your attention on the apps and the value they will ultimately provide the end users. It’s worth noting that the service will typically be used for Microsoft architected apps, however it can also support several other programming languages. You’ll find that the service also supports auto-scaling and high availability, Windows and Linux deployments, and provides automated deployment capabilities from services such as Azure DevOps (Visual Studio Team Services as it was previously known) and GitHub.
There are a whole load of benefits to the service. For starters there’s no infrastructure or operating system maintenance, it also supports multiple languages and frameworks including ASP.NET Core, Java, Ruby, Node.js, PHP or Python. It’s cost effective too, with various pricing plans based on consumption (I’ve included a full list of all the benefits at the end of the blog).
An Azure App Service Plan is required to run an app and it defines a set of resources that are available to the app. Providing that the chosen App Service Plan has sufficient resources, multiple apps can be deployed within the same App Service Plan which is cheaper than paying for a separate App Service Plan for every app. For example, the ANS GLASS Web App and API both run within the same App Service Plan. Think of this as running multiple apps in a traditional Internet Information Services (IIS) deployment model. If you have a particularly resource intensive app, you may however choose to deploy this app within a separate App Service Plan so that it doesn’t consume most of the resources and impact the performance of the other apps within the App Service Plan.
If you require additional resources, you can scale up the App Service Plan Tier. Think of this as adding additional CPU and memory to a server in a traditional app deployment model. Furthermore, with App Service Plan you can scale out manually or automatically based on certain criteria being met such as adding an additional instance of the app if the CPU exceeds 80%. For example, this would be particularly useful if an online retail business was having a large sale and traffic was expected to increase significantly. Utilising the scale out capabilities the site would automatically increase the number of instances of the app during the peak then revert to the normal baseline with no manual involvement and no business disruption.
An Azure App Service can be viewed as the starting point of a cloud native app which can then allow you to take advantage of additional Azure services that further enhance this type of cloud architecture. These include:
If you are looking to migrate existing apps to the cloud or build new cloud native apps then the Azure App Service certainly fits the bill (in my opinion).
Keep your eyes peeled for my next blog in which I’ll be taking a look at Azure Functions and WebJobs.
In Summary, here are the key benefits of Azure App Service