5 ms·

Its an interesting article. Though, I kinda feel like we're missing a good chunk of the story. As dominate as AWS is now, it was probably even more dominate in

Its an interesting article. Though, I kinda feel like we're missing a good chunk of the story. As dominate as AWS is now, it was probably even more dominate in the time period we're talking about due to really haven gotten a big head start. And every time that AWS rolled out some new proprietary feature, it tied users even more tightly to the AWS platform. IMO, what Google realized they needed was a technology prevent people from getting more dependent on AWS. Being open source is key to that goal - if they just offer another proprietary service, its hard to go to someone and tell them not to use an AWS proprietary service but to instead use a GCP one. However, with Kubernetes being open, it means that users can host their own cluster and make it easy for them to move between cloud providers. For customers on AWS, I feel like this provides a bit of an incentive not to use too many AWS proprietary services or otherwise they lose the advantage of mobility. For everyone else, GCP gets to offer the strongest Kubernetes implementation and draw customers in that way. Its pretty win-win for Google. The article talks about the decision to open source Kubernetes as some sort of decision for the betterment of the world. But if that were really the only reason, why not open source Spanner of BigTable? And that's not to say that Google did anything wrong - corporations are designed to make decisions that are in their own best interests. What I think is interesting, is that this is a really powerful example of how sometimes things that are generally beneficial to the world AND business interests line up together, and when that does, kinda cool things can happen.

SkyRocknRoll 8y ago
Well written.
ben_jones 8y ago
Good points, I have my own inferences too: At the time of k8s inception GCP was behind AWS in UX and features. App engine had (very arguably) failed, if only from its well deserved high potential. The allure of kubernetes tied people over while Google played catch-up. Now many of Google's services are superior to AWS (very arguably). Developers notice the better network performance, the improved GCP console UI, the GCP mobile app, etc. Now with kubernetes maturing to the point of production usability Google's sales team is starting to outperform AWS. AWS will have dominate market share for many years to come, but GCP is in the drivers seat. The generous free tier of GCP (both the $300 credits and the free-tiers of various services) are a big help as well.
jchw 8y ago
>why not open source Spanner [or] BigTable? Because it's genuinely difficult to open source things like that. They're way too tied to Google and have many closed-source dependencies on internal libraries and services. I think they regret missing the opportunity on some of these and that may reflect why Google has started open sourcing more 'core' things like gRPC and Bazel - it might make it easier.
- dagenix 8y ago
  Good points. But, they also faced the same issue with Borg - presumably it was hard to open source, so, they created Kubernetes instead. There is nothing stopping Google from doing the same thing with Spanner or BigTable. Such a move would probably be well received by the community. It seems likely that people at Google would want to work on such projects - AIUI, CockrochDB was created by ex-Googlers. (And I didn't mean to focus on those technologies too specifically - with HBase and CockroachDB already existing, maybe Google wouldn't want to compete, but, I suspect they have other technologies for which creating open source versions would be well received, but they choose not to). My point isn't that Google could directly open source those technologies. Nor is it that they should create open source versions of them. I'm more just musing on how when the selfish reasons to do something line up with the good reasons to do something, you tend to get cool results. At a previous job, we had this process that everyone was supposed to do via a script. Doing the process via the script meant we got the logging that we wanted and such. Everyone was supposed to do it this way. However, there were no technical controls preventing anyone from doing that process by hand. We just told people not to. So, one day, a colleague asks me how to make sure that everyone does the process the right way. And my answer is that everyone already does - the script is way easier to run that to do it by hand. The good thing to do (run it the way you were told to), lined up with the selfish reason (it was way easier to do that way). Making sure those two things were in alignment was effectively as powerful as making it impossible to do the wrong way. (since then, the process has been significantly changed). I feel like its a similar case here. The good thing to do was to create a cool technology and make it free for everyone. The selfish thing to do, was to create a technology that made business sense. The result, is Kubernetes was created as open source (at least, thats my theory). If that wasn't the good thing to do, maybe the person writing the article doesn't talk to the VP on the shuttle about it and it never happens. If it wasn't the selfish thing to do (business case), maybe the VP wouldn't approve it. But, getting those two things aligned, results in positive reinforcement and results.
