No sooner did Google announce its Infrastructure-as-a-Service offering, Google Compute Engine, at Google I/O this morning, than MapR revealed it will offer its Hadoop distribution on-demand via the new Google cloud.

The announcment with Google comes just two weeks after MapR inked a similar deal with Amazon to host M5 and M3, its enterprise and community Hadoop distributions, in the Amazon Elastic MapReduce cloud. Clearly MapR believes the cloud is its pathway to significant customer adoption.

MapR CEO John Schroeder is scheduled to appear on theCUBE live from Google I/O later today where my colleague John Furrier will no doubt discuss the Google/MapR partnership. For now, Schroeder released the following statement:

“Off-premise, on-demand computing is an important part of the future for Hadoop. MapR is solidifying that future by partnering with Google and leveraging their cost-effective, high performance and scale-out infrastructure.”

The Google partnership is a pretty big deal for MapR. Google has major Big Data street cred, having invented and just today successfully patented the MapReduce framework at the heart of Hadoop. The deal further validates MapR as a major player in the market, along with competitors Hortonworks and Cloudera.

In fact, each of the three now have distinct go to market strategies.

– For Hortonworks, the plan is to spur widespread adoption of Hadoop by offering a completely Apache compatible and free Hadoop distribution, Hortonworks Data Platform, and eventually make money providing support services.

– Cloudera is likewise promoting an open Apache Hadoop core, but supplements the open source framework with its own proprietary management and monitoring software, Cloudera Manager. Customers pay for the software along with support services.

– MapR, which has been criticized for supplementing open source Apache Hadoop with a proprietary storage services layer, is betting customers are more interested in getting up-and-running with high performance Big Data analytics quickly via the cloud, and are less concerned with whether or not the code is open and the risk of vendor lock-in (whether such concerns are valid or not.)