13 ms·

Kubernetes Documentary: A Critical Review

117 points by riccardomc 5y ago

TheUndead96 5y ago
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.
tandymodel100 5y ago
fguerraz 5y ago
Slightly biased? This is the way they present the extract of the dotScale conference in this K8s documentary: https://youtu.be/BE77h7dmoQU?t=185 https://youtu.be/BE77h7dmoQU?t=185 And the source media: https://youtu.be/3N3n9FzebAA?t=30 https://youtu.be/3N3n9FzebAA?t=30 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.
- jobegrabber 5y ago
  I mean, the title of the website is "Cloud Critical - Your service mesh is garbage". And the author says >No critical conversations about Kubernetes are taking place, aside from outspoken critics on HackerNews or Slashdot, but those are few and far between. The author's agenda is about highlighting that "Kubernetes is not a good solution for most if not all cloud deployments". I'd say there's quite a decent chance that bias is involved. At least a chance bigger than Kubernetes not being a good solution for any cloud deployment. I don't think anyone is arguing that Kubernetes is the best solution for all cloud deployments. From my POV it might not even be the best solution for most cloud deployments. But I think there's bias involved if one is even considering the possibility that Kubernetes is always a bad solution. Regarding modifying the source material and cropping it to 4:3, that's something I find odd as well and I personally find is not fitting.
  - Eritico 5y ago
    I actually believe that the k8s api could be the best abstraction for services we ever had. While i'm running k3s at home (which is very nice to be honest) and big instances at work, i would prefer to have more managed k8s offerings but many already exist. They exist from DigitalOcean, Google, Azure, AWS and its probably way easier for smaller service providers to make a managed solution available. You can also use rancher or gardener to create and manage k8s clusters 'raw' by yourself.
    - horsawlarway 5y ago
      I'm with you. Even for tiny personal deployments, I find it a very compelling experience (I'm running micro-k8s at home). With just a little bit of setup (configuring NAS storage, handing MetalLB an ip range, and installing cert-manager) I get a setup that is robust to any single machine failure (I run a 3 node system on old desktops/laptops), handles a bunch of previously manual tasks (backups, cert updates, auto-restarts) and gives me a wonderful host of tools I now use for personal projects, such as - CI/CD (DroneCi) - Private docker registry (Registry:2) - Dashboard for service availability (kubernetesui/dashboard) - A TON of personal hosted projects and tools (from bookstack to jellyfin to whatever project I'm working on now) And for the most part - I just don't have to think about it all that much. Sure, the initial setup took a few hours. But I've torn down and rebuilt the entire thing from scratch in less than an hour from backups, and my README for "starting with nothing but a blank disk in an old machine to fully functional" is about 2 pages long, and the vast majority of it is local router config and DNS entries (still manual). I'm easily replacing hundreds of dollars a month in SaaS/Cloud charges with it, and it's still just not taking up all that much of my time.
  - goodpoint 5y ago
    > No critical conversations about Kubernetes are taking place And this is spot on.
tombh 5y ago
> especially [a code base] as shit as Kubernetes 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.
- politelemon 5y ago
  "Shit" is so commonly used in developer/tech circles that I'm more surprised someone would zero in and take issue with it. I would not question their credentials and reliability over a word.
  - jobegrabber 5y ago
    > I would not question their credentials and reliability over a word In more or less informal discussions, I agree. From my POV it's not about a singular word though, it's about the context: The author labelled the (entire) code base of Kubernetes as "shit": >[...] forking a large code base, especially one as shit as Kubernetes, and still getting community support can be daunting without some sort of titanic change in the market. It's not that it's not "nice" language, it's about the statement. It could very well be that the code base of Kubernetes is in a bad state, but with this wording and without any references, it doesn't come off as neutral or particularly reasonable.
- hughrr 5y ago
  Agree with this. I've had to delve into the guts of Kubernetes and it's not perfect for sure but far better than the crap we deploy onto it :)
