In response to my post on Red Hat’s blind spot on databases, Redmonk Analyst Steve O’ Grady posted explaining why Red Hat couldn’t (or shouldn’t) enter the database market. He posed a set of 5 questions he expects in any response. In the spirit of good natured debate (with utmost respect to Steve’s views), I am going to address Steve’s questions in this post. I still stand by my assertion that lack of a database story is still a hole in their portfolio and, in the cloud world, one who holds the keys to data is the one who will emerge as the winner.
How they run a DBaaS?
In the same way they run OpenShift Online and OpenShift Dedicated. I want to see a hybrid cloud story on database too. Let us not hallucinate on the fact that running “as a Service” is expensive and requires operational overhead. Clearly, there is a need for investment to run DBaaS (as in public cloud service). Having said that their acquisition of CoreOS and the release of Kubernetes Operator Framework gives them an opportunity to take a shot. They need to invest in terms of acquiring a DbaaS vendor or get engioneering talent to roll out a product that can be termed as “Roll your own DbaaS anywhere with Kubernetes and Operator Framework”. In other words, they could provide a platform for customers to run a DBaaS like offering either on-premises or on top of any cloud. This, in turn, provides an opportunity for customers to control the data with a little operational overhead (which they would have to use even for running OpenShift Container Platform on-premises or on their own cloud account. Using the same Operator Framework, Red Hat can offer DBaaS to go along with OpenShift Online or OpenShift Dedicated.
The natural question that could arise here is “What is the point?”. If I can run my application on public cloud services, I wouldn’t be using OpenShift anyway. I can run my applications on AWS Fargate or equivalent offering from Azure or Google. Enterprise customers come to Red Hat for OpenShift Container Platform because they want to have better control over their application infrastructure. This idea fits right into that logic of Red Hat customers.
There are many ways in which Red Hat can fill this gap. Acquiring vendors in SQL and NoSQL space is one option. But, with Red Hat’s expertise in supporting open source software that is not invented inside the company, they can put their weight behind few OSS databases and tap into operator framework and additional engineering talent to offer a data platform to go with OpenShift and their serverless offering in the future. If I remember correct, they already ship some databases along with RHEL (some Red Hatter correct me if I am wrong)
How they outengineer AWS, GOOG, MSFT in that market?
They cannot. If the issue is outengineering public cloud providers like AWS, Microsoft Azure or Google Cloud, they shouldn’t be in the market. Red Hat customers are not the ones who come to them for operational efficiencies at scale but for a different purpose. Red Hat is not competing with the web scale cloud providers. They act complementary to these providers offering higher order abstractions that give more options for enterprise customers. I am arguing that my assertion about the need for a database play in the same context. As more workloads grow to public clouds and they let their customers lock their data in proprietary public cloud services (even if it is wrapped with Open Service Broker API spec), they run the risk of losing these customers to public cloud providers over the next iteration/technology evolution. Yes, they cannot outengineer public cloud providers but they need to give an option to their customers to avoid losing these customers to public cloud providers.
Which databases (plural) they offer?
It is a tough question to answer. Probably, Postgres and a NoSQL database based on trends in their customer base. The problem here is not picking the database but the philosophical decision from their executive leadership to enter this space.
How they don’t impact RHEL/OS with those choices
I don’t see any big impact. As I mentioned earlier in the post, they ship databases along with RHEL and can support multiple OSS databases on RHEL. I wouldn’t expect this to be an issue. If anything, this gives them an opportunity to sell more RHEL licenses for the instances underneath the “DBaaS”.
How they acquire traditional DB customers
The issue here is not abouit traditional DB customers but newer workloads moving the data into cloud databases. Without a DBaaS like offering, they are letting these data to enter into the proprietary databases of webscale providers and they need to stop this bleeding.
Red Hat should not compete with web scale providers and they should play in the space complementary to the public cloud focusing on enterprise customers. These are the customers who want to have more control than what public cloud can offer and also tap into the flexibility offered by hybrid and multi cloud. This is the space Red Hat should compete and in order to compete effectively and double down on OpenShift’s success, they need to fill the gap on database story. They need to offer DBaaS like platform to go with OpenShift (which is PaaS like enterprise offering). Thoughts?