Glossary
Cloud infrastructure
Cloud infrastructure is the hardware and software that turn servers, drives and networks into a shared pool of resources consumed on demand through an API. It has two layers: the physical equipment, and the software that pools that equipment, allocates it and measures its use.
The two-layer description comes from NIST SP 800-145, the US reference definition of cloud computing. The definition is independent of ownership: the same infrastructure design runs in a hyperscaler region, a service provider's facility or an enterprise data center.
Why cloud infrastructure matters for large storage estates
Most enterprises already run compute as a pool. Virtual machines and containers are requested through a portal or API and placed on whatever host has room. Storage is often the part that still behaves like the old data center: arrays bought per project, volumes allocated by ticket, capacity planned application by application. At a few hundred terabytes that mismatch is an inconvenience. At tens of petabytes it becomes the main constraint on how fast the platform team can deliver anything, because every new service waits on a storage request.
Treating storage as part of the cloud infrastructure, with the same self-service, pooling and metering as compute, changes three things at that scale: who can get capacity and how quickly, how full the hardware can safely run, and whether the cost of data can be attributed to the teams that create it.
The physical layer and the abstraction layer
The physical layer is ordinary equipment. The abstraction layer is what makes it a cloud.
| Layer | What it contains | What it does |
|---|---|---|
| Physical: compute | x86, Arm and GPU servers | Runs virtual machines, containers and functions |
| Physical: storage | Drives in servers, storage servers, arrays | Holds persistent data, images and backups |
| Physical: network | Switches, routers, load balancers, inter-site links | Connects everything, inside a site and between sites |
| Abstraction: virtualization | Hypervisors, container runtimes | Splits servers into isolated units of compute |
| Abstraction: software-defined storage and networking | Software-defined storage, virtual networks | Aggregates drives and links into volumes, file systems, buckets and private networks |
| Abstraction: control plane | APIs, scheduler, quotas, metering | Accepts requests, places them on hardware, records usage |
Cloud designs favor many identical servers over a few specialized machines. Uniform hardware lets the scheduler put any workload anywhere, and lets a failed server be replaced by any other from the pool. The control plane is the part users see: starting a virtual machine and creating a storage bucket are both API calls that it translates into actions on hardware.
Where storage sits in cloud infrastructure
Cloud infrastructure offers storage in three forms. Block storage provides virtual disks attached to one machine, used for operating systems and databases. File storage provides shared file systems mounted by several machines. Object storage provides buckets of objects reached over HTTP, almost always through the S3 API, independent of any machine.
Object storage is where bulk data in a cloud ends up: backups, logs, media, analytics tables, training datasets and model artifacts. It is also the form that pools most naturally, because buckets are not tied to a host and grow without being resized. Block and file storage carry the performance-sensitive working set; object storage carries the volume.
Storage differs from compute in one respect that shapes the whole design. Compute is stateless and disposable: a virtual machine can be destroyed and recreated in minutes. Data is the state everything else depends on, and it outlives every server that holds it.
What cloud infrastructure means for storage architects
For a team running storage at petabyte scale as part of a cloud platform, the model has concrete consequences.
- Hardware turns over beneath live data. Servers are refreshed on a cycle of a few years, while retained data stays for a decade or more. The storage layer has to accept new servers and retire old ones while tenants keep reading and writing, or every refresh becomes a migration project.
- Failure becomes a routine capacity event. Across hundreds of servers and thousands of drives, something is always failing. In a pooled design a failed drive or node reduces capacity and triggers repair in the background; in a design built around individual arrays it is an incident.
- Utilization becomes a pool decision. Headroom is held once for the whole pool, which allows the hardware to run fuller than a set of separately sized arrays, at the price of forecasting growth for the pool as a whole.
- Location becomes a choice. Owning the infrastructure means deciding which site, jurisdiction or network segment each dataset lives in, which is the basis of sovereign and air-gapped deployments.
- Staffing scales with automation. A lean team can run many petabytes only if provisioning, expansion and repair are API-driven; manual allocation does not scale with capacity.
Cloud infrastructure and Scality RING
Scality RING is software-defined object and file storage that runs on standard x86 servers, which places it in the storage part of the abstraction layer. A single RING scales to 300 billion objects, and Scality reports approximately 6 exabytes under management across its customer base. Scality lists on-premise, air-gapped and sovereign-cloud deployment options for RING, with a unified S3 namespace across sites and clouds, so the same object service can sit in a private data center or beside public cloud resources.