Storage starts with how the application wants its data

Most storage conversations open with a number. Somebody has a capacity target, and within a minute everyone is discussing terabytes and cost per terabyte. It is the easiest question in the room, and it is rarely the one that decides whether the deployment works.

The question I start with is how the application expects to reach its data. Answer that and most of the platform choice has already been made for you. Leave it unanswered and it gets settled by accident, usually at deployment, which is the most expensive place to settle anything.

Three contracts, not three sizes

Block, file and object are often drawn as a ladder, as though object were simply the big one. They are better understood as three different agreements about what the storage promises.

Block. The server is handed something that behaves like a raw disk, and the file system lives on the server. Databases, transactional systems and virtual machines expect this, because they want to manage their own layout and they care about latency more than almost anything else.

File. The storage owns the file system and many machines mount the same directories. Anything that expects ordinary file behavior fits here: shared working directories, engineering data, media libraries, most analytics tools that were written before object storage existed.

Object. The application asks for a whole object by name through an API. There is no directory tree underneath in the way an application would expect one. It suits very large and mostly unchanging data: backups, archives, data lakes, training corpora.

An application written for one of these usually cannot be pointed at another without an access layer in front of it or a change to the application itself. That is the assumption I most often find unchecked, and it is not a small one.

Why capacity is a later question

Once the access model is settled, capacity becomes a slider inside a platform rather than a decision of its own. Before it is settled, a capacity figure carries almost no information. The same 500 terabytes is a completely different machine depending on whether it has to serve a database at consistent low latency or hold an archive that gets read in bulk twice a year.

The access model also sets up the protocol conversation, and protocol choice is often as organizational as it is technical. Fibre Channel brings its own fabric and usually its own team. Ethernet-based transports reuse the network that is already there. Both are defensible. They are just different projects, with different people saying yes.

Where this lands in a real portfolio

HPE publishes two platforms that make the split easy to see. The Alletra Storage MP B10000 is the block side of the portfolio, with file as well, and suits workloads that expect enterprise block access. The X10000 is built for large unstructured data, with object and file access, which is what data lakes, AI pipelines and backup estates look like.

The design error I try to prevent is reading those two as two sizes of the same product. A customer whose application speaks block is not served by the object platform at any capacity, and the reverse is equally true. Getting that wrong does not look like a storage problem at first. It looks like an application that cannot be deployed.

What AI changed, and what it did not

AI work put two new shapes in front of the same three contracts. Training wants a data path fast enough to keep expensive accelerators busy, which is a throughput problem with a deadline attached. Retrieval behaves less like a capacity question and more like a latency budget that happens to need capacity, because a slow lookup shows up directly in the response time a user experiences.

What it did not change is the first question. The useful move was not to invent a separate storage category for AI. It was to map those workloads onto the access models that already exist, so an AI requirement resolves onto a validated design instead of starting a bespoke engineering conversation every time.

What I do with this in practice

My side of it is turning that reasoning into something a seller can use without a specialist in the room: a fixed set of validated capacity, protocol and performance points behind each access model, and a clear rule for which workloads land where.

The trade-off is honest and worth stating. Some deals land between validated points and need a documented exception, and that path has to be real and staffed. A validated envelope is also always slightly behind the newest workload shape. That gap is permanent. The job is to keep it small, not to pretend it closes.

Where this reasoning stops

If an application genuinely does not care how it reaches its data, and some modern ones do not, then the access model is not the decisive variable and capacity and cost can lead. Access layers and gateways also blur the line, at a price in latency and operational complexity that has to be counted rather than waved through.

And none of this rescues a sizing that ignores the network. Storage that can serve the throughput is not the same as a fabric that can carry it, which is a different note.