We'd like to add instances to our Azure App Service plan to scale out. Everything we've got is stateless, apart from one app. Because of the way that app is used, if there is more than one instance of it things will quickly go crazy. We can work fix this eventually - we need to build in shared storage for its state - but at the moment we don't have enough the time.
Is there any way to scale out an app service plan, but indicate that particular apps should only ever be run on one host?
I'm assuming this isn't possible, however it turns out to be surprisingly easy to move an existing app between app service plans without having to recreate the configuration. I have gone down this route for now with an eye to fixing the clustering issue and moving the app back into the original app service plan later.
Did you think about using Cloud Services or Service Fabric? Cloud Services role model is what you are thinking of - you are able to scale only one component of the solution.
Related
We are migrating to Azure. We have a Web App deployed. However, I have a Windows Service that I need to add in to the mix. The service continuously runs, checking the associated Service Bus Queue for messages every 5 seconds.
I am looking for recommendations on how to do this.
I have looked at Web Jobs. But, I don't understand how it gets kicked off. I know there is a Web Hook involved - but I just want the code to run continuously without having to be constantly kicked.
We are also trying to avoid the cost of having a VM involved.
Thanks in advance.
Since you already have a web app, you could use a Azure App Service to run the Web App. The Azure App Service will allow you to also have a Web Job that you can have run on a schedule.
It does not make sense to break you web app into Azure Functions since it is already built. You can have the service run in an Azure Function, but it will probably add more complexity to interact with the web app (if that is what is happening) and if the service is running every 5 seconds, that could get costly.
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.
I have apis written in asp .net core which can be easily containerized, i want to deploy these apis in azure app service, but i am not able to decide whether i should containerize these api and deploy as containers in web app or i can deploy directly as code, On what basis this can be decided i see that App service gives scale out capacity for both way of deployment and other factors like continuous deployment also look same , so how shall i decide which approach to take , or it really doesn't matter in this case?
In my opinion since container is buzz word doesn't mean we definitely need to use it , unless we have very specific reason to. Containers have picked up reputation after since microservice architecture has gained popularity and in that case it works great.
Use Web App for Containers when
You are trying to package application where dependencies (run-time , tooling etc) are required and critical , so you can bundle them up.
You want to become cloud agnostic. Containers are best way to switch to other cloud provider e.g. AWS if you have to without making any code changes.
Lift and shift scenario where you want to move old/legacy code to cloud.
At some point in future you intend to use API as Microservice and that would require the service being used with orchestration service like AKS (Azure Kubernetes service).
Some advance cases where you want to run containers as serverless to deal with spikes
(Container Instances e.g.)
You are well aware of containers debugging, ports etc and how they work.
Any other case i would rather stick to App Service as code deployment. You need to aware containers are good but it can be overhead if you don't know how to deal with them.
Recently I've started experimenting and getting familiar with some of the Azure offerings. I made a simple app, connected it with azure functions and azure storage as well as some other offerings like service bus for example.
So far so good, the app is working great and I got my feet wet with some great Azure services.
But now I'm unsure on how best to proceed because what I have so far is a development version of my app. If I wanted to make a prod version do I have to provision a different set of all the azure resources used for the dev version?
So basically, I would have mydevsite.azurewebsites.net and myprodsite.azurewebsites.net. Is this correct? I can restrict mydevsite.azurewebsites.net with some IP address restrictions so that is not publicly available but I still feel this is a hacky way of doing this and that there should be a better way.
Is there a common approach to a scenario like this?
This is a bit of a broad question, but I can tell how I have done it before.
A common setup would be three environments, Dev, Test and Production.
Dev mostly runs on the developer's machine (as much as it can). We use a local IIS installation to run the web app, and a local SQL Server as a database. Azure Storage and Cosmos DB can also be emulated locally. Certain services like Search for example can't be run locally so you would have to run those in Azure anyway.
Test and Production are basically two identical resource groups with the same resources, just configured slightly differently. So double the App Service Plans, SQL databases etc.
Depending on how you want to do it though, you can of course share resources across environments. But it is a good idea to somehow make sure they do not accidentally use the other environment's stuff. And the definite bad side of this is that you are putting production data in the same place as test data, which frankly should not be together.
I know some organizations run a Dev environment fully in Azure. There can be a couple reasons for this: very heavy environment which can't really run on dev machines, or they want to test ARM template deployment at dev stage too.
Having duplicated services allows you to use ARM templates for automatically deploying and updating the infrastructure, which is pretty nice.
If you are on Standard or higher, you might think to use Deployment Slots in App Service for different environments, but they are really not meant for that purpose. We use them to reduce application downtime when deploying a new version, and as a fallback if the update turns out bad. So the deployment goes to a "staging" deployment slot, which gets swapped with the other one, and the new version is live. We then stop the deployment slot so we are not running the older version in the background unnecessarily.
But otherwise we have a separate App Service Plan with separate Web Apps with their own staging slots.
Deployment slots documentation: https://learn.microsoft.com/en-us/azure/app-service/web-sites-staged-publishing