While its flagship Dreamforce event was in full swing on Wednesday, Salesforce was triaging a roughly seven and a half hour-long service outage that disrupted user access and caused “severe delays” and intermittent errors. Some customers were also unable to submit new support cases.

The service outage hit at 3:50 a.m. EDT, impacting “multiple instances across all regions,” Salesforce reported. It was marked resolved right around 3 p.m. EDT, after several hours of monitoring to determine that fixes had been successful.

Salesforce initially pegged the issue to an “external dependency failure” impacting the legacy login server. A core system component experienced increased load, limiting its capacity to process requests. The company confirmed that there were no issues with third-party infrastructure.

Beyond the obvious embarrassment from the outage occurring during Dreamforce, an analyst said the incident highlights a cloud resilience problem, rather than purely a legacy one.

“Cloud does not eliminate architectural dependencies,” said Abbas Jaffery, a principal advisory director at Info-Tech Research Group. “It can sometimes make them less visible. And when the platform is your system of record, those hidden dependencies become an enterprise risk rather than simply a technology risk.”

Rolling restarts, persistent issues throughout the day

Salesforce began experiencing service issues at 3:50 a.m. EDT on September 16, and initial investigation determined that requests were stalling while waiting on responses from an internal login service that was using up available server resources.

Initially, Salesforce blocked application programming interface (API) endpoints and attempted rolling restarts to revive the service, then pushed out fixes region-by-region. At 7:20 a.m., some customers were seeing service return to normal, and Salesforce was working on a “code-level permanent fix.”

However, the rollout did not complete for a number of instances, and some automated fixes didn’t fully resolve the issue. For example, customers reported that scheduled jobs were not running as expected, even after service was restored. Salesforce manually restarted those ‌instances.

Salesforce later reported that the impact radius was “narrower than initially understood” and saw signs of recovery by around 11 a.m. EDT, with most customers coming back online.

A sub-set of Hyperforce instances were the last to be restored. Mitigations were in place across all instances by 11:39 a.m. EDT, and Salesforce continued to monitor the issue until marking the incident resolved at 2:59 p.m. EDT.

“We apologize for how this incident affected you and your business,” Salesforce posted on its incident blog. “We will undertake a full investigation of the incident, establishing the technical trigger, the underlying cause, and preventive action to avoid a repeat in the future.”

Creating a ‘temporal’ data problem

For customers for whom Salesforce is a system of record, several hours of authentication and service disruption can create a “temporal data problem,” Info-Tech’s Jaffery explained. “Events that should have happened at different points in time may occur later, fail altogether, or arrive out of sequence,” he said.

For instance, a customer interaction may occur through another channel while Salesforce is unavailable, but an integration, workflow, or scheduled process that normally records or propagates that event is unable to run.

This has several potential consequences, Jaffery said. Transactions and customer service processes are delayed; APIs and middleware may accumulate retries, timeouts, and queues. Records can become temporarily inconsistent, and scheduled jobs and workflows may be missed. Employees could lose visibility into customer history or case status, even when the underlying data has not been lost, creating a “data divergence.”

The first mistake would be to assume that just because users can log in, the incident is over, he noted. “Enterprises should move immediately into a reconciliation and integrity phase,” Jaffery advised. This means not only verifying interactive access, but APIs, integrations, scheduled jobs, queues, workflows, automation, authentication flows, and downstream systems.

Enterprises should ask what transactions failed, partially completed, or were duplicated during the outage? Which scheduled or asynchronous processes did not execute? Did integrations retry successfully, or did they create a backlog or retry storm? Are downstream systems now consistent with Salesforce?

Security teams should also validate authentication and session behavior, privileged access, integration credentials, and any emergency changes made during recovery, Jaffery explained. “The most important question is not simply ‘Is Salesforce back?’, but ‘What did the business expect to happen during the outage, and can we prove that it actually happened?,’” he said.

What to look for in post-incident reports

A credible post-incident review from Salesforce should establish a causal chain: The trigger, dependency failure, technical propagation, customer impact, detection, mitigation, recovery, and permanent corrective action, Jaffery said.

The company should be able to answer these questions, he said:

• What was the actual initiating failure and why did the failure propagate into the login path?
• Why could the affected dependency consume sufficient capacity to affect core services?
• Why didn’t isolation or failover prevent the impact?
• Why did initial remediation attempts fail and why did the subsequent rollout require additional intervention?
• What safeguards are being added to prevent recurrence?
• How will Salesforce demonstrate that the corrective action actually works under failure conditions?

Service restoration simply tells customers: “We got it working again,” he noted. But root cause analysis tells customers: “We understand why it failed, why our controls didn’t prevent it, and what has changed so that the same failure mode is less likely to recur.”

It’s not just about ‘legacy’ pieces in the stack

One architectural lesson is that a legacy component does not have to be large to be critical, Jaffery pointed out. An older authentication service can remain part of a modern stack, and therefore become a dependency for newer services.

“The component’s age matters less than its position in the dependency graph, its blast radius, and the quality of its isolation and failure handling,” he said, pointing to this incident’s progression: Requests stalled waiting on an internal login service due to increased resource consumption led to investigation into an external dependency failure, which in turn revealed impact on a legacy login server. Finally, Salesforce said, “core system components experienced increased load, which limited its capacity to process request”.

That is a classic resilience question, Jaffery pointed out: Can a failure in one dependency remain in that one dependency, or does it become a platform-wide failure?

Modernization should not be identified simply by how much old technology has been replaced, he noted, it should also measure dependency concentration, isolation, “graceful degradation,” recovery paths, and failure blast radius.

“For enterprise architects, that is the real takeaway,” he said.

Maybe driven by agentic AI, exacerbated by layoffs

At this point, there are no obvious signs that this was a security incident, noted David Shipley, CEO of Beauceron Security. “Right now, this bears all the hallmarks of an update gone horribly wrong.”

He pointed to an incident in December 2025 when Amazon’s internal AI coding agent, Kiro, caused a 13-hour AWS outage in a mainland China region, noting, “I’m not going to be shocked if we don’t see some kind of agent role in this kind of scale disaster.”

Significant Salesforce layoffs over the last few years could also have had a negative impact on the outage and recovery, he added. “Having it happen during Dreamforce had to be all kinds of hell, though, for their sales and customer support teams,” he said. “Pour one out for them as they work on rebuilding relationships, face-to-face.”

This article originally appeared on CIO.com.

AWS is betting that AI agents need a different interface as they move beyond answering prompts and start working autonomously in the background.

The company has open-sourced Pizza Bot, a self-hosted application that gives users an inbox for managing work delegated to AI agents, with separate threads for ongoing tasks and a queue for work that is completed or needs human input, rather than keeping the management of agents restricted inside a conventional chat window.

The rationale, according to AWS, is that background agents do not always need a user’s attention while they work, and an inbox model will let users hand off longer-running tasks, return to them later, and see which jobs are complete or require intervention.

Under the hood

That approach is reflected in how the inbox organizes work with the help of an “All” tab that contains the history of each task or conversation, including the agent’s messages and work performed, the “Unread” tab that flags completed work that users have yet to review, and an “Action” tab that surfaces tasks paused while waiting for user input or approval.

The inbox interface also has a panel named Activity that shows users how an agent handled a particular task along with the transcript, AWS wrote in a blog post introducing Pizza Bot.

AWS’ inbox-oriented rationale also extends to Pizza Bot’s architecture.

It uses LangChain’s Deep Agents as the harness and LangGraph as the stateful runtime, with a combination of the two allowing an agent to checkpoint its progress as it works, preserving its messages, tool activity and current state so a task can be paused and resumed rather than being tied to a live chat session, the hyperscaler wrote.

Pizza Bot’s server sits on top of that stack, connecting the agent runtime with the user interface, skills, MCP servers and the model provider, with developers able to choose from Anthropic, OpenAI, Google Gemini and Amazon Bedrock, as well as local models through Ollama, it added.

As for its out-of-the-box capabilities, the application comes with skills for working with files, browsing the web and delegating tasks to specialist agents. Developers can also add existing Agent Skills and MCP servers to give the agents access to other tools and services, the hyperscaler wrote.

Enterprise integration could remain a hurdle

However, analysts were not too convinced that Pizza Bot’s out-of-the-box skills and support for existing tools will make its implementation easier for enterprises.

While the out-of-the-box capabilities and added support for existing skills saves enterprise teams the time to build the application, it leaves out the integration work required to make it work, said Bhupendra Chopra, chief revenue officer at IT consulting firm Kanerika.

“Integration is where most of the money in an enterprise agent deployment goes. A sales or finance team gets value from an agent when it can read and update CRM, email and ERP, and each of those systems needs a connector someone has to build, secure and maintain,” Chopra pointed out.

Pizza Bot’s integration could be further complicated by the application’s lack of support or any SLA, according to Manoj Chandra Jha, principal analyst at Nord-IQ Research. That means the integration and operational burden ultimately falls on enterprises, who would be responsible for running, securing and maintaining the open source software themselves, Jha said.

Rise in enterprise productivity likely

But for enterprises willing to take on that integration work, the inbox-oriented approach could improve productivity.

“It’s a meaningful shift because it changes the economics of delegating work to agents. A chat interface requires a person’s attention throughout the task, while an inbox brings them in only when their judgment is needed, much like how executives delegate work to their teams,” Chopra said.

“Coding agents have already demonstrated this model, where an engineer assigns an issue and reviews the resulting pull request. Pizza Bot extends that approach to tasks such as meeting preparation and follow-ups,” Chopra added.

Further, the analyst pointed out that the inbox-oriented approach could give enterprise teams a clearer window into how scheduled tasks perform.

“For scheduled tasks, having the results delivered as threads gives users a way to track what happened in the background and spot failures that might otherwise go unnoticed,” Chopra said.

Out of sight, out of mind

There are risks with this approach, however: “The inbox model can make bad work less visible. When somebody is watching an agent in a chat window, they can see it going off the rails,” said Phil Fersht, CEO of HFS Research.

In contrast, when hundreds of tasks are running quietly in the background, users may not see an agent making mistakes until the task is complete or an exception requires their attention, potentially making problems harder to catch early, Fersht said.

That reduced visibility can also create approval fatigue, according to Chopra.

“An agent sending back dozens of threads with multiple approval requests can condition users to approve them without reading them closely,” Chopra said.

There is also a risk in the delay between an agent preparing an action and a user approving it: “Information that was current when the agent paused may no longer be valid hours later, potentially resulting in an outdated CRM update or a meeting invite for a slot that is no longer available,” he said. “An assumption that might be caught in a live chat can go unchallenged as the agent continues building on it and consuming model resources. Scheduled runs can also add costs without anyone watching them in real time.”

Those disadvantages can be countered by designing processes with fewer, better-timed approval points, and verifying that the underlying data is still current before allowing an action to execute, he said.

Adoption likely to start with technical teams

Such tradeoffs are likely to shape where Pizza Bot gains traction.

“Adoption will likely be bottom-up, with individual technologists and small platform teams drawn to Pizza Bot’s control and standards-based design,” Jha said. “Risk-averse industries, especially ones in the regulated sectors, and business users with limited technical expertise, however, are likely to approach the application more cautiously,” he added.

That could leave Pizza Bot occupying a more targeted role in the enterprise, as a way for technical teams to experiment with asynchronous agents and new ways of delegating work, rather than an immediate replacement for the governed interfaces and managed services enterprises typically use for business-critical processes, he said.

This article first appeared on InfoWorld.

