Live data from Hacker News

Kubernetes Documentary: A Critical Review

cloudcritical.org

41–50 of 131 posts

Re: Kubernetes Documentary: A Critical Review

#41
post #36
post #28

Earlier quoted context omitted.

>You pick and choose the CPU/GPU horsepower, memory, storage type and storage class, You still do with kubernetes > network transfer speed, and many other things. No, you don't. There's no slider for "network performance" on GCP, Azure or AWS.

Network performance is tied to the instance type on GCP, AWS and presumably Azure.

But there’s no slider. Typically you slide the instance size for other reasons.

Here’s the thing: either you care about it (and you can game the sizing of the instance) or you dont and you run kubernetes.

But you if you don’t care then it doesn’t matter. There’s no slider for you to care about. It is not extra overhead.

Re: Kubernetes Documentary: A Critical Review

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

Re: Kubernetes Documentary: A Critical Review

#43
post #13

Earlier quoted context omitted.

Why? Our field is plagued by Authority Bias and this is one fine example. “You should, in science, believe logic and arguments, carefully drawn, and not authorities.” [1] [1] https://twitter.com/anammostarac/status/1495594139865731074

But that's exactly my point, Kris carefully draws her arguments. Which is what gives her her authority, not the other way around.

I think it's fair to call it a clusterfuck with skin in the game.

Re: Kubernetes Documentary: A Critical Review

#44
post #4

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

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.

Re: Kubernetes Documentary: A Critical Review

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

Re: Kubernetes Documentary: A Critical Review

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

Re: Kubernetes Documentary: A Critical Review

#47

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 mechani…

I think they put the word Critical in there because it is the name of the website.

Re: Kubernetes Documentary: A Critical Review

#48

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 mechani…

[deleted]

Re: Kubernetes Documentary: A Critical Review

#49

Earlier quoted context omitted.

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.

That's true, but not a particularly interesting fact. For example, if you use GKE (Google Cloud's K8s offering), you attach your K8s cluster to an auto-scaling node pool and it handles (de)provisioning of your VMs for you. You essentially don't care about the VMs, there's essentially no overhead. If you are in a private cloud, this also creates a good "API boundary" between the team responsible for running hardware,…

I would say it is an interesting fact, since it's this "good 'API boundary'" that, as you said, enables one to separate concerns, be it between different teams in an organisation or between a service provider and its users.

Yes, you don't need Kubernetes to come up with your own implicit or explicit API boundaries, and these might not be needed for smaller projects. I agree that Kubernetes is often used where it's not strictly needed.

There are things which strict abstraction, and with it, separation of concerns provide. The crucial point is that certain things are enforced.

Re: Kubernetes Documentary: A Critical Review

#50
post #22

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 pro…

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

Post reply on HN