5 ms·

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.

paulryanrogers 4y ago
Do you mean bare metal?
jdub 4y ago
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.
- vanviegen 4y ago
  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.
  - deleted 4y ago
    [deleted]
  - tekla 4y ago
    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.
    - astrange 4y ago
      What happens if they fail in a loop and you end up in “livelock”?
    - hackmiester 4y ago
      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.
      - LawTalkingGuy 4y ago
        > 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.
      - mschuster91 4y ago
        > 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.
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
  - tomrod 4y ago
    > Reliability for a single server is high In what context? Individual instances fail frequently.
    - astrange 4y ago
      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.
      - jdub 4y ago
        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.
tekla 4y ago
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.
- gtirloni 4y ago
  > Pets are a artifact of laziness I was with you until this unnecessary point.
ranger207 4y ago
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

paulryanrogers 4y ago

Do you mean bare metal?

jdub 4y ago

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.

vanviegen 4y ago
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.
- deleted 4y ago
  [deleted]
- tekla 4y ago
  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.
  - astrange 4y ago
    What happens if they fail in a loop and you end up in “livelock”?
  - hackmiester 4y ago
    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.
    - LawTalkingGuy 4y ago
      > 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.
    - mschuster91 4y ago
      > 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.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]
- tomrod 4y ago
  > Reliability for a single server is high In what context? Individual instances fail frequently.
  - astrange 4y ago
    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.
    - jdub 4y ago
      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.

tekla 4y ago

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.

gtirloni 4y ago
> Pets are a artifact of laziness I was with you until this unnecessary point.

ranger207 4y ago

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