Navigating Impact of Pricing Model Changes: BigQuery Example

Various FinOps Slack channels had given us an indicator 3-4 months in advance that Google was making a change to their pricing model beginning July 2023. At the time, no one in the Slack community could help us in determining its impact on our organization. Many experts’ provided hyperlinks to complicated documents on Google’s site and unless you knew how to decipher and understand the technical jargon, you were left to figure it out yourself. Internally, there weren’t many leads who could provide help in figuring this out. Procurement hadn’t a clue about it, finance pointed to IT and IT folks kept spinning in circles in trying to figure out who in the organization could perhaps provide assistance.

Finally, a short video on Google’s YouTube channel provided further insights and their Product Manager showed users how to use the search functionality in Billing Reports within the Google cloud console. This redirection was very helpful. Using “Big Query” in the search criteria, we found that the entire organization’s combined cost on Big Query was quite small and even if Google raised prices, we collectively came to an agreement that it did not warrant us to spend our time chasing this down. The financial cost seemed minuscule and we accepted the risk of a 25% rate increase.

Navigating change

Along came July 2023. While reviewing our team’s weekly costs, we were shocked to find out that the daily costs had exceeded 100% increase for the BigQuery API service. The price tag was higher than our original assessment of what we thought covered the entire organizational cost. I immediately alerted the technical lead about the consequences of the alteration in the BigQuery pricing model.

During the next few weeks, we sat down with experts from Google and did some adjustments that were customized for our organizational needs. It was the same pricing model, but setting specific parameters made a huge difference to our bottom line.

A month later when reporting back our costs, we were extremely happy to see a dip in the month over month costs by 97%. If this anomaly had gone undetected, the resulting incremental cost would have impacted the budget quite significantly. And finally I have an alert mechanism to notify me if the cost deviates from the previous day by 10% – but I still have to determine if it warrants the developer’s explanation.

Lessons Learned

1. When you see (or hear) something, say something. Take accountability and don’t leave any stone unturned to assess impact of changes to usage or rates.
2. Stay current with the Cloud Service Providers’ changes in their offerings. Each CSP releases many SKUs and newer tools to help customers. Sometimes these are embedded deep within the CSP console and not always easy to find (or understand).
3. An effort can be a failure, but let there be no failure of an effort. This experience was a learning moment for all of us. The psychological safety factor played a huge role in my ability to raise awareness of the upcoming change, lead down a path of exploration, and also raise a red flag when the costs did not fall as per our plan.
4. Process efficiency – We now have automation built in anomaly detection to send us alerts when there is a +/- 10% variation in the daily costs. These alerts have been set at the project level to inform the FinOps practitioner via email notifications. The process improvements have resulted in a 25% reduction in the time of one full-time equivalent (FTE) who previously performed this task manually.
5. Accountability structure – when anomalies are reported to the FinOps practitioner, they do an initial assessment to see if it qualifies further exploration. If it needs additional attention, they work with each team lead or technical lead who can focus on analyzing the root cause. Team collaboration, shared responsibility and accountability are key FinOps principles that guide the activities of FinOps practice.