barrkel 8y ago
Yup. Kubernetes is a clear platform play to commoditize AWS, their biggest competitor in the cloud platform space. The strategy wouldn't have worked without open sourcing it, because it relied on people building k8s clusters in AWS, even if AWS didnt support it directly. Leaving out the major business rationale for k8s makes the article seem childish.
swaroop 8y ago
Agreed! This was also explained nicely in https://stratechery.com/2016/how-google-cloud-platform-is-challenging-aws/ https://stratechery.com/2016/how-google-cloud-platform-is-ch...
dekhn 8y ago
leveldb with a server wrapped around it is substantially like bigtable.
- Xorlev 8y ago
  If you really want Bigtable, go use Apache HBase. It's very mature these days and performed really well at $dayjob-1. There's a lot that goes into turning LevelDB into a real database. :)
thesausageking 8y ago
> The article talks about the decision to open source Kubernetes as some sort of decision for the betterment of the world. I've never liked that Google feels the need to couch everything in making the world better. Their open source strategy has mainly been strategic business moves to stop competitive threats. Android was about stopping Apple from dominating mobile OSs. Kubernetes was about stopping AWS from dominating cloud. TensorFlow was about making sure Nvidia didn't dominate deep learning.
- stingraycharles 8y ago
  This is precisely on point and is a proven strategy for Google. Chrome is another example. Almost all their big open source projects are to mitigate existing threats, and it’s working out very well for them. It’s annoying to see them trying to frame it as a “public service”, but guess that’s how to do proper PR.
- xapata 8y ago
  Google purchased Android before the iPhone was created. I agree that open source is good business, but some of the causes you listed aren't the whole story. Also, they learned a lesson from Hadoop. If they'd open-sourced Google MapReduce, the cloud industry might look very different.
- tangentspace 8y ago
  I don't get any odd vibe like that from this article. They are pretty upfront about the business motivations in this post: > with the launch of our Infrastructure-as-a-Service platform Google Compute Engine, we noticed an interesting problem: customers were paying for a lot of CPUs, but their utilization rates were extremely low because they were running VMs. We knew we had an internal solution for this. Later, > most importantly, we were able to work with lots of great engineers, many of whom really understood the needs of businesses who would benefit from deploying containers That does not read like a decision to pursue this for the betterment of the world. It sounds like a decision to pursue this for the betterment of their customers. That's capitalism, not benevolence, and they're pretty transparent about it.

SkyRocknRoll 8y ago

Well written.

ben_jones 8y ago

Good points, I have my own inferences too: At the time of k8s inception GCP was behind AWS in UX and features. App engine had (very arguably) failed, if only from its well deserved high potential. The allure of kubernetes tied people over while Google played catch-up. Now many of Google's services are superior to AWS (very arguably). Developers notice the better network performance, the improved GCP console UI, the GCP mobile app, etc. Now with kubernetes maturing to the point of production usability Google's sales team is starting to outperform AWS. AWS will have dominate market share for many years to come, but GCP is in the drivers seat. The generous free tier of GCP (both the $300 credits and the free-tiers of various services) are a big help as well.

jchw 8y ago

>why not open source Spanner [or] BigTable? Because it's genuinely difficult to open source things like that. They're way too tied to Google and have many closed-source dependencies on internal libraries and services. I think they regret missing the opportunity on some of these and that may reflect why Google has started open sourcing more 'core' things like gRPC and Bazel - it might make it easier.

