At QCon London 2026, Luis Albinati and Surabhi Mahajan from JP Morgan Chase made the case that most enterprises are approaching multi-cloud in the wrong way. The problem isn't technical, it's organisational. Companies end up running across multiple clouds by accident, through acquisitions, shadow IT, regulatory pressure, or chasing GPU availability for AI workloads. Then they try to engineer their way out of the resulting mess, one fire at a time. Albinati and Mahajan argued that the only sustainable fix is to treat multi-cloud as a product rather than a project.
Albinati, a product director responsible for demand and portfolio management across JP Morgan Chase's multi-cloud platform, opened with what he called the "chaos tree." Cloud migration was originally sold on the basis of cost optimisation and agility. Neither panned out cleanly. Companies found themselves spending more, running ungoverned workloads, and layering on remediation programmes such as FinOps, governance, and SaaS compliance, each with its own tooling and headcount, until sixteen or more active projects were competing for the same engineering budget.
The core issue is that teams operate in silos. One team owns GCP, another AWS, another Azure, each with its own roadmap. When AI enters the picture, teams wanting access to Vertex AI, Bedrock, and Azure OpenAI simultaneously, those silos multiply. Nobody has the full picture.
Their proposed solution borrows from product management. Rather than organising around cloud providers, Albinati pushed for organising around capabilities: observability, cost management, identity, networking, and delivery. Each capability cuts horizontally across every cloud and business line, shifting conversations from "what does our AWS roadmap look like?" to "are we delivering unified observability everywhere?" He stressed structured demand governance, opening intake windows at a cadence, forcing teams to submit requirements, and closing the window to allow planning.
Mahajan, a principal architect and technical product manager for JP Morgan Chase's logging platform, brought the argument down to earth with a concrete example. She described what she called "Frankenstein logging", the reality of running a centralised logging platform that ingests data from GCP, AWS, and on-premise systems by funnelling everything into S3 buckets on AWS. The result: massive egress costs, noisy data, and SREs stuck correlating timestamps across three browser windows during a 2 AM incident.
Their fix was to think about it as a product team would. They identified their users, SREs, and cyber operations and studied how those users actually queried data during real incidents over the previous year. Then they deployed OpenTelemetry collectors at the edge in each cloud, filtering out health checks and low-value events before anything crossed a network boundary. Mahajan reported that this approach cut log volume by sixty to eighty percent, sending what she called "signals, not noise." They also standardised on distributed trace IDs as a "golden thread" that flows across all environments, which reduced the mean time to identify from hours or days to minutes.
Mahajan left the audience with a practical takeaway: a "console test", a set of scenarios that any platform team can run against their own logging infrastructure. If your platform passes, you've built something that treats the cloud providers as raw materials for a unified engineering experience. If it fails, you know what to fix next.
Albinati closed with a set of principles framed as a manifesto: capabilities over siloed solutions, shared discovery over isolated priorities, golden paths over bespoke one-offs, governance by design, and resilience over mere portability. He was blunt about that last point: portability solves some problems, but sometimes the answer involves better contracts about differentiated SLAs, not just better Kubernetes deployments.