Keeping an eye on a problematic integration

Problem

A customer had a problematic integration workload where most of the time it was really cheap and just did its job but on occasion people would be testing one of the systems and not identify the side effect of some of their testing was an increase in the data processed by an integration in the test environment.  They wouldnt realise to communicate with the integration team to suggest they might want to turn the integration off as it was outside of the scope of the testing but would have a cost increase as a side effect of the testing.

The integration team wanted to keep a close eye on the costs for this integration so if the testers were using the system in an unplanned way they could jump in and turn off the integration before the costs got too high.

Analysis

Using Turbo360 they were able to create a node on the tree view and allocate only the resources specific to this problem to that node.  It would allow them to very closely monitor the Logic Apps and Function costs associated with this integration across all of their environments in one place.

They were then able to create some graphs which gave an easy view of the running costs.  Below you can see the costs in all environments.  The blue like is the production cost which you can see is very stable but the purple cost is the test environment which you can see spikes up and down a lot more based on usage.

They were then able to create a group budget to keep an eye on the daily costs of this integration workload so that it would alert if there was some higher use than expected.  

The customer didnt care too much if there were occasional days where the cost spiked up, they would get an alert so they knew testing had been going on, but what they wanted to avoid was this cost increase being every day.

Normally the total cost of the integration for the month was around $150.

If the testers kept testing a lot every day then the side affect of the testing was that the integration (which wasnt part of their test scope) could get a lot of additional data and then for a month it would jump up to $600.

The customer could then jump in and pause the integration, communicate with the project team to understand the timeline and then turn it back on at an appropriate time.

You can see below how the anomaly detection would also catch unexpected costs

Solution

In this case one team (the integration team) had a planned budget for their operational costs, but because they integrate all of the different systems and are using a consumption based pricing model, other teams could cause the integration team to have unplanned costs that would not be expected by anyone because its a side effect of an activity the users were doing.

This can happen for event driven and batch based integrations.  A great example might be if you do a bulk data load into a system then it will push out lots of additional data on downstream integrations.

Using Turbo360 the customers integration team were able to reduce their risk of unplanned costs eating into their operational budget.