| Every network access to disk based storage... Rare for most services. Stuff like logs can be shuffled off elsewhere for a write, requiring no commit validation. Only DB/fileservers really require permanent storage with commit validation, writes are typically rare, and 100Gbps+ LAN on a PXE-based diskless cluster is not going to be introducing massive latency, especially if you prioritize the VLAN or link multiple ports. Reads are typically cheap and cacheable. that can't be cached|copied to the your ram filesystem for the lifetime of your container IMHO most services and their dependencies will come in well under 512MB, so that's a non-issue. you can't scale with RAM backed storage without more phys memory By definition, one could say the same about anything... although to be fair you could still scale via compression, sharding, or another established strategy. when you run out of RAM... In a managed scenario a service container or VM would terminate or a significant degradation in response time would be detected, it would be taken out of the service pool and stop having traffic routed to it, be restarted, then be re-introduced to the pool. Ditto extra CPU load, broken network policies, anomalous block IO, etc. Leaving modern service-level architecture aside, basic heartbeat-style IP monitoring with reliable node-level failover has existed in open source since the 90s. There's really no excuse to wing this stuff on production systems today. it's not something that is one size fits all Nothing fits all! |