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

Re: Kubernetes is a red flag signalling premature optimisation

#261

Post by sk0g » Mon, Jul 04, 2022, 12:19 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…

With 1YoE I did most of that in about 3 months. Had a deadline of 6 months to get something functional to demonstrate the proposed new direction of the company, and I did just that. If I were to do it today I could probably rush it to a week, but that would mean no progress on the backend development that I was doing in parallel. A day is probably doable with more on-rails/ batteries included approaches.

Not because I'm amazing, but there's a frankly ridiculous amount of information out there, and good chunks of it are high quality too. I think I started the job early January, and by April I had CI/CD, K8s for backend/frontend/DBs, Nginx (server and k8s cluster), auto-renewing certs, Sentry monitoring, Slack alerts for ops issues, K8s node rollback on failures, etc.

The best way to learn, is to do. Cliche, but that's what it really comes down to. There's a fair few new concepts to grasp, and you probably have picked some of these up almost by osmosis. It sounds more overwhelming than it is, truly.

Re: Kubernetes is a red flag signalling premature optimisation

#262

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

okamiueru wrote: post #106

pritambarhate wrote: post #84

Doesn't look like the author knows what he is talking about. His point about early stage startup should not use K8S is fine. But the next advice about not using a different language for frontend and backend is wrong. I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too. Another option is to use…

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…

I agree with that, setting up k8s on bare-metal took me 2 days, and we needed it to deploy elastic and some other helm charts as quickly as possible without loosing our minds maintaining nodes with some clunky shell scripts.

Also we bought us immediately an easy approach to build gitlab ci/cd pipelines + different environments (dev, staging, production) on the same cluster. Took me a week to set everything up completely and saved our team developing rapidly features really a lot of time and headache since then. But the point is, I knew how to do it, focus on the essentials and deliver quick reasonable results with large leverage down the route.

Re: Kubernetes is a red flag signalling premature optimisation

#263

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

drzel wrote: post #162

I maintain a free, open source, fast paced shooter that really only works with I frequently need to re-provision new servers and close existing ones. I've been doing all this with the help of docker-machine (now deprecated), and a collection of handy bash scripts. While this has worked, it's become more and more fragile and I need something better. For years I've resisted Kubernetes because I keep hearing "premature…

This is gonna be hard, I’d honestly look at fly.io.

But argocd hooked up to each provider along with provider specific overrides should work with enough tweaking.

Re: Kubernetes is a red flag signalling premature optimisation

#264

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

Beltalowda wrote: post #234

ratww wrote: post #104

Earlier quoted context omitted.

This is an underestimation of how hard it is to learn to program. Someone learning a first language isn't just learning a new language: they're learning how to program. It's a new profession, a new hobby, a new superpower. The rest of the stuff (standard library, ecosystem, buildsystem and all kinds of intricacies) is just a mix of trivia and bureaucratic garbage you gotta fill your brain with but will all be replace…

I think a lot of people here have been doing this programming thing for so long we've forgotten we once had trouble understanding things like: x = 1 for i in [1, 2, 3] { x = i } What is the value of "x" at the end? Assuming block scope, it will be 1, or assuming it doesn't have block scope (or that it uses the already defined "x" in this pseudo-example) it will be 3. A lot of beginning programmers struggle with this…

Well, loops are not loops in functional languages...

Re: Kubernetes is a red flag signalling premature optimisation

#265

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

While I tend to agree to the conclusion on premature optimization - I disagree with the assumption that it is premature for most startups. In fact it's a reasonable insurance for startups (that is - if at all they succeed) it'll solve the problem of scale at that point without needing to make huge changes.

BTW Google open-sourced Kubernetes not for charity (like all businesses they also want to make money), they knew they had lost the cloud war with Amazon/Azure gulping up almost 80-90% market share. So they wanted a platform on which they can lure users back to Google Cloud when they start providing kick-ass services (to avoid the much famed vendor lock-in). And since docker was able to solve the dependency management in a reasonable way (not in a very esoteric way like nix) and were dipping their toes into distributed orchestration, they took it as a open fundamental unit to solve orchestration of distributed systems.

But yes Google succeeded in convincing dev/ops to use k8s by frightening them with vendor lock-in. But the most ironic thing that I see about k8s is that all these HPA, Restart on crash all those things are being touted as great new features. These features have existed in Erlang for decades (supervisors and spawning actors). I'm not sure why Google did not try to leverage the Erlang ecosystem - it might have been much faster to market (may be NIH).

Re: Kubernetes is a red flag signalling premature optimisation

#266

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

ramraj07 wrote: post #78

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.

You just showcased my point! People would spend weeks in search for solutions that implement part of required functionality, instead of using whatever they're most familiar with and move on.

Re: Kubernetes is a red flag signalling premature optimisation

#267

Post by engineeringwoke » Mon, Jul 04, 2022, 12:30 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…

It's healthy to depend on your coworkers for their specific knowledge. The landscape is too large for everyone to know everything, and honestly if I heard someone say this in an interview I would chalk it down to social deficits because this is not how life, businesses, etc. work

Re: Kubernetes is a red flag signalling premature optimisation

#268

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

sudarshnachakra wrote: post #265

While I tend to agree to the conclusion on premature optimization - I disagree with the assumption that it is premature for most startups. In fact it's a reasonable insurance for startups (that is - if at all they succeed) it'll solve the problem of scale at that point without needing to make huge changes. BTW Google open-sourced Kubernetes not for charity (like all businesses they also want to make money), they knew…

It's because OTP does not integrate with anything not running on Erlang VM, and k8s instead derives from different family tree of general language-independent schedulers/environments.

Re: Kubernetes is a red flag signalling premature optimisation

#269

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

mt42or wrote: post #209

Kubernetes is the standard for infrastructure, everyone should use it instead of VM or all others singular infrastructure. All others options are costly on the mid and long term.

I don’t think so. I run 2 dedicated-cpu cloud instances that will thrash any load you throw at it high availability, and I can spin up an entire 3-node production cluster in a few minutes with good old Ansible and some cloud provider module.

Kibernetes brings me overhead and wastes system resources.

I already have infrastructure as code.

Why would I want to containerize systems I already have YAML to describe?

People forget they real hardware has to run this stuff, and layers os schedulers are not helpful.

Look at the disaster of fibers threads and processes already!

Re: Kubernetes is a red flag signalling premature optimisation

#270

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

okamiueru wrote: post #106

pritambarhate wrote: post #84

Doesn't look like the author knows what he is talking about. His point about early stage startup should not use K8S is fine. But the next advice about not using a different language for frontend and backend is wrong. I think the most appropriate advice is to choose a stack which the founding team is most familiar with. If that means RoR then RoR is fine. If it means PHP then PHP is fine too. Another option is to use…

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…

> 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 through nginx and cert-manager, do full integration tests, etc. I found that to be quite impressive, for one person, one year, and would probably be completely impossible if it wasn't for k8s.

But that's the thing though: they didn't do it alone. You literally pointed out that this wasn't true almost immediately: "leverage the helm chart open source community". They used the work of others to get to the result.

Also, I highly doubt they could debug something if it went wrong.

I simply cannot believe anyone would advocate, or believe, that because a Helm chart makes it simple to create a complex piece of infrastructure it must also be true that maintaining it is also simple. It's really.