- arianvanp 5y ago
  Given that contributors have been referring to the kubernetes codebase as "the clusterfuck" in talks I think it's fine to say "shit". https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://archive.fosdem.org/2019/schedule/event/kubernetesclu... It's a great talk to figure out how the kubernetes codebase works
YesThatTom2 5y ago
Yes, I agree. I wrote this years ago: 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 https://www.quora.com/Why-did-Google-make-highly-valuable-pr...
sovietmudkipz 5y ago
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.
- goodpoint 5y ago
  Most of the heavy lifting to implement containers was done by the kernel developer community and projects like LXC. Yet, docker and kubernetes are very much hype/marketing driven and took away a lot of recognition from the kernel developers.
  - mohanmcgeek 5y ago
    > kernel developer community This effort was funded in part by Google.
    - vinceguidry 5y ago
      funded != did the work
      - ecnahc515 5y ago
        The developers who implemented cgroups worked at Google and upstreamed them.
      - mohanmcgeek 5y ago
        The kernel is developed by Linux foundation and a variety of companies that have a vested interest in Linux like Intel, AMD, SUSE, RedHat, Google, Canonical. It's not a team of volunteers like it's popularly portrayed. The foundation itself is also primarily funded by such companies.
        5y ago
danpalmer 5y ago
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. 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. All the "criticism" about Kubernetes being a Google strategy could well be valid, but it's not exactly new, unique, or particularly impactful here. (Disclaimer, I work at Google, nothing to do with cloud/k8s)
- jasonrichardsmi 5y ago
  Hi danpalmer, I kind of hit on this in the article. How do you think abstracting away the server adds any value in "public cloud"? Where you can get bespoke VMs, with no concern for the underlying hardware? Can you elaborate?
  - charcircuit 5y ago
    I think part of the confusion is that server can refer to both a physical box and a VM. Abstracting away servers is about not having to think about VMs. You have a service which requires some amount of compute, memory, and storage and you just want that service to run. There is value to not having to worry about provisioning a VM or administering it.
    - jasonrichardsmi 5y ago
      But you still have to do that in Kubernetes, unless you are running Fargate. Someone has to provision and maintain that machine, and in the process introduce a ton of administrative overhead.
      - deleted 5y ago
        [deleted]
      - deleted 5y ago
        [deleted]
dimitar 5y ago
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. 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. 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. 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.
- jen20 5y ago
  > Now all the minor clouds need to catch up is to add Managed Kubernetes and they are competitive with AWS. On one axis, perhaps. This is patently absurd though. "Minor" clouds still need a hypervisor and control plane, still need IAM, still need VPC-style networking, and still need load balancers and object storage to be technically competitive with AWS - just as a starting point. All Kubernetes means here is that there is a common API style for these things.
DonHopkins 5y ago
The K8S took my server away They took her away Away from me [Apologies to The Ramones]
vishvananda 5y ago
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. 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.
- p_l 5y ago
  I suspect the documentary might have not wanted to thrash talk OpenStack. Let's be honest, a non trivial push for k8s was just how badly Open Stack sucked
pjmlp 5y ago
> I feel like we were all talking about microservices, and chaos engineering, I personally wanted decent service discovery (I still do). One day a startup will bring CORBA Name Service or Web Service Repository, in yaml, and it will be great.
beepbooptheory 5y ago
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. 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.
- 0des 5y ago
  I think they put the word Critical in there because it is the name of the website.
  - beepbooptheory 5y ago
    Ah.. My bad I did not get that, I guess then this is merely an issue of semantic overlap then. Either way I get that I was pendantic.
    - jobegrabber 5y ago
      Even with a CS background, I would expect a blog post that is supposed to be a "A Critical Review" to at least try to be fair and reasonable. It doesn't have to be neutral in my opinion. But it should clearly separate personal judgement or opinion from facts and overall rational. In the "About me" section the author says: >Originally I started this site attacking the big corporate interests (Google, IBM and VMWare) that drove this effort forward, but that really doesn’t speak to my intended audience. It also came off as acerbic, which I am fine with in regards to corporations and their CEOs, it does not do justice to all the engineers that slaved over the Kubernetes project. So I deleted those posts. Now, I just want to start, provoke, prod, or push a dialog forward, because if you just follow the tech blogs, you would think we should be running a Kubernetes cluster on our lawn mowers. Even if the blog is not about simply "attacking the big corporate interests" anymore, the language clearly puts forward the post's agenda. In my opinion, the post should have a different title, one that is clearly indicating the author's intention to highlight the negative things about Kubernetes and the documentary.
