Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Kubernetes is a red flag signalling premature optimisation

jeremybrown.tech

Post reply on HN
Print view View original

521–530 of 558 posts

Re: Kubernetes is a red flag signalling premature optimisation

#521

Post by osigurdson »

criley2 wrote: post #259
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…

>That's seems like a very negative take in my opinion. This 'simpler operational tech' would still need to be able to scale, correct? Premature optimization is a top problem in startup engineering. You have no idea what your startup will scale to. If you have 1,000 users today and 5 year goal of 2,000,000 users, then spending a year building infrastructure that can scale to 100,000,000 is an atrociously terrible idea…

If you have a website with 1000 users today and product is going to be re-designed 5 times, it's probably best just to use sqlite and host on a single smallish machine. Not all problems are like this however.

Re: Kubernetes is a red flag signalling premature optimisation

#522

Post by scheme271 »

osigurdson wrote: post #512
jbverschoor wrote: post #490

Earlier quoted context omitted.

We had J2EE almost 30 years ago. 1 file which described everything and contained everything

According to the following link, that literally sounds nothing like Kubernetes. Perhaps a more appropriate analogy to older tech is something like LSF or Slurm. https://www.webopedia.com/definitions/j2ee/

LSF and Slurm is still around and kicking on HPC systems. But they're nothing like kubernetes. Maybe close to k8s batch jobs but that's it.

Re: Kubernetes is a red flag signalling premature optimisation

#523

Post by nojvek »

I feel most places over complicate K8s. The foundational ideas are sane, especially with managed k8s in GCE, AKS, Digital Ocean e.t.c

The basic idea is that of "be like this spec" via a yaml/json file - a controller is continuously monitoring an object and making adjustments until spec matches actual.

I've seen many startups have one person who sets up and maintains their k8s cluster. If you know what you're doing, it has pretty solid ROI.

Re: Kubernetes is a red flag signalling premature optimisation

#524

Post by iostream24 »

jiggawatts wrote: post #95
iostream24 wrote: post #62

“So you want to run a bunch of stuff on one computer, why?” In a quest to get closer to the metal, Kubernetes keeps you far away, which is the opposite of what any production service should want. What is the purpose of adding layers when uni-kernels and eco-kernels give you better isolation and better performance? Your cloud provider already runs your virtual machines OS on a hardware hypervisor. Then running Kuberne…

It deduplicates the kernel memory and system image base disk. The minimum virtual machine size for a Windows server that is at all useful for anything is 4 GB of memory. Okay, okay, so you can technically boot it up on 2 GB and some roles will work fine, this will last only until some dingbat remotes to it with RDP with a 4K monitor and it starts swapping to disk. Even if you use Server Core and block port 3389, it s…

I think exokernels and isokernels solve many of these issues where containers are currently used, check the Ocaml community for examples.

They run on hardware.

Ultimately, there needs to be a singular scheduling system running on hardware and a singular HAL-like driver layer, and exo or iso kernels deliver just that, vs lxe containers provided by os services.

The sizes are also quite impressive.

Re: Kubernetes is a red flag signalling premature optimisation

#525

Post by nightpool »

mattbillenstein wrote: post #430
nprateem wrote: post #410

Earlier quoted context omitted.

This is optimistic to say the least. I've worked as an SRE for 5 years and apart from the others in the team the devs don't have nearly as much knowledge. There's no way I'd rely on them to fix an outage. And even on a small retainer you'd better hope they retained the knowledge of how all that stuff works if you're only calling on them every now and again.

The idea is devops as _culture_ - I come in as an expert and set it up, then show them how I did it, then run through various disaster recovery scenarios so they learn it and can handle the vast majority of problems. And you'd be surprised how little problems you might have - I've had many VMs with literally years of uptime running without issue. Most people focus on "devops" as a job - and they never bother to teach…

> I've had many VMs with literally years of uptime running without issue.

I hope they all have fully patched base libraries and kernels, security auditing is getting to a much more common requirement these days even among very small companies. For example, anybody using Facebook Login.

Re: Kubernetes is a red flag signalling premature optimisation

#526

Post by NoGravitas »

jjav wrote: post #347
movedx wrote: post #285

Earlier quoted context omitted.

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.

And underpaid.

Re: Kubernetes is a red flag signalling premature optimisation

#527

Post by osigurdson »

scheme271 wrote: post #522
osigurdson wrote: post #512

Earlier quoted context omitted.

According to the following link, that literally sounds nothing like Kubernetes. Perhaps a more appropriate analogy to older tech is something like LSF or Slurm. https://www.webopedia.com/definitions/j2ee/

LSF and Slurm is still around and kicking on HPC systems. But they're nothing like kubernetes. Maybe close to k8s batch jobs but that's it.

Finding machines with available cores and memory to run a workload is the fundamental feature that they share.

Re: Kubernetes is a red flag signalling premature optimisation

#528

Post by CRConrad »

jhoelzel wrote: post #81

Guys Kubernetes is a container platform for multiple nodes. I know it seems hard to understand from the outside, but its really not. You would naturally come up with ALL the same componets if you were to take your container strategy onto multiple computers. What if you dont need multiple servers? Well go the single node approach and have a flexible, true and tested way to spin up containers, which can and should be a…

> Using Containers is pre mature optimization too? maybe I should get my typewriter.

You seem to have missed the alternative "get a computer" in between there.

Re: Kubernetes is a red flag signalling premature optimisation

#529

Post by steveBK123 »

zinclozenge wrote: post #449
steveBK123 wrote: post #382

Earlier quoted context omitted.

I think it still bears repeating.. I've seen projects fail or take 10x as long due to choosing to go with k8s day 1 instead of starting with even a basic VM. It may be easy enough to get k8s itself setup. However, without an in-house expert sat within the dev team, all the access/permissions to resources to/from the cluster were hell. NFS disk Read/Write, S3 Read/Write/List, RDS DB access, Kafka access, corp network…

Don't you have to do all of this stuff even if you're not running k8s? Or are you complaining about a re-write/replacement of something that didn't need to be?

As a k8s novice, it seems apparent to me that access to physical resources from pods requires more levels of access configuration than bare metal having access to the same physical resources.

For example NFS you need to make sure the underlying hardware the k8s is running on has the mount, and then that the pods within have that access.

Whatever host level config you need to do on the VM needs to be basically replicated within each of your container images for the pods you want to run, no?

Then you have the same update cycle except across N container images instead of 1 VM?

Post reply on HN