Cloud Repatriation and the Growth Paradox of Public Cloud IaaS

Cloud Repatriation and the Growth Paradox of Public Cloud IaaS

Over the past two years, a new narrative has taken hold in the cloud market. No, it is not always about sovereign cloud. 🙂 Headlines talk about cloud repatriation – nothing really new, but it is still out there. CIOs speak openly about pulling some workloads back on-premises. Analysts write about organizations “correcting” some earlier cloud decisions to optimize cloud spend. In parallel, hyperscalers themselves now acknowledge that not every workload belongs in the public cloud.

And yet, when you look at the data, you will find a paradox.

IDC and Gartner both project strong, sustained growth in public cloud IaaS spending over the next five years. Not marginal growth and sign of stagnation. But a market that continues to expand at scale, absorbing more workloads, more budgets, and more strategic relevance every year.

At first glance, these two trends appear contradictory. If organizations are repatriating workloads, why does public cloud IaaS continue to grow so aggressively? The answer lies in understanding what is actually being repatriated, what continues to move to the cloud, and how infrastructure constraints are reshaping decision-making in ways that are often misunderstood.

Cloud Repatriation Is Real, but Narrower Than the Narrative Suggests

Cloud repatriation is not a myth. It is happening, but it is also frequently misinterpreted.

Most repatriation initiatives are highly selective. They focus on predictable, steady-state workloads that were lifted into the public cloud under assumptions that no longer hold. Cost transparency has improved, egress fees are better understood and operating models have matured. What once looked flexible and elastic is now seen as expensive and operationally inflexible for certain classes of workloads.

What is rarely discussed is that repatriation does not mean “leaving the cloud”, but I have to repeat it again: It means rebalancing. Meaning, that trganizations are not abandoning public cloud IaaS as a concept. They are just refining their usage of it.

At the same time, some new workloads continue to flow into public cloud environments. Digital-native applications, analytics platforms, some AI pipelines, globally distributed services, and short-lived experimental environments still align extremely well with public cloud economics and operating models. These workloads were not part of the original repatriation debate, and they seem to be growing faster than traditional workloads are being pulled back.

This is how both statements can be true at the same time. Cloud repatriation exists, and public cloud IaaS continues to grow.

The Structural Drivers Behind Continued IaaS Growth

Public cloud IaaS growth is not driven by blind enthusiasm anymore. It is driven by structural forces that have little to do with fashion and everything to do with constraints.

One of the most underestimated factors is time. Building infrastructure takes time and procuring hardware takes time as well. Scaling data centers takes time and many organizations today are not choosing public cloud because it is cheaper or “better”, but because it is available now.

This becomes even more apparent when looking at the hardware market right now.

Hardware Shortages and Rising Server Prices Change the Equation

The infrastructure layer beneath private clouds has suddenly become a bottleneck. Server lead times have increased, GPU availability is constrained and prices for enterprise-grade hardware continue to rise, driven by supply chain pressures, higher component costs, and growing demand from AI workloads.

For organizations running large environments, this introduces a new type of risk. Capacity planning is a logistical problem and no longer just a financial exercise anymore. Even when budgets are approved, hardware may not arrive in time. That is the new reality.

In this context, public cloud data centers represent something extremely valuable: pre-existing capacity. Hyperscalers have already made the capital investments and they already operate at scale. From the customer perspective, infrastructure suddenly looks abundant again.

This is why many organizations currently consider shifting workloads to public cloud IaaS, even if they were previously skeptical. It became a pragmatic response to scarcity.

The Flawed Assumption: “Just Use Public Cloud Instead of Buying Servers”

However, this line of thinking often glosses over a critical distinction.

Many of these organizations do not actually want “cloud-native” infrastructure, if we are being honest here. What they want is physical capacity – They want compute, storage, and networking under predictable performance characteristics. In other words, they want some VMs and bare metal.

Buying servers allows organizations to retain architectural freedom. It allows them to choose their operating system or virtualization stack, their security model, their automation tooling, and their lifecycle strategy. Public cloud IaaS, by contrast, delivers abstraction, but at the cost of dependency.

When organizations consume IaaS services from hyperscalers, they implicitly accept constraints around instance types, networking semantics, storage behavior, and pricing models. Over time, this shapes application architectures and operational processes. The usage of such services suddenly became a lock-in.

