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

Re: Kubernetes is a red flag signalling premature optimisation

#241

Post by ozim » Mon, Jul 04, 2022, 12:04 PM UTC

mrweasel wrote: post #220

shele wrote: post #45

> Imagine spending a lot of time and money picking out the best possible gear for a hobby before actually starting the hobby. Haha, this is exactly what “hobby” means to a lot of people. Less judgmental: thinking and dreaming about the right tools in disproportion to the need is something people do a lot, presumably because it is a source of joy.

That bit was pretty interesting to me as well, because that's exactly what many people do. I don't agree that this is what "hobby" means, it's more that we tend to try to buy our way into a life style. I feel that Kubernetes is exactly that for a large number of developers, operations people less so, they want to be part of a professional, world class, trendy environment/community. So they try leverage Kubernetes to…

You know these types of people who like to wear army clothes to look bad-ass even though they are wimps?

I see it the same type of folks as ones using FAANG tooling :) just so they can feel better about their job or more important when they work on business line CRUD.

I am working on business line CRUD and I like it with boring servers :)

Re: Kubernetes is a red flag signalling premature optimisation

#242

Post by toshk » Mon, Jul 04, 2022, 12:04 PM UTC

okamiueru wrote: post #210

wahnfrieden wrote: post #203

Earlier quoted context omitted.

Sounds like a waste of months that could have gone into building product by choosing simpler operational tech

That's seems like a very negative take in my opinion. This 'simpler operational tech' would still need to be able to scale, correct? If you think that there is a good and easier way to deploying 10-15 services, all of which can scale, and all of it defined in rather neat code, to be anything but "simple operational tech", then I believe you are confusing "solving a complex problem", with "simplifying the requirements…

Yeah to be honest, I run a k8s cluster now for my saas. But about 4 times more expensive then my previous company I ran on a VPS.

And scaling is the same that VPS I could just scale the same way. Run a resize in my hosting company panel. (I dont use autorescal atm)

Only if I would hit about 100x times the nrs I would get the advantage of k8s, but even then I could just split up customers into different VPS.

CI / CD can be done good and bad with both.

And in practice K8S's a lot less stable. Maybe because I'm less experienced with K8S. But also because I think its more complex.

To be honest k8s is one of those dev tools that has to reinvent every concept again, so it has it's own jargon. And then there are these ever changing tools on top of it. It reminds me of JS a few years ago.

Re: Kubernetes is a red flag signalling premature optimisation

#243

Post by okamiueru » Mon, Jul 04, 2022, 12:05 PM UTC

wahnfrieden wrote: post #227

okamiueru wrote: post #210

Earlier quoted context omitted.

That's seems like a very negative take in my opinion. This 'simpler operational tech' would still need to be able to scale, correct? If you think that there is a good and easier way to deploying 10-15 services, all of which can scale, and all of it defined in rather neat code, to be anything but "simple operational tech", then I believe you are confusing "solving a complex problem", with "simplifying the requirements…

for example lambda (not microservices, running mini monoliths per lambda function) yes by simple I mean covering high availability requirements, continuous deployment, good DORA measures - not simple as in half-baked non-functional operations (such as manually sshing to a server to deploy)

Ah, I see. Well, lambdas are also a nice tool to have, but it certainly do not fit for all applications (same as with k8s). I'd also point out that lambdas replace a rather small capabilities of k8s, and the type of systems you can put together. You would end up needing to set up the rest either through a terrible AWS UI or terraform. Neither of which I find to simplify things all that much, but perhaps this is a matter of taste.

In our case, the workers were both quite heavy in size (around 1 GB), and heavy in number crunching. For this reason alone (and there are plenty more), lambdas would be a poor fit. If you start hacking them to keep them alive because of long cold starts, you would lose me at the simple part.

Re: Kubernetes is a red flag signalling premature optimisation

#244

Post by williamcotton » Mon, Jul 04, 2022, 12:06 PM UTC

K0SM0S wrote: post #228

jhugo wrote: post #187

Earlier quoted context omitted.