There is a quiet war happening underneath the AI boom, and most people are not paying attention to the right front. While headlines focus on which model is winning, which startup is raising money, or which chatbot is gaining users, a parallel race is playing out in data centers and corporate boardrooms across the world. The race is for AI infrastructure: the GPU clusters, power contracts, cooling systems, networking fabric, orchestration tools, and inference services that make modern AI actually work. The companies fighting in that race are called neoclouds.

Understanding the importance of neoclouds matters for the same reason understanding cloud computing mattered in 2008. The companies that first saw the shift to cloud and positioned themselves around it correctly ended up controlling a massive layer of the technology industry. The same dynamics are playing out in AI infrastructure right now. But the neocloud market is more complicated than it looks. Not all of these companies do the same thing. Grouping them together as if they are all just GPU rental businesses misses the point entirely. The more useful way to understand the space is to recognize that neoclouds are evolving into four distinct categories, each with a different focus, a different customer, and a different role in the AI stack.

What a neocloud actually is

Before getting into categories, it helps to establish what the term means. A neocloud is a cloud infrastructure provider designed specifically for AI workloads. That sounds simple, but it covers a lot of ground. General-purpose hyperscalers like AWS, Azure, and Google Cloud were engineered to support a wide variety of workloads across many industries. They built architecture around flexibility, breadth of services, and broad enterprise appeal. Neoclouds took a different approach. They built around one mandate: make AI compute as fast, dense, and scalable as possible.

That means designing facilities around high power density, integrating fast interconnects between GPUs, investing in liquid cooling and energy-aware cooling, and building orchestration around tools like Kubernetes and Slurm that are purpose-built for distributed AI training. It also means competing aggressively for access to the latest Nvidia accelerators, because in AI infrastructure, GPU access is often the single most important competitive advantage a company can have.

The result is a fragmented but deeply competitive market. Some neoclouds are focused on physical capacity. Some are focused on making GPU compute accessible to developers. Some are building enterprise-grade infrastructure that can compete directly with hyperscalers in specific AI domains. And some are focused on one of the most important long-term bets in AI: inference. Let’s take a closer look at the four categories of neoclouds.

Full-stack AI infrastructure

The first and most prominent category is full-stack AI infrastructure providers. These companies are trying to become the AWS of the AI era, yet they are built from the ground up around GPUs rather than general-purpose compute. Their goal is to own as much of the AI infrastructure experience as possible: raw GPU clusters, networking, storage, orchestration, managed Kubernetes, Slurm scheduling, private clusters, enterprise support, training workloads, and inference services.

The companies in this space include CoreWeave, Nebius, Lambda, Crusoe, Nscale, and Fluidstack. CoreWeave has emerged as the clearest example of this category. It built its identity around massive GPU clusters optimized for large-scale AI training, paired with Kubernetes-native orchestration and enterprise contracts worth billions. Nebius took a different path, combining deep engineering expertise with a sovereign and European-oriented strategy while expanding heavily into US data centers. Lambda started as a developer and researcher-friendly GPU cloud for machine learning but has moved deliberately upmarket, adding superclusters and private cluster services.

Developer and self-serve GPU clouds

The second category is developer and self-serve GPU clouds. These platforms are not competing for billion-dollar enterprise contracts. They are competing for developers, startups, researchers, and smaller teams who need GPU access quickly without negotiating long-term deals. The product experience here is self-serve: pick a GPU, spin up an instance, deploy a model, run a notebook, test a workload, or launch a small cluster.

The brands that fit here include Vultr, Runpod, Civo, Lambda, and Together AI. Vultr brings GPU compute into a broader cloud platform with a global footprint and self-service deployment. Runpod has built a loyal developer following by keeping the experience simple and fast. Civo targets developers who prefer a Kubernetes-first environment. Lambda still offers strong self-serve GPU instances and 1-Click Clusters alongside its enterprise offerings. Together AI goes beyond raw GPU rental to combine inference, fine-tuning, model hosting, and dedicated clusters in one developer-accessible platform.

This category matters because not every AI team needs thousands of GPUs and a dedicated account manager. A lot of important work happens at the research bench, the startup prototype stage, and the individual developer level. These clouds serve that market, and they often grow into larger accounts as teams scale.

Inference-first AI clouds

The third and increasingly important category is inference-first AI clouds. Training gets the dramatic headlines, but inference is where AI products actually live. Every chatbot response, coding assistant completion, voice agent interaction, and image generation request is inference. And unlike training, which happens in bursts, inference runs all day, every day, for every user.

The companies to watch include Together AI, Groq, CoreWeave Inference, Nebius Token Factory, Crusoe Managed Inference, and Nscale Serverless Inference. Together AI has built one of the clearest inference-first platforms in the market, especially for open source and open-weight models, while also supporting fine-tuning and dedicated GPU clusters. Groq stands apart because its identity is tied to ultra-fast inference running on its own language processing unit (LPU) architecture, which inverts the traditional GPU paradigm. CoreWeave Inference extends CoreWeave’s infrastructure story into serverless and dedicated model-serving. Nebius Token Factory and Crusoe Managed Inference represent how full-stack players are adding inference layers to monetize their GPU capacity differently. Nscale Serverless Inference is Nscale’s move into on-demand model serving without infrastructure management.

What makes this category so compelling is the economic direction. As AI moves from a handful of large frontier labs into millions of production applications, the demand for inference infrastructure will likely dwarf training demand. Companies that control inference capacity may end up controlling the more durable long-term revenue stream.

Data-center and capacity-heavy players

The fourth category is the most physically grounded. These are the companies that are building and controlling the real estate of AI. This goes beyond GPU clouds in the traditional sense. These companies are acquiring land, securing power contracts, designing data centers, developing campuses, deploying high-density racks, and racing to control capacity that genuinely cannot be replicated quickly.

The brands that fit here include Fluidstack, Applied Digital, Core Scientific, Voltage Park, Crusoe, and Nscale. Some of these companies also offer cloud services, but their strategic advantage is fundamentally about commanding physical infrastructure. Fluidstack specializes in delivering large-scale custom GPU cluster capacity and custom data center solutions for enterprises and AI labs. Applied Digital provides hosting infrastructure for AI and high-performance computing at scale. Core Scientific transitioned from crypto-mining data centers into AI infrastructure. Voltage Park is focused on large-scale GPU capacity for AI and research organizations.

Crusoe and Nscale appear in this category as well as in others, which gets to the heart of one of the most important points about the neocloud market overall. These categories are not clean boxes. Companies routinely sit across multiple categories, and competitive pressure is pushing most of them to expand their scope. Crusoe is both a cloud provider and a data-center developer. Nscale is both a cloud platform and a major infrastructure builder. The companies that ultimately win may be those that can span the four categories most effectively.

Why the category framing matters

Understanding these categories is not just an academic exercise. It has real consequences for how companies make buying decisions, how investors evaluate the space, and how technology leaders think about AI infrastructure strategy.

A company focused on physical capacity is playing a fundamentally different game than one selling managed inference APIs. They may appear in the same technology articles and compete for some of the same headlines, but their economics, customer relationships, and long-term differentiation look very different. From an enterprise buyer perspective, understanding which layer you are actually buying from matters before you sign a contract. Some neoclouds are building long-term platform relationships. Others are offering capacity to fill an immediate gap. The category determines which is which.

The neocloud market is young, fast-moving, and genuinely complicated. New entrants, mergers and acquisitions, and platform expansion are all reshaping the landscape in real time. But the underlying logic remains constant. AI infrastructure is becoming a critical layer of the technology stack, and whoever controls that layer will have enormous influence over how AI gets built, deployed, and monetized.

The companies in this market are not all the same. Paying attention to what they actually do, rather than just what they call themselves, is how you separate the ones that will shape AI’s future from the ones that were simply first to send a press release.

For CIOs and CDOs heading into Microsoft Fabric and SQL Community Conference Europe, the main question is not which data technology sits at the center. It is whether the data platform improves revenue, productivity, and decision speed while creating a trusted foundation for AI at scale. That should drive the data strategy.

Enterprise AI is forcing companies to tackle a familiar problem, with data spread across ERP, CRM, operational systems, databases, applications, warehouses, and analytics platforms built over years. That was manageable for reporting and point-to-point integration. Copilots and agents raise the stakes because they need to reason across customers, orders, inventory, financial implications, operating constraints, permissions, and business rules at the same time.

That moves the discussion from architecture into CIO and CDO strategy. What outcomes are we trying to improve? What data and context are required? What needs to move versus connect? Where do Microsoft Fabric, Azure Databases, and other platforms fit? How will governance and authority follow the data? Where should the data be stored and what sovereignty or regulatory restrictions apply? And how will we measure results?

Microsoft is positioning its broader data platform around AI business value. That framing is useful when it translates into an operating strategy. As I wrote in Forbes about Microsoft Build in June, the next phase of AI depends less on the model and more on data readiness, governance, interoperability, and operational execution. The conference should give customers a closer view of how those pieces come together. The question for CIOs and CDOs is how that direction fits their existing data estate.

The AI problem is usually a data problem

Many AI initiatives stall on data readiness rather than the model itself. The issue is not one statistic. It is the combination of fragmented data, inconsistent definitions, and the effort needed to prepare and govern information before AI can use it reliably.

Copilots and agents need trusted context around customers, financials, inventory, operations, permissions, and business rules. AI exposes existing weaknesses. Duplicate customers, poor product data, and inaccurate inventory become more consequential when AI is recommending or taking action. AI does not create the data quality problem; it makes the operating cost harder to ignore.

The goal is to make more of the existing data estate useful for AI without turning modernization into a wholesale rebuild.

Microsoft Fabric and Azure Databases play different roles

For customers, the question is how Microsoft’s broad portfolio translates into architectural choices, including what should move, what should connect, and what can stay in place without limiting the result the business is trying to achieve.

Azure Databases support transactional and operational workloads, each with distinct performance and application requirements. Fabric provides a unified SaaS experience across data integration, engineering, analytics, real-time intelligence, data science, and business intelligence. Fabric IQ adds a semantic intelligence layer that provides shared business context for Copilot and agents. Some workloads may belong in Fabric, others in Azure Databases, and some on third-party platforms; moving them adds cost without creating enough business value.

The architecture should follow workload, data maturity, economics, and business value, not a single destination.

Connected data has to improve the decision

Microsoft’s broader data platform can connect systems of record and operational applications with analytics and AI. Azure Databases, Fabric, OneLake, Power BI, and governance can play different roles. What matters is whether those connections shorten the path from operational data to a decision, not how neatly the products line up.

A customer record may live in CRM, orders in ERP, inventory in operational databases, and demand models in an analytical environment. Fabric Real-Time Intelligence can add live events to that picture. A manufacturer can stream equipment events or production events, detect a developing issue, and alert teams while there is still time to change the outcome. The value comes from reasoning across that context so the business can understand what is happening, why it matters, and what action makes sense next.

Trusted context turns data into AI business value

I recently wrote in InfoWorld that trusted context is becoming the currency for enterprise AI. That is especially relevant here because once copilots and agents rely on enterprise data, then quality, permissions, lineage, and security become operating requirements, not background data issues.

Knowing inventory is 8,000 units is data. Knowing whether those units are available, committed elsewhere, in the wrong distribution center, or on quality hold is business context. As AI moves from answering questions to taking action, that context determines whether the result can be trusted.

Microsoft frames AI business value around growth, insight, and scale. Each needs an operating definition. Growth can mean new revenue, better customer responsiveness, or growing without adding cost at the same rate. Insight means combining context across Microsoft 365, Fabric, and operational systems to make better decisions faster. Scale means expanding AI without rebuilding governance for every use case.

