,
7 tweets,
2 min read
Read on Twitter
I saw this tweet and began screaming immediately. A thread about why.
S3 is an object store.
It is not a block store, nor a filesystem.
It can be a database, but that's out of scope for this thread.
It is not a block store, nor a filesystem.
It can be a database, but that's out of scope for this thread.
There are fundmental things you can't do with an object store as S3 is constructed. Appending to files is a key example here. Thus you're going to spend a lot of time rewriting a system on top of it to get around these limitations in an economically intelligent way.
But slow down, hasty pudding.
Why do you need such things in the first place?
"Legacy application support." And those legacy applications have no concept of things like "file appends are slow operations" or "ls in the wrong directory is expensive."
Why do you need such things in the first place?
"Legacy application support." And those legacy applications have no concept of things like "file appends are slow operations" or "ls in the wrong directory is expensive."
So you can't just drop a legacy application onto something that's got S3 as a backing store without some rework / evaluation of its disk access patterns--at which point "teaching it to talk directly to an object store" is normally the easier path.
*CAN* you do this?
Yes.
You can also use a Stradivarius as a hammer.
There are better tools for the job, and you almost always want to use them.
Yes.
You can also use a Stradivarius as a hammer.
There are better tools for the job, and you almost always want to use them.
In summary, when a guy who's enthusiastically using Route 53 as a database says "gee whiz, that seems like a dangerously bad architectural pattern," perhaps dive further before doing it.
