> The "simple" in S3 is a misnomer. S3 is not actually simple. It's deep.
Simple doesn't mean "not deep". It means having the fewest parts needed in order to accomplish your requirements.
If you require a distributed, centralized, replicated, high-availability, high-durability, high-bandwidth, low-latency, strongly-consistent, synchronous, scalable object store with HTTP REST API, you can't get much simpler than S3. Lots of features have been added to AWS S3 over the years, but the basic operation has remained the same.
> It means having the fewest parts needed in order to accomplish your requirements.
That is exactly what "deep" means, in the terminology of this post (from Ousterhout's book A Philosophy of Software Design). Simple means "not complex" (see also Rich Hickey's talk Simple Made Easy: https://www.infoq.com/presentations/Simple-Made-Easy/), while "deep" means providing/having a lot of internally-complex functionality via a small interface. The latter is a better description of S3 (which is what you seem to be saying too) than "simple" which would mean there isn't much to it.
Hickey's definition of simple is wrong. It's not the opposite of complex at all. They are not opposites, nor mutually exclusive.
- Easy is when something does not require much effort.
- Simple means the least complex it can be and still work.
- Complex means there are lots of components.
These are all quite different concepts:
- Easy is a concept that distinguishes the amount of work needed to use a solution
- Simple is a concept that distinguishes whether or not there is an excess number of interacting properties in a system
- Complex is a concept describing the quality of having a number of interacting properties in a system
Hickey's talk is useful in terms of thinking about software, but it also contains many over-generalizations which are incorrect and lead to incorrect thinking about things that aren't software. (Even some of his declarations about software are wrong)
"Deep", in the context of software complexity, probably only makes sense in terms of describing the number of layers involved in a piece of technology. You could make something have many layers, and it could still be simple, or be complex, or easy.
Simple doesn't mean "not deep". It means having the fewest parts needed in order to accomplish your requirements.
If you require a distributed, centralized, replicated, high-availability, high-durability, high-bandwidth, low-latency, strongly-consistent, synchronous, scalable object store with HTTP REST API, you can't get much simpler than S3. Lots of features have been added to AWS S3 over the years, but the basic operation has remained the same.