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.


Blogger Bob Lozano said...

Hi Serge-
As somebody involved with the philosophical foundations of the Appistry approach, I wanted to introduce myself and offer a couple of comments for your consideration.

The basic Appistry programming model is designed to follow the natural orthogonality in the data and operations. This allows the fabric to parallelize many operations across a potentially large number of machines. In some respects this is much like the Google MapReduce / MapUpdate approach.

It's my POV that programming and operation complexity are the two biggest blocks to practical development / deployment of very large scale apps. Since data and operations with many natural fissures covers a very large number of everyday situations, we wanted to make sure to make this case as simple as possible.

It's also worth noting that the fabric provides a facility known as the FAM (fabric accessible memory), which provides thread-safe access to shared state and queues, fabric-wide. It does so in a "fabric-like" manner (i.e. reliable, self-configuring, etc.).

One more thing - within the programming model, the developer has the full power of the underlying platform's programming model available at all times. This is true for whatever language / OS the developer chooses - java (esp. for POJO, Spring, and other frameworks), C / C++, .net, whatever.

So if the developer wants to construct individual tasks that spin / consume threads that is easily done as well.

Hope this helps. Thx again.


Mon Mar 26, 10:30:00 AM EDT  

Post a Comment

<< Home