Express Computer
Home  »  News  »  Your cloud bill isn’t the problem. Your operating model is

Your cloud bill isn’t the problem. Your operating model is

0 55

The cloud migration era is over. The harder part has begun.

Most large enterprises have moved their workloads. Far fewer have changed the way they run them. Now, with multicloud estates sprawling, agentic AI arriving and legacy ERP platforms still carrying the business, CIOs are being asked to optimize, modernize and secure everything at once, without breaking anything that makes money today.

Satyendra Pasalapudi, CEO of digi edZe, has watched this pattern play out across more than 26 years in enterprise technology. His diagnosis is blunt, and it starts with a gap most boardrooms don’t see on a dashboard.

“Most enterprises migrated their workloads but never migrated their operating model. They built the business case on elasticity, then carried on with datacentre habits: static sizing, capacity bought in advance, change windows.” The consequence, he says, is easy to state and expensive to live with: “cloud pricing for datacentre behaviour, and that is where value leaks.”

Multicloud’s real problem: nobody knows what anything costs

Pasalapudi says three challenges surface in almost every conversation he has with enterprise leaders about multicloud.

The first is unit economics. With several providers, each with its own billing model and taxonomy, finance and engineering teams can’t answer a deceptively simple question: what does it cost to process one claim, one policy or one order?

“Without that denominator, FinOps becomes monthly reporting rather than an engineering discipline.”
The second is data gravity. Compute moves easily between clouds. Data does not. Egress charges and latency penalties quietly turn ambitious multicloud strategies into something else entirely.
“Compute is portable; data is not, and egress and latency penalties turn many multi-cloud strategies into data architecture failures.”

The third is AI. GPU availability, inference economics and sovereignty requirements are now shaping where workloads can live, particularly, Pasalapudi notes, in India and the GCC.

His prescription is to stop treating multicloud as a destination and start treating it as a placement decision. “I would start with workload economics, classifying by latency, data volume, and regulation, so that multi-cloud is deliberate placement.” That also means abandoning the hope of a single, universal balance between performance, cost and flexibility. “I would accept that performance, cost and flexibility can only be traded off workload by workload.”

Where should standardization happen? Pasalapudi draws a clear line: containers, infrastructure-as-code, observability, identity and policy should be common across clouds, while the providers’ managed services stay in play, “because that is where the differentiated value sits.”

Agentic AI: the model is the least important decision
Ask most executives about their AI plans and the conversation quickly turns to vendors and models. Pasalapudi thinks that’s the wrong starting point.  “Everyone asks which model to pick. In my view that is the least important decision, because agents fail in production for architectural reasons, not model reasons.”

The architecture problem begins with data. Enterprise data has largely been built for reporting, not for reasoning. An agent arrives with no institutional memory, so meaning has to be made explicit through an ontology, a semantic layer, lineage and permissions that travel with the data. “The bar rises sharply once an agent acts rather than answers.”

Infrastructure has its own gap, and it is identity. Agents need their own identity, scoped entitlements and an audit trail, with inference capacity located close to the data. At the application layer, agents need tool-callable interfaces with defined contracts, idempotency and rollback. Testing changes too. Teams need evaluation-driven development, Pasalapudi says, “because you are testing behaviour across a distribution.”

Sovereignty is bigger than residency
On data sovereignty, Pasalapudi argues that many organisations are defining the problem too narrowly.
“Sovereignty is broader than residency. Prompts, retrieval patterns and decision traces are as sensitive as the data, so the reasoning layer should run inside the enterprise perimeter.”
That is the principle behind Sovereign AI, the approach digi edZe describes as keeping the knowledge layer under customer control and portable across models.

A ladder for domain relevance
For making AI relevant to a specific business, Pasalapudi uses what he calls a ladder: retrieval for fast-changing knowledge, fine-tuning for how an organisation reasons, and continual pretraining “only for genuinely proprietary domains.” Start on the lowest rung that solves the problem.

Measure the task, not the token
Cost is where agentic ambitions often meet reality. Multi-step workflows consume many multiples of the tokens a chatbot does. His advice is to right-size the model to the task, move to contained infrastructure as volumes stabilize, and change the unit of measurement entirely: “measure cost per completed business task, not per token.”

The winners, he suggests, won’t necessarily be those with the biggest models. “The outpacing will be those whose data and processes are legible enough for an agent to act on.”

Modernizing legacy without betting the business
For all the excitement around AI, much of the world’s revenue still runs through legacy applications, databases and ERP platforms. Pasalapudi has little patience for the approach that has burned so many programs.

“The classic failure is the big bang replatform. It is a three-year programme where, by year two, the sponsor has changed and nothing has gone live.”

His fix is to separate three things that organisations routinely conflate: moving the platform, changing the code and changing how the business works. Attempted together, “every problem becomes unattributable.” Instead, he sequences the work: move, stabilize, modernize, then redesign the process.

