Hacker News Reader

Comment by edrxty | Hacker News Reader

It's especially frustrating because so many projects only ship with helm chart documentation for their containers.

If you're not doing a unicorn style deployment (100% of users) then you're SOL.

K8s is probably the best/closest thing we have to a workable service "package manager" for server environments. It's a fairly reasonable way of packaging and deploying random stuff to random servers in a sustainable and secure fashion when all you're trying to manage is a small dev pipeline or a prototype/homelab type setup. Instead it feels like the community is trying to skip right over some of the most beneficial use cases for the tech and go straight to nonsense unicorn land.

View on HN

I like the idea of "package manager" for servers. Could that not be docker / nix plus another layer?

I think the issue is that for almost everyone tens of servers is the sweet spot. Most teams and even most companies don't need to manage more than tens of servers (how many teams even in large companies actually use or even touch more than 100 servers in prod?)

But kubernetes can scale to thousands.

The leap past those 2 orders of magnitude chnages the game and makes the seeet spot out of reach for the majority. It's like we are taking F1 racing cars on our daily commute and stopping off for groceries

> I think the issue is that for almost everyone tens of servers is the sweet spot

No for almost everyone one server with some packages installed is the sweet spot.

> What if it goes down?

You users will survive a little downtime, if it happens at the right time they wont even know

> But containers

For this use case? A solution looking for a problem

> Why?

Don't be a company with more servers than users

One server is a very small operation though (or very simple software if scaled up).

One server can handle quite into the 1000s of concurrent users, that is for sure some people's definition of small...

For most it really isn't.

> I think the issue is that for almost everyone tens of servers is the sweet spot.

For single node deployments of containers, Docker Compose has usually been enough.

For multiple node deployments, Docker Swarm (possibly with something like Portainer) has worked well for years: it's easy to create clusters, they don't require much in the way of resources and running workloads is pretty simple, definitely in part thanks to the Compose spec.

Of course, there have been issues over the years (CentOS 7 I think needed masquerading for networking to work properly back then) and people might be conflicted about some things - personally I love my "Ingress" being just a web server container with whatever configuration I give it, others might want Traefik or something else, whereas more advanced use cases like task scheduling and replicated storage across the cluster don't have anywhere near as many solutions as Kubernetes does.

Then again, none of those are a deal breaker for me. Of course, something like Podman can also be considered, or maybe Hashicorp Nomad if you don't mind HCL.

How about tens of servers per customer, and tens or hundreds or thousands of customers?

I think the above comment "don't have more servers than customers" seems spot on as advice :-)

I straight up refuse to use helm templates. If a project doesn't ship raw yamls I just write them myself.

Reply on news.ycombinator.com