[The following article is a guest post by Stefan Denk at Alescent, a Microsoft Partner. The views and opinions expressed in this article are those of the author. We thank Stefan for sharing his organization's story.]
When I look back at our early days, it almost seems surreal how our Cloud Economics Practice at Alescent evolved - bootstrapping a 360-degree cloud economic optimization from an internal Excel-based cloud cost analysis service, we have built a state-of-the-art FinOps hubs-based solution with a myopic focus on value realization. In this story, we share our technical evolution and a whole lot of learnings along the way.
Humble beginnings: The Excel era
About five years ago, in 2020, I was working as a cloud solution architect for my former employer – a company deeply embedded in the Cloud Solution Provider business. We set out to build a FinOps capability within the B2B consulting department, driven by the belief that the CSP should always act in the end-customer's best interest. Our initial approach was simple: we began by examining cloud cost data, focusing primarily on Azure (with a touch of AWS).
Back then, our analysis was rooted in Excel. I remember the excitement of uncovering cost patterns in data that spanned thousands – if not millions—of rows. We focused on three key Azure services:
- Virtual machines
- Virtual machine scale sets
- Azure Kubernetes Service
Using a combination of 'fgrep' and Linux shell scripting on an Ubuntu shell via Windows Subsystem for Linux, I filtered out the irrelevant data. We were clear that this was only a partial view - capturing just the compute and licensing costs - but it was enough to reveal that many customers were overspending. In fact, our early analyses showed potential savings between 15% and 30% of their total cloud costs. These savings were primarily due to two things:
- Outdated services: Many customers weren’t leveraging the latest VM versions, missing out on better per-vCPU performance and the opportunity to right-size their configurations.
- Licensing oversights: For Windows Server, customers often used Azure’s “license included” feature instead of taking advantage of cheaper licensing options through the Azure Hybrid Use Benefit (AHUB) feature.
The results were eye-opening. Customers who had migrated from their on-premises data centers in a typical lift-and-shift manner were wasting significant amounts of money on compute services and licensing: a realization that paved the way for more radical changes.
The breakthrough: Transitioning to Azure Data Explorer and Kusto Query Language
Despite the effectiveness of our Excel-based method, its limitations soon became too great to ignore. Enter Azure Data Explorer (ADX), and its powerful query language (KQL). My colleague Roland, who had a strong background in development and IoT proofs of concept, using ADX and KQL, made the case for transitioning our data analysis to ADX. Initially, I was skeptical. My bash scripts and Excel workflows, while cumbersome, were working. But the simplicity and power of KQL quickly won me over, as – having founded my own company – I quickly had to step up my game from merely providing optimization recommendations to achieving value realizations.
From that moment on, we – Roland and I – embarked on a new chapter. Working with ADX revolutionized our process. Suddenly, questions that once took hours to answer in Excel were resolved in minutes with a few lines of KQL. For example, in our working group and steering committee meetings, queries like "what has been the cost trend of our Premium Managed Disks?" or "how significant was the impact of reducing instances in our App Service Plans?" shifted from "I’ll get back to you" to "Let’s check it right now." The ability to produce credible, live data answers on the spot dramatically boosted our credibility with IT leadership – while being able to do complex calculations like the break-even of a reservation or of a commitment tier expanded both the savings potential we could tap into as well as our rapport with the cloud ops engineers supporting our FinOps programs.
And all that with data never leaving our customers’ Azure tenant: we deployed ADX into their subscriptions and opened the cloud data providing full visibility, cost transparency and allocation – sometimes for the first time – to all stakeholders in our customers’ project environment.
Our customers’ technical teams soon jumped on the KQL train. Not only did our data analysts start exchanging KQL snippets with our internal team, but our customers’ engineers began writing their own queries to generate real-time insights from Azure cost data. This cultural shift from static Excel reports to dynamic, code-driven real-time dashboards revolutionized the way cost optimization was approached.
Embracing the FOCUS standard and the FinOps hubs transition
The evolution didn’t stop with KQL. Soon after, the FOCUS standard was released, merging EffectiveCost and BilledCost into a single, unified dataset. We adapted our ingestion process to the FOCUS standard—preserving our quality-of-life improvements like calculating "first used" and "last seen" dates for resources and splitting critical tags (such as "environment" or "application") into dedicated columns. This transition significantly improved query performance and enriched our data analysis.
In late 2024, we learned about Microsoft’s FinOps toolkit and the FinOps hubs solution was also moving to ADX and KQL. Thanks to Michael Flanakin and his team’s work in mapping different FOCUS versions for backward compatibility, the transition was seamless. We only had to update a few details in our KQL queries – changing table names and converting certain data types - to cut over to FinOps hubs. Our dashboards continued to function without interruption, and our customers barely noticed the switch. In fact, our new ADX & KQL-based FinOps hubs service provided an even more robust foundation for real-time cost management by adding our dashboards and analysis scripts on top of the dashboards provided by FinOps hubs.
The impact on our journey and our customers
This transformation had a profound impact on our work:
Customer success:
By transitioning to ADX, we helped customers drastically reduce their cloud costs. Our dynamic dashboards and live queries became a cornerstone of our service, leading to contract renewals and expanded FinOps capabilities.
Internal evolution:
The success of our ADX implementation not only enhanced our credibility but also drove a cultural shift. Our customers' engineers started interacting with our data in real time, exchanging KQL code snippets, and independently verifying our findings.
Strategic partnerships:
This journey was not just a technical evolution—it was a turning point that spurred strategic growth. What started as a two-man show with Roland and me has grown to a team of 20 people with skills ranging from FinOps over license and contract optimization to AI development, using of our Value Realization Framework to drive economic optimization inside and around the public cloud.
Conclusion
Our journey from Excel to FinOps hubs is a testament to the power of innovation and the importance of evolving with the tools at our disposal. What began as a rudimentary Excel analysis transformed into a cutting-edge, real-time data processing platform that reshaped our approach to cloud economic optimization. This evolution not only enhanced our technical capabilities but also revolutionized how we interact with our customers – turning static reports into dynamic, actionable insights and reducing implementation times from months to days.
I hope this narrative not only informs but also inspires you to embrace change and continuously seek better solutions. Our journey is a living story, one that continues to evolve, just as our technology and strategies do.
Follow-up discussion:
I’d love to hear from you all – what additional details, anecdotes, or angles should we explore in future blog posts about our journey? How can we further illustrate the impact of our transition on both our internal processes and our customers’ success?
