|
|
|
|
|
|
by IBCNU
4059 days ago
|
|
|
Before I get down-voted to oblivion, apologies for snark but I think I'm making a valid point. A lot of engineer's decided to throw in with AngularJS because of Google's "considerable weight" but as we're seeing now, we're all getting burned. It's a fine technology but the pain points have been severe. My point being just because Google backs a technology doesn't mean it's going to be useful, and should instead be based on its merits. |
|
|
I think your point is fair: all technology should be reviewed strictly on its merits. We certainly don't have a magic formula that gets it right 100% of the time. I can however say we are quite committed to this area and this project in particular.
Here are the things I think about most days:
In the case of Kubernetes, we are doing is a little different to anything we have done before. We have a commercial offering (Google Container Engine) based on this project that we ultimately hope the world to consider as a great way to run containers for money (yes, we hope to create a business around this). The nice thing is we are a service provider so we just need to convince someone to use our compute services for us to benefit from an open source project we sponsor. We aren't really hiding our intentions here; we do containers well inside Google and have some whizz-bang container hosting infrastructure and services. The problem is that people are not likely to use it unless there is a 100% open, fully compatible alternative available for off-Google use. By way of background I was the product lead for Google Compute Engine (our infrastructure-as-a-service product) for several years. The product is going really well now, but I learned the hard way that big customers like choices and no-one likes to be locked in. This isn't just us being Googley (though I have a personal predilection to openness); this is a simple fact of the marketplace today. We could not convince someone to bet on a disruptive technology if an open and credible alternative does not exist.
The second thing is that we see tremendous power in the open source community that we want to tap into, both for our cloud product line, and for our own internal use (it is no secret we use a lot of OSS internally). Kubernetes has achieved an almost ridiculous velocity (check out our PR acceptance rates) because the community is supporting it. It is a better product because we benefit not only from having a bunch of Google engineers working on it, but because we also get engineers from Red Hat, CoreOS and others who bring different perspective and capabilities. We aren't enterprise guys for example, but the Red Hat folks are -- the combined team is way better than the sum of the parts. Our service (Google Container Engine) is stronger for it, and in the limit we expect to use Kubernetes to run a lot of our internal services too.
Cheers, -- craig