mohanmcgeek 5y ago
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. I remember those days and Google app engine was trying to compete with Heroku. 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. The documentary's narrative seems more accurate.
- jasonrichardsmi 5y ago
  Google released VMs in 2013, the year of this documentary, which means they were working on it for some time prior to this discussion.
  - mohanmcgeek 5y ago
    The tipping point was NASA dropping out of openstack to sign a contract with AWS. You should checkout Azure presentations from 2012 to find out how nobody saw the "cloud" coming. Kubernetes was a very effective strategy to make AWS knowledge irrelevant by providing a layer on top/alternative interface and it succeeded. Obviously AWS consultants would hate it for it.
darkwater 5y ago
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.
- nostrebored 5y ago
  I don’t think k8s is the draw that you say it is. Anecdotally my wife and I heavily penalize jobs that have migrated from serverless to k8s. My current work uses kubernetes but it’s a step in the right direction from where they were before.
- zozbot234 5y ago
  > they are trying to push you toward serverless with Lambda With bare metal code written in modern memory-safe languages, serverless/FaaS could easily become a cross-cloud abstraction much like k8s. AIUI, there are already some experiments along these lines. It turns out that the main cloud services differ slightly in how they account for resource utilization, etc. in serverless deployments, but not in a way that would make a cross-cloud abstraction useless.
crmd 5y ago
I find ‘heterodox blogger’ to be one of the more annoying business personas. 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’. These were the same guys who ran Lotus Domino in their home lab for fun because gmail was stupid. Very tedious.
- jasonrichardsmi 5y ago
  Sorry, I am not sure when heterodox is a good thing or bad thing. Maybe you could qualify that for me. Well Gmail is kinda stupid. I mean they are reading your emails.
  - deleted 5y ago
    [deleted]
  - rrdharan 5y ago
    They really aren’t.
    - jasonrichardsmi 5y ago
      https://policies.google.com/privacy#infocollect https://policies.google.com/privacy#infocollect "We also collect the content you create, upload, or receive from others when using our services. This includes things like email you write and receive, photos and videos you save, docs and spreadsheets you create, and comments you make on YouTube videos." Their words not mine.
      - joshuamorton 5y ago
        They have to to store it. Every third party email service collects the content you create, upload, or recieve. Even, under this definition, the "private" encrypted ones.
herodoturtle 5y ago
> 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? Is that not a false dichotomy? Kubernetes could promote profit margins for Google whilst simultaneously being good for OSS. 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. So for me personally, I think that the quoted passage above (and several other parts of the write-up) are a tad biased. Interesting read nonetheless.
- zozbot234 5y ago
  > Kubernetes could promote profit margins for Google whilst simultaneously being good for OSS. Yup, a typical "commoditize complements" dynamic. Google/Azure's cloud services do not implement AWS's existing API's and ways to interact with the platform, so they address this by making an alternative available.
  - herodoturtle 5y ago
    Yup 100%. Every couple of years I re-read Spolsky’s excellent article on this dynamic. For those that are curious: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
