These are not aimed at traditional DC/Enterprise workloads.
They are aimed at the likes of true hyperscale customers (read 100,000 plus servers), say Facebook or linked in. They perform HUGE amounts of web facing tasks (hence the mention and drive in this space) and you have to completely rethink your architectures (application design, storage, through networking and now the server). All the intelligence is in the software, read MASSIVE parallelisation, lots and lots of low power, low performance nodes are perfect here thanks!
1. See my first point, maybe an issue when you need to access lots of memory, but web servers and scale out apps dont (the scale out gives you the access to large resource, more than you will ever get with scale up), 32-bit is perfect here thanks! (seeing as most web apps are still 32bit anyway!). These are NOT aimed at traditional workloads.
2. Why not? Cheap and cheerful, all thats needed is a bit of metal to let me rack it. I dont need fancy management or clever interconnects, just a bit of shared power and cooling (dont really need full HA in these subsystems either) and the density. Traditional blade chassis are aimed at solving a different problem (and are very good at that).
3. Why is that a problem? To be hyperscale you need to run 100,000 plus servers, you really think loosing 4 is going to be a problem? You will also note that you cant hot swap boards either, when you want to swap them (simply wait till over half of them are failed), just take the whole tray out (72 servers) and slap a fresh one, chuck the other in the bin.
Also you will notice these dont have storage either, they are truly stateless i.e, my OS is pulled from an image server on boot and run in memory, I need lots and lots of the same thing, why stick it on local disk for every server (also makes tasks like reimaging a complete doodle, change the image on the master server, then just reboot whole racks!)
These hyperscale customers shunned enteprise type architectures (hence no blades) as there is simply too much control and intelligence in them (which adds cost and complexity) and quite frankly things like seperate storage arrays just DO NOT scale big enough. All of that is in their software layers. This is why the likes of Dell DCS and HP SL line were initially bought out. Benefits of shared power and cooling (not quite as eficient as blades, but good enough) and the density, but no excess "crap". However the weakness was always the processor, too good for what is needed.
These things draw about 3w a core, even the best Intel Atom draws about 15w! (now scale this across 10's of thousands of servers and see why people are getting excited!)
Think of it this way, we only introduced virtualisation (hypervisors that is) because CPU's have got too powerful and we needed a way of carving them up. We initially started using virtualisation in a big way on web front ends, where the problem first started to appear. All we did was add cost and complexity to mask the real problem (begs the question that if we can perform much more granular hardware partitioning, ultimately why stick a software layer in the way?)
So why not fix the actual problem. Im not suggesting these will replace computing as we know it, but its a damn fine way of solving a large percentage of the workload in the simplest way possible!
All that was required was for someone to think a little bit outside the box .................