This customer is implementing an Azure Integration Services platform and they are running with a very high velocity delivering value across multiple projects.
The customer has 5 environments, 4 that are non-production and 1 production environment.
The customer is using services like:
The customer purchased Turbo360 to help them to manage the costs of their Azure environment and then democratized the management of cost to all of the engineering and operations teams within IT and challenged them to run an efficient application.
In the Integration Team this means that they need to maximize the efficiency of their PaaS platform services.
The integration platform combines the use of Logic App Consumption and Logic App Standard. They are 2 flavours of Logic Apps which have different pricing models. Logic App Consumption is an on demand pricing model which is ideal for low use ad-hoc execution whereas Logic App Standard is better suited to high performance and predictable demand with a node per hour cost model.
The customer chose the right cost plan for each interface based on the combination of functional and non-functional requirements.
The customer uses Logic App Consumption quite a lot, both historically from before Logic App Standard was available and for on-demand interfaces. In this case the customer has 50 Logic Apps per environment which poll service bus every 30 seconds for messages. Each individual Logic App incurs a tiny charge per trigger execution but if you roll that price up across all Logic Apps per environment it all adds up.
It works out that each Logic App results in 86k trigger actions per month just checking for messages on Service Bus. The cost for a connector action is $0.000125.
This means that 86k * 0.000125 = 10.75
Each Logic App costs around $10.75 per month just for polling service bus.
If we multiple that across 50 Logic Apps & 5 environments then we are paying around $2.6k per month just for these Logic Apps which are polling service bus.
10.75 * 50 * 5 = $2.6k
In Turbo360 there is a workload optimization feature for scheduling the reconfiguration of resources. In the case of Logic App Consumption we can schedule the turning off of Logic Apps in the non-production environments out of hours.
In the below picture you can see the impact as new Logic Apps were deployed to an environment and then the optimizer feature was turned on.
The way the optimizer was used is that Logic Apps were turned off most of the time in the Dev and Build environments and in the System Test and UAT environments the Logic Apps were turned on during office hours when people would be testing between 9am to 5pm.
This means we saw the following savings:
Environment | Original Cost | Optimized Cost | Saving |
Dev | 537 | 50 | 90% |
Build | 537 | 50 | 90% |
System Test | 537 | 320 | 40% |
UAT | 537 | 320 | 40% |
Production | 537 | 537 | 0% |
Total | 2685 | 1277 | 52.5% |
For this Logic App Consumption scenario you can see we have saved $15k per year across all environments.
The customer is running some Logic App Standard on an App Service Environment. This scenario involves Logic Apps which can run with a static scaling where you would scale it 1 node at a time. On the ASE is an App Service Plan which can cost in the region of $400 per month.
With an App Service Plan the customer is able to buy a reservation. In the wider organization the central Azure admin team are not really paying much attention to the Integration Team because they have much bigger projects to handle, but using Turbo360 and giving the Integration Team scope to manage their own costs they incur.
In this case the Integration Team can see there are reservations available for their App Service Plans running on the ASE.
The team were able to purchase these reservations and reduce the costs by just under $600 per month.
Before Turbo360, the process used for managing cost just wasn’t picking up these potential reservations that were in Azure but just not being seen.
The customer was using a combo of App Service Environment (ASE) & WS type of App Service Plans for hosting Logic App Standard.
There are a range of different workflow usage patterns where the ones on the WS-* plans can take advantage of dynamic scaling to burst out when needed and others which can take advantage of the benefits of an ASE and the stepped node pricing model.
One of the challenges though comes into play when you want to scale up or down the nodes. As the customer deploys out more solutions the expectation is that they will need to scale up the App Service Plans. This is easy to do in Azure but in the non production environments it would be desirable to scale down out of hours when no one is using them.
To achieve this they use the Turbo360 scheduler feature. Below is a standard schedule to scale up during the business day and scale down at night.
Adding the App Service Plans to the scheduler means you can make the following configurations.
Time | ASE Based Plans | WS* Based Plans |
9am – 5pm | I3V2 | WS3 |
5pm – 9am | I1V2 | WS1 |
With Turbo360 you can see below how the customer made those configurations very easily by just setting the configuration required on the schedule.
The cost savings from reconfiguring the plans on the schedule are shown below.
Time | ASE Based Plans | WS* Based Plans |
9am – 5pm | I3V2 | WS3 – 225.5 |
5pm – 9am | I1V2 | WS1 – 124 |
Cost before | $1470.34 | $751.90 |
Cost after | $695.78 | $349.50 |
Cost Saving | 52.64% | 53.54% |
If you are implementing a greenfield Azure Integration Services platform, or you are migrating from BizTalk to Azure Integration Services then you need to be mindful of costs to ensure you get maximum value for money.
In this case the customer there were a range of savings over the lifetime of the project that could be implemented.
Resource type | Per year savings | Comments |
Logic App Consumption | $15,000 | |
Logic App Standard on ASE Reservations | $7,200 | |
Logic App Standard optimizations with scheduler | $14,000 | Note this saving would be combined with the reservations saving as the environment grew |
In general for this customer, Turbo360 is helping them find and implement cost savings in the region of 50% for Logic Apps in the right scenarios. This is just one team within the organisation and there are many other resource types they have which can be tuned and optimized for that team such as App Service Plans for Functions and others.