A reusable data foundation can also reduce pipeline and management effort while improving decisions around pricing, inventory, customers, supply chain, and finance. Microsoft cites coverage of more than 100 standards. The practical question is whether AI can scale without risk and complexity growing at the same pace. For multinational or regulated organizations, that also includes where data is stored and processed and which sovereignty requirements apply.

Agentic workloads raise the bar. Organizations need to know what information informed a decision, who or what had authority to act, which policies applied, and how a wrong action can be reviewed or reversed.

That is where the data platform becomes part of what I describe as decision architecture. Context explains what is happening. Decision logic determines what should happen next. Authority defines what a person or agent can do. Orchestration coordinates systems and people. Execution completes the action and provides a path to review or reverse it. Trusted data feeds that architecture. Without trusted data, automation will be difficult to trust at scale.

Microsoft’s breadth is most useful when it reduces complexity

Microsoft’s advantage may be its enterprise footprint. Azure Databases, Fabric, OneLake, Power BI, Microsoft 365, business applications, developer tools, identity, security, and partners touch many of the places where information is created and work gets done.

Most customers will keep data across multiple systems. Microsoft’s opportunity is to use that breadth to create a simpler path from data to workflow to business outcome without requiring everything to live in one place.

Customer proof points matter because data strategies can get abstract. The KPMG Australia example is useful because KymChat moved beyond an internal productivity tool into a client-facing offering, creating a path from internal AI investment to new business. Microsoft also reports that improvements to the data foundation increased KymChat search quality from 50% to 91%, with results delivered in under a second.

BMW Group provides a more recognizable operating example. Microsoft says Azure helped BMW make vehicle data delivery and analysis 10 times faster, cutting the lead time for engineering insights from days to hours or minutes. Audi adds an AI deployment example. It used Azure AI Foundry, Azure App Service, and Azure Cosmos DB to launch a secure HR assistant in two weeks and is extending the same framework to eight additional agents across the enterprise. Levi Strauss & Co. offers another angle. It consolidated nine ERP systems on Azure, reported a twofold improvement in latency and a 60% improvement in IOPS and now uses Fabric IQ for companywide cost reporting. These are the kinds of proof points that connect platform architecture to time, cost, productivity, and decision quality.

Interoperability matters across the enterprise estate

Microsoft sits in a market with Snowflake, AWS, Google Cloud, Oracle, and others, each with different strengths across infrastructure, databases, analytics, openness, and AI. Databricks also plays an important role, but the connection is different because Azure Databricks is provided as a first-party service directly on Azure. Most large enterprises will remain heterogeneous, making interoperability, cross-platform governance, and incremental modernization central to strategy.

The opportunity is to make Microsoft’s data platform useful across the mix of systems that customers already run. Most enterprises are not starting from a blank sheet, so the value is in helping them connect, govern, and modernize over time without forcing everything into one place.

CIO and CDO strategy should start with the business outcome

This is where the conversation becomes most useful at the Microsoft Fabric and SQL Community Conference Europe. For CIOs and CDOs, an architecture diagram matters more when it is backed by a decision model. A useful data and AI strategy should work backward from the business outcome through five decisions.

1. Start with the business outcome. Define what needs to improve, including revenue, margin, productivity, customer experience, decision speed, working capital, or time to value. Let the technology choice follow the objective.
2. Map the data and context required. Identify the operational, transactional, and analytical information, semantics, and business rules that influence the outcome.
3. Decide what moves and what connects. Determine where Fabric, Azure Databases, and non-Microsoft platforms fit. Let workload, economics, and value drive modernization rather than a single destination.
4. Design governance, authority, and economics together. Define how security, permissions, lineage, and controls span operational, analytical, and AI workloads, and identify opportunities to simplify pipeline, integration, and management efforts.
5. Measure the operating result. Set KPIs before scaling. Technology adoption is not the outcome. CIOs and CDOs should know which business measures should change, by how much, and over what period.

That is how the data platform becomes enterprise strategy, tying architecture, governance, AI, and economics to operating outcomes and bringing business leaders into the discussion before the architecture is set.

What customers will still want to understand

Microsoft has many of the pieces required to connect enterprise data, analytics, and AI. Customers will keep looking for guidance on the roles of Azure Databases, Fabric, and the broader data platform, along with cost, licensing, migration, and governance across heterogeneous environments. They will also want more proof points from KPMG, BMW Group, Audi, and Levi Strauss & Co. that start with a business result.

That is where Microsoft’s positioning around a data platform for AI business value comes together. The value is in helping customers connect platform choices to better decisions, faster action, and measurable operating results.

After three decades in enterprise technology, I keep coming back to the same point. The technology is only part of the answer. For CIOs and CDOs, the harder part is deciding how the data platform fits into the way the business operates, how decisions get made, and where AI can improve the outcome. That is really the question behind how Microsoft connects your data across the enterprise. The conference should give customers a useful view of how Microsoft is bringing those pieces together and where that can create better business outcomes.

For 15 years, public cloud providers have defined the industry for most enterprises: on-demand, automatically metered services delivered over the open internet that give developers immediate access to storage, databases, compute, application development platforms, and AI capabilities. That model remains dominant because it is simple, well-instrumented, and universally supported. Yet an adjacent reality has always existed. Large-scale, off-market capacity deals where technology companies with surplus GPUs, storage, and compute sold blocks of capacity in bulk to other firms under nondisclosure agreements were once common. Those were cloud transactions in substance, since you were using somebody else’s servers. However, they lacked the automation, metering, and governance that define public cloud services, and they operated entirely outside the frameworks enterprises rely on for budgeting, compliance, and accountability.

A shadow market becomes visible

These arrangements are now becoming more visible and more formalized. Some are even openly auctioned. Meta’s entrance into the cloud capacity space, essentially offering its excess compute infrastructure to outside buyers, represents the maturation of a market that has existed in back rooms for years. Large, multiyear capacity commitments are no longer whispered about during boardroom lunches. They are being announced, financed, and tracked by analysts. This shift is creating a distinct layer in the cloud landscape, one that sits between traditional hyperscalers and true private clouds, and one that enterprises can no longer afford to ignore.

The practical implication is that the cloud market you thought you understood now has a parallel track. When a large enterprise needs maximum GPU capacity for model training or inference, it has more options than a year ago, and those options come with genuinely different trade-offs. You can go to a hyperscaler and pay the published rate for metered GPU as a service, receiving a fully managed platform with all the tools, governance, and integration you need. Or you can reach out to a technology provider that happens to have idle or excess GPU capacity and negotiate a bulk deal at a fraction of the published rate. The first option provides predictability and depth of service. The second offers raw cost savings if you have the operational capability to handle less-managed infrastructure.

This bifurcation is muddying procurement decisions. The gap in pricing between bulk off-market capacity and public cloud offerings can be substantial. Some analysts cite differentials ranging from 10 to 100 times. But headline GPU rates are only part of the evaluation. Bulk deals tend to come with minimal metering, limited monitoring, and a do-it-yourself culture around incident response and optimization. You are, in effect, purchasing wholesale energy. It is robust and capable, but it requires your own wiring and maintenance. Organizations accustomed to the instrumentation and service-level agreements of hyperscalers may find such a different operational reality a bit jarring. Those with mature cloudops teams may find the economics compelling.

Who benefits and who adjusts

The hyperscale incumbents will not be displaced overnight. They offer the complete ecosystem, not just GPU frameworks but development tools, hundreds of managed services, identity, compliance, and integration layers that are genuinely difficult to replicate. However, they are now facing a market where customers with intensive computational needs can source raw GPU capacity from alternative suppliers, particularly for bursty or cost-sensitive workloads. This is not necessarily a threat to hyperscaler dominance, but it is a complication. The hyperscalers will likely respond through partnerships, capacity-coverage agreements, and possibly acquisitions of promising capacity players. Effectively, they will become customers of the same off-market ecosystem they once ignored.

The cloud market is adding a new axis of choice: managed breadth versus specialized efficiency. Enterprises will increasingly construct hybrid operating models, keeping steady-state, security-sensitive, and toolchain-dependent workloads on hyperscaler platforms while offloading cost-intensive training runs and elastic inference to bulk-capacity providers. This is not a binary choice. It is an expanding continuum of sourcing options that demands more sophisticated procurement and architecture planning.

How to take advantage

Know your actual workload cost before you negotiate. If your AI workloads are compute-intensive, model training-heavy, or require burst capacity at unpredictable intervals, the economics of bulk capacity deals can be compelling. Run a pilot that captures total cost of ownership, including data movement, integration effort, operational overhead, and potential downtime during self-managed troubleshooting before you assume bulk is simply cheaper. Compare fully loaded costs, not GPU-hour sticker prices.

Build portability into your AI stack from the start. Bulk-capacity providers often lack the governance, compliance tools, and model life-cycle management enterprises need. Mitigate this risk by standardizing on containerized inference runtimes, open model formats, and CI/CD pipelines capable of deploying across multiple targets. This type of discipline turns vendor diversity into negotiating leverage rather than operational liability. It also ensures you can shift workloads as capacity markets fluctuate.

Treat capacity sourcing as a strategic procurement function. Bulk cloud capacity is not a niche quirk. It is becoming a recognized market that rewards supply-chain thinking. Diversify your supplier base, negotiate multi-vendor commitments where possible, and develop a reserve strategy for critical workloads. Keep your hyperscaler relationship for reliability and breadth, but maintain at least one secondary capacity arrangement for cost-sensitive or elastic workloads. The enterprises that treat capacity as a variable asset, rather than a fixed infrastructure decision will be better positioned as this market continues to expand and formalize.

The cloud market is no longer a simple fork between public and private. A defined middle ground of negotiated bulk capacity is now attracting billions in investment and reshaping how AI infrastructure costs are allocated. Enterprises that understand this landscape and build flexible, portable architectures that can span it will capture more value from AI investments than those who default to the familiar hyperscaler menu alone.

Nvidia CEO Jensen Huang argues it’s the “most illogical thing in the world” to believe AI will kill SaaS, and says the markets “got it wrong” in sending SaaS stocks tumbling. Why “illogical”? Because, as analyst Benedict Evans stresses, the fact that everyone can now easily spin up code actually doesn’t solve any SaaS problems, because creating code and tools is the easy part: “The hard part is knowing that you need a tool for this in the first place and then knowing what the tool should do.”

If that’s true, then what Shopify is doing with Sidekick is potentially revolutionary by embracing and extending the traditional SaaS model.

In December, Shopify introduced custom app generation through Sidekick. A merchant (Shopify customer) describes a tool, and Sidekick writes the code, using Shopify’s interface components and connecting to its Admin API. It’s a cool option and has been very popular. Shopify says merchants created almost 4,000 custom apps in the first three weeks following the release.

This isn’t surprising: Shopify is delivering the customization customers have long wanted from enterprise SaaS while ensuring they still enjoy the comfort of ongoing support and platform stability.

I suspect we’ll see more enterprise SaaS like this, despite silly predictions that AI would kill SaaS. Cheaper code gives customers a way to fix the things they dislike about an application without replacing everything they do like. For a vendor willing to accommodate that, AI could make its product considerably more useful and, hence, much “stickier.”

The feature that never ships

Cloudflare’s Jeremy Morrell discusses this in an excellent essay on extensible software. “In the past year, your users have suddenly acquired the ability to speak code into existence,” he writes, allowing for “markets of one.” His argument is that software should let customers put that ability to work, building additions around an established core.

