This reads as though they had taken issue with some of the movement away from traditional relational databases in that era. I know it's been retracted, so who knows what the authors opinions are today, but the eureka moment to me was in horizontal scalability - not the map and reduce functions. Until then if you wanted something to go faster you simply bought a bigger computer.
In my work many of the MR use cases didn't necessarily compete with activities you'd expect of a database. For example - take the entire Geo database and generate the map tiles. I also must have written hundreds of MRs that essentially transform the entire dataset. You certainly can do that in a relational database but it seems like the wrong approach. Similarly if I was going to perform a bunch of queries I wouldn't write a new MR each time.
This was not my first programming job and I didn't mean to imply stupidity. Maybe you could give some examples?
I had seen it in some contexts: distcc, networking, seti@home. At least to me it didn't seem as common a tactic as trying to scale up the hardware on the machine or designing a different algorithm. That's generally what I saw at Microsoft in the years before.
Maybe it was more the power of combining it with a "cloud" and containers - being able to change just the value of --mapreduce_machines= to something like 10000 and seeing it happen. That's the first time I had been exposed to that.
In my work many of the MR use cases didn't necessarily compete with activities you'd expect of a database. For example - take the entire Geo database and generate the map tiles. I also must have written hundreds of MRs that essentially transform the entire dataset. You certainly can do that in a relational database but it seems like the wrong approach. Similarly if I was going to perform a bunch of queries I wouldn't write a new MR each time.