If you already run Ceph, launching S3 can look deceptively close. RGW is there, the endpoint works, and an SDK can put an object into a bucket. From an infrastructure point of view, that is a big milestone. From a customer point of view, it is only the beginning.
The gap becomes obvious the first time somebody asks a normal commercial question: How do I onboard a customer? Where do they get credentials? Can they rotate them without opening a ticket? What happens when they hit their quota? Can support explain a failed request? Which usage number ends up on the invoice?
None of those questions make Ceph RGW a bad product. They are simply outside the job it is meant to do.
RGW should stay the storage engine
There is a temptation, when building a service around infrastructure, to make the infrastructure component responsible for everything. We think that is the wrong direction with Ceph.
RGW is valuable because it gives an operator an S3-compatible object interface backed by Ceph. It has its own users, policies, multisite features, lifecycle behavior and a large amount of operational machinery. Providers already know how to run that infrastructure. We do not want to replace it with another storage layer or proxy every object through a SaaS control plane.
Instead, the commercial layer should sit around RGW and translate customer and provider intent into controlled operations.
The hidden platform appears quickly
Imagine a small provider launching object storage to its first ten customers. You can probably handle the first accounts manually. Create the identities, set quotas, send credentials securely and keep a spreadsheet of which customer belongs to which resources.
At fifty or five hundred customers, those same shortcuts become an operating model. Someone has to maintain the scripts. Someone has to decide who may run them. Support needs enough information to help a customer without receiving an administrator key. Usage collection needs to be repeatable. Billing needs inputs that can be traced back to actual storage usage. Deleting a customer must remove the right things and nothing else.
Before long, you have built the beginnings of a control plane whether you intended to or not.
The customer should not need to understand Ceph
A customer buying S3-compatible storage should not have to know what a realm, zonegroup, RGW user or placement target is. They should see the concepts that belong to the service they bought: buckets, credentials, usage, limits, policies and maybe replication or governance options.
The provider has the opposite problem. Operators do need to understand what is happening underneath, but they should not have to jump between a billing system, shell scripts, Ceph commands and an internal wiki just to answer one support question.
A useful commercial layer therefore has two jobs at once: hide infrastructure detail where the customer does not need it, and preserve enough infrastructure truth that the operator can still reason about the service.
Commercial does not mean “put a checkout page in front of Ceph”
The word commercial can sound like pricing and invoices. Those matter, but the harder part is making the whole service coherent.
- A plan or entitlement has to become an enforceable quota.
- A credential has to belong to the right customer and scope.
- Usage has to come from a path the provider trusts.
- Support actions have to respect tenant boundaries.
- Operational state has to be visible before it becomes a customer incident.
That is why ScaleStore treats onboarding, credentials, quotas, usage, diagnostics and billing inputs as parts of the same product rather than as a collection of unrelated add-ons.
Why we are building ScaleStore this way
Providers already have things that are hard to recreate: infrastructure, local presence, operational expertise, customer relationships and trust. Asking them to hand all of that over to a central storage provider defeats much of the reason to run Ceph in the first place.
Our preferred boundary is simpler. The provider keeps the RGW endpoint and object data path. ScaleStore coordinates the surrounding service through a provider-side bridge. Customers continue talking to provider-owned S3 endpoints.
There is still plenty to get right in that model, but at least the responsibilities are clear: Ceph stores and serves the objects; the provider owns the service; ScaleStore supplies the repeatable product layer around it.
That is the gap we care about. Not making Ceph look less like Ceph, but making it possible for a provider to turn good storage infrastructure into a service people can actually buy and operate.