Morrell has a commercial interest here, which he discloses: He works at Cloudflare and thinks its infrastructure is well suited to running those additions. He’s not wrong. But it’s the general opportunity to match customizability with stability that matters so much.

There are really (really) good reasons why vendors haven’t allowed customizability of their core products. Enterprise software companies limit deep customization to prevent high maintenance costs, security risks, and broken system updates. Oh, and to prevent their products from becoming convoluted bloatware. No matter how much you may want feature X, that feature would likely be irrelevant to almost everyone else, so adding it would complicate the product for the majority. No one wants that.

Customers have long paid consultants to customize software or they’ve hired developers to do it themselves (all while taking care not to violate their vendor licenses). Morrell points to Salesforce, which has spent years letting businesses build their own logic into its platform. In other words, AI didn’t invent extensibility. No, AI just makes it incredibly cheap. There’s a meaningful opportunity here for customers who can describe the change they need but have never been able to get it built. Some will save money on software or customizations they previously bought, while others will finally get software that nobody could profitably sell them.

Following the money

This change, however welcome for enterprises, won’t be comfortable for developers selling a narrow reporting tool or a small workflow improvement. Their customers may decide that an LLM-generated extension is good enough. An AI-built customization needn’t match every feature of the commercial product. It only has to do the job that the customer was paying for.

The platform underneath that extension has a different calculation. Every useful tool built against its data and APIs gives the customer another reason to stay. AI can make an individual feature less valuable to sell while making the product that hosts it more valuable to own. (Yet another reason to tsk-tsk foolish eulogies for SaaS companies.)

Ultimately, this should benefit anyone who both knows the business and can build more efficiently for that business. Benedict Evans makes this point in his newsletter, arguing that cheaper coding doesn’t solve the problem of discovering what software ought to do or persuading an organization to use it. A useful idea that spans several departments still needs those departments to agree. Even excellent code can’t sign off on a new way of running accounts payable.

Evans also describes how improvised tools eventually become important enough to need formal ownership and support. Anyone betting that companies will happily maintain everything they can generate should spend some time with the person who inherited the last departmental spreadsheet. Silicon Valley folks with little knowledge of real-world enterprises might think enterprises will vibe code all their software now, but they won’t. That’s not how software works because it’s not how people work.

This cuts both ways for established software vendors. Customers may continue to need their expertise while becoming less willing to accept a product’s limitations. A vendor that makes customization easy can benefit from that impatience, while one that blocks it has given the customer a new reason to investigate alternatives. The difficult decisions will come when customization interferes with what the vendor already sells.

I wrote in 2022 about Microsoft’s complicated relationship with open source, and how a company’s broad commitment to openness can collide with a division’s revenue targets. The same tension applies here. A CEO can be excited about letting customers build anything. The executive responsible for selling the premium reporting package may be less enthusiastic. Resolving that disagreement will determine what customers actually get to build, however capable the AI becomes.

Getting comfortable

Customers have their own calculations to make. An application shaped around the way your company works can be wonderful, but it can also be a pain to leave.

There are limits to what Shopify’s generated apps can do today. They are admin tools, not storefront or checkout extensions. Shopify also tells merchants to test them before installation because they can change customer-facing data. A generated app can be wrong, and running it inside a familiar product doesn’t relieve the merchant of checking its work.

Shopify lets merchants inspect and edit the generated code and restore an earlier version. That’s useful, but code written for Shopify’s Admin API still depends on Shopify. Having the source doesn’t give you another company ready to run it unchanged.

AI might eventually make moving those extensions easier, too. But recreating a screen is one thing; reproducing the behavior it relies on throughout a business is a considerably bigger undertaking. That includes the assumptions about records and transactions that the custom code gets to take for granted while it runs on the original platform.

None of this makes customization a bad deal. Customers can gain more control over their daily work while, somewhat ironically, becoming more dependent on a supplier. For SaaS vendors, that’s a good commercial reason to let customers finish the bits their developers will never get around to building, even when it costs them an add-on sale (and potentially some support headaches, depending on how they’re architected for extensibility). The customer is doing work that makes the underlying product more valuable.

AI, in short, has the potential to make SaaS dramatically more valuable, not extinct.

Cloud computing has always been about survival. When you’re building systems at scale, you need to think about resource planning, capacity, and adaptability when demand spikes. The survivalist mindset in cloud architecture is about building systems that can weather unexpected storms, whether that’s sudden traffic spikes or the need to scale AI inference across a global user base. During the past decade, serverless computing has been the go-to architecture for this kind of resilience, abstracting away the underlying infrastructure so you can focus on the application itself. Now, AI has arrived in that serverless world, and it’s changing how we think about deploying intelligence at scale.

The concept is straightforward enough. Instead of provisioning GPU instances, managing model deployments, and sizing your inference infrastructure, you call an API, send your data, and get back a response. The provider handles the rest; the model runs somewhere in their cloud, scales automatically, and you pay per token or per request. Services like Amazon Bedrock, Azure OpenAI Service, and Google Cloud Vertex AI have made this the norm rather than the exception. You get access to foundation models from Anthropic, OpenAI, Meta, and Google through managed APIs that abstract away everything from hardware selection to auto-scaling logic. It’s elegant in its simplicity, and for many use cases, it’s exactly what you need.

The scalability advantage

The benefits of this approach are substantial, and they’re worth examining carefully. The most obvious is that you don’t have to spend time sizing infrastructure. Sizing AI infrastructure is notoriously difficult. GPU instances are expensive, and getting the right number to handle your peak load without overprovisioning during quiet periods requires expertise most organizations lack. Serverless AI offloads that problem entirely. You describe what you need, the service provisions it behind the scenes, and you are billed for what you use. The system scales up when you need it and scales back down when you don’t. There’s no idle capacity, no waiting for instances to spin up, no late-night calls to your infrastructure team when a model needs to handle a sudden traffic surge.

If done correctly, this can be a godsend for applications that consistently scale up and down. Retail is the canonical example. During the holiday season, a retailer might see AI-powered recommendation engines handle 10 times their normal load. In January, that demand drops dramatically. A serverless approach means you’re not paying for GPU infrastructure sitting idle during the slow months. The same logic applies to seasonal businesses, event-driven applications, or any workload with unpredictable traffic patterns. You get elasticity without complexity.

The hidden costs of pay-per-use

The drawbacks need to be considered as well, and this is where many architects get into trouble. Since you don’t have direct control over scaling and descaling processes and storage resources, the cost is going to go up and down as your infrastructure needs vary. In many cases with highly variable scaling systems, this can be a benefit. We’re not overprovisioning or underprovisioning, and we’re not dealing with the impact of idle services and overpaying for infrastructure that we never use. The bills move with your actual usage, which sounds ideal until you realize that usage-based billing doesn’t always mean lower costs.

If your AI applications use a static number of resources over time, serverless services will typically cost you more. When you’re running inference at a steady rate around the clock, you’re often better off provisioning dedicated infrastructure and negotiating a fixed rate. The per-token pricing that makes serverless attractive for variable workloads becomes a premium you pay for flexibility you don’t actually need. More importantly, you’re never going to really leverage the benefits of serverless technology, because the infrastructure used in these AI processes will be relatively static over long periods. The cold starts, the scaling latency, the lack of control over instance types—none of those downsides are ever offset because you never use the upsides.

Fit architecture to use case

This is a horses-for-courses situation, and you need to think carefully about whether you want to leverage this technology. Even though serverless has been around for quite a long time in the cloud world, I’m not sure most enterprise architects and AI architects fully grasp how to deploy serverless-based AI. The technology is new enough that the patterns are still forming, and cloud providers’ documentation generally emphasizes ease of use without adequately covering scenarios where it falls short. The result is organizations defaulting to serverless AI for every use case, driven by the same “serverless is always better” thinking that plagued early cloud adoption.

Serverless AI is an architectural option like anything else. You need to be very careful with it, matching the right business problems to the technology. Variable, unpredictable workloads with strong seasonal patterns are ideal candidates. Static, steady-state inference workloads are probably not. The decision should be rooted in understanding your traffic patterns, cost constraints, and operational requirements, not from assuming that serverless is inherently better than provisioning your own infrastructure. The survivalist’s thinking applies here as it does everywhere in cloud architecture: The best tool is the one that fits the job, not the one that sounds the most exciting.

The consulting firms told us this would be different. They arrived with slick slide decks, expensive vendor packages, and promises to revolutionize how we do business. Their message was clear: Digital transformation was no longer optional; it was existential. Companies that failed to adapt would be left behind and crushed by more agile competitors with cloud-native architecture and data-driven strategies.

That was back in 2020, when Boston Consulting Group released research showing that 70% of digital transformations failed to meet their objectives. The consulting industry rushed to publish its frameworks, maturity models, and proprietary methodologies. Enterprise IT organizations spent millions on these programs, hoping to finally bridge the gap between technological capability and business value.

Several years on, I can say that little has changed. If anything, the issue has worsened.

The damage that was done

Most digital transformations didn’t just fail to deliver ROI; they actively damaged the organizations that undertook them. Technical debt accumulated as companies deployed monolithic cloud platforms that were neither modular nor scalable. Business misalignment became endemic as transformations focused on technology for its own sake rather than on solving actual business problems. Organizations found themselves locked into expensive vendor relationships that failed to deliver on their promises.

I’ve spoken with dozens of enterprise CIOs and CTOs over the past several years, and the stories are remarkably consistent. Transformations that were supposed to take six months stretched to two years. Budgets estimated at a few million exploded to six, eight, even twelve times the original projection. The consulting firms had excellent PowerPoint skills, but when it came to implementation, the results were consistently disappointing.

The damage wasn’t just financial. Organizations lost confidence in their IT capabilities. Talented people left because they were tired of being managed by consultants who couldn’t code their way out of a paper bag. Business stakeholders grew cynical about technology initiatives, having been burned too often by projects that promised transformation but delivered chaos.

Why the consulting models failed

Let’s be direct about what happened. The consulting industry discovered that digital transformation was highly profitable. They could sell their methodologies, vendor partnerships, and “best practices” frameworks, and charge premium fees for implementation support. The problem was that these frameworks were largely one-size-fits-all approaches disguised as bespoke solutions.

A major global bank doesn’t have the same requirements as a regional healthcare provider, yet both were sold the same transformation playbook. The consulting firms had invested too heavily in their methodologies to admit that the real answer might be to start with business requirements and work backward toward technology. Instead, they assembled prepackaged solutions optimized for vendor partnerships rather than clients’ actual needs.

The talent problem was equally severe. The consulting firms could certainly talk about digital transformation; they had excellent slides and compelling narratives. But when it came to implementation, the skill gaps were glaring. These organizations assembled solutions by following playbooks rather than understanding how the technology components actually fit together. The result was systems that were overengineered, overprovisioned, and ultimately underperforming.

Cloud computing was supposed to be the great enabler, but many organizations misunderstood and misapplied it. Organizations lifted and shifted their existing problems along with their existing architecture. Monolithic applications running on expensive virtual machines became the new normal, with organizations paying cloud costs that far exceeded their on-premises expenses, yet achieving none of the scalability benefits the cloud was supposed to deliver.

What we still need to learn

As we grapple with the next wave of technology transformation—this time centered on artificial intelligence—the lessons from digital transformation failures should be front and center. The first and most important lesson is brutally simple: Focus on business needs first. I know this sounds obvious, but I guarantee you that every failed digital transformation project lost sight of its core business requirements. They built technology for technology’s sake without understanding the problems they were trying to solve.