Eritico 5y ago
Its just a very bad and uneducated stand from some person. I'm running a small k8s instance at home, for a small startup and at my job in a big version. 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? 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. Your pod will be scheduled away from your node, thats it. you have a very stable and smart abstraction layer for sooo many features you get as soon as you configure them ONCE centrally: - LoadBalancing - certificate management - Volume abstraction -> making snapshots from your PV? yes! - Rollout strategies - health checks (readiness and liveness probes) - declaritive style (setup a prometheus, every service can be autoscraped due to convetion over configuration) - Certified opensource abstraction layer! (get yourself a certified k8s distribution and stop worrying about vendor lock in) - 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) - Already quite small -> there is k3s. ubuntu supports it also with not that much overhead - IaC as first class citizen. Due to k8s being declarative, IaC is much easier than it was before. - FOSS - 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. - ArgoCD / GitOps (a dream come true srsly!) 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. 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.)
- jasonrichardsmi 5y ago
  I am sorry you feel that way. The point of the article was not really attempting to address the feature sets of Kubernetes (which I also have issues with), it was really about the sales pitch being delivered by Google. I have A LOT of issues with the things you posted above, and I hope to address them in future articles. Stay tuned for more, and thanks for reading.
koffiezet 5y ago
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. 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. 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. But then again, the rest of the article showed the author understands very little of Kubernetes at all.
- jasonrichardsmi 5y ago
  https://www.infoworld.com/article/2626313/why-red-hat-should-fear-amazon-linux.html https://www.infoworld.com/article/2626313/why-red-hat-should... This was 2010, so I think I may understand better than you think.
  - mohanmcgeek 5y ago
    Except you don't. Openshift started as a paas that ran on... AWS.
    - freedomben 5y ago
      Disclaimer: Former Red Hat employee working on OpenShift Correct, OpenShift has been around longer than k8s. Red Hat identified that K8s was a remarkable platform for platforms, and rewrote OpenShift on top it. OpenShift is good on clouds, but the real shine is on-prem. For anybody with on-prem hardware, OpenShift gives you an abstraction that you can use to make it indistinguishable to your users where something is running. This means you can go cloud when scaling quickly is required, and you can build the foundation on-prem where you save a ton of money. The apps won't have to change at all (as long as they're using the OpenShift abstractions rather than say an EBS storage operator that requires AWS). Considering K8s (and/or OpenShift) only in a cloud context, is a huge error that will lead one to completely miss the "why" behind why they're so important.

117 points by riccardomc 5y ago

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.

tandymodel100 5y ago

fguerraz 5y ago

Slightly biased? This is the way they present the extract of the dotScale conference in this K8s documentary: https://youtu.be/BE77h7dmoQU?t=185 https://youtu.be/BE77h7dmoQU?t=185 And the source media: https://youtu.be/3N3n9FzebAA?t=30 https://youtu.be/3N3n9FzebAA?t=30 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.