Bare Metal in the Public Cloud Is Not a Contradiction

Interestingly, the industry has started to converge on a hybrid answer to this dilemma: bare metal in the public cloud.

Hyperscalers themselves offer bare-metal services. This is an acknowledgment that not all customers want fully abstracted IaaS. Some want physical control without owning physical assets. It is simple as that.

But bare metal alone is not enough. Without a consistent cloud platform on top, bare-metal in the public cloud becomes just another silo. You gain performance and isolation, but you lose portability and operational consistency.

Nutanix Cloud Clusters and the Reframing of IaaS

Nutanix Cloud Platform running on AWS, Azure, and Google Cloud through NC2 (Nutanix Cloud Clusters) introduces a different interpretation of public cloud IaaS.

Instead of consuming hyperscaler-native IaaS primitives, customers deploy a full private cloud stack on bare-metal instances in public cloud data centers. From an architectural perspective, this is a subtle but profound difference.

Customers still benefit from the hyperscaler’s global footprint and hardware availability and they still avoid long procurement cycles, but they do not surrender control of their cloud operating model. The same Nutanix stack runs on-premises and in public cloud, with the same APIs, the same tooling, and the same governance constructs.

Workload Mobility as the Missing Dimension

The most underappreciated benefit of this approach is workload mobility.

In a cloud-native bare-metal deployment tied directly to hyperscaler services, workloads tend to become anchored, migration becomes complex, and exit strategies are theoretical at best.

With NC2, workloads are portable by design. Virtual machines and applications can move between on-premises environments and public cloud (or a service provider cloud) bare-metal clusters without refactoring. In practical terms, this means organizations can use public cloud capacity tactically rather than strategically committing to it. Capacity shortages, temporary demand spikes, regional requirements, or regulatory constraints can be addressed without redefining the entire infrastructure strategy.

This is something traditional IaaS does not offer, and something pure bare-metal consumption does not solve on its own.

Reconciling the Two Trends

When viewed through this lens, the contradiction between cloud repatriation and public cloud IaaS growth disappears.

Public cloud is growing because it solves real problems: availability, scale, and speed. Repatriation is happening because not all problems require abstraction, and not all workloads benefit from cloud-native constraints.

The future is not a reversal of cloud adoption. It is a maturation of it.

Organizations are asking how to use public clouds without losing control. Platforms that allow them to consume cloud capacity while preserving architectural independence are not an alternative to IaaS growth and they are one of the reasons that growth can continue without triggering the next wave of regret-driven repatriation.

What complicates this picture further is that even where public cloud continues to grow, many of its original economic promises are now being questioned again.

The Broken Promise of Economies of Scale

One of the foundational assumptions behind public cloud adoption was economies of scale. The logic seemed sound. Hyperscalers operate at a scale no enterprise could ever match. Massive data centers, global procurement power, highly automated operations. All of this was expected to translate into continuously declining unit costs, or at least stable pricing over time.

That assumption has not materialized as we know by now.

If economies of scale were truly flowing through to customers, we would not be witnessing repeated price increases across compute, storage, networking, and ancillary services. We would not see new pricing tiers, revised licensing constructs, or more aggressive monetization of previously “included” capabilities. The reality is that public cloud pricing has moved in one direction for many workloads, and that direction is up.

This does not mean hyperscalers are acting irrationally. It means the original narrative was incomplete. Yes, scale does reduce certain costs, but it also introduces new ones. That is also true for new innovations and services. Energy prices, land, specialized hardware, regulatory compliance, security investments, and the operational complexity of running globally distributed platforms all scale accordingly. Add margin expectations from capital markets, and the result is not a race to the bottom, but disciplined price optimization.

For customers, however, this creates a growing disconnect between expectation and reality.

When Forecasts Miss Reality

More than half of organizations report that their public cloud spending diverges significantly from what they initially planned. In many cases, the difference is not marginal. Budgets are exceeded, cost models fail to reflect real usage patterns, optimization efforts lag behind application growth.

What is often overlooked is the second-order effect of this divergence. Over a third of organizations report that cloud-related cost and complexity issues directly contribute to delayed projects. Migration timelines slip, modernization initiatives stall, and teams slow down not because technology is unavailable, but because financial and operational uncertainty creeps into every decision.

Commitments, Consumption, and a Structural Risk

