GridGain 3.1 – What To Expect?

GridGain 3.1 will be an important release for us for several technical and business reasons:

  • This is the first release where we will separate community and enterprise editions on the release schedule.
  • GridGain 3.1e will be released first for Enterprise edition and Community edition will see the light later on in Q4 2011.
  • This is the first release to follow on our newly updated pricing model including silver and gold subscriptions.
  • GridGain 3.1e will see initial support for Document API. You’ll be able to store any document-based objects in data grid (like JSON or Java maps) and perform indexed SQL queries on them. Very powerful addition that makes GridGain 3.1 an ideal storage for “soft-schema” or NoSQL applications.
  • GridGain 3.1e will introduce REST access to the main compute and data grid functionality.
  • License support will be significantly improved for live production environments including live license update.
  • Significant improvements to TCP-based discovery with several IP-finder and metric-store implementation. This SPI is geared towards large deployments with hundreds of nodes.
  • Cumulative bug fixes updates, especially stability enhancements for data grid.
  • Several deprecations on SPI and certain API we no longer planning to support. Notably we have decided to drop support for JGroups.


Top 5 Reasons GridGain Makes Developer’s Life Easier

After seeing Cameron McKenzie’s call for other vendors to produce Top 5 reasons their products make the developer’s life easier – here’s the top from GridGain.

1. Integrated Compute and Data Grids
GridGain’s “High Performance Cloud Application Platform” is the only solution that combines state of the art compute and data grids – two built from the ground up technologies tightly integrated into one cohesive product. Developers no longer need to sacrifice features by emulating compute grid with data grid or vice versa, and no longer need to integrate unfitting products to achieve full featured affinity-based MapReduce processing.

2. Zero Deployment
Unique to GridGain, zero deployment provides advance cloud-enabled on-demand class loading to any JVM-based applications. It allows to avoid any manual deployment of the user code. No websites to click through, no awkward manual network configuration or restarts, no Ant/Maven builds, no IDE plugins, and no custom management consoles required.

You can execute new code or cache new types of data in GridGain without any specific deployment or restarting of your grid. You can essentially have a live grid/cloud installation, create dynamically new Java or Scala class and immediately put it into data grid and start querying it – again, avoiding any deployment steps or downtime due to restart.

3. Advance Functional API for Compute and Data Grid
GridGain comes with advanced Functional Programming (FP) frameworks for Java. Not only it support all the basic FP functionality like closures and predicates, typedefs and type aliases, currying, continuations and comprehensions – it also the only FP framework that is fully distributed in nature. GridGain allows to perform most of the distributed operations in FP style such as executing closures on the cloud or route distributed executions to predicate-based topology projections.

4. Native Integration with Scala
GridGain provides unique Scala-based DSL for distributed programming that dramatically simplifies the usage of GridGain with Scala language. Here’s the full Scala source code for the MapReduce application that counts non-empty characters in the given string by splitting this process over the cloud:

import org.gridgain.scalar._
import scalar._

object ShortestMapReduce {
	def main(args: Array[String]) = scalar {
		println(“Count is: “ + (grid spreadReduce (
			for (w <- args(0).split(" ")) yield () => w.length,
			(s: Seq[Int]) => s.sum

This application works on any size of grid or cloud, automatically joins the topology, uses zero deployment so no explicit deployment is required, fails over in case of errors, automatically scales up and down depending on size of the input string and number of nodes available.

And by the way – the Java version using our FP framework looks almost exactly the same…

5. Ability to run entire cloud in a single VM
It may not be the product defining feature – but the ability to lunch multiple GridGain nodes right in the same JVM is one of the greatest time savers today in distributed computing. In fact, you can lunch entire grid or cloud right in the same JVM, put breakpoints onto multiple nodes and step through the entire cloud tracing your distributed logic in your debugger never leaving the IDE.

We use this capability internally at GridGain when developing the GridGain itself and it literally saves up to few hours every day (!) comparing to remote debugging and scouring logs from multiple computers and trying to sync up the timestamps in the logs.

80/20 Rule Fallacy

I think I’ve first read about it some years back from Joe Spolsky…

There’s general perception in software that if we implement 20% of the features that competitors have and charge only 20% of their price – we’ll win 80% of the market.

The problem with this logic is the fact that in software these 20% are constantly changing from one client to another. Out of set of features {A, B, C, D, E, F, G, H, I, J} client 1 will need {A, B} and client 2 will need {E, F}both needing 20%, but different 20% each.

It is especially true in a complex distributed software middleware. People don’t acquire GridGain, Terracotta, or GigaSpaces because they provide minimally exact feature set they are looking for for a cheap price. In fact, most companies starting with GridGain don’t even realize they will need certain features at all or that the certain features even exist. In fact, we often see that features that were important at the beginning becoming less important as the project grows and vice versa.

One of the benefits of GridGain’s Cloud Application Platform is that it can grow with your project needs. You can start with something simple like utilizing automatic discovery and end up using complex affinity-based MapReduce or continuation-based Scala-DSL driven processing.

Food for thoughts…

[tweetmeme source=”gridgain” only_single=false]