Glossary
Cloud native
Cloud native describes applications built as small, loosely coupled services that run in containers, are managed by an orchestrator such as Kubernetes, and are deployed and scaled through automation and declarative configuration. It is a way of building and running software, and applies in private and hybrid environments as fully as in public clouds.
The Cloud Native Computing Foundation definition lists containers, service meshes, microservices, immutable infrastructure and declarative APIs as the characteristic techniques.
Why cloud native matters for storage teams
Cloud-native services are designed to be disposable. A container can be killed, rescheduled on another node or multiplied tenfold by an autoscaler at any moment, so it keeps nothing important on its own disk. Everything that has to survive is pushed out to services built to keep it: databases, message queues and, for most bulk data, object storage reached over the S3 API.
That shifts the hard problem from the application to the storage layer. The application tier becomes easy to scale and replace; the storage behind it now has to absorb the concurrency, the churn and the expectation of instant self-service that the application tier was built around.
Some state does stay inside the cluster. Databases and message brokers run as stateful workloads with persistent volumes, often managed by operators that automate their failover and backups. Those volumes are tied to the cluster and its nodes, which is why platform teams usually keep only the working set there and push bulk and long-lived data outward.
How cloud-native applications are built
- Containers package each service with its dependencies, so it runs the same way on any node.
- Microservices split an application into services that are deployed and scaled independently.
- Orchestration places containers on nodes, restarts failed ones and scales them with load. See cloud orchestration.
- Declarative configuration states the intended end state; controllers compare it with what is running and correct the difference continuously.
- Immutable deployment replaces running containers with new ones for every change instead of patching them in place.
- Observability exposes metrics, logs and traces from every service, because failures are spread across many small parts.
Where state lives
| Kind of state | Where it goes | Storage interface |
|---|---|---|
| Sessions and caches | In-memory stores | Key-value API; rebuilt if lost |
| Transactional records | Databases running with persistent volumes | Block storage through the orchestrator's volume interface |
| Files, media, logs, backups, datasets, model artifacts | Object storage | S3 API over HTTP |
| Configuration and secrets | Orchestrator configuration objects and secret stores | Orchestrator API |
By volume, the object row dominates. Most cloud-native platforms treat object storage as the default destination for any data that is not a database row, because it needs no volume attachment, scales without resizing and is reachable from any pod with an endpoint and a key.
What cloud native means for the storage layer
- Concurrency arrives in bursts. An autoscaler that grows a service from 20 to 200 pods multiplies the requests hitting storage by ten within minutes. The storage layer sees the peak of the application tier, with no autoscaler of its own in front of it.
- Identities multiply. Each service, namespace or pipeline gets its own access keys and policies. Thousands of narrowly scoped credentials are safer than a few shared ones, and only workable if the storage platform's identity model handles them at that count.
- Clusters come and go; data stays. Kubernetes clusters are rebuilt, upgraded and replaced. Data written to external object storage survives each rebuild untouched, which is the main reason to keep it there.
- Portability depends on API fidelity. The same application deployed on premises and in a public cloud works only if both endpoints behave the same way. Small differences in S3 compatibility, such as how listing, multipart uploads or versioning behave, surface as application bugs.
- Small objects pile up. Logs, events, checkpoints and intermediate pipeline outputs are written as many small objects. Object counts can reach billions long before capacity is large, so listing and metadata performance often matter more than raw throughput.
- Protection splits in two. Protecting a cloud-native application means backing up cluster definitions and persistent volumes on one side, while data already in object storage is protected by versioning, replication and retention set on the storage itself.
- Tenancy maps to namespaces. Platform teams typically align buckets and quotas to namespaces or teams, making storage multi-tenancy a direct extension of the cluster's own tenancy model.
Scality RING for cloud-native applications
For cloud-native applications in private or hybrid environments, Scality RING supplies the S3 object layer that stateless services write to. It runs on standard x86 servers and scales to 300 billion objects in a single RING. Scality states that RING offers full S3 fidelity and is multi-tenant by design, so services address it by endpoint and credentials with the same calls they use against public cloud S3. Clusters in front of it can be rebuilt, upgraded or moved between sites while the buckets they use stay where they are.