Too many transformations focused on individual business units rather than enterprisewide strategies. The result was a collection of systems that couldn’t work together cohesively. Isolated solutions felt like progress but actually made integration harder and created new dependencies that hadn’t existed before.

Organizations also need to invest in serious training for their people. I’m not talking about sending IT staff to vendor certification programs that teach them to pass tests on proprietary platforms. I mean fundamental architectural education that helps people understand how to assemble technology effectively.

We face a massive shortage of AI, cloud, and security architects, as well as other technical leaders who can design solutions that work. Rather than addressing this gap, organizations are placing unqualified people in these roles and hoping for the best. It’s past time to invest in education.

The case for simplicity

Here’s something that also should be obvious but clearly isn’t: You can solve the same business problem with $1 million or $20 million, depending on the sophistication of the IT organization building the solution. Both designs will work reasonably well, but one solution costs 20 times more because it is overbuilt and overengineered.

Organizations are adding AI to everything under the sun, even when simpler solutions would work just as well. They’re overprovisioning cloud resources because they lack the architectural discipline to rightsize their infrastructure. They’re building systems designed for scale they’ll never reach, complexity they don’t need, and features no one requested.

The path forward requires a minimalist approach. Build systems that are good enough for their intended purpose. Focus on requirements rather than capabilities. Resist the temptation to adopt every new technology just because it’s available.

Digital transformation didn’t fail because the technology was flawed. It failed because we forgot that technology exists to serve the business, not the other way around. To succeed with AI, we need to remember that fundamental truth. And remember the consulting industry’s tendency to sell us expensive solutions to problems we don’t have.

Entrusting mission-critical workloads in the cloud puts a lot of pressure on IT operations to build resilience into data infrastructure they don’t even own — to make sure that when an incident happens elsewhere, the lights stay on at home. Fortunately, savvy CIOs are learning they can architect their systems for resilience and high availability to keep mission-critical cloud workloads running when disaster strikes.

When designing for resilient, highly available cloud workloads it is critical to understand the details of your cloud provider’s service level agreement (SLA) and recognize that providers operate on a shared responsibility model. That means there are many things the provider is responsible for, but the workloads you’ve got running on their infrastructure are not among them. With that in mind, we’ll need to focus on three core goals essential to building and maintaining highly available, resilient cloud workloads:

1. Identify and eliminate single points of failure
2. Close or mitigate conditions leading to recovery gaps, and
3. Overcome operational complexity.

Remember, everything fails

Designing for application-level resilience and high availability is predicated on recognizing that everything fails. That’s not pessimism, but realism, and embracing this fact gives you a leg up in architecting resilient IT. Hardware breaks down, disasters occur, mistakes are made, software incompatibilities are common, and limits are exceeded that result in loss of service. There are four categories of failure that need to be taken into consideration when designing for resilience and high availability:

1. Single point of failure: As the term suggests, this describes a non-redundant device, route, or point of connectivity that results in zero fault tolerance in the event of an incident involving that choke point.
2. Excessive load: Exceeding the throughput or memory limits of a device or service can result in latency, service degradation, or failure affecting service level agreements (SLA) and service level objectives (SLO).
3. Misconfigurations and bugs: Perhaps the most common source of failure, these breakdowns often occur during installation, maintenance, and patching leading to the incorrect execution of code.
4. Shared fate: This type of failure is like non-redundant connectivity. When you rely on third-party services and there is an incident beyond your control affecting a partner, it can result in downtime or service degradation.

Having identified the primary challenges to maintaining service uptime and continuity, let’s explore an approach to achieving resilience through high availability, disaster recovery, and the process of continuous improvement.

Working toward continuous improvement

High availability is often thought of as measured by “X Nines,” representing the percentage of time a service is operational over the course of a specified time frame, usually a year. Six nines of availability, for example, means that a service can be expected to run 99.9999% of the time, or 8759.99 hours out of 8760 in a year. That sounds good until a disaster happens. Then we shift to disaster recovery, or the ability to restore a service and its associated data quickly and correctly when things go wrong. Disaster recovery is often measured and evaluated by a recovery point objective (RPO), which is the maximum acceptable amount of data loss, and a recovery time objective (RTO), which is the maximum acceptable amount of time a service can be down.

By learning from our mistakes, incidents, and the ongoing process of testing, observing, and evaluating IT operations, we apply new information in the goal of continuous improvement to get peak performance out of our investments in IT. But because we’re addressing resilience and high availability in the context of workloads operating in the cloud, we should understand the shared responsibility model that most cloud service providers use. Details may differ from provider to provider, but the shared responsibility model of cloud services is your vendor’s statement of responsibility for maintaining its infrastructure and ability to deliver storage and compute capacity in a region and availability zone where you have a need. In return, you accept responsibility for the configuration, maintenance, availability and operation of the workloads you choose to run on your vendor’s cloud.

SIOS Technology

A cloud service provider will typically operate and maintain physical infrastructure in different areas around the world, with multiple availability zones in each area. Each availability zone will have one or more data centers with its own power, cooling, and other operational support. Data centers are typically located far enough from each other to minimize the chance that a natural or regional disaster will affect multiple data centers, but close enough that they can operate as a single, logical data center — thereby maximizing bandwidth and throughput, while minimizing latency. This is redundancy at scale that eliminates a single point of data center failure.

Designing for application high availability and disaster recovery

To build out or retrofit your infrastructure for application-level resilience and high availability, there are four things you must have: clustering, data replication, failover, and disaster recovery. Let’s look at each and how to architect for them.

Clustering

Clustering is the practice of connecting like and complementary systems to improve availability and reliability. Think of it as putting into practice the maxim “the whole is greater than the sum of its parts.” Traditionally, clustering was achieved using hardware, specifically storage area networks (SAN), to connect and support systems in a physical data center. However, in the cloud age, hardware-based clustering has proven to be expensive and inflexible. Software-based SANless clustering with products such as SIOS LifeKeeper delivers all the benefits of the traditional approach while also working better in cloud and hybrid environments.

SIOS Technology

SANless clusters enable the configuration of nodes based on the organization’s operational priorities and work easily for enterprises running geographically distributed data centers or cloud availability zones. Because SIOS LifeKeeper supports single-site, multi-site, cloud, or mixed environments, and affords real-time access to operational data during incidents requiring failover, it is ideal when mission-critical workloads are distributed across multiple providers. LifeKeeper clusters create redundancy and eliminate single points of failure, both of which are necessary for achieving high availability. For enterprises operating hybrid or multi-cloud infrastructure, this enables you to shift to secondary resources should your primary service experience an outage.

Data replication

IT operations and your mission-critical applications rely on data, so it’s vital to keep data in sync between nodes in real time, whether synchronously or asynchronously, depending on the application. When working to achieve high availability, it’s important to monitor the health of infrastructure elements and the applications you’re running. This ensures that downtime affecting the application and any downstream dependencies is detected so that failover and recovery to a standby node can occur automatically. When everything is in sync and data replication is happening, this ensures complete readiness; there’s no need to rebuild a database or for any manual operations. And with SANless clusters using SIOS DataKeeper, this will happen across availability zones, regions, and to or from on-premises, cloud, or multi-cloud resources in hybrid environments.

SIOS Technology

What’s important here is that the software you use for SANless clustering be application aware. That’s SIOS LifeKeeper. Because high availability and resilience mean not just failing over to standby infrastructure resources, but for properly failing over mission-critical workloads (think SQL Server, SAP, Postgres, or industry-specific applications like Meditech), the software needs to understand how those applications work so that they can recover and restart cleanly. Otherwise, when failover occurs, there’s a good chance that workload is not going to be available, or it could be out of sync. When your software is application-aware, failover and recovery is fast and predictable with no API dependencies or last-minute provisioning.

Failover

With SIOS SANless application-aware clustering and replication in place, you can automate real-time failover and achieve the goal of high availability and resilience. Because we’ve chosen a software-based approach, failover occurs in the data plane, so there’s no need to spin up a new instance following an incident. Everything is already running, in sync, and ready. Furthermore, failover is immediate and it’s predictable. That is what you need when dealing with mission-critical workloads. Consider that many of the mission-critical applications you use were not designed to operate in the cloud, so even if your infrastructure is resilient, the application itself represents a single point of failure. Without replication, application monitoring, and real-time failover automation, you risk loss of revenue, security degradation, or worse.

SIOS Technology

Depending on the size of your enterprise and the industry in which it operates, an hour of downtime can cost $1 million or more, and 90% of organizations report costs of at least $300,000 per hour. Beyond that simple loss of revenue are soft costs associated with reputation damage, lost productivity, missed transactions, and more. Revenue protection is only part of the equation; it is about protecting the business.

Disaster recovery

Any design for high availability and resilience must also take into consideration the risk of a non-IT disaster that disrupts operations. Natural disasters like fires, earthquakes, and floods, or disasters caused by humans like the accidental severing of a trunkline or an act of sabotage conspire to bring operations to a sudden halt. Clustering, replication, and failover all play into disaster recovery, but there are additional considerations that must be addressed. For disaster recovery (DR), you’re going to want geographic distance between your primary site and your DR site to minimize the risk that a regional event doesn’t affect both. That means you’re going to want asynchronous (or near real-time) data replication.

SIOS Technology

Asynchronous replication is typically only a second or less behind synchronous replication, so it is de facto real-time, but that delay allows you to replicate across higher-latency networks and across longer distances. And because replication is happening continuously, even if you have a local failover between node one and node two, replication to the DR node doesn’t stop. Instead, when node two comes online it becomes the source of the mirror replicating to the DR site and back to node one once it is restored.

Patching and planned maintenance

Beyond the simplicity and cost advantages that come from taking a software-based approach to designing your cloud and hybrid infrastructure for high availability there is another big benefit. You are also better prepared to respond to the increased pressure on rapid implementation of software updates and security patches. No one wants to be the person responsible for taking too long to patch for a vulnerability, but every time you touch a system, you’re introducing the risk of error. That risk is greater when dealing with the cloud where you have less control over the underlying infrastructure, more abstraction, and a lot more moving parts.

In short, patches can break things as well as fix them. They have thus become a significant contributing factor as a cause of downtime. With SANless clusters you’re able to minimize that risk by enabling rolling updates, meaning you can patch a secondary server, verify that the patch didn’t break anything, and then patch the original server where the primary application is still running. If something does break on the secondary server, the primary is unaffected and you can quickly recover to the previous state while you figure out what went wrong. This simplifies the process of executing ad hoc patches and performing planned maintenance, mitigating the associated risks.

An investment in cloud and hybrid infrastructure and services doesn’t have to put IT operations at the mercy of a third party. With the right approach, you can design for high availability and resilience and keep your mission-critical workloads running in the cloud even when things outside of your control go wrong.

—

New Tech Forum provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all inquiries to doug_dineley@foundryco.com.

Back in 2023 and into 2024, as the hyperscalers announced massive data center expansions and plans for gigawatt-scale facilities, I was in boardrooms explaining why these timelines were unrealistic. The response was often a polite dismissal. The vendors were confident. The press was enthusiastic. And I was, well, the guy asking uncomfortable questions about power grids and infrastructure realities.

Now, in 2026, articles are confirming exactly what I and others who understand infrastructure have been saying all along. These massive data center projects are being delayed or canceled. Power shortages are creating bottlenecks across the industry. The grid simply cannot support the ambitions announced with such fanfare just a few years ago.

It wasn’t a mysterious formula to crack. It was simple math. And the math said the timeline was impossible.

Enterprises left holding the bag

