2008 Again
There are moments when you look at a Kubernetes setup
and suddenly feel like it’s 2008 again.
So many acronyms.
So many standards.
So many layers.
And somewhere underneath it all,
this quiet feeling:
This is impressive.
But do we really need all of this?
Back then, it was JavaEE.
Sometimes OSGi.
Sometimes an application server
that needed a full minute to start
just so you could render a login page.
Today it’s Kubernetes.
And GitOps.
And ten more things
you apparently “just need” on top.
The names change.
The pattern stays the same.
Enterprise Solves Everything
JavaEE was supposed to standardize enterprise applications.
Lifecycle.
Deployment.
Transactions.
Messaging.
Dependency injection.
Everything structured.
Everything formalized.
Kubernetes is trying to do the same thing.
Just for the cloud.
Pods.
Deployments.
Services.
Controllers.
Operators running operators.
Neither of these systems is wrong.
They’re just very thorough.
Maybe too thorough.
It Felt Elegant
OSGi had this kind of magic to it.
Bundles discovering each other.
Loading dynamically.
Restarting cleanly.
Very elegant.
Right up until the first time
you had to figure out
why a bundle wasn’t resolved.
GitOps sometimes feels similar.
You describe a desired state.
A controller keeps things in sync.
Theoretically beautiful.
In practice, it often means:
A YAML file.
Transformed by one tool.
Generated by another tool.
Applied by a controller.
That eventually does… something.
And when it breaks,
you’re not debugging code anymore.
You’re debugging state.
None of It Was Optional
JavaEE had everything.
EJB.
JPA.
JMS.
JTA.
CDI.
Spring trying to simplify things.
OSGi promising modularity.
Karaf somewhere in the middle of it all.
A toolbox
that could do everything.
Which also meant
it demanded a lot.
Kubernetes has everything too.
Helm.
Kustomize.
ArgoCD or Flux.
CRDs for every possible idea.
Service meshes,
because networking is architecture now.
Everything modular.
Everything replaceable.
And somehow,
you end up running all of it anyway.
The Old Reflex
Both worlds share the same reflex:
When things get complicated,
we build a system
that can model all of it.
Every edge case.
Every team.
Every possible workflow.
That sounds reasonable.
Until you realize
you only use 20% of the features,
but carry 100% of the mental weight.
Complexity isn’t reduced.
It’s just organized.
Too Much of It
JavaEE didn’t fail
because it was bad.
It was just easy to overdo.
A lean stack
was excellent.
Too much of it
was exhausting.
Kubernetes feels the same sometimes.
Pods.
Deployments.
Services.
A clean GitOps flow.
That part works.
What makes it painful
isn’t the tooling.
It’s the urge
to install the entire CNCF landscape
while you’re at it.
Big Teams Build Big Systems
The interesting part isn’t really technical.
JavaEE and Kubernetes
come from the same environment.
Large teams.
Shared systems.
Too many moving parts.
At some point,
someone starts building structure around all of it.
Then more structure.
Then tooling for the structure.
Then tooling for the tooling.
Some of it is genuinely useful.
Some of it exists
because the previous layer became too complicated.
And after a while,
nobody is really talking about the original problem anymore.
That’s usually when culture takes over.
Keep the Stack Small
JavaEE wasn’t really a lesson in simplicity.
It was more a lesson in restraint.
Use the smallest setup
that actually solves the problem.
Not the biggest one
the ecosystem allows.
Kubernetes works the same way.
Pods.
Deployments.
Services.
A clean GitOps flow.
That part is usually fine.
What hurts
is adding everything else.
Lean setups tend to age better.
Fewer moving parts.
Fewer weird surprises.
Easier debugging.
A clearer system.
If you install everything
just because it exists,
you eventually end up building your own application server.
Only this time,
it’s YAML.
Enough
Kubernetes isn’t the problem.
GitOps isn’t the problem.
Just like JavaEE wasn’t the problem back then.
It’s the same old idea:
That more structure
will somehow make complexity manageable.
Maybe the trick
isn’t choosing the most powerful tool.
But the smallest one
that still does the job.
And stopping there.