Two disciplines keep that sequence safe. An API layer lets new capability build against a stable contract while the legacy core changes underneath it. And every cutover needs a rollback that fits inside the maintenance window, planned around the business calendar. He also treats the estate as a portfolio rather than a single project: some systems are rehosted, some are wrapped, and others are planned for retirement.

Where to spend the next rupee
Pasalapudi is direct about where he would put investment first. “APIs are the highest-leverage investment, because they serve modernization and agent access to legacy systems at once. If an enterprise asks where to spend their dollar, it is there.”

Cloud-native architecture, he argues, “earns its keep at the edge,” in new services, channels, integration and analytics, while systems of record can stay put longer when the interface layer is right.

AI’s strongest role in modernization is not what most people expect. It is less about generating new code and more about understanding the old: code comprehension, dependency mapping and recovering business rules that nobody documented. AI also speeds up testing. But he is skeptical of the hype around code generation. “Writing code was never the hard part of an ERP migration; understanding and testing were the tough parts.”

Managed services: the best provider is the one you hear from least
The economics of managed services are quietly colliding with automation. “The traditional model is bodies multiplied by hours, and automation is hostile to it. If a provider automates away much of the toil, under most contracts they have reduced their own revenue.”

So before evaluating any provider’s AI roadmap, Pasalapudi asks a contractual question first: does the commercial model reward them for doing less work?

Inside the enterprise, the shift is just as significant. L1 support increasingly becomes machine work, and human value moves to L3 and engineering. “Teams stop running systems and start governing systems that run themselves, a skills transition most organisations underestimate.” And predictive operations have a prerequisite that is easy to overlook: years of consistent telemetry. “Fragmented monitoring gives you anomaly detection, not prediction.”

Rethinking the scorecard
Traditional response and resolution SLAs, he says, have a perverse side effect: they “reward incidents existing.”

His preferred measures point in the other direction:
• Auto-remediation rate
• Mean time between failures
• Change failure rate
• Incidents prevented
• Cost per workload falling over the contract term

Outcome-based contracts are the right destination, but Pasalapudi acknowledges they are hard to write. His advice is to start hybrid: a stable baseline, plus “a meaningful fee at risk against two or three outcomes both sides can measure.”

To connect operations to the business, he recommends defining service tiers around processes rather than infrastructure: payment availability, claims throughput, order-to-cash cycle time. Then track the cost per business transaction.

“The best managed service is the one you hear from least, provided the commercial model does not penalize silence.” That premise, he says, underpins digi edZe’s autonomous operations capability.

Resilience in the age of agents: Identity is the new perimeter
As workloads spread across clouds and AI agents begin to act on behalf of the business, Pasalapudi believes security teams are guarding the wrong thing.

“Identity is the new perimeter. In a multi-cloud estate, the real attack surface is accumulated entitlements nobody has reviewed in years, and agents magnify that, operating at machine speed with credentials.”

His answer is to insist on scoped, time-bound, auditable access from day one, and to extend protection to the AI stack itself, including models and knowledge layers, against prompt injection, data poisoning and supply-chain threats.

Disaster recovery needs the same honesty. Most plans, he says, are written for infrastructure failure, yet the incidents that have hurt most recently were control-plane, identity-provider, certificate or configuration failures. He urges teams to test those scenarios, map dependencies candidly, and define AI containment, rollback and stop authority.

An untested kill switch is not a control
On governance, the goal is not to add gates but to remove friction from doing the right thing: “encode guardrails in the pipeline so the compliant path is the easiest.” That is how, in his view, organisations keep resilience from slowing innovation.

Four lessons from 26 years
Asked what two and a half decades across cloud transformation and enterprise technology have taught him, Pasalapudi offers four lessons.

1. Technology failures are ultimately ownership failures. When something breaks badly, the root cause is rarely the technology. It is that nobody clearly owned the outcome.
2. Untested recovery is not recovery. He recommends testing restores quarterly, in production conditions.
3. The fastest organisations have the strongest fundamentals. The reason is simple: “real rollback makes being wrong cheap.”
4. Transformations succeed when business and technology leadership stay in the room when it gets difficult.

The last, he says, is the one that decides outcomes. “Architecture is solvable; misalignment is what kills them.”

The takeaway for CIOs
Pasalapudi’s message is that the next phase of enterprise technology will not be won by the organisation with the most clouds, the biggest model or the boldest roadmap. It will be won by the one that has done the unglamorous work: knowing its unit costs, making its data legible, putting APIs in front of its legacy core, aligning its contracts with its goals, and rehearsing failure before failure arrives.

For CIOs weighing where to start, his advice amounts to a short list of questions. Do you know what a business transaction costs you today? Can an agent understand your data, and be held to account for what it does with it? Does your provider profit when your systems break? And if your most important system failed this quarter, who owns the outcome, and when did you last prove you could

Leave A Reply

Your email address will not be published.