Use case for Azure App Service Deployment Slots - variation on versions of apps

user_4095326 0
Viewed 403

I read about the Deployment Slots on Azure App Service, and all docs and articles point out that these can be used for something like Prod and Stage versions of an app, with a swap of Stage to Prod to promote it to Prod after testing.

But is that the only use case? For example, we have a web app hosted on Azure App Service. Now we need to make a variation of that app for a specific purpose. It will never be swapped with the production slot. It will just co-exist as basically two separate apps.

Can deployment slots be used like this? Any downsides? It seems to me to be a way to host two or more web apps in an App Service without creating multiple App Services (therefore lower cost).

azure-web-app-service azure
1 Answers

Technically I believe it is possible to do what you are suggesting because each deployment slot does host a fully functional version of your application and you can access specific slots using this routing method. You would simply deploy each environment to its own slot and never swap them.

You can create additional web applications at no cost. You are only paying for the App Service Plan, and you can have as many web apps running on that plan as you want, so you would be better off creating a separate App Service for each of your environments, and since they are all non-production, you can safely run them all in the same App Service Plan.

You can deploy multiple separate WebApps under an App Service Plan. All those WebApps (/websites) will have their own separate default domain (FQDN) and also you can set custom domain for each of those WebApps.

App Service – Service which enables you to build and host web apps, mobile back ends, and RESTful APIs.
Apps– Your individual Apps (WebApps), these apps run in App Service Plan.
App Service Plan - An App Service Plan (ASP) defines a set of compute resources for a web app to run.

Since you pay for the computing resources your App Service plan allocates, you can potentially save money by putting multiple apps into one App Service plan. You can continue to add apps to an existing plan as long as the plan has enough resources to handle the load. However, keep in mind that apps in the same App Service plan all share the same compute resources.

If those are separate WebApps, it would be easier to manage separate WebApps than via virtual subdirectories/paths or hostname, or sub-domains. Using App Service Plan feature (provision many apps under the tier) to save cost.

Downsides:

  1. There is a limitation for hosting number of apps in an app service plan bases on plan Tiers you are using, like you can host up to 100 apps in a same app service plan if using the Shared Plan Tier and in the Free Tier, you're charged per app in the app service plan. Refer this for more details.
  2. Azure maintenance requires servers to restart at least once a month or more. If all your apps are on a shared plan, a patch reboot can mean the entire system is down and that all apps compete for resources when starting up simultaneously
  3. Deployment and restarting of apps can cause CPU spikes for the plan (which is a server). If your apps are performance sensitive and you deploy often, you might want more separation.

Note:

  1. Use separate plans as environment boundaries, so a production plan separate from a test plan. "Test" apps go on test plan, "Prod" apps on production to prevent testing from impacting users.
user_166301380
Related