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

Re: Kubernetes is a red flag signalling premature optimisation

#71

Post by jpgvm » Mon, Jul 04, 2022, 9:03 AM UTC

maverwa wrote: post #42

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.

I think the argument was/is not "its a problem we cannot have javascript" but "if we can have javascript everywhere, we only need to hire javascript devs and only need to care about javascript tooling", which is a fair point. That does ignore the fact that an experienced frontend JS dev is not necessarily also a good productive backend JS dev, but at least they know the language basics, can use the same IDE, etc. If…

I think this has been a huge failing of our industry of late.

The rise of the "fullstack developer" has mostly reduced quality across the board. When you hire a "fullstack developer with 5 years experience" you aren't getting someone who is as good as a frontend developer with 5 years AND a backend developer with 5 years but someone that adds up to 5 years split between those 2 endeavors but probably with less depth as a result of switching.

(as a side note I also think it's contributed to developer title inflation)

Learning a new language and its tooling is comparatively easy compared to learning the required domain knowledge to be effective in a new area. i.e transition from frontend -> backend or visa versa has very little to do with the language or tooling.

Your average frontend dev doesn't know squat about RDBMS schema design or query optimisation, probably aren't familar with backend observability patterns like logging, metrics and tracing, most likely have very little experience thinking about consistency and concurrency in distributed systems, etc, etc.

Just like the backend dev is going to struggle with the constraints of working in a frontend context, understanding UI interactions, optimizing for browser paint performance, dealing with layout and responsiveness, etc.

Meanwhile if you know say Java and some scripting language, say Python and you end up a new job doing backend in JS it's not going to take long for you to pick up JS and hit the ground running because you are going to encounter exactly the same stuff just different syntax and runtime.

Backend being substantially divorced from frontend isn't a bad thing, it's generally a good thing that results in nice clean separation of concerns and healthy push-pull in design decisions about where certain logic and responsibilities should lie etc.

Re: Kubernetes is a red flag signalling premature optimisation

#72

Post by Stormwalker » Mon, Jul 04, 2022, 9:05 AM UTC

I have read that this article isn't about k8s, but in my experience, companies that try to avoid k8s in favor of other specialized solutions are leaning more into premature optimisations. The company that used Nomad spent weeks in analisys of simple auth service, but every company that used k8s, went with whatever and moved on.

Re: Kubernetes is a red flag signalling premature optimisation

#73

Post by iostream24 » Mon, Jul 04, 2022, 9:06 AM UTC

iostream24 wrote: post #62

“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 Kuberne…

Merely making scriptable infrastructure doesn’t require kubernetes or containers… Ansible or it’s ilk will do just fine. Deploy cloud instances like you currently deploy containers. Save money, get better performance, have real networking.

*i have used kubernetes and understand how to use it as intended. I feel like I am missing the motivation for it’s current widespread usage in web apps

Re: Kubernetes is a red flag signalling premature optimisation

#74

Post by [deleted] » Mon, Jul 04, 2022, 9:08 AM UTC

[deleted]

Re: Kubernetes is a red flag signalling premature optimisation

#75

Post by gjulianm » Mon, Jul 04, 2022, 9:08 AM UTC

wronglyprepaid wrote: post #67

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.

> I guess redundancy is not really a thing then?

Most of the time it really doesn't need to be. In the end what you care about is uptime and cost. A redundant solution doesn't have a perfect uptime just because it's redundant, in fact sometimes it might have even less uptime because of failures in the redundancy mechanism. Of course if you need to be always up it might be worth it. But for a lot of situations some downtime is acceptable and most of the time it's better to be on a simpler setup that's easier to debug and less costly to maintain, than to be on a complex one that requires more maintenance and still doesn't have perfect uptime.

Also, I wouldn't underestimate the cost of maintenance in managed solutions compared to self-hosted. It wouldn't be the first time that the managed solutions screw something up or apply some changes and you don't know whether it's your fault or theirs. You also have to add the cost of adapting your solution to their infrastructure, which is not trivial either.

Re: Kubernetes is a red flag signalling premature optimisation

#76

Post by iostream24 » Mon, Jul 04, 2022, 9:08 AM UTC

sorry_outta_gas wrote: post #14

I don't use it much right now but I've found kubernetes (at least the managed service variety) fairly staright forward compared to some of the altearntives it beats the pants off the the random rubricks of ansible and puppet projects I've run into the past anyway

How does it beat the pants off Ansible?

Re: Kubernetes is a red flag signalling premature optimisation

#77

Post by waffles2021 » Mon, Jul 04, 2022, 9:09 AM UTC

jsiepkes wrote: post #61

Izkata wrote: post #54

Earlier quoted context omitted.

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

There is also an issue with conceptual leakage, most noticeably I've found with devs well versed in one language bending another language into behaving like the former.

Re: Kubernetes is a red flag signalling premature optimisation

#78

Post by ramraj07 » Mon, Jul 04, 2022, 9:09 AM UTC

Stormwalker wrote: post #72

I have read that this article isn't about k8s, but in my experience, companies that try to avoid k8s in favor of other specialized solutions are leaning more into premature optimisations. The company that used Nomad spent weeks in analisys of simple auth service, but every company that used k8s, went with whatever and moved on.

There are other options.

You can use elastic beanstalk, and RDS. You get scaling, reliability and backups. And it’s not complicated and you can set up easy CICD with just GitHub actions.

If you don’t need scaling, just use lightsail and litestream.

There are many many options to do things simply.

Re: Kubernetes is a red flag signalling premature optimisation

#79

Post by febeling » Mon, Jul 04, 2022, 9:10 AM UTC

pjmlp wrote: post #20

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…

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.

It needs to be all Javascript, because Javascript in itself is already at least 5 languages, with ES6, browser runtimes, Node, ESM and CJS, and TypeScript, some CoffeeScript remenants, and the list doesn't end. There is no end to complexity.

Re: Kubernetes is a red flag signalling premature optimisation

#80

Post by jpgvm » Mon, Jul 04, 2022, 9:10 AM UTC

gjulianm wrote: post #65

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

This is a common misconception. k8s isn't about scale, multi-node or even reliability/resiliency. We had solutions for all of that before it came along.

It's about having a standard API for deployment artifacts.

The k8s manifests are trivial (if verbose) the complexity comes from running the underlying layer which when you are small you simply outsource to AWS or GCP.

There is some k8s know-how that is table stakes for a good experience, namely knowing what extra stuff you need on top of a base k8s cluster. i.e certmanager, external-dns.

Overall it's a lot less required knowledge than it takes to manipulate lower level primitives like GCP/AWS directly or be capable of setting up standalone boxes.

Before anyone starts with "but serverless!" you need to consider the spagetti you end up with if you go down that route, API Gateway, 100x Lambdas and thousands upon thousands of lines of Terraform boilterplate does not a happy infra team make.