Hacker News Reader

Comment by dkhenry | Hacker News Reader

Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea.

Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything needs to be a plugin and nothing should work out of the box the complexity started to creep up.

You should be able to run your small blog on kubernetes without requiring a team of consultants to set it up or manage it. Just waving your hands and saying well it needs to be complex to scale is a total lie.

View on HN

This is the cycle of life. Zawinski's Law is a powerful force.

The same thing happens with ticketing systems: $old_ticketing_system is way too complicated and bloated, so let's jump to $new_ticketing_system because it's small and easy to understand. Oh, but we miss $feature_1, so let's ask for that. And $feature_2, and $feature_3. Continue until $new_ticketing_system becomes way too complicated and bloated, at which point you find $newer_ticketing_system, which is great except that it's missing $feature_3. Oh, and $feature_4. And 1 and 2, come to think of it. Oh geez, now $newer_ticketing_system is also coming apart at the seams, time to migrate to $even_newer_ticketing_system. . .

This strikes as the exact opposite of reality. Java App Servers were specifically built for vertical scale. You just paid $80,000 to rack 30 CPUs and now you need to a way to optimally utilize all of them so we have a deployment model for sticking multiple applications in a single multi-threaded runtime. That was a pretty decent concept for 2005 and was pretty successful. The concept of packing code into archives (jar/war) has proven to be pretty durable.

Kubernetes is explicitly about managing horizontal scale where the hardware is abstracted away.

That's not the point of the analogy. The point is that k8 and JAS are designed for "large scale" deployment, whatever that means.

(But yes, you're correct about what "large scale" meant in the early 00's)

You don't think Kubernetes is used for bin packing?

Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it.

Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult-y bits. Containers, serverless/FaaS, and Kubernetes can be pretty great if you're the plane pilot dropping the cargo on the island rather than the cult living on it, and future stuff will probably be even better.

Oh they have and are; but what is the business case open source such a wrapper? Wouldn’t you just host it on your own hardware and basically be another Heroku? This kind of software is complex enough it would take corporate backing (either an industry group or VC backing) so it’s probably not getting built unless there’s a business case.

Even Google only released K8s because they thought it would push people towards GCP — which it didn’t because it was too easy for AWS to implement a similar service using Google’s open source tech. The open source freemium model for infrastructure tech is pretty much dead as a result of this kind of activity.

The wrapper can still be something self-hosted. There will always be SaaS/PaaS/IaaS abstractions out there for just about everything; even MySQL. The idea would be for someone to be able to very easily self-host something that's as simple to use and configure and interface with as AWS EKS or Google GKE.

I have no idea what business case there'd be to open source it. Maybe some open source devs with former experience at a big company will create one just for fun after they leave the company? Who knows. It'll probably happen eventually, by someone, either way.

Would you do your day job “just for fun” after you just quit?

The reality is that most of this technology — especially around infrastructure — has become so complex at scale that the tech strategy and the business strategy are the same thing. So infrastructure software has to match your business architecture which is largely dictated to a technology org. Which is why “tech ops” these days is largely just “ops” — the technological complexity is a reaction to increased business sophistication, not the other way around.

Me? No. But some people seem to like to do that. And some people do seem to be genuinely very passionate about infrastructure and such. Kubernetes can be applied to a lot of different business and technological architectures, I think, and a simpler alternative could be similarly general.

> it was too easy for AWS to implement a similar service using Google’s open source tech

AWS had the most K8S deployments even before they released EKS, according to the CNCF:

https://www.cncf.io/wp-content/uploads/2018/08/cncf_survey_g...

Or perhaps somebody will evolve Kubernetes itself into becoming simpler?

I know that's a pipe dream, but really, why does it have to be? What would have to happen for people to actually work on making existing things simpler and better factored rather than reinventing the wheel?

My personal theory is that it's largely because that kind of work simply isn't being valued highly enough. Reinventing the wheel is a much lower friction path to take and has a higher chance of being rewarded highly. It shouldn't be like that, though.

I think k3s is sort of trying to do that?

Have you tried it? Is it any good? I've been looking for a simpler Kubernetes, although I don't know how much simpler it can be in practice and still do the same things.

I've tried k3s, and while I was impressed, it leaves out several important features.

RKE is a great alternative, and kubespray is quite stable well.

How about Hashicorp nomad? (https://www.nomadproject.io/)

The problem with making things simpler is compatibility. If you make something simpler, but don't stay compatible, it might be better to just find a new name for your simple version.

Do we even need k8s for a personal blog? What problem does it solve for someone coming from docker or a VM?

k8s is a building block one can use to provide a simpler service, and if you want to convince anyone it needs a refactoring, maybe provide some specifics?

That would be knative.

> Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years.

I know it's not the same but Docker Swarm is pretty great if you just want to deploy some container images on a single host or a cluster - this guide covers setup + traefik + swarmpit ui https://dockerswarm.rocks

I think you’re getting it backwards here. Kubernetes was explicitly built because the existing solutions were not robust enough to enable containerization at Google’s enterprise clients. Docker existed, and there were plenty of quick and easy ways to deploy your blog from a docker container and get it working. Those still work today.

The “running my blog” use case is a Docker use case. Kubernetes was designed from the ground up to enable transparent integration between containerized apps and ITSM platforms. I have always viewed it as more of a scaled application framework than a hosting platform.

What about Nomad? It looks simpler, although it doesn’t seem to have batteries included for things like ingress. I’ve never used it, but I’m curious.

But then the question arises, why would I need kubernetes to run a small blog... why not just run the blog. I mean.

Reply on news.ycombinator.com