A Cloud-Agnostic File Platform

The project provided business applications with a consistent file service, so upload, download, and temporary access no longer depended directly on a specific cloud provider.

File upload is straightforward within one application. Once many systems directly use Ceph addresses, credentials, and APIs, however, moving to OBS or OSS requires each application to be changed, tested, and released. Historical files, existing links, and rollback become separate risks.

The project replaced these direct storage connections with a shared file capability managed as a platform.

Role and key responsibilities

I was responsible for the architecture and the key delivery path. The work included:

• A stable application interface. Applications used common operations such as upload, download, temporary access, metadata, and deletion instead of a provider SDK.
• An honest comparison of providers. I mapped differences in multipart upload, metadata, signed links, lifecycle rules, and errors, deciding what could be unified and what had to remain explicit.
• Central security controls. Long-lived cloud credentials no longer had to be distributed across applications. The platform managed them and issued access that was limited in scope and time.
• A reversible migration plan. Old and new storage ran together, new files moved gradually, and historical files were copied in checked batches. The team could pause or fall back if a problem appeared.

I also established the SDK, monitoring, and recovery conventions required for teams to adopt and operate the platform.

Unified service boundary

For an application, the platform became one service window. It could say “upload this file” or “give this user a download link valid for ten minutes,” and the platform selected the real storage destination.

Applications no longer constructed provider URLs, calculated signatures, or interpreted provider-specific failures. A future storage change could happen mainly inside an adapter rather than spreading across every product team.

A common interface did not mean pretending that all providers behaved identically. I first created a capability comparison:

• behaviour that was genuinely consistent belonged in the common interface;
• behaviour that could be translated was adapted with documented limits;
• provider-only features were exposed clearly as extensions;
• requests that could not be supported reliably failed early with a useful explanation.

This avoided an interface that looked portable in code but behaved differently in production.

Migration of existing files

A migration is more than changing an endpoint. It must handle both new files being created now and old files accumulated over years.

My design put the common client in front while retaining the old path. New writes then moved gradually. Historical files were copied in small batches, checked to make sure the content had not changed, and tracked with progress and failure records. References, permissions, and CDN behaviour were verified as well.

The old route remained available until the new platform had proved stable. The migration could therefore pause, retry, or fall back instead of depending on one risky cutover.

Outcome and architecture value

The platform reduced the applications' dependence on any one storage vendor. Adding or changing a provider no longer required many application teams to coordinate a simultaneous rewrite. Credentials became easier to control, and incidents could be separated into application, platform, or provider problems.

Most importantly, storage migration changed from one large irreversible event into a staged operation that could be measured, checked, and stopped safely.

Interface design, security controls, provider differences, existing data, operations, and rollback all had to hold at once; that is what kept the platform boundary standing through a real migration and through production traffic.