Quite often I am being asked about what is the most important feature or the feature that I like the most in GridGain. My answer usually comes around one feature or characteristic of GridGain that is unique and often overlooked in grid computing - developer's productivity.

The whole idea behind the GridGain came about from a frustration of working in Java with something like Globus or Sun Grid Engine. These things were so out of touch with modern Java development that using them seemed almost contrived. All the things we've come to expect and appreciate like lightweight containers, IoC, AOP, conventions over configurations, light deployment process, meta-programming with annotations, simple and powerful APIs - all of them were "missing in action".

Lack of focus on developer's productivity is what largely created this painful stigma that grid computing is a complex and very expensive proposition. In the minds of many mid-level managers grid computing is still firmly associated with hiring IBM Global Services to help with this "monumental" undertaking - installing and configuring Globus grid infrastructure...

So, when we started GridGain our goal #1 was to develop grid computing infrastructure that will be as productive to use as Spring (or Seam or Grails if you fast forward to our times). Here's what GridGain 2.0 provides when it comes to developer's productivity - your productivity as software engineer:

• Zero deployment with p2p class loadingThis is the key feature that boosts developer's productivity more than anything else. In a nutshell, when you are writing grid application with GridGain you don't copy files, you don't run special Ant scripts, you don't FTP anything, you don't start or re-start or re-provision anything, you don't go to a GUI console to do something - you just click "Run" and the code with your latest changes just works across the grid.
• Many grid nodes per computer or even per JVMLet me ask you a question: what other product allows you run multiple independent grid nodes in parallel on the same computer? How about in the same VM?? Can you run 10 nodes in the same VM and debug your complex distributed algorithms without leaving your favorite Java IDE? Yes - with GridGain you can.
• Conventions over configurationGridGain works out-of-the-box without a single line of configuration that needs to be changed. And this is not a special toy setup - this is the setup that would work for many production environments and for the most of development setups too. Moreover, we took a great care of thinking what default configuration means for each and every of our SPI - ensuring that you, the developer, spending time coding and not fiddling with configuration unless it is absolutely necessary.
• XML and non-XML configurationWith GridGain we use Spring XML beans as configuration medium. If you know Spring XML beans - you already know how to configure GridGain. In the same time - you don't have to know Spring at all. GridGain can be equally configured via Java code as our entire configuration is concentrated in a single interface:
  • You can inject it via Spring which is default IoC framework
  • You can inject it via any other IoC-container/framework
  • You can configure it in Java without any XML or IoC
• Strongly typed Java 5 interfacesWe take strong typing seriously and GridGain is using parameterized types in many places. That has great benefit for the developers as you don't need to guess and rely on runtime or junits to catch something that any IDE will highlight as you are typing...
• Best Javadoc you have even seenWe take pride in our Javadoc. We know most of the developers that are using GridGain looking at it every time they need some answers on API and we wanted to make our Javadoc simple and effective API documentation. It's well organized, has useful UML diagrams for all classes, cross-linked with our wiki, and has generous coding and configuration examples.