A single server can go a long way these days | Hacker News Reader

A single server can go a long way these days

twitter.com

48 pointstosh28 comments

I think the key message here is that knowing when to use a given technology (e.g: Kubernetes) is good - but it's more important to recognize when not to use it.

Don't get me wrong, I love Kubernetes, but I agree w/ Kelsey here - if you're running Kuberenetes on top of an orchestrated hypervisor and not using it to the fullest, you're just losing on performance.

I think we generally forget how bare metal (and scaling vertically) can sometimes be the right approach, like illustrated in this Let's Encrypt blog post: https://letsencrypt.org/2021/01/21/next-gen-database-servers

I wish there were some $$ numbers on that post to compare to EC2 instances.

I wish there were more people saying stuff like this these days. Reaching for k8s right out of the gate is so rarely the necessary approach.

One of the problems is managing a server is a giant pain in the ass. Say you run your Java app on the said H3 instance, keeping it “clean” requires tooling like ansible or chef. Docker is another option and containers are a nice abstraction. You can still run a single container on this giant instance.

But then you have to update the container, and you need a script to do it. Then you need to roll something back, maybe automatically. Maybe you want a load balancer in front of your server to do TLS termination, and at this point you’d benefit from just using k8s (or ecs or google cloud run)

For a single server I’d rather have one config management system - Chef/Ansible/… - and just have that set up docker & nginx, rather than have config management set up Kubernetes, and then also need to write Kubernetes manifest YAML files in addition to my config management thingies.

