I'm not sure this was authored in full good faith. Things like dismissing Kubernetes attempts to "abstract away the servers" as being pointless because we already had virtualisation is at best ignorance of the differences, and at worst, gaslighting.<p>It's clear that the author doesn't like Kubernetes, and to be honest this documentary is unlikely to change their mind because they are not the target audience.<p>All the "criticism" about Kubernetes being a Google strategy could well be valid, but it's not exactly new, unique, or particularly impactful here.<p>(Disclaimer, I work at Google, nothing to do with cloud/k8s)
Slightly biased?<p>This is the way they present the extract of the dotScale conference in this K8s documentary:<p><a href="https://youtu.be/BE77h7dmoQU?t=185" rel="nofollow">https://youtu.be/BE77h7dmoQU?t=185</a><p>And the source media:<p><a href="https://youtu.be/3N3n9FzebAA?t=30" rel="nofollow">https://youtu.be/3N3n9FzebAA?t=30</a><p>They've altered the quality of the audio and video to make it look old. They even cropped it to 4:3! This is preposterous.
The one thing I did not appreciate with the documentary was how "historic" footage was edited to be 4:3 aspect ratio with artificial grain. This made it look like these segments were filmed in the 90's rather than 2013. I can understand how this can emphasise the difference between footage shot now and 9 years ago, but it made the documentary feel inauthentic somehow.
I find ‘heterodox blogger’ to be one of the more annoying business personas.<p>When I had to work at IBM in the early 2000s because of an acquisition, we met a lot of ‘corporate edgelords’ whose personal brand was built on eloquently explaining to IBM audiences how every cloud computing innovation coming out of West Coast tech companies already existed on the mainframe since the 1970s, and was therefore stupid to invest in. Their big closer was usually some version of how ‘Silicon Valley is so far behind IBM they think they’re ahead’.<p>These were the same guys who ran Lotus Domino in their home lab for fun because gmail was stupid.<p>Very tedious.
> especially [a code base] as shit as Kubernetes<p>I completely agree that Kubernetes is best understood through the lens of Google's corporate interests. But 1. resorting to language like "shit" makes me question the writer's credentials and reliability and 2. the code base may not be exemplary but its quality is far from belonging to the poorer end of the known spectrum.
On one side there are the Kubernetes corporate enthusiasts that are probably exactly doing what this post i saying: try to remove the advantage that AWS has over all the other vendors. On the other, we are also plagued by AWS shills/fanbase that hate Kubernetes exactly because of that (they are trying to push you toward serverless with Lambda). In the middle ground there is probably the truth, where AWS had a programmatic API that enabled automation for years, and that Kubernetes *is* hip, it adds even more automation to the game and helps attracting/retaining talent in the current hot market. But technically you could totally have a working startup, mid-size or big company without using Kubernetes.
I think the format of this review is rather strange, a little hard to get into. Coming from the humanities, when I think "critical review" I think a wholistic and encompassing argument about the foundations of the subject, and it is not determining of whether the writer is going to critique the subject at hand, or agree with it. Examples and textual analysis are used carefully in order to speak to the grander mechanism and assumptions at play.<p>This feels more like MST3K than any kind of critical review of the subject. The author is passionate and has a lot to say, thats for sure, but I see little substance here beyond definite wit.
> It also makes me think if OSS is created solely to promote profit margins, is that really good OSS, or just a tactic to wrap strategy in a thin veneer of altruism?<p>Is that not a false dichotomy?<p>Kubernetes could promote profit margins for Google whilst simultaneously being good for OSS.<p>Sure, if Kubernetes was touted purely as being about what's good for OSS, then that would be disingenuous. But throughout the documentary they allude to Google wanting to look after its bottom line.<p>So for me personally, I think that the quoted passage above (and several other parts of the write-up) are a tad biased.<p>Interesting read nonetheless.
Yes, I agree. I wrote this years ago: <a href="https://www.quora.com/Why-did-Google-make-highly-valuable-proprietary-technology-like-TensorFlow-and-Kubernetes-public-and-available-to-competitors-as-open-source-even-though-it-still-mainly-funds-and-does-the-vast-majority-of-continued/answer/Thomas-A-Limoncelli?ch=17&oid=103210847&share=acd19668&srid=h8ML&target_type=answer" rel="nofollow">https://www.quora.com/Why-did-Google-make-highly-valuable-pr...</a>
Its just a very bad and uneducated stand from some person.<p>I'm running a small k8s instance at home, for a small startup and at my job in a big version.<p>Abstraction of VMs is a real benefit: Have you ever had to restart a VM because of some security issues? Yes? Were you worried that your server comes up again?<p>With k8s, you know that 1. its cloud native to a certain extend. It will come up again because it came up before. 2. you have more nodes available. Either to surge or because you have more than just one node running.<p>Your pod will be scheduled away from your node, thats it.<p>you have a very stable and smart abstraction layer for sooo many features you get as soon as you configure them ONCE centrally:<p>- LoadBalancing<p>- certificate management<p>- Volume abstraction -> making snapshots from your PV? yes!<p>- Rollout strategies<p>- health checks (readiness and liveness probes)<p>- declaritive style (setup a prometheus, every service can be autoscraped due to convetion over configuration)<p>- Certified opensource abstraction layer! (get yourself a certified k8s distribution and stop worrying about vendor lock in)<p>- Unified setup for plenty of apps (monitoring, logging, app store, tracing, storage systems, iam etc. etc. etc.) We had deb before and rpm and whatnot. Now you have a helm chart for a certified k8s platform)<p>- Already quite small -> there is k3s. ubuntu supports it also with not that much overhead<p>- IaC as first class citizen. Due to k8s being declarative, IaC is much easier than it was before.<p>- FOSS<p>- Central easy policy implementation and management. Write your central policies, allow your teams to manage their own namespace and make sure to allow only certain registries etc.<p>- ArgoCD / GitOps (a dream come true srsly!)<p>I cant understate how much i love k8s and how much better it is then everything i have seen before. This is the main reason why i even spend the time writing here because that çritical review' is just utterly bullshit.<p>Did we had similiar things somehow before? yes. So whats new on k8s? K8s unites across companies and just drives this further. For me k8s is the winner of this race which happened in parallel (mesos, docker, nomad etc. etc.)
A bulk of this criticism seems to rely on the author's understanding that somehow Google app engine and AWS were competitors before Google seriously realised that AWS was a high margin business that was bankrolling all of Amazon.<p>I remember those days and Google app engine was trying to compete with Heroku.<p>Google is also known to exist in markets in the form of 20% projects and not take put serious muscle behind those efforts: Take Orkut vs Facebook as an example vs the Google+ effort in 2010-11 when Facebook seemed like it was going to eat the world.<p>The documentary's narrative seems more accurate.
I agree with the take, but I don't think it's a bad thing. Sometimes you want to abstract away the cloud provider and you are willing to pay the price for that abstraction. Sometimes it's easier/simpler to duplicate a bit more know-how and code.<p>In terms of consumers Kubernetes may have saved the cloud from becoming an AWS monopoly the way the PC got coupled to Microsoft Windows and Office.<p>Previously every Cloud provider no matter how small had their copy of EC2,IAM,VPC,S3,ELB and such, but struggled copying the dosens of other commonly used services. It is kind of like the saying that everyone uses 20% of Excels features, but for each user is a different 20%, and you want to keep your options open. Or you are fine with running Linux, but you need this one app that doesn't work on it.<p>Now all the minor clouds need to catch up is to add Managed Kubernetes and they are competitive with AWS. And vendors like VMWare can also hop on the bandwagon without having to deal with AWS.
As a freelancer focusing on k8s, and who has quite a few clients running OpenShift on-prem or outside of cloud providers, his analysis of RedHat's need for OpenShift shows he does not understand RedHat's biggest customers.<p>They run OpenShift because they want Kubernetes with it's organisational advantages on-prem, while having the support they're used to. With the exception of Azure, none of the cloud providers can offer this.<p>RedHat saw this coming, and understood that if k8s became big in the cloud-space, someone needed to address that enterpricy market. If they could get there first, AND at the same time put a second big name behind this new tech giving it more viability, it also gave them more push.<p>But then again, the rest of the article showed the author understands very little of Kubernetes at all.
I'm surprised that neither the documentary nor the review gets into the legacy of OpenStack. I may be biased, but it seems to me that a huge amount of the success of kubernetes is directly attributable to OpenStack.<p>First, OpenStack paved the way for a bunch of companies to invest real money in working together to compete with AWS. Second, there was massive turnover in ~2013 in open source contributors from OpenStack to Kubernetes. I wouldn't be surprised if a good 50% of the kubernetes community was inherited directly from OpenStack.
I regularly listen to the kubernetes podcast run by Google employees. Through time and through various guest interviews I've gotten the impression that some (most?) who created borg/kubernetes did basically all of the work that Docker did creating containers but are upset Docker has all that recognition. I can't quite articulate it but it seems like the Googlers are super judgmental and want to snub their noses at Docker.
> I feel like we were all talking about microservices, and chaos engineering, I personally wanted decent service discovery (I still do).<p>One day a startup will bring CORBA Name Service or Web Service Repository, in yaml, and it will be great.