We’ve been handling cloud and DevOps for our clients for years, which also means we've been helping them make sense of their cloud bills and cut down waste. We’ve tried plenty of cloud management tools along the way, most of which are SaaS-based and require exposing sensitive client data. The ones that come from the cloud providers are usually limited in scope and take forever to update their features.
Then we found Finala.
At the end of 2024, one of our team members came across Finala, an open-source, self-hosted tool. Finala scans cloud resources based on the rules you define in YAML files. For example, you can set a rule to find servers that are only utilized by 50% over the last 14 days.
How had we never heard of this before? Well, there had been no commits in over four years on GitHub.
Even with its old code base, it seemed to have a lot of potential. It is written extensively in Go and uses ReactJS as a frontend.
But it needed work.
During our review, we found a couple of issues with how the code was written against the old AWS APIs. Because of this, some services, such as RDS, no longer worked.
I took a quick jab at it, and even though I wasn't a Golang developer by any stretch of the imagination, I was able to create a simple fix for the RDS service. Excited, I raised a PR to SimilarWeb (the maintainer of Finala), but got no response. It seemed that any issues we found, we would have to fix ourselves.
Well, QBurst had a lot of developers; surely they could help us fix them?
Tackling the Problems in Finala
QBurst has an open source initiative to encourage resources with the time and inclination to contribute to the community. This seemed perfect for our use case. We reached out to them and created a roadmap of what we would like to see. We forked the project and got started.
We had five major asks at the time:
- Fix any bugs similar to the RDS we had encountered.
- Add a functionality to export results via email.
- Refactor the code to use less memory (by default, the system took anywhere from 8 GB to 12 GB of RAM)
- Update the codebase to newer versions of Go and React.
- Implement a login page.
The team, though, had other projects going on, which meant they had to prioritize the work they put in. Also, the number of Golang developers who had free time could be counted on one hand. Still, they did address the first two, so we could at least start using it internally till we got the rest of the features going.
We adapted.
Is the system taking up too much memory? Let's try hosting it internally on a Kubernetes cluster and schedule the collectors during off-hours.
Authentication page not available? Fine, let's implement a simple HTTP basic auth page via Nginx until they get around to it.
Unfortunately, other projects intervened, and we ended up moving Finala to our list of backlogs and nice-to-haves.
Revisiting the Problems with AI Assistance
The project picked up again when our company started rolling out Cursor and Copilot licenses. Though I was reluctant to incorporate AI into my regular workflows due to the number of mistakes the earlier models made, vibe coding felt like the right fit for our Finala problem.
I asked Cursor to optimize. It went wild.
My first prompt to Cursor was along the lines of “go to town, reduce the memory footprint of this project”.
And it did. It edited files left, right, and center.
A few iterations later, everything was broken. The application stopped showing any metrics and just gave an empty page. That kicked off a cycle of feeding error after error to Cursor and waiting in between.
A dead loop.
Something wasn’t right. Was this the best that AI had? Or was I doing it wrong?
I turned to good old Google to brush up on prompt engineering tips and came back armed with the specific problem I wanted addressed. Finala was based on ElasticSearch, which seemed to be taking too much memory to run. How could I solve this while not changing the API's input-output structure or the core architecture of the system?
Cursor gave me my first valid idea: why not try migrating to Meilisearch?
Eureka!
I spent a week of my free time talking and playing with Cursor to migrate Finala from ElasticSearch to Meilisearch while not breaking the existing APIs.
There was a lot of back and forth. I gave it smaller tasks. I congratulated it when it got things right, and told it to stop each time it went on a tangent.
And it worked.
In a week, I had tackled all the major features we had been sitting on for months.
The New Finala
The project that emerged from that week is a different beast entirely:
- Reduced Memory - Migration to Meilisearch reduced Finala's memory footprint from 8Gb to under 2GB.
- Updated Libraries - The underlying Go and React libraries got a full upgrade, along with security patches.
- Bug Fixing - Fixed bugs in the pricing API for ELB and ElasticIP.
- New Login Page - Earlier, Finala was open to anyone on the network. It now has a login page to restrict access to data.
- Improved UI - Split data into two categories: Potential Savings and Unused Resources. Previously, everything was lumped together and sorted only by dollar value. Now it’s easier to prioritize and review unused assets.
- Updated Documentation - Organized everything into clear folders and sections to make it easier to navigate. Since the official docs may no longer be maintained, this version might help in the long run.
What I Learned About AI While Rebuilding Finala
What started as a search for a better FinOps tool ended up shifting how I think about AI.
I came in with high expectations and little understanding of its limitations, assuming it would just figure things out. I've since learned that AI is best as a pair programmer: sharp in some areas, a complete dud in others. It needs direction, review, and feedback. That’s when it starts to actually help.
On a more personal note, I'm happy to give back to the community. Finala is now cleaner, more usable, and ready for others to build on.
Do check out the new Finala hosted in the QBurst repository.
Interested in FinOps? This post by my colleague might be helpful.