On my home server I use Chef. I have a recipe for each service that sets up a docker container plus an NGINX config that does the TLS and port mapping stuff. To handle container updates I run Watchtower (https://containrrr.dev/watchtower/) which pulls and then restarts my containers when I send a POST.

Deploys are super easy, just docker build, docker push, curl -h $DEPLOY_TOKEN $DEPLOY_URL.

don’t need anything complicated for rollback, just retag and curl again.

As I said to the other guy - that configuration had to go somewhere, and for a single server it’s not going to be much. I don’t care if it’s 50 lines of bash, or chef, or yaml. I’d guess that the complexity of configuring find and your services is roughly equivalent to the k8s yaml on a simple setup.

It’s a sidestep of complexity IMO.

Personally, I find it loads simpler to use Packer + Terraform, and boot new machines when I have to re-spin the Packer image. Some of the Terraform modules maintained by the cloud providers can reduce the amount of boilerplate you have to write by quite a bit. It’s still non-zero configuration required, but IMO it is easier to understand and manage than piles of YAML.

You only have piles of yaml if you have piles of stuff to use. If you’re just running a single container then it’s not really much yaml at all. The config has to go somewhere, and 50 lines of yaml vs chef vs terraform - I don’t really care.

In the current ecosystem even for a single server I would use K8S via something like minikube. You get for free: operators, observability, a standard API (so you can use helm and such), ...

> Reaching for k8s right out of the gate is so rarely the necessary approach.

Then what is? It seems like a lot of the single server ochestration stuff has all been left to rot.

There is a simple heuristic for what to use:

Use whatever keeps the cloud costs the lowest while ensuring the reliability is acceptable.

For client projects, a trick is to pretend the cloud expenses are coming out of your own wallet.

The title and FTA are true but the economics for a startup is tricky.

One of the spectrum is true bare metal - setting up a data center, space, power, cooling and all of that.

Next step might be colocation.

The other end of the spectrum might be something like Firebase or DynamoDB. A step to the left from there might be Cloud Run, and then GKE.

It’s difficult to know how to spend your time and money as a function of the associated costs and maintenance.

Unfortunately from what I’ve seen the big clouds are a bit too expensive compared to the likes of Hetzner et al to just overprovision and forget about it.

I will say that it’s getting easier to have a self hosted set up that supports failover well with CockroachDB, TiDB and such.

The app side still needs refinement. Maintaining a k8s cluster on bare metal isn’t trivial.

He points to Ruby on Rails for this sort of configuration.

I’d say the inverse…… Ruby on Rails is so slow that it needs larger computing power. Using Golang for your back end single server will wring out the performance you need from that single machine.

> Ruby on Rails is so slow that it needs larger computing power.

That's true, but...

If you measure both developer productivity and server costs and on unified metric, for at least some projects it's 100% worth paying for powerful servers so that you can use the unbelievable magic that a good Ruby on Rails team (or single dev) can sometimes achieve.

I've seen many times over the last 10-15 years where a good Ruby dev or team pushes out a working project in a weekend or just a week or two - for something a typical Java dev team would still be writing requirements docs and editing boilerplate from their dev tooling.

I probably wouldn't want to have to support the RoR project up to Facebook or TikTok scale. But neither Facebook nor TikTok are supporting the code/platform/decisions they launched with either. Hopefully whatever your project is, it'll start turning over enough profit to pay for a 50 person dev team to do a ground up rewrite choosing a stack based on observed user behaviour at scale rather than guesses or hopes about what users are going to need.

>> the unbelievable magic that a good Ruby on Rails team (or single dev) can sometimes achieve

I don't believe that Ruby On Rails has magical developer productivity beyond other technologies.

If yes, explain the mechanics of it to me.

Ruby on Rails does nothing special beyond Python or TypeScript or Golang or whatever.

The idea that Ruby On Rails is magically more productive is just fiction created by Ruby enthusiasts.

I use Django, which is also very slow, for the vast majority of projects and a few of them run on the same server with no issues.

The "single Hetzner server" approach has only failed me once - and we fixed it by just migrating to a bigger single Hetzner server. Computers have gotten very fast!

As others have said, by the time you have enough users to outgrow the easy-but-slow stack, you'll have enough money for a rewrite.

Thats a small single server he uses as an example.

Multi TB RAM and 128+ cores on one node is pretty easy these days.

Cheap boxes are cheap nowadays. It really depends on your risk tolerance and skillset. If you have the skills, then lowendbox.com (or hetzner) is your friend.

You most likely will never outgrow your first box, because you probably won't have m/any customers.

That said, if you want to scale w/o work cloud is really the way to go. Our infrastructure costs are less now with 1bn requests (250TB) over 30 days compared to when we were doing 1k requests/month. That's what can happen when you leverage the cloud. And that's with 2 mostly FTEs. That even includes the massive amount of telemetry we have (which we're handling ourselves).

2TB RAM on a single server is possible these days and isn't even exotic anymore.

It's not only possible to run single server, but even memory-only single server in many cases (if you are willing to pay for it).

If you have an application/architecture which can benefit from 64GB or more ram, or 32 or more cores, the payoff time compared to running on AWS is probably single digit months. Perhaps twice that for some of the smaller and hungrier wannabe hyperscalers.

From my perspective and this is based on every single project I've worked on in the last 20 or 25 years, the development velocity you can get with a tiny team building a monolith that can be reasoned about successfully by non genius level developers makes it totally worth going all in on a single server monolith. You do need to acknowledge that you'll rip and replace it all when(if) you start to approach the level of growth that justifies having a development team of at least several dozen, who'll need to split into teams of 2-5 working of sub components to be able to have the entire team work well. But until you can afford to pay for that team of 30 or 50 or more devs, stick with the single server approach.

Bold words from captain Kubernetes. Meant in good spirit, just having fun

Kelsey is not against Kubernetes, just like he isnt against Microservices.

But like me he wants you to really THINK and CONSIDER why you should use Kubernetes and Microservices in the first place.

Kubernetes has its place.

Single servers have their place.

Monoliths have their place.

Microservices have their place.

In the end, its all about tradeoffs.

I think about it plenty for work :( None of this is a judgement, elbowing between unknowing friends

So kubernetes has been around for more than gen years now and the argument doesn’t look at way to “just doing the bare minimum” and get the best of both worlds as long as you’re okay with spending a bit more.

Dumb idea: launch an eks cluster ok aws (managed control plane, little to no mgmt time + painless upgrade) and just create a nodegroup with one node.

You get all the benefits of kubernetes and you can upgrade the underlying machine with no downtime (add a new node to the node group, drain the old node, delete old node)

Which is why I really like Oxide's approach even though it is aiming at the enterprise market. Where they design the whole Rack as a single computer rather than our current server which is as small as 1U and could have 2 Node inside it.

On another note I just looked up the non-Hyper Scaler cloud hosting and DigitalOcean is now worth $3.5B market cap. They are doing much better than I thought. Compared to Linode which was acquired for $900M in 2022.

By "single server" he means cloud VM with network storage and migration strategy implemented by someone else.

Question: Would provisioning a very large single server to run multiple apps or things be considered a valid Cloud pattern?

Yeah, and probably "boring technology" in a good way. Shared hosting using CPanel and Plesk used to run a huge percentage of the SMB web/email/filestorage market.

You need to work out whether you can trust all the multiple app devs enough to take on the risk of bugs slowing or crashing the entire server and how that impacts whatever uptime and SLAs you need. (and whether you trust all the app devs to write secure-enough code...)

Reply on news.ycombinator.com