Most large organizations do not consume public cloud on a purely on-demand basis. They negotiate commitments, look at reserved capacity, and spend-based discounts. These are strategic agreements designed to lower unit costs in exchange for predictable consumption.

These agreements assume one thing above all else: that workloads will move. They HAVE TO move.

When migrations slow down, a new risk pops up. Organizations fail to reach their committed consumption levels, because they cannot move workloads fast enough. Legacy architectures, migration complexity, skill shortages, and governance friction all play a role.

The consequence is subtle but severe. Committed spend still has to be paid and because of that future negotiations become weaker. The organization enters the next contract cycle with a track record of underconsumption, reduced leverage, and less credibility in forecasting.

In effect, execution risk turns into commercial risk.

This dynamic is rarely discussed publicly, but it is increasingly common in private conversations with CIOs and cloud leaders. The challenge is no longer whether the public cloud can scale, but whether the organization can.

Speed of Migration as an Economic Variable

At this point, migration speed stops being a technical metric and becomes an economic one. The faster workloads can move, the faster negotiated consumption levels can be reached. The slower they move, the more value leaks out of cloud agreements.

This is where many cloud-native migration approaches struggle. Refactoring takes time and re-architecting applications is expensive. Not every workload is a candidate for transformation under real-world constraints.

As a result, organizations are caught between two pressures. On one side, the need to consume public cloud capacity they have already paid for. On the other hand, the inability to move workloads quickly without introducing unacceptable risk.

NC2 as a Consumption Accelerator, Not a Shortcut

This is where Nutanix Cloud Platform with NC2 changes the conversation.

By allowing organizations to run the same private cloud stack on bare metal in AWS, Azure, and Google Cloud, NC2 removes one of the biggest bottlenecks in migration programs: The need to change how workloads are built and operated before they can move.

Workloads can be migrated as they are, operating models remain consistent, governance does not have to be reinvented, and teams do not need to learn a new infrastructure paradigm under time pressure. It’s all about efficiency and speed.

Faster migrations mean workloads start consuming public cloud capacity earlier and the negotiated consumption targets suddenly become achievable. Commitments turn into realized value rather than sunk cost, and the organization regains control over both its migration timeline and its commercial position.

Reframing the Role of Public Cloud

In this context, NC2 is not an alternative to public cloud economics, but a mechanism to actually realize them.

Public cloud providers assume customers can move fast. In reality, many customers cannot, not because they resist change, but because change takes time. Platforms that reduce friction between private and public environments do not undermine cloud strategies. They are here to stabilize them. And they definitely can!

The uncomfortable truth is that economies of scale alone do not guarantee better outcomes for customers, execution does. And execution, in large enterprises, depends less on ideal architectures and more on pragmatic paths that respect existing realities.

When those paths exist, public cloud growth and cloud repatriation stop being opposing forces. They become two sides of the same maturation process, one that rewards platforms designed not just for scale, but for transition.

Nutanix should not be viewed primarily as a replacement for VMware

Nutanix should not be viewed primarily as a replacement for VMware

Public sector organizations rarely change infrastructure platforms lightly. Stability, continuity, and operational predictability matter more than shiny and modern solutions. Virtual machines became the dominant abstraction because they allowed institutions to standardize operations, separate applications from hardware, and professionalize IT operations over the long term.

For many years, VMware has become synonymous with this VM-centric operating model, as it provided a coherent, mature, and widely adopted implementation of virtualized infrastructure. Choosing VMware was, for a long time, a rational and defensible decision.

Crucially, the platform was modular. Organizations could adopt it incrementally, integrate it with existing tools, and shape their own operating models on top of it. This modularity translated into operational freedom. Institutions retained the ability to decide how far they wanted to go, which components to use, and which parts of their environment should remain under their direct control. These characteristics explain why VMware became the default choice for so many public institutions. It aligned well with the values of stability, proportionality, and long-term accountability.

The strategic question public institutions face today is not whether that decision was wrong. Rather, if they can learn from it. We need to ask ourselves whether the context around that decision has changed and whether continuing along the same platform path still preserves long-term control, optionality, and state capability.

From VM-centric to platform-path dependent

It is important to be precise in terminology. Most public sector IT environments are not VMware-centric by design. They are VM-centric. Virtual machines are the core operational unit, deeply embedded in processes, tooling, skills, and governance models. This distinction is very important. A VM-centric organization can, in principle, operate on different platforms without redefining its entire operating model. A VMware-centric organization, by contrast, has often moved further down a specific architectural path by integrating tightly with proprietary platform services, management layers, and bundled stacks that are difficult to disentangle later.

