I just need something that can do S3 and is reliable and not slow.
I'm a simple man, I just need edge delivered cdn content that never fails and responds within 20ms.
I just need something that can do S3 and is reliable and not slow.
I'm a simple man, I just need edge delivered cdn content that never fails and responds within 20ms.
Like it or not, S3 has become the de facto API for object storage for many developers. From the operations side of things, managing files is easier and already taken care of by your storage solution, be it a SAN, NAS or something entirely different. Being able to backup and manage whatever is stored in S3 with your existing setup is direct saving.
If you actually use a large subset of S3s features this might not be good solution, but in my experience you have a few buckets and a few limited ACLs and that's it.
- Lets me deploy stateless containers easily
- Let’s me leverage the NAS for local redundancy and a more centralized place to do backups
- When a project grows it’s easy to promote it to use a hosted S3
- Local S3 becomes a target for Litestream and Restic
- Developing against the local fs and then handling file storage is a huge friction, unless I’m using something like Rails that already has a good abstraction
If you split the interaction API out to an interface detailing actual program interaction with the service, then write an s3 backend and an FS backend. Then you could plug in any backend as desired and write agnostic application code.
Personally I end up there anyways testing and specifying the third party failure modes.
That’s the entire point: my domain code ‘stores’ something, my implementation decides if that is S3 or a fixed kind of error or writes to a disc.
If my domain uses a third party app that needs an S3 API, and we see not pointing it at S3, then I am writing an s3 API to test that dependency and ensure the third party code works regardless. Normally I’d call that “their problem” and call their service with the same wrapper as above.