Decentralization is Hard. Really hard. It brings in all kinds of fun issues - What if you get bit flips on one particular node? What if a random host fails? Wha

Decentralization is Hard. Really hard. It brings in all kinds of fun issues - What if you get bit flips on one particular node? What if a random host fails? What if your load on your hosts is not perfectly balanced? What happens when you're halfway through a software deployment and half of your system's running a different version of the software? Not to mention most people aren't great at reasoning about even just multiple fault-free threads in the same address space, much less multiple threads on multiple machines facing potential byzantine failure conditions. Centralizing bits of it therefore will make these issues easier - at the expense of reduced scalability. So then the question becomes, "Can I get away with centralization here?" You look at the performance and failover characteristics required, and see if centralization will work for you over the next N years, and see what your plan (and timeline) for scaling out when your central box isn't enough would look like. And if you find you can get away with it, you probably should. Of course, nothing ever works out quite the way you expected. Maybe your fancy algorithm requires more memory than you thought. Maybe failover's a bit too slow. Maybe it's eight times more CPU-intensive than you expected and that one box isn't going to be enough. Things happen, and sometimes you get it wrong. Still, starting from a default position of "let's centralize what we can" will save you a lot of headaches, just because it's so much easier to reason about the system's behavior that way.