This is where the strategic divergence begins.

Over time, VMware’s platform has evolved from a modular virtualization layer into an increasingly integrated software-defined data center (SDDC) and VCF-oriented (VMware Cloud Foundation) stack. That evolution is not inherently negative. Integrated platforms can deliver efficiencies and simplified operations, but they also introduce path dependency. Decisions made today shape which options remain viable tomorrow.

So, the decisive factor is not pricing. Prices change. For public institutions, this is a governance issue (not a technical one).

There is a significant difference between organizations that adopted VMware primarily as a hypervisor platform and those that fully embraced the SDDC or VCF vision.

Institutions that did not fully commit to VMware’s integrated SDDC approach often still retain architectural freedom. Their environments are typically characterized by:

  • A strong focus on virtual machines rather than tightly coupled platform services
  • Limited dependency on proprietary automation, networking, or lifecycle tooling
  • Clear separation between infrastructure, operations, and higher-level services

For these organizations, the operational model remains transferable. Skills, processes, and governance structures are not irreversibly bound to a single vendor-defined stack. This has two important consequences.

First, technical lock-in can still be actively managed. The platform does not yet dictate the future architecture. Second, the total cost of change remains realistic. Migration becomes a controlled evolution rather than a disruptive transformation.

In other words, the window for strategic choice is still open.

Why this moment matters for the public sector

Public institutions operate under conditions that differ fundamentally from those of private enterprises. Their mandate is not limited to efficiency, competitiveness, or short-term optimization. Instead, they are entrusted with continuity, legality, and accountability over long time horizons. Infrastructure decisions made today must still be explainable years later, often to different audiences and under very different political circumstances. They must withstand audits, parliamentary inquiries, regulatory reviews, and shifts in leadership without losing their legitimacy.

This requirement fundamentally changes how technology choices must be evaluated. In the public sector, infrastructure is an integral part of the institutional framework that enables the state to function effectively. Decisions are therefore judged not only by their technical benefits and performance, but by their long-term defensibility. A solution that is efficient today but difficult to justify tomorrow represents a latent risk, even if it performs flawlessly in day-to-day operations.

It is within this context that the concept of digital sovereignty has moved from abstraction to obligation. Governments increasingly define digital sovereignty not as isolation or technological nationalism, but as the capacity to maintain control and freedom of an environment. This includes the ability to reassess vendor relationships, adapt sourcing strategies, and respond to geopolitical, legal, or economic shifts without being forced into reactive or crisis-driven decisions.

Digital sovereignty, in this sense, is closely tied to governance and control. It is about ensuring that institutions retain the ability to make informed, deliberate choices over time. That ability depends less on individual technologies and more on the structural properties of the platforms on which those technologies are built. When platforms are designed in ways that limit flexibility, they quietly constrain future options, regardless of their current performance or feature set.

Platform architectures that reduce reversibility are particularly problematic in the public sector. Reversibility does not imply constant change, nor does it require frequent platform switches. It simply means that change remains possible without disproportionate disruption. When an architecture makes it technically or organizationally prohibitive to adjust course, it creates a form of lock-in that extends beyond commercial dependency into the realm of institutional risk.

Even technically advanced platforms can become liabilities if they harden decisions that should remain open. Tight coupling between components, inflexible operational models, or vendor-defined evolution paths may simplify operations in the short term, but they do so at the cost of long-term flexibility. In public institutions, where the ability to adapt is inseparable from democratic accountability and legal responsibility, this trade-off must be examined with particular care.

Ultimately, digital sovereignty in the public sector is about ensuring that those dependencies remain governable. Platforms that preserve reversibility support this goal by allowing institutions to evolve deliberately, rather than react under pressure. Platforms that erode it may function well today, but they quietly accumulate strategic risk that only becomes visible when options have already narrowed.

Seen through this lens, digital sovereignty is a core governance requirement, embedded in the responsibility of public institutions to remain capable, accountable, and in control of their digital future.

Nutanix as a strategic inflection point

