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

Re: Kubernetes is a red flag signalling premature optimisation

#341

Post by andybak » Mon, Jul 04, 2022, 2:15 PM UTC

afiori wrote: post #224

andybak wrote: post #189

Earlier quoted context omitted.

> Kubernetes is actually pretty great for the vast majority of use-cases. From my brief glances at it, it seems like a great solution for very complex use-cases. But "vast majority"? The cost-benefit seems way off unless you have a very different sense of "typical use-cases" to me. Most people are building simple web sites and apps that run on a single server, surely?

> Most people are building simple web sites and apps that run on a single server, surely? I believe so, which makes a comparison between k3s and docker-compose very interesting.

I learned the basics of docker-compose in about an hour and I don't see myself outgrowing it in the near future.

Re: Kubernetes is a red flag signalling premature optimisation

#342

Post by blown_gasket » Mon, Jul 04, 2022, 2:16 PM UTC

Speaking from an infrastructure focused perspective who writes to make the provisioning faster, I understand why software-writing focused individuals like Kubernetes both on-prem and in the cloud. It's super easy to deploy to once the platform is provided to you. On the other hand which is a REQUIREMENT, is to get the platform available no matter the method, it can be a laborious chore that doesn't need to exist unless you need it.

on-prem: procuring hardware, installing hardware, installing the host OS/deploy the host virtual machines, networking, deploying K8s, CNI, CSI, etc

if cloud: increasing quotas, verifying that CPU sizes are available for more nodes or new node pools, performing virtual networking and subnetting for the K8s clusters, etc.

both: security everything from RBAC to networking to image validation, upgrades - you made sure to have a scalable app right? if not fingers crossed on availability.

Would the chore exist outside of Kubernetes, of course there would be a chore. I'm not sure so great though. While deploying to Kubernetes is simple. Setting up an on-prem platform is not what-so-ever and if you with public cloud you now have to be aware of all the caveats and gotchas that aren't handcuffs with on-prem.

Re: Kubernetes is a red flag signalling premature optimisation

#343

Post by iso1631 » Mon, Jul 04, 2022, 2:17 PM UTC

movedx wrote: post #285

iso1631 wrote: post #283

Earlier quoted context omitted.

You're forgetting that many people will want to use K8s for a project because they want it on their CV to get the high paying jobs. I saw the term on HN a couple of weeks ago -- CVOps

I'm not forgetting that fact, I'm simply choosing to ignore such people. They're not really what the industry is about. That's not in the spirit of a healthy society. That's just leeching. Good luck to them, but they're not going to occupy time and space in my mind.

Maybe it's just my organization, but I see the behavior across the corporation far more than I'd like, and inevitably these people move on leaving a complex mess in their wake that long term support staff have to deal with.

We seem to mostly manage to avoid that in my department, but we have a very low turnover.

Re: Kubernetes is a red flag signalling premature optimisation

#344

Post by andybak » Mon, Jul 04, 2022, 2:18 PM UTC

quickthrower2 wrote: post #185

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…

Kubernetes is the React of devops. You wont get fired for picking it. And there will be a tonne of support available online, as well as courses, and experienced people you can hire. Also there is cloud managed k8s which takes most of the pain out of it. And plenty of out the box stuff. It is not a bad choice if you want to do the ops yourself for some reason. If you don't then use a BaaS or PaaS, that might be easier…

You seem to be saying there's nothing inbetween K8s and "use a BaaS or PaaS"?

What about something that does the subset of what K8s does that is the simple bit and covers most use-cases outside of complex clusters?

I get the strong sense people are just misusing it for the wrong types of task. I've seen this happen countless times in tech. Development by CV.

Re: Kubernetes is a red flag signalling premature optimisation

#345

Post by gxt » Mon, Jul 04, 2022, 2:18 PM UTC

Thank you, I've been struggling with the decision to move away from k8s as I am spending much time making it work, and much more again every time it needs to change, or be updated, when everything is already fine on metal. I just need to find a way to keep or convert the dockerfiles so that it just runs on metal and without docker.

Re: Kubernetes is a red flag signalling premature optimisation

#346

Post by jjav » Mon, Jul 04, 2022, 2:18 PM UTC

politician wrote: post #294

Jistern wrote: post #288

Earlier quoted context omitted.

