Appistry is one way of doing it

Appistry 3.5

allows Java and .NET applications to scale out across a number of servers while running as though it were one application on one server. The Fabric makes the application think it's running on one computer, and the developer writes applications as though it will run on a single computer. But in execution, the application could be distributed over 100 or more computers.

So we seem to have at least 4 approaches:

1. The conventional multithreading where the programmer writes all the controls for the threads and how they share and don't share data, in the hope of optimizing resources (e.g., threads, memory, communication).
2. The future multithreading yet to be usable, where the programmer does not have to write all the controls for the threads and how they share and don't share data, yet resources are still optimized.
3. The Google Grid technique called MapReduce.
   
4. The Appistry Grid technique where the programmer writes single-threaded logic and the underlying system takes care of managing the available resources (threads and memory).

The Appistry approach seems to pose difficulties for applications that require multiple threads to share data. It allows applications to launch multiple threads but probably does not offer more help for controling their interactions than what the language already offers. This remains to be verified. If it is the case, then for scaling, the programmer has to make difficult non-obvious choices between the single-thread auto-scaling by Fabric versus the conventional multithreading approach. I would think that if you have Fabric then you minimize your use of multithreading.