This is why Nutanix should not be viewed primarily as a replacement for VMware. Framing it as such immediately steers the discussion in the wrong direction. Replacements imply disruption, sunk costs, and, perhaps most critically in public-sector and enterprise contexts, an implicit critique of past decisions. Infrastructure choices, especially those made years ago, were often rational, well-founded, and appropriate for their time. Suggesting that they now need to be “replaced” risks triggering defensiveness and obscures the real strategic question.

More importantly, the replacement narrative fails to capture what Nutanix actually represents for VM-centric organizations. Nutanix does not demand a wholesale change in operating philosophy. It does not require institutions to abandon virtual machines, rewrite operational playbooks, or dismantle existing governance structures. On the contrary, it deliberately aligns with the VM-centric operating model that many public institutions and enterprises have refined over years of practice.

For this reason, Nutanix is better understood as a strategic inflection point. It marks a moment at which organizations can reassess their platform trajectory without invalidating the past. Virtual machines remain first-class citizens, operational practices remain familiar and roles, responsibilities, and control mechanisms continue to function as before. The day-to-day reality of running infrastructure does not need to change.

What does change is the organization’s strategic posture.

In essence, Nutanix is about restoring the ability to choose. In public-sector (and enterprise environments), that ability is often more valuable than any individual feature or performance metric.

The cost of change versus the cost of waiting

A persistent misconception in infrastructure strategy is the assumption that platform change is, by definition, prohibitively expensive. This belief is understandable. Large-scale IT transformations are often associated with complex migration projects, organizational disruption, and unpredictable outcomes. These associations create a strong incentive to delay any discussion of change for as long as possible.

Yet this intuition is misleading. In practice, the cost of change does not remain constant over time. It increases the longer the architectural lock-in is allowed to deepen.

Platform lock-in rarely occurs as an intentional choice, but it accumulates gradually. Additional services are adopted for convenience, tooling becomes more tightly integrated and operational processes begin to assume the presence of a specific platform. Over time, what was once a flexible foundation hardens into an implicit dependency. At that point, changing direction no longer means replacing a component; it means changing an entire operating model.

Organizations that remain primarily VM-centric and act early are in a very different position. When virtual machines remain the dominant abstraction and higher-level platform services have not yet become deeply embedded, transitions can be managed incrementally. Workloads can be evaluated in stages. Skills can be developed alongside existing operations. Governance and procurement processes can adapt without being forced into emergency decisions.

In these cases, the cost of change is not trivial, but it is proportionate. It reflects the effort required to introduce an alternative (modular) platform, not the effort required to escape a tightly coupled ecosystem.

VMware to Nutanix Windows

By contrast, organizations that postpone evaluation until platform constraints become explicit often find themselves facing a very different reality. When licensing changes, product consolidation, or strategic shifts expose the depth of dependency, the room for change has already narrowed. Timelines become compressed, options shrink, and decisions, that should have been strategic, become reactive.

The cost explosion in these situations is rarely caused by the complexity of the alternative platform. It is caused by the accumulated weight of the existing one. Deep integration, bespoke operational tooling, and platform-specific governance models all add friction to any attempt at change. What might have been a manageable transition years earlier becomes a high-risk transformation project.

This leads to a paradox that many institutions only recognize in hindsight. The best time to evaluate change is precisely when there is no immediate pressure to do so. Early evaluation is a way to preserve choice. It allows organizations to understand their true dependencies, test assumptions, and (perhaps) maintain negotiation leverage.

Waiting, by contrast, does not preserve stability. It often preserves only the illusion of stability, while the cost of future change continues to rise in the background.

For public institutions in particular, this distinction is critical. Their mandate demands foresight, not just reaction. Evaluating platform alternatives before change becomes unavoidable means taking over responsibility.

A window that will not stay open forever

Nutanix should not be framed as a rejection of VMware, nor as a corrective to past decisions. It should be understood as an opportunity for VM-centric public institutions to reassess their strategic position while they still have the flexibility to do so.

Organizations that did not fully adopt VMware’s SDDC approach are in a particularly strong position. Their operational models are portable, their technical lock-in is still manageable and their total cost of change remains proportionate.

For them, the question is whether they want to preserve the ability to decide tomorrow.

And in the public sector, preserving that ability is a governance responsibility.

Nutanix Is Quietly Redrawing the Boundaries of What an Infrastructure Platform Can Be

Nutanix Is Quietly Redrawing the Boundaries of What an Infrastructure Platform Can Be