jobegrabber 5y ago
I mean, the title of the website is "Cloud Critical - Your service mesh is garbage". And the author says >No critical conversations about Kubernetes are taking place, aside from outspoken critics on HackerNews or Slashdot, but those are few and far between. The author's agenda is about highlighting that "Kubernetes is not a good solution for most if not all cloud deployments". I'd say there's quite a decent chance that bias is involved. At least a chance bigger than Kubernetes not being a good solution for any cloud deployment. I don't think anyone is arguing that Kubernetes is the best solution for all cloud deployments. From my POV it might not even be the best solution for most cloud deployments. But I think there's bias involved if one is even considering the possibility that Kubernetes is always a bad solution. Regarding modifying the source material and cropping it to 4:3, that's something I find odd as well and I personally find is not fitting.
- Eritico 5y ago
  I actually believe that the k8s api could be the best abstraction for services we ever had. While i'm running k3s at home (which is very nice to be honest) and big instances at work, i would prefer to have more managed k8s offerings but many already exist. They exist from DigitalOcean, Google, Azure, AWS and its probably way easier for smaller service providers to make a managed solution available. You can also use rancher or gardener to create and manage k8s clusters 'raw' by yourself.
  - horsawlarway 5y ago
    I'm with you. Even for tiny personal deployments, I find it a very compelling experience (I'm running micro-k8s at home). With just a little bit of setup (configuring NAS storage, handing MetalLB an ip range, and installing cert-manager) I get a setup that is robust to any single machine failure (I run a 3 node system on old desktops/laptops), handles a bunch of previously manual tasks (backups, cert updates, auto-restarts) and gives me a wonderful host of tools I now use for personal projects, such as - CI/CD (DroneCi) - Private docker registry (Registry:2) - Dashboard for service availability (kubernetesui/dashboard) - A TON of personal hosted projects and tools (from bookstack to jellyfin to whatever project I'm working on now) And for the most part - I just don't have to think about it all that much. Sure, the initial setup took a few hours. But I've torn down and rebuilt the entire thing from scratch in less than an hour from backups, and my README for "starting with nothing but a blank disk in an old machine to fully functional" is about 2 pages long, and the vast majority of it is local router config and DNS entries (still manual). I'm easily replacing hundreds of dollars a month in SaaS/Cloud charges with it, and it's still just not taking up all that much of my time.
- goodpoint 5y ago
  > No critical conversations about Kubernetes are taking place And this is spot on.

tombh 5y ago

> especially [a code base] as shit as Kubernetes 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.

politelemon 5y ago
"Shit" is so commonly used in developer/tech circles that I'm more surprised someone would zero in and take issue with it. I would not question their credentials and reliability over a word.
- jobegrabber 5y ago
  > I would not question their credentials and reliability over a word In more or less informal discussions, I agree. From my POV it's not about a singular word though, it's about the context: The author labelled the (entire) code base of Kubernetes as "shit": >[...] forking a large code base, especially one as shit as Kubernetes, and still getting community support can be daunting without some sort of titanic change in the market. It's not that it's not "nice" language, it's about the statement. It could very well be that the code base of Kubernetes is in a bad state, but with this wording and without any references, it doesn't come off as neutral or particularly reasonable.
hughrr 5y ago
Agree with this. I've had to delve into the guts of Kubernetes and it's not perfect for sure but far better than the crap we deploy onto it :)
arianvanp 5y ago
Given that contributors have been referring to the kubernetes codebase as "the clusterfuck" in talks I think it's fine to say "shit". https://archive.fosdem.org/2019/schedule/event/kubernetesclusterfuck/ https://archive.fosdem.org/2019/schedule/event/kubernetesclu... It's a great talk to figure out how the kubernetes codebase works

YesThatTom2 5y ago

Yes, I agree. I wrote this years ago: 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 https://www.quora.com/Why-did-Google-make-highly-valuable-pr...

sovietmudkipz 5y ago

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.

goodpoint 5y ago
Most of the heavy lifting to implement containers was done by the kernel developer community and projects like LXC. Yet, docker and kubernetes are very much hype/marketing driven and took away a lot of recognition from the kernel developers.
- mohanmcgeek 5y ago
  > kernel developer community This effort was funded in part by Google.
  - vinceguidry 5y ago
    funded != did the work
    - ecnahc515 5y ago
      The developers who implemented cgroups worked at Google and upstreamed them.
    - mohanmcgeek 5y ago
      The kernel is developed by Linux foundation and a variety of companies that have a vested interest in Linux like Intel, AMD, SUSE, RedHat, Google, Canonical. It's not a team of volunteers like it's popularly portrayed. The foundation itself is also primarily funded by such companies.
      - 5y ago

danpalmer 5y ago

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. 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. All the "criticism" about Kubernetes being a Google strategy could well be valid, but it's not exactly new, unique, or particularly impactful here. (Disclaimer, I work at Google, nothing to do with cloud/k8s)

jasonrichardsmi 5y ago
Hi danpalmer, I kind of hit on this in the article. How do you think abstracting away the server adds any value in "public cloud"? Where you can get bespoke VMs, with no concern for the underlying hardware? Can you elaborate?
- charcircuit 5y ago
  I think part of the confusion is that server can refer to both a physical box and a VM. Abstracting away servers is about not having to think about VMs. You have a service which requires some amount of compute, memory, and storage and you just want that service to run. There is value to not having to worry about provisioning a VM or administering it.
  - jasonrichardsmi 5y ago
    But you still have to do that in Kubernetes, unless you are running Fargate. Someone has to provision and maintain that machine, and in the process introduce a ton of administrative overhead.
    - deleted 5y ago
      [deleted]
    - deleted 5y ago
      [deleted]

