Vijay Raina is a powerhouse in the world of enterprise SaaS and software architecture, bringing a rare blend of technical depth and strategic foresight to the evolving landscape of cloud economics. As organizations grapple with the seismic shift toward artificial intelligence, Vijay has become a go-to authority on how to navigate the complex trade-offs between ballooning infrastructure costs and traditional software investments. His perspective is particularly vital now, as the industry moves from a “growth at all costs” mentality to a disciplined, “two-speed” budget reality where every dollar spent on a GPU is a dollar potentially taken away from a software seat. This conversation dives into the heart of the “engine room,” exploring how FinOps must evolve to manage the friction between the data center and the boardroom.
The core themes of our discussion center on the dramatic divergence in IT spending priorities, where data center and server investments are projected to massively outpace software budgets in the coming years. We explore why traditional FinOps tagging and “pay-as-you-go” models are insufficient for the persistent, high-utilization nature of GPU workloads, and how this creates an internal conflict between platform teams and business units. Vijay also outlines a pragmatic roadmap for budget reallocation, emphasizing the need for granular workload classification, rigorous seat audits, and the implementation of “governance with teeth” to prevent idle compute power from silently dismantling a company’s productivity toolset.
With data center systems projected to surge by more than 50 percent in 2026, we are seeing a massive shift in where the next dollar of IT spending goes. How are organizations identifying which “nice-to-have” platforms or software licenses to cut to make room for this expensive GPU power without hurting their core operations?
It is a fascinating and somewhat ruthless time for IT budgeting because we are operating in what I call “communicating vessels”—the budget pot isn’t necessarily getting bigger, it’s just being reshuffled. When the GPU invoice or a massive colocation megawatt commitment lands on the CFO’s desk, the immediate reaction is to look for “fat” in the software layer, which is currently only growing at low-to-mid single digits. We are seeing a very consistent pattern where organizations target duplicate productivity suites and unused seats that often linger after a merger or a period of rapid tool sprawl. There is a specific focus on observability and developer tooling where overlap is rampant; for instance, a company might realize they are paying for three different APM licenses or two redundant CI systems. It isn’t about a “drama-filled” slashing of budgets, but rather a cold, hard look at feature modules in ERP or CRM systems that were purchased with high hopes but never actually adopted by the workforce. This reallocation is the only way to fund the massive 30 percent growth we see in server and data center requirements without blowing the entire corporate forecast.
You’ve mentioned that traditional cloud FinOps logic often breaks when it encounters the reality of GPU demand. Why is the “pay-as-you-go” default no longer enough, and what structural changes do teams need to make to their cost profiles?
Traditional FinOps was built for the era of elasticity—instances you could spin up for an hour and shut down, or storage that you could tier based on age. Persistent GPU demand completely shatters those assumptions because training runs can span days or even weeks, and inference clusters need to run at high utilization to be even remotely cost-effective. The granularity is the first thing that bites you; while a SaaS license is predictable every month, a GPU hour fluctuates wildly based on the spot market, regional availability, and even the specific model size you are loading. We are seeing a move toward “CapEx pressure” even in the cloud, where teams have to lock in budget for reserved instances or committed-use discounts just to secure the capacity they need, which creates a huge risk if that capacity sits idle. The most successful teams I see are moving away from a single “GPU blanket fee” and instead categorizing their spending into clear workload classes: training, batch inference, and experiments. Without this distinction, you end up with a 100 percent on-demand GPU pool, which isn’t a strategy—it’s just an expensive convenience that drains the budget.
There is an inherent conflict when the AI team scales their infrastructure while a business unit loses a vital tool to pay for it. How can leadership bridge the gap between the platform teams managing GPUs and the business owners who are seeing their software budgets evaporate?
This is where the “unfairness” of the shift really hits home, and it’s a major cultural hurdle for many DACH organizations and global enterprises alike. SaaS is typically bought by a specific line of business to solve a specific problem, but GPU capacity almost always lands in the lap of the platform team or a centralized Cloud Center of Excellence. To resolve this, you have to move toward “showback before chargeback,” making the costs per workload class visible to everyone before you start sending internal bills. I always recommend a quarterly joint review where the license owners and the cluster owners are forced into the same room to look at the data together. If you only review SaaS, you see half the truth; if you only review GPUs, you might be silently dismantling the very productivity tools that the AI is supposed to enhance. It requires a single currency where GPU hours, tokens, and SaaS seats are all converted into euros per month per team so the debate stays grounded in financial reality rather than office politics.
When looking at the physical location of these workloads, there is a constant debate between public cloud, colocation, and on-premise hardware. What is the actual calculation teams should be doing to decide where a model belongs, especially considering site risks like grid access?
The decision-making process has to be driven by utilization data rather than “gut feel” or a generic “cloud-first” mandate. For short-lived experiments or unpredictable peaks in demand, the public cloud is almost always the winner because of its sheer flexibility. However, once you see stable, high utilization that stretches over months, the economics start to favor reserved instances, colocation, or even bringing capacity back on-premise. You have to factor in more than just the hardware; you have to look at power and location, because capacity without grid access or the right permits is essentially dead budget. I’ve seen projects stall because they didn’t account for the site risks in data center projects, which can be a massive hidden cost. Without a rigorous cost model that compares these runtimes, any claim that “on-prem is cheaper” is just an assertion, not a real financial calculation.
For a FinOps team looking to get their house in order during this reallocation phase, what are the “quick wins” or “kill switches” they should implement immediately to stop the bleeding?
The fastest lever you can pull, even before you start killing licenses, is implementing a hard kill-switch for idle experimental clusters and notebook instances. If a data scientist leaves a cluster running over the weekend without an active job, that is pure waste that could have funded several software seats. We also advocate for a strict 90-day usage audit for all software licenses; if a seat hasn’t been touched in three months, it should be on the chopping block, but you have to do this with data to avoid repurchasing those same licenses at a higher price next quarter. Another critical step is moving to a quota system for experimental teams—giving them a specific GPU-hour quota per sprint rather than an open-ended credit card. If they exceed that quota, it requires a formal approval process, which forces a level of discipline that prevents the “Q3 surprise” where the GPU invoice suddenly dwarfs the entire software forecast.
What is your forecast for the future of IT budgeting as AI infrastructure continues to mature?
I believe we are entering an era of “hybrid governance” where the distinction between a software budget and a hardware budget will almost entirely disappear, replaced by a “workload-centric” view of the world. In the next two to three years, the most successful companies won’t just be the ones with the best AI models, but the ones with the most disciplined allocation engines—those that can pivot a euro from a legacy CRM module to a high-inference cluster in real-time based on actual ROI. We will see a stabilization in the growth of data center systems as efficiency improves, but the pressure on “shadow SaaS” and underutilized licenses will remain permanent. The “engine room” of the future will be run by teams who can plan their reallocation with surgical precision, rather than those who simply endure it as a series of budgetary shocks. Do you have any advice for our readers? My advice is to stop looking at your cloud bill as a single line item and start treating your GPU capacity and your software licenses as two sides of the same coin; if you don’t manage them together, one will inevitably devour the other.
