Kubernetes Documentary Part 1: A Critical Review(cloudcritical.org)
cloudcritical.org
Kubernetes Documentary Part 1: A Critical Review
https://www.cloudcritical.org/article/kubernetes-documentary-part-1/
1 comments
Hi streetcat1 thanks for responding in such a courteous manner.
To your points:
1. I am not going to get into the ethics of AWS rebranding OSS. That could be an entirely different topic. Unlike almost all other OSS products, K8s was not designed to solve OUR problems. It was developed to solve GCP's lagging marketshare. GCP needed to normalize our workloads in the hopes people could easily migrate to their cloud.
2. I am sorry that is not true. The documentary clearly spells out Kubernetes was not community first. I point out that fact several times. They even quote Urs as saying that. I believed what you believed at one point as well, I don't anymore.
3. I am not understanding your point, I am familiar with the history of Openstack.
your next points: 1. That is portability not scalability, and I agree a clear bonus brought by Docker, not Kubernetes. 2. I am not sure the point here. If you mean I can fork it, I addressed that. AWS has way more workloads then 5%, in just straight market share and as a slice of the K8s pie. 3. I am completely familiar with the "control loop", I hope the best for your business, I guess.
2. I am sorry that is not true. The documentary clearly spells out Kubernetes was not community first. I point out that fact several times. They even quote Urs as saying that. I believed what you believed at one point as well, I don't anymore.
3. I am not understanding your point, I am familiar with the history of Openstack.
your next points: 1. That is portability not scalability, and I agree a clear bonus brought by Docker, not Kubernetes. 2. I am not sure the point here. If you mean I can fork it, I addressed that. AWS has way more workloads then 5%, in just straight market share and as a slice of the K8s pie. 3. I am completely familiar with the "control loop", I hope the best for your business, I guess.
Sure. So I do agree that kubernetes was developed to solve GCP market share issue. I do not think that anybody think otherwise. I just not sure why this is a bad thing. I.e. why do you care why kubernetes was developed, vs the actual merit of the product.
2. When I refer to community first, I mean that the product was rushed to market, half baked, and than was iterated in the market. I think that Google worked with redhat on the initial API (I.e. deployment object came from redhat)
Regarding AWS, AWS does not have 5% of the global IT market, of course it have 40% of the global cloud market, but not the IT market. Also, the usage of AWS or any other cloud for that matter, is very skewed, I.e. 63% percent of the customer have one S3 bucket, or one EC2 node.
My point about open stack is reflecting your point about VMWARE / IBM. I.e. kubernetes will end up maintained by companies that sell multi cloud/on prem solution.
Overall, I believe that kubernetes is the only way the IT world can decrease the power of the big 3 cloud providers(I cannot see any other option at this scale), hence usage should be encouraged.
2. When I refer to community first, I mean that the product was rushed to market, half baked, and than was iterated in the market. I think that Google worked with redhat on the initial API (I.e. deployment object came from redhat)
Regarding AWS, AWS does not have 5% of the global IT market, of course it have 40% of the global cloud market, but not the IT market. Also, the usage of AWS or any other cloud for that matter, is very skewed, I.e. 63% percent of the customer have one S3 bucket, or one EC2 node.
My point about open stack is reflecting your point about VMWARE / IBM. I.e. kubernetes will end up maintained by companies that sell multi cloud/on prem solution.
Overall, I believe that kubernetes is the only way the IT world can decrease the power of the big 3 cloud providers(I cannot see any other option at this scale), hence usage should be encouraged.
I think the design behind Kubernetes served one purpose, normalize people's workloads. Not to reach Uber or Netflix scale. That is important in the context of the history, and I care because I don't think it is a very good product, because of this very reason.
It was definitely rushed to market, they say it in the video, and all the major players in the ecosystem, IBM, Redhat, Google, and VmWare, all wanted a piece of that pie, because all of them were barely treading water.
I don't think that is how market share is measured.
I am not sure how you decrease the power of the big 3 like this. Kubernetes does not solve that issue. I agree it is an admirable ambition, but I think you would have better luck trying to regulate them like utilities.
It was definitely rushed to market, they say it in the video, and all the major players in the ecosystem, IBM, Redhat, Google, and VmWare, all wanted a piece of that pie, because all of them were barely treading water.
I don't think that is how market share is measured.
I am not sure how you decrease the power of the big 3 like this. Kubernetes does not solve that issue. I agree it is an admirable ambition, but I think you would have better luck trying to regulate them like utilities.
1. Of course kubernetes was developed to get customers to GKE and for profit reasons. 99% of the open source developers are paid programmers. Hence there is an alternative cost to their time. I am not sure why this is wrong. At least they did not fork an open source project and offered it without credit to the original companies, like other cloud providers.
2. The way google develop open source products is community first / tech later. But this is stated. For example, kubeflow - it was started as a community project, got the requirements/community in place first, and than was redesigned I think 2-3 times. The one thing about google / GCP is that they are doing the initial R&D, but fail to follow - I.e. they expect the community to pick up. I assume that this can be attributed to the internal promotion cycle inside google (where engineers are expected to rotate), vs tech reason.
3. Of course kubernetes will be maintained by on perm companies (e.g. VMWARE/IBM). The predecessor to kubernetes was open stack, which was also developed by on perm hardware companies (e.g. CISCO / HP). You still need money to pay engineers.
Moreover, I think that you are missing the key attributes of kubernetes, which morphed from its original goals. Kubernetes is about 3 things:
1. Scalability - you can run it on you laptop or IOT device up to the cloud (e.g. k3s).
2) Distribution - Kubernetes as a platform is permission-less and widely spread. I.e. If you want to extend it or develop on it, you do not need anyone permission, and you can assume that it would exist on your customer cluster. It is my belief that AWS have about 5% of IT workload, and is hitting a wall (see the latest sessions on AWS conference, which is catering to more legacy companies).
3) Automatic operation - Kubernetes control loop allow machines to manage machines (both software and hardware). I.e the carrot of the cloud is offloading management of your infra. The stick is that you pay 20x more on your hardware. Kubernetes give you another way - which is encapsulate the IT knowledge in a automatic robots - called operators, and let those manage your application. The problem is that this feature is not widely known. (and it is my goal to change that).