For customers, it'll come down to a choice of which platform's philosophy is the best fit. With Red Hat, the underlying technologies (such as Kubernetes) power a larger platform; with Google, the underlying technologies are the platform.
Hitting the sweet spots
The most significant source of pressure on Google to improve Kubernetes, both the open source project and its as-a-service delivery, may be Docker. Last month, Docker revealed it was directly merging its Docker Swarm technology to provide many of Kubernetes' benefits as a convenient, out-of-the-box offering without the overhead of Kubernetes. (After all, a tool that emerges from within Google is likely biased toward massive scale in both its feature set and its presumptions about how it's set up and used.)
Google can offset Docker in two main ways. First, it can obviate any issues involved with setting up and running Kubernetes by offering it as a service. This approach only works to the extent that people use Google Cloud Platform, though.
The other, more general approach is to make Kubernetes a tool that's explicitly aimed at organizations large enough not to mind the heavy lifting needed to get it running -- in other words, let Docker Swarm and Kubernetes be different products for different markets. Docker generally is aimed at a broader swath of users, so it's likely Swarm will provide the best alternative in environments where "just enough" clustering is needed -- but Kubernetes will aim to be the tool for where the broadest possible scale is required.
Sign up for CIO Asia eNewsletters.