I'm looking to deploy a "Web App On Linux + MySQL" but am not sure what some of the features of the S1 Standard pricing tier mean.
"Up to 10 instance(s)" - What constitutes an instance?
"5 Slots" for "Web app staging" - What does this mean?
I'm trying to decide whether or not I need the S1 Standard offering or if B1 Basic is sufficient for my needs. Appreciate any insight from people better versed in Azure than I am.
"Up to 10 instance(s)" - What constitutes an instance?
You could refer to this official document.
When you create an app in App Service, it is put into an App Service plan. When the app runs, it runs on all the VM instances configured in the App Service plan. If multiple apps are in the same App Service plan, they all share the same VM instances. If you have multiple deployment slots for an app, all deployment slots also run on the same VM instances. If you enable diagnostic logs, perform backups, or run WebJobs, they also use CPU cycles and memory on these VM instances.
In this way, the App Service plan is the scale unit of the App Service apps. If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together based on the autoscale settings.
For S1 standard, you could autoscale your app run 10 VM instances.
You also could could refer to this question.
"5 Slots" for "Web app staging" - What does this mean?
You could refer to this official document.
When you deploy your web app, web app on Linux, mobile back end, and API app to App Service, you can deploy to a separate deployment slot instead of the default production slot when running in the Standard or Premium App Service plan mode. Deployment slots are actually live apps with their own hostnames.
Related
I have been developing a React SPA with Python Api using Docker and Azure Web Apps for Containers.
Now when I want to develop the production deployment process I find that there are no app service tiers which include slots other than very expensive production tiers.
Am I mistaken?
If not, is there a reason for this?
You could see S1 or above price tier also support Staging slots when you expand See additional options tab.
I am trying to reduce the number of one-off App Service Plans my organisation has for a number of App Services. However, when clicking "Change App Service plan" within the App Service, often the App Service Plan I would like to move it to doesn't show up in the list.
What determines whether two app services can run on the same App Service Plan besides region? Is it just the Operating System, or also the stack? Does it have something to do with the resource group of either the App Service Plan or App service?
About change app service plan, there is a description in the office document: Move an app to another App Service plan.
About your problem, you said the target plan is not listed in the list, the most likely reason is that they are not in same App Service Environment. In the document it say all plans created with the same resource group and region combination are deployed into the same webspace.
So make sure your App Service Environments are same, like region and resource group before moving web. Hope this could help you, if you still have other problem please feel free to let me know.
Free has 10 and Shared has a quota of 100.
Think out how you want to group your applications though as keep in mind they will share the same compute resources if combining. Also if deploying infrastructure as code keep in mind now that there are more dependencies when combining the applications into one App Service Plan.
I have an ASP.NET core 3.1 based web api ready to deploy to Azure for production use. For test / development, I have been deploying it to a traditional app service on Azure which I believe is a shared Windows VM under the hood. I have been on F1 tier and it suits my needs for test and dev.
But for production, even the cheapest plan costs me $93.44 per month which I would like to avoid if I can.
In order to lower the cost, I have decided to containerize my app and deploy it using "web app for containers" or "azure container instances". My question is, based on your experience, which method will give me reasonable production-scale performance while minimize my monthly cost? Or would containerize my app save me any money at all?
Please note that I have evaluated Azure Functions and decided it is not what I would like to use.
For your requirements, first of all, you need to know that the Azure Container Instance benefits for its quick start and running. See this:
Azure Container Instances is a great solution for any scenario that
can operate in isolated containers, including simple applications,
task automation, and build jobs.
It's good for the simple application, but not good for scenarios where you need full container orchestration, including service discovery across multiple containers, automatic scaling, and coordinated application upgrades. And I think it's also not stable for the production use, it's more appropriate for the test.
And the Azure App Service is cost according to the service plan, the service plan billed on a per second basis. You can plan the use with time as you need and the App Service has more features than Container Instance. Or if you do not satisfied with App Service, maybe you can take a look at the Azure Kubernetes Service, it has more control and feature then the Container Instance.
As of beginning of 2022 looks like Container Instances and Web Apps for containers will be the same ~32eur which is a bit better than the app service ~50eur.
Deployment slots on azure app service are really intended to run new versions of same app for blue/green deploy strategies. The question I have is it against the rules to run an app with multiple components (front end/back end) to put them into different deployment. On Standard plan, I can load up to 5 services into a single azure app service plan. This would be great as cost saving measure in non prod environments where a single instance of each service is just fine. The question I have is
a) is this against the rules?
b) are there any pitfalls with this strategy?
Thanks
You can host as many web apps on your app service plan as you want. You just have to ensure they don't consume to much CPU or memory. So I wouldn't use deployment slots.
I have an app service running on Azure with an associated SQL server DB.
I would like to create a test environment for the project.
I looked at a few Azure Dev/Test tutorials but they are for setting up VMs and I couldn't see anything indicating it can be used for a app service.
Is my only option to duplicate the appservice, db, ssl certs, custom domains and effectively double my azure bill?
Bruno gave good advice, but here's a few more things to consider.
If you use deployment slots, you are sharing your Web App CPU and memory between all slots. If something goes horribly wrong with a test build that's deployed to a slot on your production machine, your production environment can end up resource starved. I personally don't recommend using slots for testing for this reason. Slots are more for smoke testing/warming up a build that you're about to swap into your production slot.
If you want to save money yet still have the benefit of separate environments, consider looking into ARM templates. ARM templates let you script the provisioning of Azure resources. You can create ARM templates based on your production environment, including scripting the App Settings section of your Web App to hold test configuration settings. You can then deploy your ARM template that spins up a test environment right from a Visual Studio project. If you put all of your test resources into the same resource group, tearing down your test environment is a few mouse clicks to delete the test resource group.
For the App Service, you have something called Slots. This allows you to have multiple environments on the same App Service. You can also have multiple Web Apps under the same App Service Plan as well instead of using Slots, so in this case, you only pay for 1 backend. App Service has a Free Tier, but with limitations such as not supporting custom domains.
Set up staging environments in Azure App Service
For SQL Databases you have to pay for each DB or use Elastic Pools (1 backend for multiple DBs) but that's only worth when you're using at least 100DTUs DBs. The minimum database you can have is the Basic one, but that's $6/month.