I’ve met yesterday with one or our clients and a good question came up: given the size and sheer volume of features in GridGain 3.0 how do we start and where do we start with GridGain?
In thick of a mad rush to push the release of GridGain 3.0 it is easy to be blind folded of just how much GridGain grew in functionality and how it is unsettling for someone new looking from outside in to find a starting point in using GridGain…
So the answer is: don’t start BIG.
GridGain is similar to Spring in this regard: although Spring has large number of projects in its portfolio – most people start with Spring IoC/DI container and general Spring wrappers, and then move on as they need.
The same is with GridGain. You can start with our new Actor-based messaging in 3.0 or simply piggy back on our automatic discovery and topology management. Many clients used GridGain as a better alternative to Java’s RMI – and there’s nothing wrong with that too.
I have always been saying that one of the most elegant use of GridGain is to use standard Java executor service backed by GridGain (just call executor() on grid projection). This basically gives you a standard bottom-less grid-wide thread pool. Nothing can be easier – just one extra line of code to get the thread pool.
So, the best way to use GridGain: start small, see what features make sense for you and then dig deeper to optimize your use case. GridGain is an excellent tool that will grow with you…