Another good example that when using cloud, you must always follow the cost structure of your application.
Yesterday after checking on one Logic App in development environment with simulated production load, we noticed that about 75 % of it’s cost was coming from history data retention – and no wonder, the default 90 days is a loooooong time for image binaries to be stored. Especially when after completion this binary data is absolutely not required for anything else.
The portal has (as a preview feature) a setting to control data retention time, so just what we needed…setting a smaller value and everything is fine.
…except after next time our release pipeline updated the Logic App, it was back to default setting of 90 days.
But if it gets overwritten, you’ll have to be able to set it somehow in ARM template, right? Unfortunately, a quick search and documentation didn’t help this time. There was only a short Stack Overflow answer on how to set the Hight throughput value above this one – also undocumented feature. But that meant that there is must be an answer.
Derek Li helpfully tipped me to right direction on Twitter:
Should be possible. I’d take a network trace setting it in portal and duplicate it in ARM template.
— Derek Li (@derek1ee) 19. kesäkuuta 2019
And so I did press F12 on my browser, changed the value in portal and the answer was in the network trace on this line – just like Derek suggested.
Opening the JSON payload revealed the final answer:
And now I just had to copy-paste the runtimeConfiguration part to the ARM template, under Logic App resource’s properties. Valid setting is from 7 to 90 days like in portal, and you can’t set it smaller in template either – tried it 🙂
But why?
We calculated that this setting change – when it’s automated and not relying on someone to remember to update it manually – will actually save the customer a couple of hundred euros per month. Naturally, by using Azure Functions, we could almost completely eliminate this cost. But this customer prefers Logic App integration workflows, so at least we are now optimizing the costs. So – closing with the same words as I started:
This was another good example that when using cloud, you must always follow the cost structure of your application.
PS. Thanks also to my ex-colleague Okko Oulasvirta (Twitter: @okkooulasvirta) who seemed to test this same functionality last night about the same time as I did and confirmed my findings on a Finnish Azure slack channel.
