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

Re: Kubernetes is a red flag signalling premature optimisation

#51

Post by adastra22 » Mon, Jul 04, 2022, 8:48 AM UTC

subhajeet2107 wrote: post #49

tenfourty wrote: post #2

[OP here] It feels bizarre saying this, having spent so much of my life advocating for and selling a distribution of Kubernetes and consulting services to help folks get the most of out it, but here goes! YOU probably shouldn't use Kubernetes and a bunch of other "cool" things for your product. Most folks building software at startups and scale-ups should avoid Kubernetes and other premature optimisations. If your co…

What about standardisation that comes with using a framework like kubernetes , while not using k8s you end up with adhoc deployment methods, clunky work arounds of handling networking, policies, secrets etc, with Kubernetes or even ECS it signals that the team or the developer is looking to use fixed set of rules for infrastructure, also k8s scales well even for smaller apps

Seriously, I use k8s for the same reason I use docker: it's a standard language for deployment. Yeah I could do the same stuff manually for a small project.. but why?

Re: Kubernetes is a red flag signalling premature optimisation

#52

Post by biztos » Mon, Jul 04, 2022, 8:49 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…

And isn’t Wasm supposed to (some day) free us from the need to pick JS for the front end?

Re: Kubernetes is a red flag signalling premature optimisation

#53

Post by rkangel » Mon, Jul 04, 2022, 8:49 AM UTC

The flipside of this philosophy is that you have to be able to revisit your decisions when your requirements change.

This is a superpower that you want to have individually as an engineer but you need organisationally as a culture too. If you have that power then you when you need to write some similar code you can copy and paste, because you can trust that when you have a third use you will actually refactor properly. It means that you can get the service up and running quickly on a box you've got, because you can trust that if the service actually gets used your org will allow you the time to put it on the cloud properly.

It's the most important part of agile - make the right decision for what you've got now, and then make a different one later.

Re: Kubernetes is a red flag signalling premature optimisation

#54

Post by Izkata » Mon, Jul 04, 2022, 8:51 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.

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.

Re: Kubernetes is a red flag signalling premature optimisation

#55

Post by p_l » Mon, Jul 04, 2022, 8:51 AM UTC

adastra22 wrote: post #51

subhajeet2107 wrote: post #49

Earlier quoted context omitted.

What about standardisation that comes with using a framework like kubernetes , while not using k8s you end up with adhoc deployment methods, clunky work arounds of handling networking, policies, secrets etc, with Kubernetes or even ECS it signals that the team or the developer is looking to use fixed set of rules for infrastructure, also k8s scales well even for smaller apps

Seriously, I use k8s for the same reason I use docker: it's a standard language for deployment. Yeah I could do the same stuff manually for a small project.. but why?

Last year I tried to "simplify" by doing things mostly the old way (though we used containers for a bunch of things later on).

The experience pushed me to decide "never again" and to plonk k3s or at least something like podman from the start on the server.

Re: Kubernetes is a red flag signalling premature optimisation

#56

Post by secondcoming » Mon, Jul 04, 2022, 8:52 AM UTC

pjmlp wrote: post #36

hadlock wrote: post #9

Earlier quoted context omitted.

You can get away without an orchestrator right up until about when your ARR hits $10mm Hiring people with k8s experience in 2022 is not a difficult task, it's not an obscure technology anymore, and when your initial crop of devops decides to leave, the new guys coming in can scan your deployments and namespaces and pretty much hit the ground running within 48-72 hours. That's a big, important part of running a busine…

So much for theory. I just came out of a project where Kubernetes performance issues involved wild guess and blind tuning until the so called experts actually found out why the cloud cluster was behaving strangely, including support from Cloud vendor. And good luck making sense of all the YAML spaghetti available for bootstrapping the whole cluster from scratch. 72 hours? They better be 10x DevOps team.

This is our world right now. A kubernetes cronjob sometimes fails and we have no idea why.

Re: Kubernetes is a red flag signalling premature optimisation

#57

Post by tluyben2 » Mon, Jul 04, 2022, 8:52 AM UTC

lmm wrote: post #47

nicoburns wrote: post #41

Earlier quoted context omitted.

That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter), whereas rewriting it later would be a massive undertaking. This I very different to say starting a with a micro service architecture which imposes relatively high overheads, with lit…

> That assumes it’s harder to build it in the other language though. Maybe if that language is C then that will the case, but building in say Go may be just as easy as building in JavaScript (or close enough that it doesn’t really matter) The cases where Go is significantly faster than JavaScript are vanishingly small. > whereas rewriting it later would be a massive undertaking. This is vastly overstated IME. Porting…

> This is vastly overstated IME. Porting existing code as-is between languages is actually pretty easy.

Yep. We always implemented (parts of) embedded software in Java first and later in JS and then port it. If no additional functionality is added, this is trivial and saves a lot of work and errors as you already tested, debugged and fixed the logic parts.

Re: Kubernetes is a red flag signalling premature optimisation

#58

Post by supermatt » Mon, Jul 04, 2022, 8:52 AM UTC

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 over manually setting everything up for every project you work on.

Re: Kubernetes is a red flag signalling premature optimisation

#59

Post by ianpurton » Mon, Jul 04, 2022, 8:53 AM UTC

If you have one docker container to deploy then yes you can get away with heroku or fly.io etc.

More than one container then cloud hosted kubernetes makes sense. It's a transferable skill a kind of learn once apply to any cloud technology.

Re: Kubernetes is a red flag signalling premature optimisation

#60

Post by cryptonym » Mon, Jul 04, 2022, 8:53 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.

That's sad, JavaScript was already not great for front-end and we now get it in backend and even the edge.

Most job offers are for a mythical full-stack developper that'll master web design, CSS/HTML, front-end interactions and code, networking, back-end architectures, security,... You end-up with people who don't have time to get enough expertise and write and build clean stuff. Hacking poor JavaScript code everywhere.

With the same language, you may think you can somehow reuse stuff between front and back. A bad idea in most project, will typically create more problem than it'll solve.