One of the earliest architecture decisions in ScaleStore was also one of the easiest to state: customer object traffic should not have to travel through ScaleStore Cloud.
If a provider already operates Ceph RGW, the natural S3 data path is from the customer to that provider’s RGW endpoint. Putting a central SaaS proxy in the middle would add bandwidth cost, latency, another failure domain and a much larger trust boundary. It would also blur a simple ownership question: who is actually serving the storage?
We still need a safe way to coordinate provider-side operations. That is what the Provider Bridge is for.
Control traffic and object traffic are different things
An object upload can be gigabytes. A control action might be “create this customer-side identity,” “apply this quota,” or “report the health of this integration.” Treating those as the same traffic class makes little sense.
ScaleStore Cloud deals with product intent: a provider configures a service, a customer requests a workflow, or an operator investigates a problem. The Bridge turns approved intent into bounded provider-side operations.
The object itself never needs to make that trip. Customers can keep using normal S3 clients, SDKs and backup software directly against the provider endpoint.
Why not call RGW directly from the cloud?
The naive alternative is simple: expose an administrative API and let ScaleStore Cloud call it. That may work in a lab. It is less appealing when the environment belongs to a real provider.
Broad inbound administrative exposure creates firewall work, credential distribution and a permanent external path into systems that may otherwise be private. It also assumes every provider has roughly the same network topology.
The Bridge reverses that relationship. It establishes outbound connectivity from the provider environment and receives only the work it is allowed to perform. That is a much cleaner integration boundary for environments that should not accept arbitrary inbound management traffic.
The Bridge is deliberately boring
We do not want the Bridge to become a second control plane hidden inside the provider network. It should not own customer state, invent policy, proxy S3 data or quietly become the source of truth.
Its job is closer to a controlled executor and integration point:
- enrol the provider environment;
- report health and capability information;
- perform approved RGW-facing operations;
- return bounded results and diagnostics;
- keep provider credentials and network access on the provider side where possible.
That narrowness matters. Small components are easier to reason about, upgrade and restrict.
One provider, one boundary
Each provider has its own Bridge because providers are separate security and operational domains. They may run different Ceph versions, different endpoint layouts and different internal policies. They certainly have different customers.
We do not want one provider’s integration state or credentials bleeding into another provider’s path. Treating the Bridge as a per-provider boundary makes that separation explicit in the architecture instead of relying on convention.
What happens when the Bridge is unavailable?
Separating control and data paths keeps this failure away from customer object traffic.
If a customer already has valid credentials and the provider’s RGW endpoint is healthy, ordinary object traffic should not depend on ScaleStore Cloud carrying the bytes. A control-plane incident may affect new provisioning or management workflows, but it should not automatically turn into an outage for every existing S3 transfer.
That does not eliminate failure modes—distributed systems never do—but it keeps the blast radius aligned with the thing that failed.
The architecture is really about ownership
The Bridge is not interesting because agents are fashionable or because outbound connections are clever. It exists because we want the technical architecture to match the commercial relationship.
The provider owns the Ceph infrastructure, S3 endpoint, customer relationship and operating policy. ScaleStore supplies the product layer and coordinates approved actions. The Bridge is the seam between those responsibilities.
When that seam stays narrow, both sides are easier to understand.