Remix clone Hacker News

Most of the complaints in this fun post are just bad practice, and really nothing to do with “making a Kubernetes”.

Sans bad engineering practices, if you built a system that did the same things as kubernetes I would have no problem with it.

In reality I don’t want everybody to use k8s. I want people finding different solutions to solve similar problems. Homogenized ecosystems create walls they block progress.

One is the big things that is overlooked when people move to k8s, and why things get better when moving to k8s, is that k8s made a set of rules that forced service owners to fix all of their bad practices.

Most deployment systems would work fine if the same work to remove bad practices from their stack occurred.

K8s is the hot thing today, but mark my words, it will be replaced with something far more simple and much nicer to integrate with. And this will come from some engineer “creating a kubernetes”

Don’t even get me started on how crappy the culture of “you are doing something hard that I think is already a solved problem” is. This goes for compilers and databases too. None is these are hard, and neither is k8s, and all good engineers tasked with making one, be able to do so.

▲

mac-chaffee 15 hours ago | parent | next [-]

I welcome a k8s replacement! Just how there are better compilers and better databases than we had 10-20 years ago, we need better deployment methods. I just believe those better methods came from really understanding the compilers and databases that came before, rather than dismissing them out of hand.

▲

delifue 15 hours ago | parent | prev | next [-]

Can you give examples of what "bad practices" does k8s force to fix?

	▲	hyperadvanced 14 hours ago \| parent [-]
		To name a few: K8s really kills the urge to say “oh well I guess we can just do that file onto the server as a part of startup rather than use a db/config system/etc.” No more “oh shit the VM died and we lost the file that was supposed to be static except for that thing John wrote to update it only if X happened, but now X happens everyday and the file is gone”.. or worse: it’s in git but now you have 3 different versions that have all drifted due to the John code change. K8s makes you use containers, which makes you not run things on your machine, which makes you better at CI, which.. (the list goes on, containers are industry standard for a lot of reasons). In general the 12 Factor App is a great set of ideas, and k8s lets you do them (this is not exclusive, though). Containers alone are a huge game changer compared to “cp a JAR to the server and restart it” K8s makes it really really really easy to just split off that one weird cronjob part of the codebase that Mike needed and man, it would be really nice to just use the same code and dependencies rather than boilerplating a whole new app and deploy, CI, configs, and yamls to make that run. See points about containerization. K8s doesn’t assume that your business will always be a website/mobile app. See the whole “edge computing” trend. I do want to stress that k8s is not the only thing in the world that can do these or promote good development practices, and I do think it’s overkill to say that it MAKES you do things well - a foolhardy person can mess any well-intentioned system up.

▲

Kinrany 19 hours ago | parent | prev [-]

So you're saying companies should move to k8s and then immediately move to bash scripts

	▲	mbrumlow 18 hours ago \| parent [-]
		No. I am saying that companies should have their engineers understand why k8s works and make those reasons an engineering practice. As it is today the pattern is spend a ton of money moving to k8s (mostly costly managed solutions) in the process fix all the bad engineering patterns, forced by k8s. To then have an engineer save the company money by moving back to a more home grown solution, a solution that fits the companies needs and saves money, something that would only be possible once the engineering practices were fixed.