For much of the last decade, enterprise infrastructure strategy had a fairly clear direction: move more workloads to the cloud. There were good reasons for that.
Public cloud changed how organizations provision infrastructure, scale applications, and consume managed services. Capacity that once took weeks or months to procure could be available in minutes, alongside databases, analytics, cybersecurity, development platforms, and increasingly sophisticated AI services.
For many workloads, public cloud remains the most practical answer. But I do not think “cloud-first” by itself is a sufficient architecture strategy anymore. The more useful question is: “Where should this particular workload run, and why?”
That small change leads to a different discussion. Instead of beginning with a preferred platform, we begin with the workload: its business impact, data, regulation, latency, availability, integration, compute requirements, operating model, and economics.
Only then do we decide whether it belongs in public cloud, private cloud, sovereign cloud, an enterprise data center, the edge, or some combination of them. That is what I mean by moving from cloud-first to workload-first architecture.
Cloud should be an architecture option, not the architecture objective
Infrastructure strategies built around a platform decision can bias the architecture before the workload has been assessed. A “cloud-first” policy can turn the discussion into “How do we make this application fit the cloud?”, while a private-cloud strategy can create the opposite pressure: “How do we justify keeping this workload inside our infrastructure?”
I prefer a simpler starting point:
“What does the workload actually require?”
How critical is the application, what data does it process, and where does that data already reside? Does regulation restrict where the data can be stored or administered? What latency, RTO, and RPO requirements apply?
Does it require GPUs, accelerators, high-memory compute, or other specialized hardware, and is demand predictable or highly variable? Which applications, networks, databases, APIs, operational systems, or external organizations must it communicate with? What happens when connectivity to another environment is interrupted?
Finally, who will operate the platform, and what will the workload cost over three to five years rather than during the first few months?
These questions usually tell us much more about the appropriate architecture than the label attached to a particular platform.
This is also consistent with the direction of current industry research. Gartner’s September 2026 research, Achieve Optimal Workload Placement for Hybrid IT in 5 Steps, identifies rising costs, sovereignty mandates, resilience risks, AI demand, and changing provider economics as factors reshaping placement decisions.
The important point is not that enterprises are moving away from cloud. They are becoming more selective about where different workloads should run.
Public cloud remains the right answer for many workloads
A workload-first approach is not an argument against public cloud, which continues to solve many problems extremely well.
Take an internet-facing application with unpredictable traffic. Building private capacity for occasional peaks may make little economic sense when infrastructure can scale with demand. The same applies to development and test environments, global digital services, short-lived compute, analytics, managed databases, integration platforms, and applications that depend heavily on managed services.
Public cloud can also provide early access to new AI capabilities without requiring organizations to purchase and operate expensive infrastructure. Speed has business value too: one architecture may enable a service to launch in weeks while another requires a long procurement and deployment cycle.
The question is whether those characteristics match the workload.
Private cloud has a different role
Private cloud is often described as an on-premises version of public cloud, but that is too simplistic. It is also distinct from a conventional virtualized data center: running virtual machines on enterprise-owned servers does not automatically create a cloud operating model.
A mature private-cloud environment should provide standardized services, automated provisioning, orchestration, policy enforcement, lifecycle and capacity management, monitoring, API-based operations, and some degree of self-service.
When those capabilities exist, private cloud can be an appropriate option for workloads requiring tighter infrastructure control, predictable performance, specialized hardware, stable long-term capacity, close integration with existing systems, or particular security boundaries.
Private infrastructure can also make economic sense when demand is large, stable, and consistently utilized, but buying servers is not the same as calculating private-cloud TCO.
A full calculation includes storage, networking, facilities, power and cooling, platform software, backup and disaster recovery, monitoring, security, support, engineering resources, and hardware refresh cycles.
It should not be declared cheaper without doing the full calculation.
Sovereignty adds another dimension
For governments, financial institutions, telecommunications providers, utilities, healthcare organizations, and critical-infrastructure operators, workload placement can involve another set of requirements: digital sovereignty.
Gartner forecasts worldwide sovereign-cloud IaaS spending of approximately USD 80 billion in 2026, representing 35.6% growth from 2025. That investment reflects a real shift in how governments and regulated organizations think about infrastructure control.
Sovereignty should not be reduced to “Is the data center located inside the country?” Data location can be important, but the architecture requirements may go considerably further.
An organization may need to verify who can administer the infrastructure, where privileged access originates, who controls encryption keys, the applicable jurisdiction and support location, operational continuity without external connectivity, and independent auditability.
Technology dependency also matters, including the ability to operate if access to an external provider or control plane is lost. This is why I see sovereignty as an architectural and operational posture rather than simply a product category.
A service does not become sovereign because the word appears in its commercial name; the technical controls still have to prove it.
AI makes workload placement more complicated
AI changes the infrastructure discussion because these workloads do not always behave like conventional enterprise applications. CPU, memory, storage capacity, network throughput, availability, and database performance still matter, but AI adds another layer.
AI placement may depend on GPU type and memory, accelerator availability, high-speed interconnects, storage throughput, model size, serving architecture, utilization, power density, and cooling.
These resources are not inexpensive. Gartner forecasts worldwide AI-optimized IaaS spending of approximately USD 42 billion in 2026, driven by demand for model training and the operational use of AI across enterprise applications and workflows.
This raises a practical economic question: should an organization purchase accelerator infrastructure or consume it when required? The answer depends heavily on utilization. A substantial GPU environment can produce poor economics if expensive accelerators spend much of their time idle; continuously consuming external accelerator capacity for predictable production workloads can create a very different cost profile.
There is no useful universal rule here. The architecture depends on the workload.
AI training and inference can require different architectures
It is also worth separating AI training from AI inference. They are related, but they do not necessarily belong in the same infrastructure environment. Training can require a significant concentration of accelerator resources for a limited period, which makes elastic infrastructure attractive.
Inference may behave differently. Once AI becomes part of normal enterprise operations, it can run continuously and become latency-sensitive.
Consider an industrial environment, telecom network, transportation platform, or citywide video analytics system.
If a camera, sensor, vehicle, or machine needs an immediate decision, sending every piece of raw data to a distant centralized environment may create excessive network demand, unacceptable latency, or a dependency on connectivity that the application cannot tolerate. In that situation, some inference may belong at the edge.
Central private or sovereign infrastructure may manage sensitive operational information and enterprise integration, while public cloud provides elastic training capacity or selected managed AI capabilities.
A legitimate architecture could therefore span:
Edge → Private or Sovereign Platform → Public Cloud
This is exactly why I do not think enterprises should force every component of an AI solution into the same infrastructure environment.
Data gravity still matters
Data gravity is another factor that is easy to underestimate.
Imagine an enterprise already has several petabytes of operational information in its data center.
Moving that data repeatedly to another environment simply because compute capacity exists there may introduce substantial bandwidth consumption, transfer costs, latency, security considerations, and operational complexity.
Sometimes it makes more sense to move compute closer to the data.
This becomes particularly relevant for AI, analytics, video, IoT, telecommunications, scientific workloads, and other data-intensive environments.
AWS Prescriptive Guidance for multicloud environments in financial services makes a similar point, recommending that workload placement consider requirements such as latency, data location, security, integration, operating complexity, and cost. Its discussion of contiguous workloads across cloud providers also addresses the operational effect of separating applications from their data.
The underlying principle is vendor-neutral: the location of the data is part of the architecture decision.
Edge computing should be driven by a requirement, not by fashion
Edge computing is another area where architecture can easily become driven by terminology. Putting compute at the edge only makes sense when there is a reason for it.
Good reasons can include very low latency, local autonomy, bandwidth optimization, intermittent connectivity, privacy requirements, or the need to process high-volume data close to where it is generated.
A manufacturing system may need to make a decision locally. A video analytics system may need to analyze streams near the cameras and send events rather than every raw frame to a central platform. A telecom workload may need processing close to the network edge, while an IoT deployment may need to continue operating when WAN connectivity is unavailable.
Those are architecture requirements. “Edge” by itself is not a requirement.
Hybrid should be treated as an operating model
Hybrid cloud is sometimes described as an intermediate state.
The assumption is that an organization has some legacy workloads on-premises today, but eventually everything important will move to public cloud.
For some organizations, that may be exactly what happens.
For many large enterprises, governments, banks, telecom operators, and critical-infrastructure organizations, I would not assume it.
Hybrid may be the intended long-term architecture.
The difficult part is not drawing two clouds and a data center on an architecture diagram.
The difficult part is operating them consistently.
Identity and access management should work coherently, security policies need consistent enforcement, and logs and telemetry need to be observable. Configuration and infrastructure deployment should be automated, while backup and disaster-recovery policies must work across platform boundaries.
Vulnerability management cannot stop at the edge of one provider, and data governance has to follow the information. FinOps needs visibility across consumption-based and fixed-capacity infrastructure.
AI introduces additional governance around models, data, prompts, inference, access, and auditability.
Without that operating model, hybrid infrastructure can quickly become several independent technology islands connected by a network—hardly the outcome enterprises should be aiming for.
A practical workload-placement framework
When I evaluate workload placement conceptually, I prefer to consider several dimensions together rather than starting with a preferred provider or technology.
The following questions provide a useful architecture baseline.
Business criticality. What is the impact if the workload becomes unavailable?
Data sensitivity. What data does the workload process, generate, or store?
Regulation and sovereignty. Which residency, jurisdiction, administrative-access, encryption-key, and audit requirements apply?
Latency. How close must processing be to users, devices, systems, or data?
Compute requirements. Does the workload require GPUs, accelerators, high-memory systems, special processors, or other specialized hardware?
Data gravity. Where does most of the associated data already reside?
Scalability. Is resource demand stable, seasonal, unpredictable, rapidly growing, or temporary?
Availability and disaster recovery. What levels of availability, RTO, RPO, geographic redundancy, and operational continuity are required?
Integration. Which existing applications, networks, databases, APIs, devices, partners, and external services must connect to the workload?
Operational capability. Does the organization genuinely have the skills, processes, tooling, and support structure required to operate the selected platform?
Economics. What is the realistic three-to-five-year lifecycle cost?
Dependency and exit. What happens if the organization needs to move the workload to another platform later?
The last point deserves more attention than it usually receives.
Architecture teams naturally spend a lot of time planning how a workload enters a platform, but it is also worth understanding what it would take to leave. That does not mean avoiding managed services or proprietary technology; those capabilities can deliver significant value. It means treating dependency as an architecture trade-off rather than discovering it several years later.