>> I agree entirely. I agree entirely too. >> Start with a monolith on two VMs and a load balancer. Chips and networks are cheaper than labour, Kudos to you! You are a dangerous man for you opine the truth. My advice is generally, "Build something. Then see if you can sell it." or "Sell something and then go build it." Either way, it all starts soooo small that the infrastructure is hardly a problem. If you "get luck…

You can’t just hire 1 DevOps superstar though because they need to sleep and not burnout. You’ll need ~7 people on a rotation if you need to really support anything worth really supporting. DevOps is about giving Developers a dedicated System Operations job for some small fraction of their time.

> You can’t just hire 1 DevOps superstar though

You don't go from zero to needing global 24x7 support overnight.

Hiring 1 DevOps superstar is exactly what we did a few startups back and it worked great. Of course there was no after-hours support, it's a small startup. Eventually the team grew.

Re: Kubernetes is a red flag signalling premature optimisation

#347

Post by jjav » Mon, Jul 04, 2022, 2:21 PM UTC

movedx wrote: post #285

iso1631 wrote: post #283

Earlier quoted context omitted.

You're forgetting that many people will want to use K8s for a project because they want it on their CV to get the high paying jobs. I saw the term on HN a couple of weeks ago -- CVOps

I'm not forgetting that fact, I'm simply choosing to ignore such people. They're not really what the industry is about. That's not in the spirit of a healthy society. That's just leeching. Good luck to them, but they're not going to occupy time and space in my mind.

> They're not really what the industry is about.

We'd like that (I'd like that), but resume-driven choices are a very large driver of technology direction, unfortunately.

It means those of who want to build something very maintainable and very stable using the most boring (stable, secure) technology possible are often outnumbered.

Re: Kubernetes is a red flag signalling premature optimisation

#348

Post by status_quo69 » Mon, Jul 04, 2022, 2:22 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…

Having very recently done this (almost, another dev had half time on it) solo, It's not _too_ terrible if you go with a hosted offering. Took about a month/month and a half to really get set up and has been running without much of a blip for about 5 months now. Didn't include things like dynamic/elastic scaling, but did include CD, persistent volumes, and a whole slew of terraform to get the rest of AWS set up (VPCs, RDS, etc). I'd say that it was fairly easy because I tinkered with things in my spare time, so I had a good base to work off of when reading docs and setting things up, so YMMV. My super hot take, if you go hosted and you ignore a ton of the marketing speak on OSS geared towards k8s, you'll probably be a-ok. K8s IME is as complex as you make it. If you layer things in gradually but be very conservative with what you pull in, it'll be fairly straightforward.

My otherhot take is to not use helm but rather something like jsonnet or even cue to generate your yaml. My preference is jsonnet because you can very easily make a nice OO interface for the yaml schemas with it. Helm's approach to templating makes for a bit of a mess to try and read, and the values.yml files _really_ leak the details.

Re: Kubernetes is a red flag signalling premature optimisation

#349

Post by gjulianm » Mon, Jul 04, 2022, 2:23 PM UTC

jhugo wrote: post #187

gjulianm wrote: post #170

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. On the other hand, there are quite a lot of startups that fail because they put too much focus on the infrastructure and Kubernetes and the future and too little on the actual product for the users. Which is the point o…

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

I mean, you still have to invest time on putting k8s to work, get people skilled with it, maintain and debug the problems... If Kubernetes didn't cost anything to deploy I'd agree that using it is the better idea, but it costs time and people, and those things might be better invested in features that matter to the users.

Re: Kubernetes is a red flag signalling premature optimisation

#350

Post by jhugo » Mon, Jul 04, 2022, 2:24 PM UTC

gjulianm wrote: post #349

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…

I mean, you still have to invest time on putting k8s to work, get people skilled with it, maintain and debug the problems... If Kubernetes didn't cost anything to deploy I'd agree that using it is the better idea, but it costs time and people, and those things might be better invested in features that matter to the users.

It depends. There are many things that carry a cost early but pay for themselves many times over later. Whether that will be the case for your startup depends whether you end up needing to scale quickly or not.

It's also worth considering that appropriate use of k8s can quite likely save you time and money early on as well. It standardises things, making it very easy for new ops people to onboard, and you might otherwise end up spending time reinventing half-baked solutions to orchestration problems anyway.