Hacker News Reader

Comment by gtirloni | Hacker News Reader

A 128-core 4TB "pet" is much easier to manage than the equivalent Kubernetes cluster with same capacity.

Not saying it's the way to go for every situation.

Its not a fair comparison to compare to k8s.

I've replaced pets with ASGs that do nothing but sit there unless the EC2 instance fails. Its amazing because you no longer have to baby the pet, it just recovers in a nice clean state, same massive instance..

Pets are a artifact of laziness.

> Pets are a artifact of laziness

I was with you until this unnecessary point.

It should still not be administered as a pet. In fact, it's even more important when you have a single instance of some importance to make it entirely rebuildable and replaceable.

If you manage to run your entire service on a single (heavy weight) server, uptimes will usually be excellent. Reliability for a single server is high. It gets lower for each server you add, unless you're adding redundancy. But that adds complexity, and that hurts reliability too.

My point: a single dedicated server may be a more reliable, simpler and much cheaper solution than the cloud provides.

Reliability means jack shit when I have a system that auto-recovers on any failure.

I literally do not care about any particular server. If it fails, it kills itself, and a new server comes up and serves traffic.

No alerts, no pages, nothing.

But you are introducing the complexities of managing a fleet. This may or may not be an improvement in overall complexity, cost, or reliability. This decision should be made per-project, and neither option is a good fit for all projects.

> the complexities of managing a fleet

These things are inherent complexities in any situation with backup/DR. You've already got to figure this out. When one machine is degraded and another is trying to recover from db logs, that's a cluster.

> This decision should be made per-project

This is one of the least project-dependent things ever, akin to source control. If you don't have scripted installs you don't know what you're running and you can't reliably test it or upgrade it.

You don't need to run a cluster, or have auto-scaling groups, just because you can.

> But you are introducing the complexities of managing a fleet.

Depends on who manages the fleet. An EC2 instance provisioned by Elastic Beanstalk is quite easy, the problem is EBS can be an utter PITA of edge cases and weird failure modes.

What happens if they fail in a loop and you end up in “livelock”?

> Reliability for a single server is high

In what context? Individual instances fail frequently.

They can fail much less often than you’d think. StackOverflow runs on 10-ish dedicated servers. There’s plenty of other services out there that don’t autoscale and are much more reliable than anyone needs them to be.

And if one of those boxes fails for any reason, hardware or software, I should be able to replace it 100% extremely quickly. Cattle, not pets.

A cattle server needs no special maintenance. Yes, if you only have one server then by definition it'll require special maintenance, but that maintenance should be as generic as practicable so that if you ever need to set up a second one then you don't need to do anything special. That's the distinction between pets and cattle, not the tooling: you can configure cattle by hand if you have a repeatable and non-special cased setup script to follow, and you can use Ansible or Puppet or whatever to set up the unique environment your pet server needs. The important thing is that the setup process, maintenance, etc is standardized and documented. Automated is a bonus that should be relatively easy if you're doing it right

Do you mean bare metal?

Reply on news.ycombinator.com