Reading through this and it feels very... dated. Firewalling your game servers is just not a good idea if latency matters at all. It shouldn't really be presen

Reading through this and it feels very... dated. Firewalling your game servers is just not a good idea if latency matters at all. It shouldn't really be presented as an option. Separate VLANs or subnets or some other method of segregating traffic is the correct answer here. I understand there is a disclaimer, but it's just not ever the right choice. Out of band management: If you're in a production setting and having to manually fix mistakes when you broke your IP configuration, you're doing it wrong. Why are you not using configuration management tools? Why are you manually configuring your servers? If you're using the cloud, why wouldn't you just toss away a broken instance? Fault tolerance: Vague statements about how building in redundancy is somehow a single point of failure itself. It mentions further details are available in some other chapter, but that chapter appears to not be on the site, or isn't written yet, or something. This seems somewhat nonsensical to me, as there are many proven high availability configurations. RAID: Software raid is fine for a game server vs. hardware raid? There's so many caveats to this... If your RAID is software based, that means your CPU is handling the calculations required for the RAID. Do you have the spare cores for this? Will it negatively impact server performance? Will it perform as well as it would with a dedicated controllers? How often are you loading things from disk? Blade servers: Unsubstantiated anecdotal evidence about how blade servers are less reliable. If they're really less reliable, there should be data on this. This appears to be the beta for a book that will be sold. If this is a product, back up your assertions. "Mission critical servers": Recommendations to put your mission critical servers on a 4U because this will somehow make them more reliable than on a 1U or 2U, despite many failure modes having absolutely nothing to do with the amount of space the server takes up on the rack. SANs: Apparently these are not acceptable for database servers. I believe many of us are in for rude awakenings. RAID with battery backed write cache vs. NVMe: Apparently it does not matter what type of storage you are using underneath the RAID as long as you have a write cache. No mention of what happens if you are pushing more data to the RAID controller than can be cached before being flushed to the disks backing it. Cloud storage: "Just now" cloud providers are providing virtual machines with local disk options. Last I checked, many of the big name cloud providers launched their virtual machine offerings with local disk options. Vendors: Just avoid SuperMicro? No explanation here beyond they're "not mature enough". I suppose two and a half decades isn't mature. Browsing some of the other sections, like the 'Cloud' chapter... "Hardware Replacement": Mentions that cloud providers will automatically instantly relaunch a busted instance for you, and that you'll lose your hard disk data. Many providers don't automatically do anything of this sort, and if you are using network storage, you certainly aren't losing your storage because you moved your instance to new hardware. Network throughput: Somehow a 100mbps port is going to push out 13 petabytes of data in one month. I'm not entirely sure how. VM migration: Apparently all clouds live migrate VMs, and these live migrations with small latency spikes are worse than complete failure. Large boxes: Those 4U boxes in the other chapter supposedly do not have equivalents available in the cloud. No mentions at all of the tradeoffs in performance on virtualization vs. bare metal, mitigating factors, etc. I honestly feel like this was written by someone who is stuck architecting things like it's 2002.