dagenix 8y ago
Good points. But, they also faced the same issue with Borg - presumably it was hard to open source, so, they created Kubernetes instead. There is nothing stopping Google from doing the same thing with Spanner or BigTable. Such a move would probably be well received by the community. It seems likely that people at Google would want to work on such projects - AIUI, CockrochDB was created by ex-Googlers. (And I didn't mean to focus on those technologies too specifically - with HBase and CockroachDB already existing, maybe Google wouldn't want to compete, but, I suspect they have other technologies for which creating open source versions would be well received, but they choose not to). My point isn't that Google could directly open source those technologies. Nor is it that they should create open source versions of them. I'm more just musing on how when the selfish reasons to do something line up with the good reasons to do something, you tend to get cool results. At a previous job, we had this process that everyone was supposed to do via a script. Doing the process via the script meant we got the logging that we wanted and such. Everyone was supposed to do it this way. However, there were no technical controls preventing anyone from doing that process by hand. We just told people not to. So, one day, a colleague asks me how to make sure that everyone does the process the right way. And my answer is that everyone already does - the script is way easier to run that to do it by hand. The good thing to do (run it the way you were told to), lined up with the selfish reason (it was way easier to do that way). Making sure those two things were in alignment was effectively as powerful as making it impossible to do the wrong way. (since then, the process has been significantly changed). I feel like its a similar case here. The good thing to do was to create a cool technology and make it free for everyone. The selfish thing to do, was to create a technology that made business sense. The result, is Kubernetes was created as open source (at least, thats my theory). If that wasn't the good thing to do, maybe the person writing the article doesn't talk to the VP on the shuttle about it and it never happens. If it wasn't the selfish thing to do (business case), maybe the VP wouldn't approve it. But, getting those two things aligned, results in positive reinforcement and results.

barrkel 8y ago

Yup. Kubernetes is a clear platform play to commoditize AWS, their biggest competitor in the cloud platform space. The strategy wouldn't have worked without open sourcing it, because it relied on people building k8s clusters in AWS, even if AWS didnt support it directly. Leaving out the major business rationale for k8s makes the article seem childish.

swaroop 8y ago

Agreed! This was also explained nicely in https://stratechery.com/2016/how-google-cloud-platform-is-challenging-aws/ https://stratechery.com/2016/how-google-cloud-platform-is-ch...

dekhn 8y ago

leveldb with a server wrapped around it is substantially like bigtable.

Xorlev 8y ago
If you really want Bigtable, go use Apache HBase. It's very mature these days and performed really well at $dayjob-1. There's a lot that goes into turning LevelDB into a real database. :)

thesausageking 8y ago

> The article talks about the decision to open source Kubernetes as some sort of decision for the betterment of the world. I've never liked that Google feels the need to couch everything in making the world better. Their open source strategy has mainly been strategic business moves to stop competitive threats. Android was about stopping Apple from dominating mobile OSs. Kubernetes was about stopping AWS from dominating cloud. TensorFlow was about making sure Nvidia didn't dominate deep learning.

stingraycharles 8y ago
This is precisely on point and is a proven strategy for Google. Chrome is another example. Almost all their big open source projects are to mitigate existing threats, and it’s working out very well for them. It’s annoying to see them trying to frame it as a “public service”, but guess that’s how to do proper PR.
xapata 8y ago
Google purchased Android before the iPhone was created. I agree that open source is good business, but some of the causes you listed aren't the whole story. Also, they learned a lesson from Hadoop. If they'd open-sourced Google MapReduce, the cloud industry might look very different.
tangentspace 8y ago
I don't get any odd vibe like that from this article. They are pretty upfront about the business motivations in this post: > with the launch of our Infrastructure-as-a-Service platform Google Compute Engine, we noticed an interesting problem: customers were paying for a lot of CPUs, but their utilization rates were extremely low because they were running VMs. We knew we had an internal solution for this. Later, > most importantly, we were able to work with lots of great engineers, many of whom really understood the needs of businesses who would benefit from deploying containers That does not read like a decision to pursue this for the betterment of the world. It sounds like a decision to pursue this for the betterment of their customers. That's capitalism, not benevolence, and they're pretty transparent about it.