What Nutanix Actually Is

If you've worked around a traditional data center, you've seen the usual setup: a storage array (a SAN) holding all the data, separate physical servers doing the computing, a separate networking layer connecting everything, and virtualization software (a hypervisor) running on top of the servers to let them host multiple virtual machines. Each of these — storage, compute, network, virtualization — is often a different vendor's product, bought separately, managed through a different console, and upgraded on its own schedule.

Nutanix is built around a different idea, called hyper converged infrastructure, or HCI. Instead of separate boxes for storage and compute, HCI runs everything — compute, storage, and networking — as software on the same standard servers, managed as one system.

An analogy, briefly

Think of the traditional setup like hiring a plumber, an electrician, and a general contractor separately for a home renovation — each does their part, but you're the one coordinating the schedule between them, and each speaks a different professional language. HCI is closer to hiring one contractor who handles all three trades under one plan. The underlying work — running pipes, wiring outlets, framing walls — still has to happen. What changes is that it's coordinated as one job instead of three you have to manage yourself.

The three pieces Nutanix ships

Nutanix's platform is made of three main software components:

• Acropolis (AOS) — the foundational layer that handles VM management, backup, and data protection.
• AHV — Nutanix's own built-in hypervisor, based on the open-source KVM project, included at no separate license cost. Nutanix also supports running VMware ESXi or Microsoft Hyper-V instead, if an organization already has one of those in place.
• Prism — the management console. This is the single screen an administrator uses to monitor and manage the cluster, instead of switching between a storage vendor's tool, a networking vendor's tool, and a hypervisor vendor's tool.

How the storage actually works

Each physical server in a Nutanix cluster has its own local disks, but those disks aren't dedicated to that one server the way they would be in a traditional setup. Nutanix's software pools the local storage from every server into one shared pool, and copies of data are distributed across multiple servers automatically. If one server fails, the data it was holding still exists on at least one other server, and the virtual machines that were running on the failed server can start up elsewhere without data loss.

This is different from a traditional SAN, where storage lives in one dedicated box and every server has to travel across the network to reach it. In Nutanix's model, a lot of the data a server needs is physically local to it, which is part of why the company markets performance benefits tied to hardware like NVMe drives — the data doesn't have to travel as far.

How it grows

Traditional storage arrays are usually sized in advance and expanded by adding shelves of disks to the same box, or eventually replacing the box outright once it's maxed out. Nutanix clusters grow by adding more standard servers, called nodes, to the cluster. Each new node brings its own compute and storage capacity, and the cluster automatically incorporates it into the shared pool. This is why it's described as scaling out rather than scaling up — capacity grows in increments that match actual need, rather than in large jumps tied to a single hardware purchase.

None of this is unique to Nutanix as a concept — HCI is a category with several vendors in it. What's specific to Nutanix is the combination of its own hypervisor (AHV), its management layer (Prism), and the fact that the same control plane is meant to work the same way whether the nodes are sitting in a core data center, a small branch office, or — through a product called NC2 — running inside a public cloud like AWS or Azure.

What that actually looks like for the person running the infrastructure day to day — provisioning a VM, applying an upgrade, handling a failed node — is a separate question from the architecture itself, and it's a fair one to ask before assuming simpler architecture means less work.