Image; Getty Images/iStockphoto

Perhaps Google’s greatest asset in its cloud ambitions is the phenomenal engineering that has gone into running Google at massive scale. Ironically, and perversely, this may also be its greatest weakness. As enterprises increasingly embrace public clouds, they’re looking for help to make the jump. Google’s infrastructure may be more daunting than aspirational.

It’s also very possible that it oversteps the mark. As James Urquhart put it, “Google is the Sun Microsystems of this decade. Engineering for engineering to engineer by engineering. A phenomenal approach for discovering innovative solutions, but not necessarily a great one for product-market fit.” Is Google too Googley for its own good?

SEE: The industry cloud: Why it’s next (ZDNet/TechRepublic special feature) | Download the free PDF version (TechRepublic)

Building for the masses

A little history may help. During my MongoDB years, we actively sought to overcome the perception that MongoDB couldn’t scale–that it was for small-scale pet projects. We authored a page that highlighted how different companies were running MongoDB at serious scale (that page has changed a little since we first wrote it). While we didn’t reference them by name, we called out how major Chinese web companies, in particular, ran MongoDB at “web scale.” We wanted so much to show that MongoDB wasn’t a toy.

What’s interesting to me is just how little this page has changed. I suspect this mostly derives from the fact that the early myth that MongoDB couldn’t scale has long been retired. But it also speaks to a more important point: MongoDB doesn’t need to be “web scale” to be critical data infrastructure for 99.999% of enterprises.

SEE: Amazon Web Services: An insider’s guide (free PDF) (TechRepublic)

Database guru Mark Callaghan calls this to mind in his response to Jim Dowling, who said of MySQL, “Funny thing is even if we had built a web-scale, sharded MySQL, the tech companies [like Google] would never have paid for it.” Writes Callaghan:

[MySQL] should have been built for everyone else, not for Google because big web-scale is a small market. MongoDB built that product and is thriving by selling it to everyone but big web-scale. Not sure MySQL execs ever understood this. Most of the things we [Google] fixed were needed by everyone – make replication crash safe, get InnoDB to scale on two-socket servers, and much more. Wasn’t asking for web-scale MySQL as we do that via glue code. Was asking for reasonably reliable single-node MySQL.

Catch that? As nice as it might be to brag about Google or Tencent or Facebook or some other web giant using your code at scale, it’s far smarter business to make a mass-market product that mainstream enterprises can use. This is what MongoDB has done, as Callaghan points out, but is it what Google should do?

Should Google be Google?

Google is, after all, Google. Everything it does to run at gargantuan scale is science fiction for those mainstream enterprises. For Google to distinguish itself in the cloud against AWS and Microsoft Azure, it needs to play to its strengths. I’ve argued that “giving developers access to its cloudy secret sauce” (like BigTable) is a big step forward. I’ve also suggested that while Google has hitherto told enterprises that they “could run a lot more like Google if they weren’t so stubbornly like themselves” but that “it’s becoming clear that the ‘run like Google’ tagline is an attainable goal, one that even the most staid of enterprises can realize.”

But is it?

I know there was resistance within Google for some time to embrace the “run like Google” marketing message, largely because it had the potential to scare off more customers than it enticed. What Google (and the other web giants) does is hard. It’s incredibly complex, futuristic engineering. Frankly, it’s not what most enterprises need (or perceive that they need, which amounts to the same thing).

SEE: Open source vs. proprietary software: A look at the pros and cons (Tech Pro Research)

Google has routed around some of these concerns by (brilliantly) open sourcing key components like Kubernetes (build and deploy like Google) and TensorFlow (embrace AI/ML like Google). These open source projects have encouraged developers to learn the Google way on their own terms, without Google having to aggressively spend on sales and marketing to prepare the market. Given how hard it must be for Google to not be Google, an even more active approach to open source could pay big dividends.

It’s possible that Urquhart is correct in his indictment of Google’s engineering-for-engineering’s-sake culture. It’s also likely, as Tom Barber has stressed, that mainstream enterprises, and even SMBs, should try to run more like Google (and other web giants that have pioneered cloud development), however daunting. Google’s open source strategy may be a thoughtful way to allow Google to be Google, while simultaneously enabling the industry to “be Google,” as well.