Ask HN: If not Kubernetes, what do you use to run your apps?

[tontony]

Kubernetes is everywhere these days, and it might feel like there are very few alternatives to it when you need a simpler sort of self-hosted platform to run your apps/workloads (not talking right now about PaaS options like Heroku, Render, etc.)

- What do people use for single-server app management?

- For multi-node setups, is anyone using Docker Swarm, Nomad, or any other tool that is outside the Kubernetes ecosystem?

[lylo]

I have a single server running https://pagecord.com. I use Hatchbox on a Hetzner server. I wrote a bit about it here:

https://olly.pagecord.com/migrating-the-pagecord-rails-app-f...

I have plenty of paying customers but I still think K8s would be complete overkill at this stage.

[adamcharnock]

For deployment to a single-server I would certainly reach for Ansible as a starting point. Using that I would probably configure systemd units on Debian.

Speaking off-the-cuff (so don't hold me to this):

If you need multi-node for (fairly good but not amazing) reliability, then the easiest first step would be a cloud instance, rather than bare-metal server. Given live migration, they are effectively multi-node.

If you need multi-node for performance, then get a single dedicated bare-metal server. They can pack a huge punch while being cost effective. And you'll likely get 100% uptime in a good year.

If you need multi-node for reliability & performance, then kubernetes.

[psviderski]

Can you still justify K8s even if you need to jump from one cloud/dedicated instance to say 2-3 for reliability?

[adamcharnock]

I was being a bit terse in my original comment. I do think there are a bunch of other situations which don't fit into what I described above.

If scaling really is on the horizon, then yes, doing k8s immediately will save you some time in the long run. If that is the case though, you could always reach for a managed K8S service first (EKS/GKE), then deploy to dedicated later. Just avoid any entanglements with other proprietary cloud services, because that will be time consuming to untangle later.

[SamInTheShell]

Kubernetes just kinda won the container orchestration war against swarm, nomad, and mesos. It is quite an improvement over working with those orchestrators.

My strategy involves building stateless apps with distributed services that have good support in Kubernetes like Yugabyte and Minio.

What I do is host the thing on a cheap cloud server until it grows enough to need HA or scaling. At that point I move my workloads into a cluster.

I already have everything patterned out though so, I’m living in some sunk costs if anything newer or truly better comes along.

[tontony]

> What I do is host the thing on a cheap cloud server until it grows enough

Curious, do you use anything specific (like Compose) for that single-server phase?

[czhu12]

We open sources https://canine.sh for this reason!

It basically lets you keep the good parts of kubernetes, but not suffer any of the complexities

Use it at work, because we wanted the Heroku experience, without the prices.

[flybayer]

ECS is great and simpler than k8s. Flightcontrol[1] is an easy way to spin up and deploy to ECS clusters. (I'm a cofounder)

[1] https://www.flightcontrol.dev/

[mmarian]

Self-host CapRover (Docker Swarm overlay) on a $7/month Hetzner VPS. Use it to deploy 4-5 apps, on the same VM.

[cranberryturkey]

i just use a dedi