> I think the set of cases where "we need to scale up rapidly if it succeeds" and "Kubernetes solves all of our scaling needs and we aren't going to have problems with other components" is almost empty. I agree, but so what? K8s isn't magic, it won't make all your problems go away, but if you have people who are genuinely skilled with it, it solves a lot of problems and generally makes scaling (especially if you need…

Meanwhile, random_pop_non-tech_website exploding in traffic wasn't setup to scale despite years actively seeking said popularity through virtually any means and spending top dollar on hosting, and it slows down to crawl. "Why no k8s?", you ask, only to be met with incredulity: "We don't have those skills", says the profiteering web agency. Sure, k8s is hard… Not. Nevermind that it's pretty much the only important par…

That’s clearly not a startup!

Re: Kubernetes is a red flag signalling premature optimisation

#245

Post by candiddevmike » Mon, Jul 04, 2022, 12:06 PM UTC

mattlondon wrote: post #229

cryptonym wrote: post #60

Earlier quoted context omitted.

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

In my mind it is not code reuse between frontend and backend, but expertise and standard library reuse that is the winner. Better to have a full stack developer that can concentrate on becoming an expert and fluent in just one language rather than being kinda-ok in 3 or 4 IMHO.

You really think programming languages are that different?

Re: Kubernetes is a red flag signalling premature optimisation

#246

Post by chrisweekly » Mon, Jul 04, 2022, 12:08 PM UTC

AgentME wrote: post #214

spion wrote: post #164

Earlier quoted context omitted.

It depends. If you do server-side rendering with something like nextjs, then its quite a lot of code. With trpc you can share types without going through an intermediary schema language ( https://trpc.io/ ) although I think it would've still benefitted from separating the schema from the implementation (hope you don't forget the type specifier and import your backend into your frontend by accident) For business logic…

Even when using Nextjs, it's still pretty common to have a separate API backend that doesn't also have to be in Javascript/Node. There are parts of backend code (HTML generation) that very strongly benefit from being unified with the frontend code, and there are parts of backend code (like database persistence code) that much less strongly if at all in some cases benefit from unification with the frontend code. Many…

This. I like how the Remix.run devs frame the "BFF" (Backend-For-Frontend) pattern: https://remix.run/docs/en/v1/guides/bff

Re: Kubernetes is a red flag signalling premature optimisation

#247

Post by nemetroid » Mon, Jul 04, 2022, 12:12 PM UTC

hsn915 wrote: post #200

tr33house wrote: post #180

As a startup founder that's not VC funded, I would totally recommend you look into building with kubernetes from the get go. The biggest learning curve is for the person setting up the initial deployments, services, ingress etc Most other team members may just need to maybe change the image name and kubectl apply to roll things out. Knowing that rollouts won't bring down prod and that they can be tested in different…

> The biggest learning curve is for the person setting up the initial deployments, services, ingress etc Most other team members may just need to maybe change the image name and kubectl apply to roll things out. This is a huge redflag. It's basically admitting that you expect most later employees to not understand k8s or how its being used. You may think they don't need because it works, but you have to think about w…

YAML supports comments.

Re: Kubernetes is a red flag signalling premature optimisation

#248

Post by candiddevmike » Mon, Jul 04, 2022, 12:14 PM UTC

sweaver wrote: post #166

For sure, there is power at the cost of agility! I've seen cases where we started off as simply as possible with no k8's. We built the initial product really quickly using a ton of managed services. Whilst it was great to get us going, once we hit "growth" things just didn't scale. (1) The cost of cloud was getting astronomical for us (and growing with each new deployment) and (2) it was totally inflexible (whether t…

I think it's funny that everyone uses/loves k8s ends up building a product to make it easier to use. There are a lot of examples in the comments here. To me, that's enough of a red flag that k8s doesn't understand their users or can't meet them where they're at.

Re: Kubernetes is a red flag signalling premature optimisation

#249

Post by Annatar » Mon, Jul 04, 2022, 12:15 PM UTC

It takes a month to set up a Kickstart infrastructure (DHCP, TFTP, NFS, Kickstart profile(s)),

a day to three days for an experienced system engineer to package the components,

and a week to three weeks to test and package the configuration (by automating in %pre and %post of the RPM's).

That's far less than one year, and far less than it takes to set up Kubernetes, Terraform, Docker and a complete CI / CD pipeline.

Re: Kubernetes is a red flag signalling premature optimisation

#250

Post by BobbyJo » Mon, Jul 04, 2022, 12:16 PM UTC

wrnr wrote: post #175

okamiueru wrote: post #106

Earlier quoted context omitted.

I don't think their advice about not using it in a startup is correct either. You just need to somewhat know what you're doing. I know of such a case, where a single engineer could leverage the helm chart open source community, and set up a scalable infrastructure, with prometheus, grafana, worker nodes that can scale independently of web service, a CI/CD pipeline that can spin up complete stacks with TLS automated t…

How long did it take him to do this setup, a year you say, and that is impressive? I am not trying to be cute here, my question comes from a genuine place of curiosity. I've love to learn to spin-up a system like that, but from the tech/sales talks I see I am made to believe this can be done in a day. Expectation management is important, if people say ops is just a solved problem then I expect this to take very littl…

You can get a majority of those things "running" in few days. If you don't want it to fall over every other day, then you need to have a ton of ancillaries which will take at least several months to set up, not to mention taking care of securing it.