How to do Grid Computing right?

Nah.. There are plenty of forums and consultants who would talk and guide you on complex challenges with Grid Computing. Following are seven simple premise to do Grid computing right. No this is not off of a book or a result of any theoretical analysis but my field experience with numerous clients over the last three years of Coherence consulting on high volume systems.

1. Process where data are - Its a proven fact that processing data where they are is much more efficient than bringing it over the wire and then processing it - A concept popularized by PL/SQL.
   
2. Storage Disabled - This challenge I have seen often with products that have embedded Coherence. Application objects competing for the same heap that Coherence uses to manage data. Remember Garbage Collection in Java still remains an unresolved necessity. GC can not be avoided but its affect can be minimized. Make a rule of thumb - Make your application storage disabled member of the Grid if you really want a stable Grid with predictable performance. Application layer can be scaled out independently of storage nodes. Application can go under long GC and the load-balancer can choose another application instance while the Data Grid remains responsive and stable. An effective way of building a high responsive system.
   
3. Key Association - In any serious application we always talk about associated data. Person associated with an Address. If computing demands Person and Address to be processed together then keep them together and use Coherence Key Association or partition affinity. Partition affinity can have some major performance impact.
4. Domain Model - Typically not talked about much. You don't have to put every object of your application in Coherence just because you have them. Put only those objects in Cache that are needed for computation. A stock is associated with an Account which is associated with an address. Why to keep Address in the Cache if it has no bearing on stock's buy or sell? Selective association also trims the composite object size and helps in effective partition affinity.
   
5. Thread Count - Make sure you use the Machine to its fullest. Don't just go by some rule of threads and cores ratio. Run the application in real-life-like environment and see which number makes sense? Appropriate thread count with Invocation Service can have real impact.
6. Backing Map Listeners - If done right BMLs can make the application layer very light weight. BML using Executor service to do asynchronous processing is a proven architecture but take it with salt and see if that makes sense for your application. But when it comes to raw end-to-end computing performance take a stab at it.
7. Custom Backing Map - By default in distributed scheme, Objects are stored in Binary format. This is the most efficient and effective format to manage partitioned data but it doesn't have to be. If your application requires to minimize deserialization cost during an expensive computation then you can change the Object format to what ever you like it to be or keep them unchanged by writing a custom Backing Map. Work with someone who has done this before because Backing Map should be the most efficient piece of the solution.

I haven't seen a single application that has violated any of these seven rules and have not have had any problems, yet. So Enjoy!