dimitar 5y ago

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. 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. 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. 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.

jen20 5y ago
> Now all the minor clouds need to catch up is to add Managed Kubernetes and they are competitive with AWS. On one axis, perhaps. This is patently absurd though. "Minor" clouds still need a hypervisor and control plane, still need IAM, still need VPC-style networking, and still need load balancers and object storage to be technically competitive with AWS - just as a starting point. All Kubernetes means here is that there is a common API style for these things.

DonHopkins 5y ago

The K8S took my server away They took her away Away from me [Apologies to The Ramones]

vishvananda 5y ago

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. 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.

p_l 5y ago
I suspect the documentary might have not wanted to thrash talk OpenStack. Let's be honest, a non trivial push for k8s was just how badly Open Stack sucked

pjmlp 5y ago

> I feel like we were all talking about microservices, and chaos engineering, I personally wanted decent service discovery (I still do). One day a startup will bring CORBA Name Service or Web Service Repository, in yaml, and it will be great.

beepbooptheory 5y ago

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. 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.

0des 5y ago
I think they put the word Critical in there because it is the name of the website.
- beepbooptheory 5y ago
  Ah.. My bad I did not get that, I guess then this is merely an issue of semantic overlap then. Either way I get that I was pendantic.
  - jobegrabber 5y ago
    Even with a CS background, I would expect a blog post that is supposed to be a "A Critical Review" to at least try to be fair and reasonable. It doesn't have to be neutral in my opinion. But it should clearly separate personal judgement or opinion from facts and overall rational. In the "About me" section the author says: >Originally I started this site attacking the big corporate interests (Google, IBM and VMWare) that drove this effort forward, but that really doesn’t speak to my intended audience. It also came off as acerbic, which I am fine with in regards to corporations and their CEOs, it does not do justice to all the engineers that slaved over the Kubernetes project. So I deleted those posts. Now, I just want to start, provoke, prod, or push a dialog forward, because if you just follow the tech blogs, you would think we should be running a Kubernetes cluster on our lawn mowers. Even if the blog is not about simply "attacking the big corporate interests" anymore, the language clearly puts forward the post's agenda. In my opinion, the post should have a different title, one that is clearly indicating the author's intention to highlight the negative things about Kubernetes and the documentary.

mohanmcgeek 5y ago

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. I remember those days and Google app engine was trying to compete with Heroku. 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. The documentary's narrative seems more accurate.

jasonrichardsmi 5y ago
Google released VMs in 2013, the year of this documentary, which means they were working on it for some time prior to this discussion.
- mohanmcgeek 5y ago
  The tipping point was NASA dropping out of openstack to sign a contract with AWS. You should checkout Azure presentations from 2012 to find out how nobody saw the "cloud" coming. Kubernetes was a very effective strategy to make AWS knowledge irrelevant by providing a layer on top/alternative interface and it succeeded. Obviously AWS consultants would hate it for it.

darkwater 5y ago

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.

nostrebored 5y ago
I don’t think k8s is the draw that you say it is. Anecdotally my wife and I heavily penalize jobs that have migrated from serverless to k8s. My current work uses kubernetes but it’s a step in the right direction from where they were before.
zozbot234 5y ago
> they are trying to push you toward serverless with Lambda With bare metal code written in modern memory-safe languages, serverless/FaaS could easily become a cross-cloud abstraction much like k8s. AIUI, there are already some experiments along these lines. It turns out that the main cloud services differ slightly in how they account for resource utilization, etc. in serverless deployments, but not in a way that would make a cross-cloud abstraction useless.

crmd 5y ago

I find ‘heterodox blogger’ to be one of the more annoying business personas. 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’. These were the same guys who ran Lotus Domino in their home lab for fun because gmail was stupid. Very tedious.

