tl:dr: Kubernetes could become Xen
Recently, I made a statement saying that “Kubernetes is the de facto leader but they should be shit scared of AWS”. I made this claim based on the publicly available information on Kubernetes deployments. Clearly, this is only one subset of Kubernetes deployments (those deployments with ports open to the internet) but it is clearly indicative of a trend that I have highlighted in the previous posts. As expected, I got backlash from Kubernetes community and in this post, I want to explain why I think that Kubernetes community should be scared of AWS.
I have been arguing against AWS monopoly since early cloud days but AWS has been racing ahead of competitors by a wide margin. During the last AWS re:invent, I realized how many enterprises are willing to go all in with AWS. If anything, the AWS lead is going to further increase in the next decade. And, it is not a secret that AWS hosts the largest number of Kubernetes deployments and the data I showcased in the previous posts confirms the trend. In an ideal world, this should be good and a clear indicator of Kubernetes’ success.
During the 2017 AWS re:invent, just after AWS announced Fargate and managed Kubernetes service (EKS), I had conversations with senior IT managers of large enterprises including some well-known brands “we hear” regularly. Most of them were running their own Kubernetes managed clusters on top EC2 and almost every one of them said, they will move from their DIY Kubernetes to EKS offered by AWS because it makes both productivity and economic sense. They also said that once Fargate becomes an abstraction on top of EKS (either with an abstraction on top coming under Fargate brand or as a new service), they will embrace it because Fargate removes operational friction and makes running container clusters seamless (sucking the juice out of their dependence on Kubernetes). After Fargate makes Kubernetes a sideshow in their container cluster management, how long will it take AWS to give an easy on-ramp to ECS? Remember, contrary to the pundit expectations, ECS is growing well and AWS is continuing to invest in the service. In a not so distant future, users of container clusters will not care if they are using Kubernetes or under some AWS abstraction because it is the efficient way to do containers. In an ideal world, this is also good and it just shows AWS cares for their customers.
But
Kubernetes is an open source project released by Google but with heavy contributions from Red Hat and other vendors including startups. The community is operating under Cloud Native Computing Foundation. AWS joined CNCF as a member and the world rejoiced about the ultimate success of Kubernetes. I have been critical of lack of OSS code contribution from AWS for long but pundits like Matt Asay has been critical of my assessment (See this TNS podcast where myself and Matt Asay discuss this topic and other topics related to AWS and Kubernetes).
AWS’s position (which Andy Jassy has highlighted on few occasions) is that contribution to open source is not important but giving the users of OSS a seamless User eXperience is more important. This is AWS’ philosophy from day one and it is continuing even today. Yes, they have hired Adrian Cockcroft and he has put together a rockstar team for advocating OSS inside and outside of AWS. But what matters is code contribution and we are yet to see any significant contribution from AWS. Even their contribution to Linux kernel are the patches that are helpful to their services. Some announcements around Kubernetes by Adrian in the last Kubecon was also around making Kubernetes work seamlessly on AWS. I haven’t seen AWS taking a leadership role on OSS in any of these big OSS communities.
Let me be pretty clear here. OSS is not charity, and no user is expected to contribute back to OSS. But the general guiding principle for OSS is one of “Live and let live”. AWS is not doing anything legally or morally wrong here. Their “optimization philosophy” of building a successful business, both in the case of retail and AWS, is also legally and morally right. But their lack of contribution to OSS goes against the guiding principles for OSS communities. The hard work of all the engineers paid by various vendors should be respected by reciprocal code contribution. The mantra of “We make consumption of OSS seamless” is not the right way to say thank you to these engineers across companies, race, gender, countries, etc.. The only way any vendor can thank the engineers in OSS communities is by contributing valuable code back. Code contribution is the only currency that matters for vendors in the Open Source Communities (as far as vendors benefitting from OSS is concerned).
Now consider
AWS is the runaway leader in the cloud computing space and they are a runaway leader in the number of Kubernetes deployment. They are in the process of creating a service that will take the pain out of cluster management and integrate it with their managed Kubernetes service. What could go wrong for Kubernetes community? Just think about it.
I also remember how Xen fanbois used to boast about AWS using Xen for their cloud service. The last I heard, Citrix is not a player in the cloud space. Should Kubernetes become another Xen? This is a question for the Kubernetes community to ponder.
In the last post of the series which I expect to post early next week, I will talk about its implications to end users.
