They say you should treat your servers as cattle, not as pets. When a pet gets poorly you take it to the vet and spend a lot of money treating it until it is well again. When one of the cattle gets poorly you shoot it.
A DB server is too complicated to be just one of the herd, but it is wrong to treat it as a pet. Consider it more like a prize bull, one worth giving a bit of attention to but also prepared to shoot if it becomes too poorly.
One of the key tools in making a DB server a prize bull is virtualisation. A DB server installed on to a physical box will always be a pet and demand more attention than it should get. A virtual DB server, especially if it is part of a guest cluster, can more easily be a prize bull.
All members of a guest cluster get built the same. If one member becomes poorly then build a new member, join it to the cluster and evict the poorly member (then shoot it).
Migrating through members of a cluster can also be useful when doing OS upgrades. My old place did this when upgrading the DB servers from W2016 to W2019. On the other hand, we always chose to build a new cluster with a new name when upgrading SQL versions.
Running SQL as a guest costs about 0.5GHZ of a single core in CPU overhead and about 500MB in memory overhead. The payback is flexibility of server topography. That flexibility gives a lower risk of a physical server failure causing an outage and a greater choice of pathways to deal with changing server topology to cope with business requirement changes.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara