Cogs bad
I love posts like this because, love it or hate it, it gives me a checkmark of thoughts to compare my choices to.<p>I see three possible approaches, all with their advantages and disadvantages. (Of course people may fit between them with a mixture of attributes.)<p>1. Monolithic - Build it all yourself, purpose built and high performance.  This is why mailinator and plenty-of-fish are able to produce high thruput on a surprisingly small number of machines.<p>2. Confederated - Completely distributed. Each machine is its own monolithic platform with everything from DNS to database, including web server on that node, but a cluster of nodes gives you scalability, and workload is distributed across the cluster.  (I'm not aware of any examples of this, which is why I'm building Nirvana.)<p>3. COGS: You build your cluster of machines by architecting a system whereby you minimize (but not eliminate) single points of failure.  You have N web server machines and X database machines and you seek out really high performance open source cogs to keep the number of machines low (e.g.: Redis, MongoDB, etc.)<p>The COGS approach is often taken with the idea that we need something really fast. MongoDB being fast (and "SQL") are the reasons its often chosen.  Redis being fast is given as a key advantage (which is relevant for an in memory database, sure.) Node.js is often chosen for similar reasons.<p>But the ends result of the COGS approach is a brittle architecture.  You may have multiple redundant web servers but the thing that distributes loads is a SPF.  More specifically the architecture is complicated- each machine has a different configuration, etc.<p>With Monolithic, you get performance, and save hosting costs, and you can probably scale pretty well because you know your system really well, and you've squeezed out a lot of the inefficiencies that come from being generic (in the cogs approach) such that you can interoperate.<p>What I think we should see more of is confederated- no machine is a unique snowflake.  Every machine is identical to every other machine.  This way configuration becomes dead simple-- just replicate your model node, bring it up and data and load starts going to it.<p>This can be done with cogs- but they have to be fully distributed cogs.  An example is Riak (Which hit 1.1 yesterday) which is open source and written in erlang and probably loses to nodeDB in every single single node benchmark you can come up with (not that the Basho people have designed it to be slow, quite the contrary.)   But where's the fully distributed web platform for such an architecture?  (If you have an answer, please make this question non-rhetorical. I'm putting a lot of time into building one because I couldn't find one.)<p>An interesting thing about the confederated approach is, because each machine is identical, it could be built in a monolithic fashion.  Thus super optimized for its purpose.  I'm using a sorta cogs approach because there are many good erlang cogs to use in my project.<p>But I think the big mistake is to focus on single node performance these days.  Servers are relatively cheap, and you need more than one anyway for redundancy, so might as well have a cluster and no single points of failure.