> the often recommended "good practice" of separating storage and compute.
This gets me thinking... has developer conventional wisdom ever recommended binding things together? Or does it only ever recommend more separation, more abstraction?
10 years ago when people still used the term "big data" there was some enterprise buzzword usage around "hyper convergence" that was supposed to make it easy to bring compute and storage together/move compute jobs close to the storage they were supposed to operate on. I guess the idea was something like if you had a map-reduce job, you have some scheduler that runs workers on nodes that are in the same rack/directly connected to the storage partition they'll need.
React is a recent example of the “right” thing being less separated than prior conventional wisdom - we’re now mixing JS, often styling, and “HTML” when the historical powers that be demanded separation.
Mechanical sympathy. And conventional low-latency systems do that as much as possible - binding all sorts of layers. When you're picking the first few bytes of the packet and semi-parsing it, you don't traditionally and conventionally have that go through some vtable and perform dynamic dispatch to find the right parser or whatever. It's all plugged into everything monolithically.
This gets me thinking... has developer conventional wisdom ever recommended binding things together? Or does it only ever recommend more separation, more abstraction?