If your AI road map relies on the abundant cloud capacity vendors promised, you’re likely facing tough conversations right now, and your AI growth plans are feeling pain. The promised compute doesn’t exist as advertised, and you’re scrambling to decide next steps. Looking inward is the only option at this point.

The vendors had every incentive to sell their vision with confidence and enthusiasm. When you’re a hyperscaler announcing a 10-billion-dollar data center campus, you’re in the business of capturing mindshare and customer commitment. While this strategy boosts sales, it fosters dangerous assumptions from customers. The enterprises that are struggling right now relied on vendor promises without doing their own analysis. They trusted the vendors to be right or, at least, close enough. They built their plans around the promises. When reality doesn’t match up, they are left holding the bag.

I speak frankly with my clients, and I’ll say it plainly here. You must do your own analysis. Vendors aren’t malicious, but their incentives don’t perfectly align with yours. They want your business, which means painting rosy pictures of capacity and timelines. You need someone to look out for your interests, and that person must be internal or a trusted advisor without a stake in selling you cloud services.

Two years ago, I was warning clients that the promised AI capacity was a fantasy for most organizations within the stated time frames. My advice was to plan for constraints, to build flexibility into infrastructure strategy, and to assume that the needed compute would be harder to get than the vendors suggested. Many clients nodded politely and went back to assuming the vendors would deliver. Some suggested I was too pessimistic.

The enterprises that took my advice seriously are in a much better position today. They planned for constraints. They chose hybrid strategies. They didn’t bet everything on hyperscaler promises that were never realistic. They’re not happy with the situation, but they’re not panicking either. For enterprises still scrambling, the first step is to admit that the old plan is dead. You cannot execute an infrastructure strategy built on vendor promises that never materialized. You need a new plan that accounts for real power constraints, real timeline challenges, and real competition for limited compute resources.

The grid isn’t expanding fast enough. Nearly half of all new US data center builds are being delayed or canceled. Yet AI demand continues to grow. These realities don’t care about your road map or your executive commitments.

Three realities to plan for

So, how should enterprises plan for future infrastructure growth? Let me offer three realities that need to be part of your planning process going forward.

1. First, assume constraints. Every infrastructure plan should assume you won’t get the power, space, or compute you want within the time frame you need. Build your strategies around limitations, not abundance. This isn’t pessimism; it’s realism. If the limitations hit, you’re ahead of the game. If they don’t materialize, you’ve simply over-engineered your solution and you can scale back.
2. Second, build for flexibility. The days of locking into single-vendor strategies based on promised capacity are over. You need infrastructure strategies that can adapt as reality unfolds. That means maintaining options, keeping relationships with multiple providers, and building architectures that can shift workloads as conditions change. The enterprises that will succeed aren’t the ones who picked the right hyperscaler. They’re the ones who didn’t put all their eggs in one basket.
3. Third, do the math yourself. When a vendor shares future capacity plans, analyze whether they’re realistic. Review power infrastructure constraints. Review construction timelines. Review historical patterns of delivery versus promises. Make vendors substantiate their commitments in writing with enforceable accountability clauses. Protect your organization from optimistic sales projections that don’t align with operational realities.

Hype never stops

The AI capacity crisis we’re living through was predictable. Those who predicted it were largely ignored because the message wasn’t what people wanted to hear. But that’s always the way infrastructure reality works. The grid can only expand so fast. Power capacity has real limits. Massive new demands create real bottlenecks.

The vendors will keep selling the vision. The press will keep covering the announcements. And the hype will continue to outpace reality. Your job is to be skeptical. Your job is to build infrastructure strategies that work in the world that actually exists, not the world that vendors are selling.

My warnings two years ago about the data center capacity crisis were right. I expect to continue being right. The question is whether enterprises will finally start listening before the next wave of unrealistic vendor and media promises leads to the next round of painful corrections.

As always, the choice is yours.

Microsoft is betting that the integration of HorizonDB, the cloud-native PostgreSQL alternative it is developing, with Azure will attract more enterprise AI and agentic workloads to its cloud services.

Enterprises may not be willing to take that bet.

It’s been nine months since Microsoft unveiled HorizonDB, but the service remains in public preview with no announced general availability date. Why put AI projects on hold waiting for HorizonDB to arrive, when AWS, Google, Databricks, Snowflake, and others already have production-ready PostgreSQL services positioned for the same AI workloads that Microsoft says it is building HorizonDB to handle?

AWS has had the longest head start. Aurora PostgreSQL became generally available in 2017 and has since evolved from a cloud-native PostgreSQL database into an AI-ready service with vector search and integrations with Amazon Bedrock. Similarly, Google’s AlloyDB, which followed in 2022, now includes AlloyDB AI with vector search, embeddings and model interaction for generative AI and agentic applications.

Databricks and Snowflake, too, have their own platform-centric services in the form of Lakebase, which became generally available on AWS and Azure this year, and Snowflake Postgres, which was made generally available in February 2026.

As the latecomer, when Microsoft pitched HorizonDB at Ignite in November 2025 it talked up its new architectural approach to cloud-native PostgreSQL, built around disaggregated compute and storage and a database-as-log design. The hyperscaler also positioned native vector search and deep integration with Foundry and Fabric as key differentiators for AI-heavy workloads.

No reason to wait

Those architectural differences may not be compelling enough for CIOs to wait for HorizonDB to become generally available, though.

“Most enterprises with urgent needs will not wait. A long preview window creates uncertainty around SLAs, pricing, operational maturity, and roadmap confidence,” said David Linthicum, an independent cloud consultant.

And, said Stephanie Walter, practice lead of AI stack at Hyperframe Research, enterprises cannot build mission-critical production plans around an undefined GA date, regional footprint or support commitment.

Given the difficulty of unwinding a poor database choice, enterprises will approach unknown quantities with caution.

“Database platforms eventually become sticky control points. Once the database is connected to the rest of the application, analytics, AI, and governance stack, switching becomes a business transformation rather than just an infrastructure swap,” said Michael Ni, principal analyst at Constellation Research.

In the case of a cloud database, there’s also the unwelcome possibility of “huge egress fees” in case of change, said Bradley Shimmin, lead of the data and analytics practice at The Futurum Group.

All that uncertainty is likely to lead enterprises to restrict HorizonDB to experimental use cases for now, Shimmin added.

Performance anxiety

Analysts also questioned whether HorizonDB’s technical differences will show up in performance benchmarks.

Microsoft has said HorizonDB can deliver up to three times the throughput of open-source PostgreSQL, but makes no comparisons with rival offerings such as Aurora or AlloyDB that it will compete with, Walter said.

The bigger question, according to Igor Ikonnikov, advisory fellow at Info-Tech Research Group, is whether those performance advantages, still largely on paper, translate into a meaningful difference in production.

“A database with a better compute benchmark can still be more expensive once resilience and ecosystem costs are included,” Ikonnikov said.

The economics also point to another HorizonDB limitation, particularly for workloads that are not continuously running, said Advait Patel, senior site reliability engineer at Broadcom.

HorizonDB currently uses provisioned compute rather than a serverless, scale-to-zero model, meaning customers continue to incur compute charges while an instance is provisioned, even if its workload is intermittent or idle, Patel said.

There are developer considerations too.

HorizonDB’s PostgreSQL compatibility does not necessarily mean every existing PostgreSQL application will move cleanly as in its current form the database supports only an approved set of PostgreSQL extensions rather than arbitrary ones, Walter said.

Who should wait?

For enterprises already deeply invested in Microsoft’s Azure ecosystem, those limitations may not be enough to rule out waiting for HorizonDB, Patel said: The chance to integrate the database with AI services and the wider Microsoft stack may outweigh immediate availability, he added.

That calculus also reflects how enterprises typically make database decisions in the first place: not by comparing databases in isolation, but by weighing how well they fit into the broader technology stack, including the cloud platform they have standardized on, Ikonnikov said.

For Azure shops, the choice may therefore be less about moving an existing workload away from Aurora or AlloyDB and more about whether a new Azure workload should start on Azure Database for PostgreSQL today or wait for HorizonDB when it becomes available, he said.

That may be an open question for some enterprises, said Devin Pratt, research director at IDC. “Plenty of organizations are still mid-decision, not locked in,” he said.

Microsoft finally offers a timeframe

Microsoft still won’t say exactly when HorizonDB will launch, with Shireesh Thota, corporate vice president for Azure Databases at Microsoft, saying only, “General availability for Azure HorizonDB is currently targeted for the second half of 2026.”

That narrows it down to a period of a little over four months, including Microsoft’s FabCon and Ignite conferences — an eternity in AI.

After two decades of cloud architecture consulting, I see an unchanging pattern in enterprise deployments. Organizations approach me with unexpectedly high cloud bills, operational chaos, and architectures that look good on paper but cause headaches in production. The common thread is almost always the same. Fundamental concepts that should be foundational to any cloud deployment are treated as optional or ignored altogether.

I’m not talking about exotic requirements, bleeding-edge technologies, or vendor-specific best practices. Basic engineering principles are somehow getting lost amid the excitement of cloud adoption. I wish I could say it’s rare, but after working with organizations across industries and geographies for years, I can confirm that missing these fundamentals is more common than most people realize. The results are predictable. Bills grow faster than business value, architectures require constant firefighting, and teams are stretched too thin to optimize anything.

The good news? You don’t have to start over, but you do have to go back to basics. Here are three concepts most cloud architects overlook that will make your architecture dramatically more valuable and efficient.

Identifying common ground

When deploying heterogeneous architecture, especially in multicloud environments, organizations must aggressively reduce silos. This means establishing common control planes for security, governance, and operations. You won’t get there by relying on whatever proprietary technology each cloud provider offers out of the box. Each provider wants you locked into their way of managing things. That is fine for simple deployments, but when you are running across multiple clouds and on-premises systems, proprietary control planes introduce redundancy, complexity, and cost.

You need a single control layer that spans your entire environment. Instead of managing 10 different security solutions from 10 different providers, you have one. Instead of separate identity management systems for each cloud, you need one that works everywhere. This eliminates the need to change security parameters in five different consoles, maintain five different skill sets for five different operational models, and reconcile five different governance frameworks. The common control plane ties everything together.

This might sound hard, but it’s not as bad as you think. (I will cover the specific patterns in a future article.) The real issue is that most architects have never been trained to think this way. They were taught to select the best services from each provider rather than abstract away the differences. This fundamental gap costs organizations real money every single day.

Cost observability and optimization

Most architects treat cost visibility and optimization as afterthoughts, things that can be bolted on after the architecture is in place. That backward approach shows up in the results. Without cost observability and optimization baked into your architecture from day one, you cannot understand where your money is going, where waste is accumulating, or where you should make changes to align expenses with delivered value.

The more complex and heterogeneous your environment, the more critical this becomes. You need a unified cost observability layer that spans public and private clouds and your own infrastructure. This is about building a layer that aggregates cost data from everywhere, provides a single source of truth for spending, and delivers the insights needed to actively optimize. Without this, you are flying blind, making decisions based on incomplete data and discovering problems only after the invoice arrives.

Too many organizations fail to gain control of their cloud spending because their billing data is scattered across multiple consoles, with no way to correlate usage across providers. They cannot see which teams, projects, or services are driving costs. They miss opportunities to right-size, consolidate, or eliminate waste. You cannot improve what you cannot measure. Without a common cost observability and optimization layer built into your architecture, you will never achieve the efficiency the cloud was supposed to deliver.

Consider the human element

