It is really important for companies to have implemented strategies and policies defined before starting to implement integration solutions on Azure or give decision design power to external consultant companies, such as:
- Which services are part of the middleware solution in Azure?
- What are they for, and when can we use them?
- How can we handle requirement exceptions?
- Naming conventions, CI/CD, and tag policies
- And so on.
I’m about to tell a real story about how I saved more than 20K a year for one of my clients and why those reasons above are so important. I should have asked for a bonus since they have already saved more than 100K because of me.
One of my clients decided to do a POC on Azure Integration using Logic Apps and Service Bus, and during that period, I was busy working on a critical application for that client. So, they decided not to initially involve me and delegated this POC to another partner. The requirements were quite simple:
- They would like to have an async process to integrate HR information between the two systems.
- They would want to use a no-code, low-code approach using Azure Integration Services as much as possible.
And they did it! They actually implemented a very good solution, looking only at the technical implementation. They decided to design a push implementation that allowed an almost real-time integration.
Once my client contacted me to help them deploy it to production, I only knew that this was a POC and, if everything went well, would be used in production as a real solution. So, if they were asking me to help them deploy to production, that meant at that point that:
- Everything worked well and as expected.
- The requirements were accomplished.
- And they already accepted that solution.
However, I asked if I could do a minor assessment of the solution, mainly to understand how the pieces were built and how we could deploy them to production, and since I was doing it, validate if everything was according to best practices.
And after analyzing the solution, I became curious, so I went to my client and asked the following questions:
- Is this a mission-critical application?
- Client: No, this is not a mission-critical application.
- Do you need almost real-time integration?
- Client: No. Even if they are not integrated today, they will be resent tomorrow or in the next synchronization.
- On average, how many messages do you send per day?
- Typically, close to 100 or less.
- Are they big messages (more than 256 KB)?
- No, they are small.
Of course, I already expected this type of response and had my homework done. Tools like Serverless360 are used to analyze the cost of the application, and the Azure Calculator is used to predict the costs. I had a rough estimation of how much this solution would cost my client monthly and yearly.
I know they are a big company, but I asked the most obviously logical question in this situation:
- Do you know how much this solution costs to you?
- Client: Not really, but I know that we have already exceeded the planned budget. Do you know how much?
They were shocked when I told them: ~$677 per month.
But that was worse because they have four environments: DEV, TEST, QA, and PROD, so they need to multiply that by 4, meaning ~2.7K per month, which means close to 32.5K per year! To process 100 messages per day on a non-critical application!
Is there a better approach?
Well, I don’t say that there is a better approach. An approach is good when it will fulfill the technical and financial expectations. In many cases, the previous approach will be the better approach. Especially if you already have Service Bus premium in your organization and several applications are using that.
Now, if you are starting your journey with Azure or want to control the cost, you should opt for a significantly cheaper approach that also fulfills all the technical requirements.
So, how can we reduce the costs of this solution by 99%?
Yes, you are reading correctly. Actually, it is more than 99% since by the time we end refactoring, the estimated monthly cost was $2.68 (don’t forget we had four environments) or $128.64 per year!
Basically, the only drastic difference in the design of the solution was to transform it into a pull architecture.
- Because we only needed a queue, we have downgraded our Service Bus from Premium to Basic.
- We removed the Event Grid from the equation since it requires Service Bus Premium.
- And finally, we change the trigger of the Logic App to pull messages from the Service Bus queue each X minutes.
All the requirements were accomplished with this new architecture. The costs were surprisingly cheap, which motivated the client, who was already concerned about Azure costs, to adopt more cloud integration solutions.
The solution is still running in production without any changes or improvements.
I hope you enjoy this cost reduction tip, and stay tuned for more content.
Hope you find this helpful! So, if you liked the content or found it useful and want to help me write more, you can buy (or help me buy) my son a Star Wars Lego!
