There is a moment in almost every infrastructure project where the engineering team says, “it works,” and the product team says, “great—how does a customer use it?” Object storage has a particularly large gap between those two sentences.
If aws s3 cp succeeds against an RGW endpoint, you have proven something important: the storage path works. You have not yet proven that you have a storage product.
The API is the easy part for the customer
S3 compatibility matters because customers already have tools and software that understand it. Backup products, SDKs, command-line clients and applications can point at a familiar endpoint and get on with their work.
But customers rarely experience the service only through S3 calls. Before the first request, somebody needs to create the account and give them the right kind of access. Later they want to rotate a key, see how much storage they use, understand a limit, change a bucket setting, or ask why something failed.
That surrounding experience is where “object storage” turns into “our object storage service.”
A product has a lifecycle
It helps to think beyond the happy-path demo. A real customer goes through a lifecycle:
- They are onboarded and associated with the right provider and tenant.
- They receive or create credentials with the scope they need.
- They create buckets and start storing data.
- Usage grows and quotas begin to matter.
- Keys are rotated, staff changes, policies evolve.
- Something breaks and support has to explain it.
- Eventually the service is changed or terminated cleanly.
If several of those stages require an operator to open a shell and remember an internal procedure, the product is still partly manual.
Operators have a lifecycle too
The provider side is easy to underestimate because customers do not see it. Operators need to know whether the integration is healthy, whether a provisioning action actually reached RGW, whether usage ingestion is current, and whether a support action is safe for the tenant they are looking at.
They also need boring things that become critical under pressure: correlation IDs, audit trails, bounded diagnostics, recovery procedures and a clear source of truth for configuration.
These features do not make a marketing screenshot exciting. They are what makes an on-call engineer trust the service at 02:00.
Sensible defaults are part of the product
A raw platform exposes possibilities. A product makes choices.
For example, a provider can technically offer dozens of knobs around access and bucket behavior. That does not mean every knob belongs in the customer portal. A good product chooses safe defaults, exposes the controls customers genuinely need, and leaves low-level Ceph administration with the people responsible for the cluster.
The same is true for credentials. Long-lived access keys are familiar and sometimes necessary. Temporary scoped credentials are often safer for interactive or delegated workflows. A product should make the safer path practical rather than merely documenting that it exists.
The hard part is keeping all of this connected
It is possible to build each surrounding feature separately: one portal for accounts, another tool for usage, a billing export, some scripts for quotas, a support dashboard and a runbook for credentials. Many providers naturally end up there.
The cost shows up in the seams. A quota in the commercial system drifts from RGW. A support engineer sees a customer but cannot safely trace the provider-side action. Usage has a number but nobody is completely sure which collection path produced it.
We think the product layer should connect those workflows deliberately. The customer, entitlement, credential, quota, usage record and operator action should describe one service, not six loosely related systems.
That is the product ScaleStore is trying to be
ScaleStore is not interesting because it adds a nicer button for something Ceph can already do from the command line. The useful part is making the whole provider workflow repeatable while keeping Ceph where it belongs.
The provider still runs the storage. Customers still use the provider’s S3 endpoint. ScaleStore handles the product and operational layer around that path.
When we judge a feature, that is the standard we use: does it make the service easier to buy, safer to use, or easier to operate? If it does none of those things, it probably does not belong in the product.