Here is an uncomfortable truth most architects do not want to discuss: The more complex your architecture is, the broader the range of skills you will need to keep it running. Complexity requires expertise, and expertise requires hiring, training, and retention. If your architecture demands 15 different skill sets to operate, you’d better have a plan for finding and retaining the people with those skills.

I have seen beautifully designed architectures fail because the organization could not meet hiring requirements. They compromised by hiring underqualified individuals, which led to operational failures, security gaps, and mounting technical debt. The architecture itself was sound. The human infrastructure around it was not. This is a solvable problem. It starts with acknowledging that you are not designing for yourself. You are designing for the team that will inherit this system after you have moved on to your next assignment or promotion.

The solution isn’t just simplifying architecture, though that should be a goal. The key is to consider human factors in your design. What skills are required? How can you find and train people? What cultural changes are necessary for effective operation? These questions are essential; ignoring them risks failure.

The simple bottom line

I understand why most cloud architects miss these basic principles. No single course or book brings all of this together in one place. Cloud architecture has become a collection of best practices, vendor recommendations, and conference talking points, rather than a disciplined engineering discipline focused on business value.

As a result, architectures end up optimized in the wrong places, if they are optimized at all. They are expensive to run, difficult to secure, and nearly impossible to operate at scale without constant intervention. The cloud promises efficiency, yet we are not delivering it because we have lost sight of the fundamentals.

It’s time to go back to basics. Commonality, human factors, and cost observability and optimization are the three things that separate architectures that create value from those that create cost. Incorporate these concepts into your architecture and you’ll get ahead of most production systems in use today.

Microsoft has had a narrow escape from total embarrassment: A security company uncovered a critical vulnerability that could have compromised all Azure Cosmos DB databases — both those of customers and Microsoft’s own.

Google subsidiary Wiz found a flaw in the database’s Gremlin API, usually used for storing and managing property graph data.

If bad actors had discovered it first, they could have exploited it to acquire what Wiz called the Cosmos Master Key, which would have enabled them to use the primary key of any Cosmos database, resulting in read and write access to any account. They would also have had access to a list of every database on the service, with identifiers such as subscription and tenant IDs.

Azure Cosmos DB is a NoSQL database that underpins Microsoft’s cloud services. It can be accessed through SDKs for framework such as Python, Node.js, Java, and .NET.

Wiz described how it discovered the vulnerability in a blog post. It disclosed details of the flaw to Microsoft in November 2025.

Microsoft deployed a hot fix within two days, but it took another eight months to re-engineer the infrastructure, removing the Cosmos Master Key and introducing new guardrails to Cosmos DB to prevent similar attacks.

It is not the first time Cosmos DB customers’ primary keys have been under threat: In 2021, Wiz found a flaw in data exploration tool Jupyter Notebook that could be exploited to access the database keys and other secrets.

This article first appeared on CSO.

Every cloud architect, every financial services executive, and frankly every enterprise CTO should be paying attention to what is going on in the United Kingdom right now. Britain has formally designated Microsoft, Google, Amazon Web Services, and Oracle as “critical third parties” to the financial sector, meaning they are now subject to direct oversight by UK financial regulators rather than being treated as distant infrastructure suppliers outside the regulatory perimeter.

The designations took effect on July 13, 2026, and the oversight will be carried out by the Bank of England, the Prudential Regulation Authority, and the Financial Conduct Authority. The point is straightforward. If these platforms underpin critical banking and financial operations, then their resilience is no longer just a procurement issue. It is now a matter of financial stability.

This is a bigger deal than many people understand. For years, enterprises have treated cloud platforms as outsourced technology providers. Regulators are now making a different argument. They are saying that when enough banks, insurers, payment firms, and market infrastructures depend on the same small group of cloud providers, those providers become systemic infrastructure whether they like the label or not. Reuters reported that the UK’s framework will bring requirements such as resilience testing, self-assessments, and incident reporting directly to these providers. In other words, this is not just more policy language. It is operational oversight aimed at the platforms themselves.

The first thing to understand is that this move is not anti-cloud. It is the opposite. It is an acknowledgment that cloud has become too important to remain lightly touched when it comes to systemic risk. Regulators are not trying to unwind cloud adoption in financial services. They are accepting the reality that core financial operations now depend on a concentrated set of external platforms. When that happens, the conversation changes from vendor management to infrastructure resilience.

Systemic cloud concentration

The market has spent years talking about cloud concentration risk as if it were some vague future concern. It is no longer abstract. The UK is acting because concentration at this level means that a disruption at one major provider can ripple across multiple institutions simultaneously. That is the core issue. It is not whether Microsoft, Google, Amazon, or Oracle are competent operators. In many cases, they are exceptionally good at what they do. The problem is that too much critical activity depends on too few shared platforms.

This is a concept many business and technology leaders still struggle to internalize. A single bank can do a fine job managing its own vendor exposure and still be part of a broader systemic vulnerability if every other bank is relying on the same provider, the same region, the same identity layer, or the same operational dependencies. Regulators are stepping in because the risk is collective, not just institutional. That is why this matters well beyond the UK. It provides a framework for thinking about cloud not as outsourced capacity, but as part of the plumbing of the financial system itself.

Regulators expand their reach

Traditionally, regulators focused on the bank, insurer, or market institution and expected that entity to manage the risks created by outside suppliers. That approach still exists, and financial institutions remain accountable for their own resilience. However, the UK now says that, in some cases, this indirect model is not enough. If a third party becomes critical enough, regulators want direct line of sight into that provider’s resilience posture as well. This is probably the most important architectural and policy signal in the entire move.

That changes the relationship between the financial sector and the cloud providers in a meaningful way. Direct oversight means cloud providers are increasingly being treated less like optional technology partners and more like essential utilities that support national economic confidence. Once that happens, architecture decisions start to carry a different weight. Decisions about control planes, failover models, identity dependencies, regional design, observability, and incident response are no longer just internal engineering choices. They become part of a broader resilience conversation that may now include regulators.

A lot of enterprises have been behind the curve. They built architectures under the assumption that the cloud was simply a faster and cheaper hosting model. It is not. At scale, cloud is shared critical infrastructure. The UK has now made that point explicit.

More scrutiny isn’t more safety

It’s tempting to read this and assume the problem has now been solved. It has not. Direct oversight of hyperscalers does not remove the responsibility of banks or other enterprises to architect well. In fact, it should push them to architect better. A regulated provider can still be a concentration point. A resilient platform can still be used in a fragile way. And a well-run cloud service can still become part of a badly designed dependency chain.

If you are in a regulated or highly sensitive industry, you should take this as a warning that resilience can no longer be treated as a side topic. You need to know exactly which services are business-critical, which control planes are shared, which identity systems create cross-platform dependencies, and how your recovery assumptions actually work in the real world. Most organizations are much weaker here than they believe.

The UK’s move should also force a hard conversation about operational transparency. If regulators are requiring incident reporting and resilience evidence from major providers, enterprises should be demanding clearer dependency mapping and better architectural visibility inside their own environments. You cannot build true resilience on top of assumptions and vendor slide decks.

The start of a much larger shift

The deeper message is that cloud is crossing a line from enterprise technology choice into national and sector-level infrastructure policy. Once a few governments and central regulators start treating cloud this way, the rest of the world tends to follow in some form. We have already seen comparable concern in Europe, and now the UK has made its own move with direct designations and direct oversight.

Architects, CIOs, and boards need to mature their thinking quickly. The conversation is no longer limited to feature depth, discounts, migration speed, or which provider has the best AI story this quarter. The conversation is now about resilience, concentration, transparency, control, and systemic dependency. Those are bigger issues, and they are not going away.

The UK is telling the market something very clearly. Microsoft, Google, Amazon, and Oracle are not just selling cloud services into the financial sector. They are becoming part of the infrastructure on which that sector depends. Once you understand that, everything changes, including how we architect for the future.

All of the major AI providers want you to use, and ideally stay within, their super apps, and now Microsoft is looking to capture that attention, too.

During an earnings call this week, CEO Satya Nadella confirmed that the tech giant is building a Copilot ‘super app’ that will be rolled out this quarter. The new platform will bring together various Copilot tools, including chat, Cowork, long-running Autopilot agents, and the always-on Microsoft Scout, powered by OpenClaw.

Microsoft said the super app will be wired into many of its other governance platforms, including Agent 365, IT Ops, SecOps, FinOps, and business processes. And, it said, CRM and ERP systems will “serve as skills and plug-ins that go into core work.”

“You’re able to take that enterprise-wide workflow and wire it into the super app,” Nadella said, describing it as “the coming together of a new way to work.”

With this move, Microsoft will compete with OpenAI’s ChatGPT Work, Claude Cowork, and a growing number of others trying to capture as much of a user’s workflow as possible. It could prove a strong contender, as everyday Copilot “usage intensity” is at the same level as that of Outlook or Teams, Nadella said, and paid seats now surpass 30 million.

Every model should be ‘swappable’

Even as it builds a super app to bridge workflows, Microsoft is acknowledging enterprise demand for model choice. Customers are making it clear that they don’t want to be locked into one model; they want the ability to move between open, closed, and frontier options based on the best tool for the job.

This trend is reflected in Redmond’s own usage statistics: Since the beginning of the year, it has tracked a 5x increase in the number of customers building with models from multiple providers featured on its platform.

The company claims it has the broadest model catalog in the cloud, offering more than 11,000 models from OpenAI, Anthropic, Mistral, its own MAI family, and others.

“We are building a new model system, where the harness, context, memory, and action space are separate from any one model family, thereby moving the frontier on the cost-to-outcome curve,” Nadella said. “That’s really the enterprise design architecture that we are going to evangelize.”

He described enterprises as “learning machines” that need their own internal learning machines, and said that they will be evaluating how providers are helping them reach their business goals and support knowledge creation.

“The models are an input, not some extraction of the knowledge of the enterprise,” Nadella said. “This is not going to be about, ‘come in and take all my knowledge and benefit yourself, [and] I am not getting anything out of it.’”

The key is in balancing the advantages of frontier models with lower-cost options, open weights with closed weights, and having the ability to train internal models based on outputs, traces, and context. “You should and you can use frontier models,” Nadella said. “There’s no reason not to.”

However, he said, any given model at any given time should be swappable to democratize design.

For instance, data from cybersecurity evaluation framework CyberGym showed that Microsoft’s new MAI-Cyber-1-Flash coding agent achieved Claude Mythos-level performance at 50% of the cost. This is because 90% of tasks were completed by Cyber-1-Flash and 10% by frontier models from OpenAI, Anthropic, and others. 

This ability to use the right model for the right task in what is essentially a pipeline job is a “super important characteristic,” Nadella said. Microsoft Copilot, Security Copilot, and GitHub Copilot are all built to support movement between different models based on the task.

This strategy is also reflected in the company’s new Project Perception cybersecurity offering. The platform features three specialized types of agent (red, blue, and green), and the underlying harness decides which AI model is best suited for a given task. Guided by specialized playbooks, red team agents discover vulnerabilities, blue team agents triage, and green team agents propose remediation plans.

“You create your own agentic system that’s continuously operating to create the cyber defense you need,” Nadella explained. “Especially in cyber[security], it becomes critical to have that multi-model approach.”

Nadella also pointed to the recent Hugging Face incident, in which an OpenAI model went rogue, broke out of its sandbox, and launched an attack against the popular open-source platform, noting that enterprises will likely need to use multiple models to offset and remediate the various challenges of each, and should not be “subject to the refusals of one model.”

“We talk about the frontier as if it’s one thing,” Nadella said. “The frontier is about every firm having a frontier, the choice, the cost control, and the capability that they need in order to be able to control their destiny.”