jasonrichardsmi 5y ago
Sorry, I am not sure when heterodox is a good thing or bad thing. Maybe you could qualify that for me. Well Gmail is kinda stupid. I mean they are reading your emails.
- deleted 5y ago
  [deleted]
- rrdharan 5y ago
  They really aren’t.
  - jasonrichardsmi 5y ago
    https://policies.google.com/privacy#infocollect https://policies.google.com/privacy#infocollect "We also collect the content you create, upload, or receive from others when using our services. This includes things like email you write and receive, photos and videos you save, docs and spreadsheets you create, and comments you make on YouTube videos." Their words not mine.
    - joshuamorton 5y ago
      They have to to store it. Every third party email service collects the content you create, upload, or recieve. Even, under this definition, the "private" encrypted ones.

herodoturtle 5y ago

> 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? Is that not a false dichotomy? Kubernetes could promote profit margins for Google whilst simultaneously being good for OSS. 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. So for me personally, I think that the quoted passage above (and several other parts of the write-up) are a tad biased. Interesting read nonetheless.

zozbot234 5y ago
> Kubernetes could promote profit margins for Google whilst simultaneously being good for OSS. Yup, a typical "commoditize complements" dynamic. Google/Azure's cloud services do not implement AWS's existing API's and ways to interact with the platform, so they address this by making an alternative available.
- herodoturtle 5y ago
  Yup 100%. Every couple of years I re-read Spolsky’s excellent article on this dynamic. For those that are curious: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/ https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

Eritico 5y ago

Its just a very bad and uneducated stand from some person. I'm running a small k8s instance at home, for a small startup and at my job in a big version. 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? 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. Your pod will be scheduled away from your node, thats it. you have a very stable and smart abstraction layer for sooo many features you get as soon as you configure them ONCE centrally: - LoadBalancing - certificate management - Volume abstraction -> making snapshots from your PV? yes! - Rollout strategies - health checks (readiness and liveness probes) - declaritive style (setup a prometheus, every service can be autoscraped due to convetion over configuration) - Certified opensource abstraction layer! (get yourself a certified k8s distribution and stop worrying about vendor lock in) - 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) - Already quite small -> there is k3s. ubuntu supports it also with not that much overhead - IaC as first class citizen. Due to k8s being declarative, IaC is much easier than it was before. - FOSS - 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. - ArgoCD / GitOps (a dream come true srsly!) 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. 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.)

jasonrichardsmi 5y ago
I am sorry you feel that way. The point of the article was not really attempting to address the feature sets of Kubernetes (which I also have issues with), it was really about the sales pitch being delivered by Google. I have A LOT of issues with the things you posted above, and I hope to address them in future articles. Stay tuned for more, and thanks for reading.

koffiezet 5y ago

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. 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. 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. But then again, the rest of the article showed the author understands very little of Kubernetes at all.

jasonrichardsmi 5y ago
https://www.infoworld.com/article/2626313/why-red-hat-should-fear-amazon-linux.html https://www.infoworld.com/article/2626313/why-red-hat-should... This was 2010, so I think I may understand better than you think.
- mohanmcgeek 5y ago
  Except you don't. Openshift started as a paas that ran on... AWS.
  - freedomben 5y ago
    Disclaimer: Former Red Hat employee working on OpenShift Correct, OpenShift has been around longer than k8s. Red Hat identified that K8s was a remarkable platform for platforms, and rewrote OpenShift on top it. OpenShift is good on clouds, but the real shine is on-prem. For anybody with on-prem hardware, OpenShift gives you an abstraction that you can use to make it indistinguishable to your users where something is running. This means you can go cloud when scaling quickly is required, and you can build the foundation on-prem where you save a ton of money. The apps won't have to change at all (as long as they're using the OpenShift abstractions rather than say an EBS storage operator that requires AWS). Considering K8s (and/or OpenShift) only in a cloud context, is a huge error that will lead one to completely miss the "why" behind why they're so important.