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

Re: Kubernetes is a red flag signalling premature optimisation

#121

Post by beachy » Mon, Jul 04, 2022, 9:42 AM UTC

cryptonym wrote: post #60

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.

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…

I'm far from a full stack developer, but really how much code would actually be common across the front and and back end? I would have thought maybe some validation code, not sure how much else?

Re: Kubernetes is a red flag signalling premature optimisation

#122

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

ggktk wrote: post #102

biztos wrote: post #52

Earlier quoted context omitted.

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

Unfortunately, that doesn't seem the way WASM is going. It's been 5 years and we still can't access the DOM without going through JS.

There isn't the political will-power to make it happen and force all the browser vendors to agree and implement. Hence status-quo remains.

Re: Kubernetes is a red flag signalling premature optimisation

#123

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

jpgvm wrote: post #116

ramraj07 wrote: post #88

Earlier quoted context omitted.

It would be great if otherwise smart people Also learn to know when what’s trivial to them is not trivial to the masses. K8s is not trivial, not to me at the least. I’m not some super duper engineer but I do alright? That’s all I can say at the least.

Have you made a good faith attempt to use k8s? Or are you just regurgitating how hard it is to use based on what you hear on the Internet? My experience is even mediocre engineers are capable of understanding k8s concepts with minimal assistance assuming things are either sufficiently standard (i.e google-able) or well documented with any company specific practices. K8s == hard to run, k8s != hard to use.

I have made a good faith attempt at using it, yes. Is spending an entire week on it good faith?

I did get everything running but also saw so many settings and features I had to take on faith as being handled without understanding it. I just chose not to bother further because this seems like a minefield of problems in the future as we on boarded other engineers. The number of times I’ve seen production deployments go down due to k8s misconfiguration on other teams has only validated my concerns.

Re: Kubernetes is a red flag signalling premature optimisation

#124

Post by szundi » Mon, Jul 04, 2022, 9:44 AM UTC

biztos wrote: post #52

maverwa wrote: post #42

Earlier quoted context omitted.

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?

I am waiting to be able to run the JVM and have client side swing again in WASM

Re: Kubernetes is a red flag signalling premature optimisation

#125

Post by jalk » Mon, Jul 04, 2022, 9:45 AM UTC

ratww wrote: post #97

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.

Most developers don't seem to want to learn more than "one" thing. Once they do one tutorial, it seems they're done for life with learning. And they don't really have time to learn new stuff, as they spend too much of their time on Hacker News complaining there's too many new frontend frameworks or something like that.

I have never met such a developer - most devs I have met, are way more eager to learn the next shiny thing than just getting the job done.

Re: Kubernetes is a red flag signalling premature optimisation

#126

Post by Chilinot » Mon, Jul 04, 2022, 9:48 AM UTC

pas wrote: post #105

grumpy-de-sre wrote: post #92

At this point I'm pretty much convinced these repeated "Kubernetes is bad for startups" rants are some kind of FUD campaign (probably grass roots from people who've missed the containerisation and declarative infra train). Kubernetes is actually pretty great for the vast majority of use-cases. Sure if you don't have experience with kubernetes leave learning it until after you've hit product-market fit. But rejecting…

could you elaborate on the "ideal" argocd workflow? let's say devs push to gitlab, which starts a pipeline, tests run, container images get built, then in the last step in the gitops repo a version bump happens and then argocd will pick it up automatically? (and if one wants to be able to rollback then that's the same workflow just instead of version "bump" the pipeline tags images with the commit hash and at the las…

For deployments using Argo, yea that's pretty much it. You can set it to automatically deploy to your target environment as soon as it detects changes to your k8s mainfests, or you can require a manual "approve" step which is a push of a button for configs that are out of sync with what is applied to k8s.

For rollbacks, you have a button in argo that lists previous deployments and you can just choose which previous deployment you want to go back to. It works pretty well those (thankfully few) times i have had to rollback any deployments.

Re: Kubernetes is a red flag signalling premature optimisation

#127

Post by tsujamin » Mon, Jul 04, 2022, 9:49 AM UTC

as someone who is currently tearing down a managed k8s cluster and migrating the services into SaaS I sympathise with this blog heavily

Re: Kubernetes is a red flag signalling premature optimisation

#128

Post by CipherThrowaway » Mon, Jul 04, 2022, 9:49 AM UTC

I lean conservative in my tech choices but I just don't see the big issue with Kubernetes. If you use a managed service like GKE it is really a breeze. I have seen teams with no prior experience set up simple deployments in a day or two and operate them without issues. Sure, it is often better to avoid the "inner platform" of K8s and run your application using a container service + managed SQL offering. But the difference isn't huge and the IaC ends up being about as complex as the K8s YAML. For setting up things like background jobs, cron jobs, managed certificates and so on I haven't found K8s less convenient than using whatever infrastructure alternatives are provided by cloud vendors.

The main issue I have seen in startups is premature architecture complexity. Lambda soup, multiple databases, self-managed message brokers, unnecessary caching, microservices etc. Whether you use K8s or not, architectural complexity will bite your head off at small scales. K8s is an enabler for overly complicated architectures but it is not problematic with simple ones.

>Did users ask for this?

Not an argument. Users don't ask for implementation details. They don't ask us to use Git or build automation or React. But if you always opt for less sophisticated workflows and technologies in the name of "just getting stuff done right now" you will end up bogged down really quickly. As in, weeks or months. I've worked with teams who wanted to email source archives around because Git was "too complicated." At some point you have to make the call of what is and isn't worth it. And that depends on the product, the team, projected future decisions and so on.

Re: Kubernetes is a red flag signalling premature optimisation

#129

Post by shankr » Mon, Jul 04, 2022, 9:49 AM UTC

jpgvm wrote: post #116

ramraj07 wrote: post #88

Earlier quoted context omitted.

It would be great if otherwise smart people Also learn to know when what’s trivial to them is not trivial to the masses. K8s is not trivial, not to me at the least. I’m not some super duper engineer but I do alright? That’s all I can say at the least.

Have you made a good faith attempt to use k8s? Or are you just regurgitating how hard it is to use based on what you hear on the Internet? My experience is even mediocre engineers are capable of understanding k8s concepts with minimal assistance assuming things are either sufficiently standard (i.e google-able) or well documented with any company specific practices. K8s == hard to run, k8s != hard to use.

I am not a SDE but I did try one weekend to set-up a self managed k8s cluster in the previous company. I did have some previous knowledge of using k8 in GCP. Although when trying to set it up on a completely new cluster outside of GCP, I did run into some issues where I felt I was out of my depth. I think unknowingly I exposed whole of the cluster to the public internet.

On the other hand, with docker swarm, I built a cluster in less than a day. So yeah setting up k8 isn't as trivial as you are making it out to be.

Re: Kubernetes is a red flag signalling premature optimisation

#130

Post by majewsky » Mon, Jul 04, 2022, 9:49 AM UTC

beachy wrote: post #121

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…

I'm far from a full stack developer, but really how much code would actually be common across the front and and back end? I would have thought maybe some validation code, not sure how much else?

Sounds about right. I have an API service written in Go for which we also offer a client library in Go. We moved the common ground between the two into a separate module to avoid code duplication. That module ended up having the type declarations that appear on the API in JSON payloads, plus some serialization/validation helper methods, and that's it.