Kubernetes is a red flag signalling premature optimisation • Hacker News Board

Re: Kubernetes is a red flag signalling premature optimisation

#61

Post by jsiepkes » Mon, Jul 04, 2022, 8:54 AM UTC

Izkata wrote: post #54

pjmlp wrote: post #20

Earlier quoted context omitted.

Its seems to be a new thing with younger generations. We never had an issue with multiple languages across tier-n architectures. Suddenly with the uptake of HTML 5, it became an issue not being able to use JavaScript everywhere.

The impression I've gotten from some of my co-workers is that in bootcamps and college they only learned one language, remember the time and effort that went into that, and assume learning another language will take the same time and effort. Because they haven't really put effort into a second one, they don't yet realize just how much conceptually transfers between the languages.

While concepts transfer over between languages the language is only 10% of it. The rest of it is the standard library, ecosystem, buildsystem and all kinds of intricacies you have to know about and what not which is specific to the language (ecosystem).

Re: Kubernetes is a red flag signalling premature optimisation

#62

Post by iostream24 » Mon, Jul 04, 2022, 8:56 AM UTC

“So you want to run a bunch of stuff on one computer, why?”

In a quest to get closer to the metal, Kubernetes keeps you far away, which is the opposite of what any production service should want.

What is the purpose of adding layers when uni-kernels and eco-kernels give you better isolation and better performance?

Your cloud provider already runs your virtual machines OS on a hardware hypervisor. Then running Kubernetes on top of the OS and then a zillion containers on it is a recipe for poor performance.

What is the logic here that I am clearly missing?

Cloud providers native Kubernetes stacks don’t improve performance or pricing, compared to their cloud compute instances virtual machines and a dedicated virtual machine per would-be-container that thankfully doesn’t need to now share processing resources with others.

What gives? Why on earth would anyone run production processes in Kubernetes?

Re: Kubernetes is a red flag signalling premature optimisation

#63

Post by glintik » Mon, Jul 04, 2022, 8:58 AM UTC

I can understand developers and devops - overengineering allows them to play with technologies for company money. Tech managers should control level of overengineering, but in many cases they just miss..

Re: Kubernetes is a red flag signalling premature optimisation

#64

Post by roenxi » Mon, Jul 04, 2022, 8:58 AM UTC

lmm wrote: post #27

ale42 wrote: post #17

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance…

> It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. But the overwhelming majority of the time you don't need it, at least not yet. I would say that unless you have actual evidence that your other language would not be adequate - i.e. an implementation of your system or some representative subset of it, in your main language, that you spen…

The experts in how to profile/optimize/etc a system aren't going to be JS devs though. They're going to be people who are used to dealing with systems that need to be written in languages from the machine-code-compiled lineage.

Which is to say ... while JS developers do know how to profile code, people who are routinely exposed to this problem are not going to be JS developers. The people who are good at identifying when a system needs to be re-written in Go for performance reasons are probably already Go developers and people who have lots of experience writing performant code.

Plus writing in that sort of language from the start means there is a chance to segue into performant code without needing to rewrite things in a new language.

Re: Kubernetes is a red flag signalling premature optimisation

#65

Post by gjulianm » Mon, Jul 04, 2022, 8:59 AM UTC

supermatt wrote: post #58

I don’t get these complaints AT ALL. I don’t use kubernetes, simply because I am running apps in managed environments, and have been using docker-compose with vscode remote to emulate those environments. But being able to define your resources and how they are linked via a schema, makes sense even from a dev perspective. Isn’t that all that kubernetes is doing at it’s most basic? Sounds like that saves time to me ove…

From what I've seen with Kubernetes, the problem is that in order to define the resources and links with a schema, it needs several abstractions and extra tooling. So you not only need to define the schema (which isn't that trivial) but also understand what Kubernetes does, how to work with it, and how to solve problems. It's a tool that adds complexity and difficulty, if you're not using the advantages it provides (mainly multi-node management and scale capabilities) you're just handicapping yourself.

Re: Kubernetes is a red flag signalling premature optimisation

#66

Post by varispeed » Mon, Jul 04, 2022, 8:59 AM UTC

ale42 wrote: post #17

Why should using different languages for front-end and back-end be a problem? I rather think that it is better to use languages that are appropriate for the given problem. It is not premature optimization to have parts of a back-end implemented in C/C++/Go/whatever else if high performance is needed. It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance…

> It would rather be a waste of resources, money and energy not to use an high-performance language for high-performance applications.

Given that probably most developers support the push to tackle the climate change, they seem to be making no effort to ensure their apps execute in as short time as possible using as little resources as possible. You would expect that people would actually embrace doing things in C or Go to save energy. Maybe cloud providers should think of showing the carbon footprint as a first class performance metric.

Re: Kubernetes is a red flag signalling premature optimisation

#67

Post by wronglyprepaid » Mon, Jul 04, 2022, 8:59 AM UTC

mattbillenstein wrote: post #3

In the limit, there are some startups that could run production on a single Linux host - I recently helped one get off Heroku and their spend went from ~$1k/mo to ~$50/mo and it made debugging and figuring out performance issues so much easier than what they were doing previously...

> In the limit, there are some startups that could run production on a single Linux host

I guess redundancy is not really a thing then?

With serverless offerings you can get rather good deals, I don't think you need your own K8S cluster if you can get away with a single Linux host, but a single Linux host is pretty pricey maintenance wise compared to google Cloud Spanner and cloud run.

Re: Kubernetes is a red flag signalling premature optimisation

#68

Post by cutler » Mon, Jul 04, 2022, 9:00 AM UTC

Same for Docker.

Re: Kubernetes is a red flag signalling premature optimisation

#69

Post by amirteshome » Mon, Jul 04, 2022, 9:00 AM UTC

Docker Swarm Rocks " .... I would recommend for teams of less than 200 developers, or clusters of less than 1000 machines.

This includes small / medium size organizations (like when you are not Google or Amazon), startups, one-man projects, and "hobby" projects. " https://dockerswarm.rocks/

Re: Kubernetes is a red flag signalling premature optimisation

#70

Post by imjonse » Mon, Jul 04, 2022, 9:02 AM UTC

When I see k8s I automatically think o13g due witnessing it being tried a couple of times for the coolness factor, not because it was actually required.