A single server can go a long way these days

https://twitter.com/kelseyhightower/status/1827422119640383697

by tosh • 2 years ago

48 28 2 years ago

twitter.com

bravetraveler2• 2 years ago

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

mindcrash• 2 years ago

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.

bravetraveler2• 2 years ago

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

cjk2• 2 years ago

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.

maccard3• 2 years ago

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)

jitl• 2 years ago

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.

cjk2• 2 years ago

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.

awoimbee• 2 years ago

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), ...

bsder• 2 years ago

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.

thelastparadise• 2 years ago

Thats a small single server he uses as an example.

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

andrewstuart2• 2 years ago

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.

bigiain3• 2 years ago

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.

andrewstuart2• 2 years ago

> 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.

franga2000• 2 years ago

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.

firesteelrain• 2 years ago

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

bigiain3• 2 years ago

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...)

denysvitali• 2 years ago

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

fragmede• 2 years ago

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

OutOfHere• 2 years ago

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.

dragontamer• 2 years ago

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).

bigiain3• 2 years ago

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.

endisneigh• 2 years ago

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.

ksec• 2 years ago

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.

mannyv• 2 years ago

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).

remram• 2 years ago

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

znpy• 2 years ago

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)

A single server can go a long way these days

Related Stories