During my time as a SRE-SE I began to piece together that infrastructure tends to be born from small software patterns. Looking at messaging systems, key/value

During my time as a SRE-SE I began to piece together that infrastructure tends to be born from small software patterns. Looking at messaging systems, key/value stores, and even computational orchestrators much of their high-level mechanics comes from how you would produce such a solution in a monolithic repo. Obviously there's a lot of layered abstraction to make the solution generic enough, and there's code to make the system fault tolerant inside a distributed system which inevitably requires failure tolerance. I don't think I agree with this article though. Infrastructure solutions are good if you require robustness or the same solution is needed by many components that can share the infrastructure. Robustness in this case would be comparing a layer 8 load balancer and a thread that load balances workers. You could seemingly start up many threads on the same machine, or even segregate them by virtual machines (for example Tomcat does this) but if failure of a single host is of concern (or catastrophic enough concern) then dedicating the load balancer to its own machine is desirable. My point being, if you step back and look at what you're actually trying to solve for it will tell you where the infrastructure should go, and has the added benefit of influencing the rest of your surrounding ecosystem.