Comment by netdur
4 hours ago
why would any software want to have Kubernetes moment? can't count how devop I know that is confused by it
4 hours ago
why would any software want to have Kubernetes moment? can't count how devop I know that is confused by it
I still don't know what it is tbh. Something for docker?
I was in the same boat as you until I needed to learn how to use it in my $dayjob. It was like discovering a new continent. I couldn't care less about it before, but the moment I realized it's a kind of cloud OS I was astounded by how this thing is genius. It's the kind of thing that gives you dopamine rushes when you use it. Something about how there is a solution to every problem you didn't know even mattered turns it into a magical perfect software. I just love it.
There is something special about complex systems that just-work(tm)
> the moment I realized it's a kind of cloud OS
The foundation of this is thirty years old:
Mark Andreesen founded a company to do what Amazon did: Loudcloud. This was cloud computing, BEFORE AWS was public. Loudcloud was founded in the nineties; AWS opened its APIs in 2006.
Loudcloud failed and became Opsware. Opsware was server automation.
Its competitor was Bladelogic.
Luke Kanies, from BladeLogic, founded Puppet. Puppet was open source, and steamrollered over nearly every installation of BladeLogic and Opsware in existence, because you can’t beat free.
Folks from BladeLogic migrated to jobs at DCOS.
DCOS was steamrollered by Kubernetes, the same way Puppet steamrollered BladeLogic.
The author of the piece predicts that open weight models will steamroller everything next.
I fear he’s right.
I worked for Opsware and BladeLogic.
I watched it happen in real time.
Financially, Andreesen’s wealth stems from Opsware. He is known for Mosaic, but Opsware put him on the map, financially. HP bought them.
If one wants to follow in Andreesen’s footsteps, study how he did it at Opsware.
Conveniently, there is a book.
“The Hard Thing about Hard Things.”
This is the initial endorphin rush you get when wielding a complex system. The feeling changes when the complexity explodes in your face.
1 reply →
So Kubernetes is LSD? ;)
I was in this state a few weeks ago. I spent a bit of time familiarizing myself then wrote up my learnings as a series of exercises.
If you think of docker as "kinda like vms except not really" and k8s as "kinda like deploying and composing docker containers but not really", this may be for you:
https://ojensen.net/infra/understanding-k8s-1
It's actually really neat, i wish i had bothered to learn it years ago.
I appreciate the effort and I'm in your target audience, but that document didn't help me. It seems to dive into the details of installing and running k8s without saying much about the purpose.
From my very ignorant standpoint, K8s seems to be about running a "cluster", but I don't know why I would want to do that.
2 replies →
If you can get it implemented for anything you can’t be fired.
Kubernetes is for docker what your init system is for daemons.
It's for running a massive number of docker containers and automatically managing them and scaling them up and down on demand. It is also so famously brutally complex that basically you need a dedicated Kube expert to handle it.
to be fair, at any large scale you need infra people.
1 reply →
You... don't know what Kubernetes is... pretty impressive, honestly.
Its 2026 and its the de facto method of deploying software basically everywhere.
You gotta really work for it to not know what its for by now.
I don't do much deployment but I'm in the same boat. Something something docker automation?
> Its 2026 and its the de facto method of deploying software basically everywhere.
That is some really impressive bubble you are living within. Basically everywhere - nowhere near that, no.
[edit]: Maybe containers, but software in general is so much more broad than containers.
Everywhere, huh? Still plenty just running on VMs or serverless that don't need full blown container orchestration.
I'll agree that (nearly) everyone should know when Kubernetes is useful, but let's not pretend its the default method for everything. Even then, choosing to deploy on K8s falls on the sysadmins/DevOps I wouldn't expect the devs know or do much more than provide the Dockerfile.
2026 is the year for vercel and Render.
2 replies →
Recently my company bought another company, and we kept zero of the original engineers, we just had to run the ghost ship.
We walked in, and it was fine. Because it was all kubernetes and laid out like every other app for the most part.
The kube hate is just sad at this point. You need to know like 15 concepts that are all applied in the same way. It mostly just works.
I ported my company over to k8s to solve a concurrency and scaling issues.
What 15 concepts? You're making me worry that I missed something. It was straight forward: pods, nodes, hw type, lifecycle, deployment. They run almost the same docker as the old ec2s used.
What did I miss? Is there something important I need to read?
It’s the pineapple on pizza of ops, people just like to fit in sometimes.
I’ve been running my own personal k8s cluster on digital ocean for the last 5+ years now and it’s dead simple.
Takes me 30 minutes to create a new namespace a deploy an app, love the bonus of having complete flexibility on my stack too — PVC + SQLite ftw
Ghost ship status is not something most orgs aspire to.
The value built on that stability was probably worth acquiring, and it’s infra will decay.