Real change happens when a platform evolves in ways that remove old constraints, open new economic paths, and give IT teams strategic room to maneuver. Nutanix has introduced enhancements that, taken individually, appear to be technical refinements, but observed together, they represent something more profound. The transition of the Nutanix Cloud Platform (NCP) into a fabric of compute, storage, and mobility that behaves as one system, no matter where it runs.

This is the dismantling of long-standing architectural trade-offs and the business impact is far greater than the technical headlines suggest.

In this article, I want to explore four developments that signal this shift:

  • Elastic VM Storage across Nutanix clusters
  • Disaggregated compute and storage scaling
  • NC2 is generally available on Google Cloud
  • The strategic partnership between Nutanix and Pure Storage

Individually, these solve real operational challenges. Combined, they create an infrastructure model that moves away from fix constructs and toward an adaptable, cost-efficient, cloud-operating fabric.

Elastic VM Storage – The End of Cluster-Bound Thinking

Nutanix introduced Elastic VM Storage, which the ability for one AHV cluster to consume storage from another Nutanix HCI cluster within the same Prism Central domain. It breaks one of the oldest implicit assumptions in on-premises virtualization that compute and storage must live together in tightly coupled units.

By allowing VMs to be deployed on compute in one cluster while consuming storage from another, Nutanix gives IT teams a new level of elasticity and resource distribution.

It introduces an operational freedom that enterprises have never truly had:

  1. Capacity can be added where it is cheapest. If storage economics favour one site and compute expansion is easier or cheaper in another, Nutanix allows you to make decisions based on cost, not on architectural constraints.
  2. It reduces stranded resources. Every traditional environment suffers from imbalanced clusters. Some run out of storage, others out of CPU, and upgrading often means over-investing on both sides. Elastic VM Storage dissolves those silos.
  3. It prepares organizations for multi-cluster private cloud architectures. Enterprises increasingly distribute workloads across data centers, edge locations, and cloud-adjacent sites. Being able to pool resources across clusters is foundational for this future.

Nutanix is erasing the historical boundary of the cluster as a storage island.

Disaggregated Compute and Storage Scaling

For years, Nutanix’s HCI architecture was built on the elegant simplicity of shared-nothing clusters, where compute and storage scale together. Many customers still want this. In fact, for greenfield deployments, it probably is the cleanest architecture. But enterprises also operate in a world full of legacy arrays, refresh cycles that rarely align, strict licensing budgets, and specialized workload patterns.

With support for disaggregated compute and storage scaling, Nutanix allows:

  • AHV compute-only clusters with external storage (currently supported are Dell PowerFlex and Pure Storage – more to follow)
  • Mixed configurations combining HCI nodes and compute-only nodes
  • Day-0 simplicity for disaggregated deployments

This is a statement from Nutanix, whose DNA was always HCI: The Nutanix Cloud Platform can operate across heterogeneous infrastructure models without making the environment harder to manage.

  1. Customers can modernize at their own pace. If storage arrays still have years of depreciation left, Nutanix allows you to modernize compute now and storage later instead of forcing a full rip-and-replace.
  2. It eliminates unnecessary VMware licensing. Many organizations want to exit expensive hypervisor stacks while continuing to utilize their storage investments. AHV compute-only clusters make this transition significantly cheaper.
  3. It supports high-density compute for new workloads. AI training, GPU farms, and data pipelines often require disproportionate compute relative to storage. Disaggregation aligns the platform with the economics of modern workloads.

This is the kind of flexibility enterprises have asked for during the last few years and Nutanix has now delivered it without compromising simplicity.

Nutanix and Pure Storage

One of the most significant shifts in Nutanix’s evolution is its move beyond traditional HCI boundaries. This began when Nutanix introduced support for Dell PowerFlex as the first officially validated external storage integration, which was a clear signal to the market, that the Nutanix platform was opening itself to disaggregated architectures. With Pure Storage FlashArray now becoming the second external storage platform to be fully supported through NCI for External Storage, that early signal has turned into a strategy and ecosystem.

Nutanix NCI with Pure Storage

Nutanix now enables customers to run AHV compute clusters using enterprise-grade storage arrays while retaining the operational simplicity of Prism, AHV, and NCM. Pure Storage’s integration builds on the foundation established with PowerFlex, but expands the addressable market significantly by bringing a leading flash platform into the Nutanix operating model.

