tecosystems

VMware’s Database Play: Will Red Hat Follow?

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Developing cloud based apps will require new data management and storage models. VMware is getting well ahead of the curve by investing in Redis, a well thought of, blazing fast, Key Value store, what is being called a NoSQL database. I wrote up why RabbitMQ is interesting the other day.

While Maritz may say VMware isn’t getting into the database business, he means not the relational database market. The fact is application development has been dominated by relational- Oracle on distributed, IBM on the mainframe – models. Cloud apps are changing that. As alternative data stores become natural targets for new application workloads VMware does indeed plan to become a database player, or NoSQL player, or data store, or whatever you want to call it.”
– James Governor, “VMware’s SpringSource Redis and Rabbit acquisitions: A Database Play is Emerging

Let’s say you’re a technology vendor with a credible, high share offering in one or more of the lucrative enterprise market segments. Where do you look for growth? You land and expand, as they say. There isn’t an enterprise vendor on the planet that doesn’t feel that somewhere, somehow, it’s leaving money on the table.

Which is why VMware’s strategy as outlined by James above is both interesting and eminently logical. By acquiring SpringSource (coverage) and Zimbra (coverage), after all, VMware would – theoretically at least – be realizing a higher percentage of deal revenue. Still, while stacks and messaging is all well and good, the real money is in the database.

But investing in a database could potentially damage relationships and antagonize important partners like IBM, Microsoft, and Oracle. What if, however, VMware could invest in a new database field, one with high growth potential but effectively zero commerical presence from any of the traditional database providers?

What if, indeed. Welcome to the VMware family, Redis and RabbitMQ (coverage).

If we were to speculate who might be embarking upon a similar path, we would be looking for a vendor whose:

  1. Clearest strategy for growth is the expansion of its product footprint
  2. Growth has in the past come from acquisition supplied stack expansion
  3. Partner concerns have prohibited database investments in the past
  4. Ambitions lie at least in part in cloud related workloads

Which brings us to Red Hat. Let’s see how they match up.

  1. Red Hat’s best strategy for growth does appear to be an expansion of their footprint, as their potential for share gains in their core operating system and middleware markets appear to be incremental at best.
  2. Red Hat has in the past chosen inorganic growth via new market opportunity acquisition in JBoss.
  3. Red Hat has been rumored to be reluctant to commit to a database path for fear of upsetting partners; as Matt Asay put it, “I’ve heard it said that Red Hat executives are loathe to upset any database vendor by acquiring MySQL (before Sun did) or EnterpriseDB (PostgreSQL).” Instead they’ve chosen the indirect route, funding EnterpriseDB and MySQL at various junctures.
  4. Red Hat does, in fact, have substantial ambitions in the cloud. Witness www.redhat.com/solutions/cloud/.

Will Red Hat enter the database market circuitously via a non-relational project or projects? Only they can say for sure. But like all public companies, they need to grow, and where better than a potentially high margin market with with a variety of maturing open source projects and little if any partner conflicts to manage?

4 comments

  1. […] VMware’s Database Play: Will Red Hat Follow? […]

  2. […] Related, be sure to check out Stephen’s database at VMWare & RedHat thinking. […]

  3. […] Redmonk analyst Stephen O’Grady posits, the desire for growth may well lead Red Hat to follow VMware, which recently acquired RabbitMQ, […]

  4. “Will Red Hat enter the database market circuitously via a non-relational project or projects?”

    You mean re-enter? See “Red Hat Database” i.e., postgresql.

Leave a Reply

Your email address will not be published. Required fields are marked *