18
Save lots of $$$ with Azure DevOps and Azure CLI
I am a big fan of the Microsoft Azure platform. It is super easy to pick and choose the pieces that you need to build a great scalable digital platform with little effort. These pieces, or Azure resources to be exact, provide the required service without having to worry about the installation and maintenance of the underlaying infrastructure.
With great power comes great responsibility. That is why it is important to keep in mind that you pay for what you use. In other words: if you create a resource, the meter will start running. It is therefore good to think about this in advance and come up with a cost saving plan. After all, it is a shame to pay for something that you do not (fully) use.
Tip: set up Azure budgets to immediately get notified when the costs are higher than you would expect.
Consumption-based plans could be a good outcome here, where the costs are more in line with what you really need or use. Unfortunately this is not currently available for all resources, but the possibilities are constantly being expanded. In this article I will show you how you can reduce costs using the power of Azure DevOps together with a couple of super simple Azure CLI scripts.
When preparing quotations, I often make an overview of the necessary components needed to host the digital platform.
Tip: the Azure pricing calculator is a handy tool to quickly click together the required architecture and shows an overview of the required costs.
These costs are based on the price if the resource were fully used during that period of time. In my opinion this is not completely realistic and that is why I went looking for a way to reduce costs.
I came up with the idea to automatically scale a number of components, such as the App Service Plan and the SQL Database, based on availability needs. As a result, the digital platform is available during office hours and performs as expected. During the night and in the weekend, the environment is scaled back to a minimum.
For example, this automatic scaling can be applied to test and QA environments that are mainly used during business hours. But it can also be used for a digital workplace where the majority of the visits takes place during the day.
We are going to use Azure DevOps to create release pipelines for every time that we want to scale the Azure resources. In this example we will scale up the environment in the morning and scale it back down again in the evening from Monday to Friday. As a result, the environment is also in cost-saving mode during the weekend.
Note: depending on your setup you might use different resources which could be eligible for autoscaling. This example will only focus on scaling App services and SQL databases, basic components to host e.g. a Digital eXperience Platform like Kentico Xperience.
In Azure DevOps Pipelines, create a new release pipeline and select the “Empty job” option:
Next configure the scheduled release trigger as follows:
The configuration above will automatically start the release pipeline every Monday to Friday at 08:00 in the morning. Don’t forget to select your time zone. 😉
Click the Stage 1 box and give it a meaningful name. For example: Scale up Azure resources. Next configure the tasks for the stage:
The screenshot above contains steps to scale up the App Service Plan and the SQL Database. An Azure Resource Manager connection is required to run the scripts in the correct environment. For more info on how to setup the service connection have a look at my article 👉 How to connect the Azure DevOps Release pipeline and deploy to Azure using a Service Connection and Azure App Registration.
Using the following Azure CLI scripts we are going to scale up the Azure resources:
Azure CLI script to scale the App Service Plan
az appservice plan update --name MyAppServicePlan --resource-group MyResourceGroup --sku F1Azure CLI script to scale the SQL Database
az sql db update -g mygroup -s myserver -n mydb --edition Standard --service-objective S1 --max-size 250GBNote: for more info on how to specify scale configurations check out the Azure CLI documentation for App Service Plans and SQL Databases.
Save the release pipeline and repeat the steps above to create a release pipeline to automatically downscale the Azure resources during off-hours:
Remember the Azure pricing calculator I mentioned in the beginning of this blog post? I will use it to calculate the saved costs based on the previously mentioned example where the application is fully performing from 8 a.m. to 6 p.m. from Monday to Friday.
First I will calculate the price for the App Service Plan running at the P1V2 tier together with a SQL Database on the Premium P1 tier:
The total cost of this combination is: $19.80 per day or $138.60 per week.
Using the automated scaling the situation is different. The above mentioned performing setup will only be running for about 10 hours a day and not in the weekend. This results in the following calculation:
Because the application still runs the other 14 hours a day we will have to calculate the price and add it using the appropriate downscaled pricing tiers:
Note: you might be able to downscale to lower tiers depending on your situation. I recommend testing this thoroughly and optimize the auto-scale configuration.
Finally in the weekend the application runs 24 hours in the downscaled tiers:
This results in the following price for the auto-scaled setup: $9.58 per day (Monday to Friday) / $2.28 (weekend) totaling in $52.46 per week.
Compared to the 24/7 performing application which cost $138.60 per week, the amount can be reduced by $86.14 per week.
In this article I shared the idea of setting up an automatically scalable environment through Azure DevOps, where a release is triggered at fixed times to scale Azure resources via Azure CLI scripts, so that it is optimally available, especially during working hours. The example provided resulted in a savings of $86.14 per week.
I hope this post inspired you and will help you optimize your Azure architecture. I am looking forward to hearing your cost-saving tips in the comments.
Thank you for reading!
18