Increased push to usage-based pricing, closing demand gaps

As Microsoft emphasizes its model-agnostic architecture, it is also shifting from per-seat to per-seat-plus-consumption pricing; the company recently added usage-based billing to Cowork and Agent 365, and plans to continue that trend across its products.

While these moves have resulted in sticker shock and ‘tokenmaxxing’ at many companies, Nadella framed it as a revenue driver. “We are advancing the frontier on the cost-to-outcome curve, ensuring every customer can turn tokens into business results.”

Meanwhile, Microsoft said it will continue to close data demand-capacity gaps.

The company added 88 data centers in FY 2026, including 31 across five continents this past quarter. It contended that it is bringing capacity online “faster than ever,” reducing dock-to-live times for new GPUs in its largest regions by nearly 50% over the fiscal year.

However, CFO Amy Hood acknowledged during the earnings call, “the situation is obviously that demand exceeds available supply in a relatively extreme moment.”

Reflecting this, revenue for Azure and other cloud services grew by 43% in Microsoft’s fiscal year ended June 30, and the company expects similar revenue growth (45%) in fiscal year ‘27.

Hood said that Microsoft remains “focused on delivering efficiencies,” including in its CPU and GPU fleets, and engineers are also working on process improvements. The company added another gigawatt of capacity this quarter and is on track to roughly double its overall capacity in two years.

“We are also getting more from the infrastructure we already have by optimizing across silicon, systems, and software,” Hood said.

This article originally appeared on CIO.com.

For years, the public cloud was the default for new workloads because its convenience, elasticity, and breadth of services made sense. However, as AI’s strategic importance grows, its economics and infrastructure are changing. Tesla is one of the clearest examples of a company deciding that AI is too important, too expensive, and too central to its business to leave largely in the hands of a third-party cloud provider.

 At the center of Tesla’s strategy is a simple idea. If AI is key to how you build your products, run your business, and define your future, the infrastructure that powers AI becomes a strategic asset. It is no longer just plumbing but part of the product itself. Tesla’s models, databases, applications, and workflows increasingly rely on infrastructure that is built, hosted, and managed by Tesla. That means the company has direct control over the hardware, the software stack, data movement, performance tuning, and security posture. For a company that depends on AI to support autonomy, robotics, manufacturing intelligence, and future product direction, that control matters.

This is the real heart of the matter. Tesla is not treating AI as a side project or a feature layer added on top of an existing business. AI is central to Tesla now and into the future. It is a force multiplier, but more than that, it is an essential aspect of product development, operational efficiency, automation, and competitive differentiation. Once a company reaches that level of dependence on AI, the conversation around infrastructure changes very quickly.

Public cloud is attractive because it provides a complete AI ecosystem on demand. You can provision compute, storage, training environments, managed services, orchestration tools, and deployment pipelines without building much yourself. That is why I often call public cloud “the easy button” for AI. It is fast, convenient, and feature-rich. But convenience comes with a premium, and for many companies moving deeply into AI, that premium is becoming very hard to justify.

Cost is driving AI out of the cloud

One of the biggest forces driving this shift is price. Many enterprises moving into AI are shocked by what public cloud providers charge for AI infrastructure. Training clusters, inference engines, storage, networking, observability, and support services all add up quickly. What begins as a convenient path to experimentation can become an extremely expensive operating model when AI moves into production at scale.

In my experience during the past 15 years, public cloud is often at least twice as expensive as comparable private infrastructure for sustained workloads. That is not true in every case, and it depends heavily on utilization patterns, architecture, and operational maturity. However, for large, predictable, always-on AI workloads, public cloud economics often become difficult to defend. The markup associated with convenience, elasticity, and managed ecosystems is substantial.

In response, companies are increasingly exploring alternatives. Some are moving toward neoclouds that specialize in AI infrastructure. Others are evaluating sovereign cloud options for control, locality, or compliance reasons. Many are revisiting private cloud infrastructure for the most strategic and cost-intensive workloads. Tesla is becoming the poster child for how successful that approach can be when a company has the scale, the sophistication, and the long-term commitment to execute it well.

Control, governance, and security

Cost is only one part of the equation. Control is the other major driver. When Tesla runs its AI infrastructure on equipment it owns and operates, it gains much tighter control over performance, data handling, workload placement, governance models, and operational priorities. That matters a great deal when the workloads involved are mission-critical and directly connected to the future of the company.

A privately controlled AI environment can provide better security because the organization has direct oversight of the infrastructure stack. It can provide better governance because data, models, and workflows remain inside systems the enterprise fully controls. It can also improve reliability and performance tuning because engineering teams can optimize specifically for their own AI pipelines rather than adapting to the generalized patterns of a shared cloud environment.

Of course, many people are quick to point out that running your own private infrastructure comes with significant labor and cost. They are not wrong. Building and operating private AI infrastructure requires capital, engineering skill, facilities, procurement discipline, operational excellence, and long-term commitment. This is not a shortcut, nor is it easier than public cloud. In many ways, it is harder.

However, the point is that for sophisticated companies with large-scale, steady-state AI needs, it can be worth it. Better control, better governance, better security, and ultimately lower cost can justify the additional operational burden.

The future of AI infrastructure

What makes Tesla so important in this discussion is that the company chose this route because AI is inseparable from its business strategy. Many other enterprises are heading in this same direction. As AI becomes less experimental and more operational, the infrastructure conversation shifts from convenience to economics, control, and differentiation.

Not every company should follow Tesla’s path. Many enterprises are not ready to build, host, and manage their own AI environments. Many lack the scale to justify it. Many still benefit tremendously from the agility of public cloud. But for organizations where AI is becoming central to products, services, and competitive advantage, Tesla’s strategy is increasingly relevant.

There are three things every enterprise should think about when considering ownership of its own AI infrastructure:

• First, understand the operational burden in full. Private AI infrastructure requires teams, processes, facilities, and discipline that many organizations underestimate.
• Second, know the economics of your workload patterns. If AI demand is large, steady, and strategic, the cost advantages of ownership may be compelling.
• Third, think beyond cost alone and focus on control. If AI is core to your future, owning the infrastructure may offer strategic benefits in governance, security, optimization, and long-term independence that public cloud cannot easily match.

Tesla’s strategy is not for everyone, but it is a persuasive example of what happens when a company decides that AI is too important to rent forever. Public cloud remains the easy button, and for many organizations, that will be enough. But for companies that see AI as fundamental to how they will compete, private infrastructure may turn out to be the smarter choice.

Model Context Protocol (MCP), the emerging standard for connecting AI models to external tools and enterprise data, is undergoing its biggest architectural overhaul yet.

The latest release candidate, scheduled for release on July 28, removes protocol-level sessions in favor of a stateless architecture, a change which industry experts say is intended to make MCP easier to deploy across standard cloud infrastructure as enterprises move AI pilots into production.

“The session-based model made sense when MCP servers were local processes on a developer’s laptop. In production, it became an operational tax,” said Muskan Bandta, cloud associate at ZopDev.

“When your infrastructure team asks whether MCP services can scale like other cloud applications, the answer used to be ‘not quite.’ With the move to a stateless architecture, the answer is now yes,” Bandta added.

Earlier versions of the protocol maintained information about every client connection, meaning servers had to keep track of each session throughout an interaction. While that approach worked well for local development, it complicated deployments across multiple servers because requests often had to be routed back to the same machine, limiting scalability and making MCP a less natural fit for modern cloud architectures.

“Under the new stateless design, every request contains the information needed for any available server to process it independently. Applications that need to maintain context across multiple requests can still do so, but developers must now manage that state explicitly rather than relying on the protocol itself,” she said.

This transition to a stateless design goes beyond simplifying infrastructure by fundamentally changing how AI applications manage and share context across tools, according to Amit Jena, AI development manager at IT consulting firm Kanerika.

Instead of keeping application state hidden inside protocol sessions, the new design makes it explicit, allowing AI models to access, reason over, and pass that information between tools, giving developers greater control over how context is preserved and shared across tools, Jena said.

It should also make AI workflows more portable, resilient, and easier to orchestrate across distributed environments, he said.

MCP’s new features

Other changes to MCP include the addition of a Multi Round-Trip Requests (MRTR) mechanism that changes how AI agents request additional information they need to complete a task.

Instead of relying on a persistent connection between the client and server throughout the interaction, the new mechanism lets the server request additional input through a standard request-response exchange before continuing the task, Jena said.

Routable transport headers, another addition, enable API gateways and other networking infrastructure to identify and route MCP requests without inspecting their contents.

They reduce processing overhead, lower latency, and let enterprise teams enforce routing, rate-limiting and security policies more efficiently using existing API management infrastructure, Jena said.

MCP is also getting an updated authorization framework built around OAuth 2.1 and OpenID Connect; interactive MCP Apps; and deterministic caching of tool and resource listings to improve LLM prompt-cache hit rates, potentially saving on token costs.

Rebuilding the trust boundary

The MCP release steering committee also decided to deprecate some legacy features, including Roots, Sampling, Logging, the older HTTP+SSE transport and Dynamic Client Registration, although these will continue to work in this version and any other released over the next year.

The deprecation of Sampling is likely to have the biggest impact because it changes who is responsible for interacting with foundation models, said Jena.

“Sampling let MCP servers invoke the LLM through the client, which meant the server had a callback path into the model without owning that connection. Deprecating it means rebuilding that trust boundary,” Jena said. “Your server now calls the model provider directly. That changes your network architecture, your auth model, and depending on how you’ve built cost attribution, your billing flow.”

The year-long transition period will be enough for teams to audit their sampling dependencies now, said Jena: “The risk is that teams who haven’t implemented sampling themselves won’t know if a third-party MCP server they’re depending on uses it.”

Updated MCP SDKs

To accompany the protocol update, there are updated MCP SDKs for Python, Typescript, Go, and C#. These support both the old and new protocol versions, so new clients can continue communicating with older servers, while updated servers will also support older clients, reducing the risk of immediate disruptions.

That backward compatibility should make the transition largely incremental, except for enterprises that built custom infrastructure around MCP’s earlier session-based architecture, Bandta said.

Identifying and auditing those session dependencies may not be easy, Jena warned.

“Session management complexity tends to be hidden across multiple layers — the gateway config, the deployment scripts, the monitoring dashboards. The code change is small; finding everywhere the assumption lives is what takes time,” he said.

Microsoft cloud and Azure services hosted on the West Coast of the US went down for hours on Thursday when network connectivity failed. Although services running entirely within Microsoft’s West US cloud region were unaffected, any traffic entering or leaving the facilities was affected.

Microsoft has now published a Preliminary Post Incident Review (PIR) of the incident, reporting that connectivity was lost for five hours between 14.44 UTC (7.44 a.m. Pacific Time) and 19.41 UTC on July 23. The problem was caused when a set of IP routes was removed in error while isolating a device for routine maintenance.

Before starting the maintenance work, Microsoft checked that at least one of the two redundant paths to the facility remained operational. When it came to starting the work, however, automated systems included some additional devices in the perimeter to be isolated, and removing some IP routes that had not been included in the initial assessment.

Customers discovered the problems very quickly, and engineers identified the issue within the first hour and started to reconnect services.  Microsoft said the disruption had been caused by some “recent fiber maintenance activity”.

To minimize the risk of disruption from such errors in the future, Microsoft advised organizations handling mission-critical data to consider a multi-region approach.

The Azure outage was the second significant one to hit Microsoft this year. In February, there was a 10-hour disruption to US West and US East regions.

This article first appeared on Network World.