Why is this strategically important?

  • It confirms that Nutanix is committed to disaggregated architectures, not just compatible with them. What began with Dell PowerFlex as a single integration has matured into a structured approach. Nutanix will support multiple external storage ecosystems while providing a consistent compute and management experience.
  • It gives customers real choice in storage without fragmenting operations. With Pure Storage joining PowerFlex, Nutanix now supports two enterprise storage platforms that are widely deployed in existing environments. Customers can keep their existing tier-1 arrays and still modernize compute, hypervisor, and operations around AHV and Prism.
  • It creates an on-ramp for VMware exits with minimal disruption. Many VMware customers own Pure FlashArray deployments or run PowerFlex at scale. With these integrations, they can adopt Nutanix AHV without replatforming storage. The migration becomes a compute and virtualization change and not a full infrastructure overhaul.
  • It positions Nutanix as the control plane above heterogeneous infrastructure. The combination of NCI with PowerFlex and now Pure Storage shows that Nutanix is building an operational layer that unifies disparate architectures.
  • It aligns modernization with financial reality. Storage refreshes and compute refreshes rarely align. Supporting multiple external arrays allows Nutanix customers to modernize compute operations first, defer storage investment, and transition into HCI only when it makes sense.

Nutanix has moved from a tightly defined HCI architecture to an extensible compute platform that can embrace best-in-class storage from multiple vendors.

Nutanix Cloud Clousters on Google Cloud – A Third Strategic Hyperscaler Joins the Story

The general availability of NC2 on Google Cloud completes a strategic triangle. With AWS, Azure and now Google Cloud all supporting Nutanix Cloud Clusters (NC2), Nutanix becomes one of the very few platforms capable of delivering a consistent private cloud operating model across all three major hyperscalers. It fundamentally changes how enterprises can think about cloud architecture, mobility, and strategic independence.

Running NC2 on Google Cloud creates a new kind of optionality. Workloads that previously needed to be refactored or painfully migrated can now move into GCP without rewriting, without architectural compromises, and without inheriting a completely different operational paradigm. For many organizations, especially those leaning into Google’s strengths in analytics, AI, and data services, this becomes a powerful pattern. Keep the operational DNA of your private cloud, but situate workloads closer to the native cloud services that accelerate innovation.

NC2 on Google Cloud

When an enterprise can run the same platform – the same hypervisor, the same automation, the same governance model – across multiple hyperscalers, the risk of cloud lock-in can be reduced. Workload mobility and cloud-exit strategies become a reality.

NC2 on Google Cloud is a sign of how Nutanix envisions the future of hybrid multi-cloud. Not as a patchwork of different platforms stitched together, but a unified operating fabric that runs consistently across every environment. With Google now joining the story, that fabric becomes broader, more flexible, and significantly more strategic.

Conclusion

Nutanix is removing the trade-offs, that enterprises once accepted as inevitable.

Most IT leaders aren’t searching for (new) features. They are searching for ways to reduce risk, control cost, simplify operations, and maintain autonomy while the world around them becomes more complex. Nutanix’s recent enhancements are structural. They chip away at the constraints that made traditional infrastructure unflexible and expensive.

The platform is becoming more open, more flexible, more distributed, and more sovereign by design.

A Primer on Nutanix Cloud Clusters (NC2)

A Primer on Nutanix Cloud Clusters (NC2)

If you strip cloud strategy down to its essentials, you quickly notice that IT leaders are protecting three things. I am talking about continuity, autonomy and freedom of movement. Yet most clouds, private or public, quietly decimate at least one of these freedoms. You can gain elasticity but lose portability. You get managed services but have to accept immobility. And you can gain efficiency, but introduce concentration risk. Once the first workloads are deployed on a hyperscaler, many organizations underestimate the difficulty of reversing that decision later. And in some cases, they are aware of it and call it a strategic decision.

Nutanix Cloud Clusters (NC2) repositions control. It extends your existing Nutanix Cloud Platform (NCP) directly into the hyperscaler of your choice (AWS, Azure; or Google Cloud in tech preview) without requiring you to rewrite applications or adopt a new operational model. NC2 runs the same Nutanix stack on hyperscaler baremetal. Think of it as extending your private cloud to someone else’s cloud.

Workload Mobility

