My takeaway was that the single JBOD approach won't work in next generation systems as a JBOD of SSD/NVME/PCI-SSDs will be greatly limited by the controller, and that infrastructure complexity will increase presumably by having many JBODs with smaller number of disks.
Which is silly, because controllers can simply be designed to handle more data, and likewise they can be made more power efficient. So, far the only real limitation has been the interface, which off-course can be changed.
I'm not sure why that is your main take away from that article. The point is that relatively slow disk controllers designed for rotating magnetic storage are a bottleneck when you connect fast enough Flash storage. Connecting the storage via PCIe alleviates this bottleneck, to the point that you are no longer bound by the traditional constraints of small caches and large, slow permanent storage.
Isn't 8 GB per core still reasonable? Especially if you can share indices and buffer caches across cores, for example. There must still be diminishing returns for caching.
Depends on your dataset. Systems like Databases perform much, much better the less you have to touch a storage controller. One of the things that's going into Intel's 2017/2018 platform is the support for 6 channels of memory, and not all of that needs to be DRAM. There's a new standard, NVDIMM, that lets you use non-volatile memory as RAM, and take advantage of its much higher densities. So, if you have things like a database, you can map a much larger dataset into actual memory, instead of needing to just have the indexes in there.
I do a load of work with high throughput genetics sequencing. One of the programs that processes the data for a sample is single-threaded, but requires about 40GB of RAM. I currently have a server with 384GB RAM and 64 CPU threads, so 6GB/thread. RAM capacity is a definite bottleneck, since I can only run 9 at a time, instead of 64.
The more you can keep in memory, the better off you're going to be, even with the fastest SSDs in the world.