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).
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:
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.
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
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:
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.
Related
I have a client coming on board to Azure from other cloud service provider. They would like to host up to 10 web apps on Azure and cost is really an issue for them.
Normally I'm suppose to create VM's that would host each of these web Apps; but they can't afford the price. Hence the choice of deploying all of them on the same Azure App service plan.
I think Azure App service offers only 50gb storage. The 10 Web Apps would require storage capacity far more than 50gb; is it scalable or can we link each of these Apps to an Azure storage account. And also is there any implications for deploying multiple web Apps on an Azure App Service plan
An App Service Plan is capable to run multiple Web Apps, each in its own sandbox. It's like a VM but as a PaaS service. Note that the storage included in the plan will be shared across all Web Apps so you'll have to use Azure Storage if you want to store more data.
An App Service Plan is designed to handle multiple web apps/Function apps, use BLOB Storage or similar for your data it will scale to whatever you need, depending on your needs you can add further services like Azure Front Door to load balance multiple apps on multiple app service plans
One important thing to remember is that the app service plan has limitations with outbound connections so even if each of your webapps are not so busy the sum of them all might bring you over the limit so be very careful how you handle your outbound connections.
I am trying to understand better how Azure App Service Plan (ASP) load-balances the traffic when multiple/different App Services are deployed in it.
Let's assume my ASP is made of 2 nodes (VMs or instances) and I deploy 2 apps (total 4 app instances running) and with following URL:
https://app1.azurewebsites.net
https://app2.azurewebsites.net
I know that there are ASP front-ends acting as load balancers. So here if I understand correctly it is like when I have a web-server hosting different web-sites and address distinction is based on virtual hostnames (which are the URL above). Right?
App Service is a multitenant service, so it uses the host header in the request to route the request to the correct endpoint. The default domain name of App Services, *.azurewebsites.net (say, contoso.azurewebsites.net), is different from the application gateway's domain name (say, contoso.com). ref.1
When using App Service, you can scale your apps by scaling the App Service plan they run on. When multiple apps are run in the same App Service plan, each scaled-out instance runs all the apps in the plan.
Apps are allocated to available App Service plan using a best effort approach for an even distribution across instances. While an even distribution is not guaranteed, the platform will make sure that two instances of the same app will not be hosted on the same App Service plan instance.
The platform does not rely on metrics to decide on worker allocation. Applications are rebalanced only when instances are added or removed from the App Service plan.
You can also now do Per-app scaling, which can be enabled at the App Service plan level to allow for scaling an app independently from the App Service plan that hosts it. This way, an App Service plan can be scaled to 10 instances, but an app can be set to use only five. ref.2
I have multiple App Services hosted on a single App Service plan (Basic Small), which is basically a fully managed VM with all it's resources reserved for me. These are all Asp.Net apps.
As I have plenty of resources still available I'm considering moving my WordPress applications to Azure (each to a new App Service within the same App Service plan.
WordPress unfortunately, has a tendency to get infected every now and then. Also the infection can spread to other websites if they are not properly isolated (infected website may change files of the other websites).
So my question is:
If one of my WordPress websites gets infected are other websites from different App Services, but the same App Service plan also in danger?
The answer to this greatly depends on how you trust Microsoft and their claims.
All Azure Web Apps (as well as Mobile App/Services, WebJobs and
Functions) run in a secure environment called a sandbox. Each app runs
inside its own sandbox, isolating its execution from other instances
on the same machine as well as providing an additional degree of
security and privacy which would otherwise not be available. The
sandbox mechanism aims to ensure that each app running on a machine
will have a minimum guaranteed level of service; furthermore, the
runtime limits enforced by the sandbox protects apps from being
adversely affected by other resource-intensive apps which may be
running on the same machine.
So it should be secure.
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
I would like to run Virtual Machines as Worker Role inside an Azure App Service Environment. I think I've tried and read everything. Is this scenario supported at all?
The short answer is no. Azure VM's, worker roles (cloud services), and App Services are three different hosting offerings.
Virtual Machines are an Infrastructure as a Service (IaaS) solution. Think of it as your own server in the cloud. It is the most most flexible option. However, you are responsible for managing and patching it.
Cloud Services are a Platform as as Service (PaaS). Your concerns are limited to building and deploying your application. Microsoft manages updating the underlying VM.
App Services are a higher level of PaaS. Specifically, you can think of Web Apps (formerly Web Sites) as a hosted IIS. You have the least amount of control compared to the other platform offerings, but it is the easiest way to get started.
I would suggest trying to run your application first in an App Service, then moving to a cloud service if you need more control, and finally to a VM when even more flexibility is required.
More information:
http://robertgreiner.com/2014/03/windows-azure-iaas-paas-saas-overview
http://blogs.msdn.com/b/hanuk/archive/2013/12/03/which-windows-azure-cloud-architecture-paas-or-iaas.aspx
We are running several azure websites (or web apps) on a medium instance. I would like to know if there will be an impact on performance on any of the other sites when running a simple load test on one of them. In other words, do these sites share the same processor/memory or is this handled differently in azure?
If the apps are in the same app service plan then yes there will be an impact. Apps within the same app service plan share resources and capacity.
https://azure.microsoft.com/en-us/documentation/articles/azure-web-sites-web-hosting-plans-in-depth-overview/