Most cloud migrations fail not because the target cloud is inadequate, but because the friction of moving virtual machines (VMs) is underestimated. Every dependency, every network pattern, every stored image becomes an anchor that slows down the migration. NC2 removes most of these anchors. Because the target environment is still Nutanix, your VM format, storage layout, operational tooling, and lifecycle management remain identical.

NC2 on AWS

This creates a kind of reversible migration (aka repatriation). You are no longer forced to commit to one direction. You can burst, repatriate or rebalance depending on business needs, not platform constraints. The psychological barrier of “this migration better be worth it because we cannot undo it” disappears.

Cloud Exit

Cloud exit is a topic we have been discussing in our industry for some time now. IT decision-makers want to know if and how they could exit a cloud if necessary. Cost shocks, sovereignty concerns, regulatory pressure, or simple risk diversification can all trigger a reassessment.

What happens if our cloud dependency becomes a risk? What if we need to move? Do we have an exit plan?

NC2 is one of the few architectures where an exit is not a complicated multi-year re-architecture effort. Workloads running on NC2 can be moved back to an on-premises Nutanix cluster without replatforming and without importing cloud-native dependencies that are difficult to untangle. Platform symmetry makes the exit not only thinkable, but executable.

When your workloads run on NC2 in AWS or Azure, they do not inherit the hyperscaler’s native VM formats, storage layouts, or proprietary IAM constructs. They run inside the same Nutanix Cloud Platform you already operate on-prem. This means that the workloads you run in the cloud are the same as those you can run in your data center.

In many organizations, repatriation is seen as a point of failure. Something you only do when the cloud strategy “didn’t work out”. That framing is outdated. Repatriation is increasingly a proactive governance mechanism:

  • Sovereignty changes? Move workloads home.
  • Cost pressure rises? Bring certain workloads back on-prem during peak cost cycles.
  • Predictable costs? Run static workloads privately but scale elastically via NC2.
  • Vendor terms change? Shift to a different infrastructure model.
  • GPU scarcity? Temporarily run training or inference workloads where you have capacity.

Nutanix Hybrid Multi-Cloud Operations

The cloud world has become multipolar. Many organizations are no longer choosing between “on-prem vs cloud”, but between multiple clouds like hyperscalers, European sovereign clouds, vertical-specific clouds, and dedicated regions.

Repatriation used to mean going home. With NC2, it can also mean going sideways:

  • From Azure to a sovereign cloud provider
  • From a hyperscaler to a private cloud built on NCP
  • From one hyperscaler to another when commercial, regulatory, or technical factors shift
  • From cloud to edge
  • From cloud to hosted private infrastructure via a service provider (OVH for example)

In other words, it allows organizations to move workloads to the location that makes sense right now, not the one that made sense during a six-year-old strategy cycle.

Note: NC2 is fundamentally a sovereignty mechanism because it makes long-term commitments reversible.

Operational Relief for Small IT Teams

Every new stack, platform, or cloud demands new knowledge, new operational patterns, new tooling, and new troubleshooting domains. When a team of five suddenly needs to understand the details of AWS, Azure, Nutanix, Kubernetes, storage arrays, hypervisors, and cloud-native services, hybrid cloud becomes an unmanageable landscape.

Even though NC2 is not a managed service, it behaves like a consolidation layer that collapses the operational surface. The team does not need to master the specifics of hyperscaler virtualization models, instance families, cloud-native block storage semantics or proprietary IAM patterns, but they operate the same Nutanix environment everywhere. The public cloud stops being an alien planet with its own physics and becomes an extension of the data center they already know.

For small teams, the value is immense. They no longer split their attention between incompatible worlds. They do not require deep AWS or Azure certifications to run VMs in the cloud, nor do they need a dedicated cloud operations squad. No need to maintain multiple monitoring stacks, patching processes or network topologies. They simply work through Prism, with the same lifecycle management, upgrade workflows, automation, and storage patterns. Regardless of where the hardware resides.

In short, efficiency increases as complexity decreases.

Conclusion

Ultimately, NC2 is not just a technical extension of Nutanix into public cloud regions. Think of it as a structural correction to a decade of cloud decisions shaped by lock-in, fragmentation, and asymmetrical dependencies. It gives organizations the right to change their mind without paying a penalty for it. It reduces operational noise instead of amplifying it. It allows teams to stay focused on outcomes rather than infrastructure politics.