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.
Related
I have some containers deployed on Azure App Service. To achieve zero downtime, Azure recommends using Deployment slots and swapping the staging and production slots. This is fine for a normal web applications, but If I have a web app where I am also doing other stuff like reading messages from queues, running workers in the background etc.
How do I ensure that the container is terminated in a graceful manner. Do Azure sends some kind of signal to the docker container indicating that it is terminating the application, so we should do cleanups. If not, how can I make my app truly zero downtime deployable hosted in App Service?
but I have a web app where I am also doing other stuff like reading messages from queues, running workers in the background etc.
This design is going to make it very difficult for you to do zero-downtime upgrades. I would recommend splitting the different purposes, and deploy them on different azure resources which can be upgraded in different ways:
your web app runs on Azure App Service, with blue/green upgrades using deployment slots
worker processes, and queue processing, could each be done by Azure Functions, which have their own version of deployment slots for zero-downtime upgrades
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 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'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.
I have been busy breaking up a monolithic service layer into about 30 small 'chunks' that can be independently deployed (C#, web API).
At the same time, we are moving to Azure.
How should these microservices be deployed?
We need 4 environments (devint, QA, UA and Prod) so we were going to use 4 slots per PaaS, and a new Paas for every microservice.
But this would get expensive and hard to manager.
Are there better approaches? (I know little to nothing about Azure so any help is appreciated).
Thanks
Azure Service Fabric is built for Microservices, and would likely be the best option to go with. Especially for forward thinking when running on the Azure platform. However, depending on your time line the fact that Service Fabric is still in Preview may be an issue. Azure features in Preview don't have the full SLA guarantee that they will when made Generally Available (GA).
The simplest hosting solution to use for Microservices in Azure App Service would be to deploy the different services as Web Apps, possibly using Web Jobs for any background processing. Web Apps and Web Jos work extremely well for building Microservices, and I have used this approach on projects in the past.
Regarding you comment about "4 slots". If you are referring to Web App Deployment Slots, then you will want to reconsider having 4 deployment slots of the same Web App to host your different environments. Especially in Production, there should be a Deployment Slot used for the Live Production instance, and one slot for a Staging area used for testing deployments before swapping them. When it comes to Dev/Int, QA and UAT then you'll want to have 1 or more Web Apps with necessary Deployment Slots to fit your needs. The last thing you want to do is mix up your Dev/Int, QA, UAT and Production environments. It's also very important to understand that all the Deployment Slots for a single Web App run on the exact same Virtual Machine; which means if you have all 4 environments as Deployment Slots then your Dev and QA environments could affect the performance of Production; which would be horrible.
You should consider using Azure Web Apps to host your chunks because it doesn't require any customization of the API or Websites you code (unlike Cloud Services which have their packaging and deployment format). The same WebDeploy mechanism will work on any IIS server (on your own server, AWS or Azure)
Take a look at Azure Resource Manager (ARM) to define the underlying resources such as the hosting App service plan (equivalent to a web server), web apps and databases. You will in all likelihood have the same set of resources in each environment and different configuration (such as different API URLs) or minor tweaks (such a premium SQL plan or larger/more instances of the web applications). ARM template can thus be shared across the 4 environments with each environment having its own ARM parameter file.