For me what made a huge difference was adding acid, specially for stews. A hearty splash of vinegar or soy sauce while stewing, or even a dash of lime just before serving takes it from “meh” to “seconds please!”.

Time to piss off both camps an start calling it f5x.

Looks like an old one too, based on the ashtrays in the armrests and the “stereo” headphone plugs.

Donwside to 2: Your VM becomes harder to move between hardware, you lose snapshotting capabilities from a copy-on-write image.

5 is flexible, but has limitations. For example you wouldn’t want to run databases on NFS volumes.

If initialization time is the only problem with 4, you could create several smaller images on the disk. Create the first one, initialize the VM and set up an LVM volume on it, then start creating more volumes and extend the LVM volume.

These days I would recommend CrowdSec over fail2ban.

Good article for discussion.

Health checks is one situation where kubernetes really shines. It makes a clear distinction between readiness probes (when the pod is ready to start serving traffic), liveness probes (when the pod should be considered dead), and startup probes (when the pod has finished bootstrapping). Coupled with autoscaling it then becomes acceptable to have a pod stop serving new traffic when it’s too busy, because other pods can be created in a short time to take the extra load.

Including backend checks in your application depends on its nature. I think the mistake that the article’s author made was not to include the checks, but to have too big of a blast radius when the check fails.