If you blew $100k on your SSD / Memcache project and have nothing to show for it, then there is something wrong with your engineer or perhaps you have a rare app that does not benefit from cache…. which I find hard to believe.

I agree that you power costs must be astronomical… this would be helped tremendously if you built a cache layer that was hit before your dbase layer.

Finally, you can get a 32GB SSD that is SLC for $400.

Bottom line, I like to see real hard data, not marketing hype. Bring me an appliance that solves my problems, I will negotiate the price and get a better bottom line for my company. Now thats only what I care for.

You get more of them, and if they fail, they can be:

a) replaced cheaply
b) take down only 1/x of the infrastructure dedicated to that service/pool

Putting your eggs in a giant basket/schooner is precisely what they don’t want to do @ their scale. Data center engineers @ GAYM assuming failure as a constant in their environments. Distributing that failure equates to lowering the probability of sustained downtime and impact.

Additionally, the granularity allows a data-center to evolve to more modern hardware smoothly… decommissioning a machine doesn’t mean loss of service.

Enterprises are a different story, and schooner may have a shot there.

An observation about appliances generally: if you are big enough to need extreme performance that might justify buying an expensive appliance rather than using a large, generic server, you usually have someone around who can tweak and tune the server application to get a similar result less expensively. It is a rare company that has Internet-scale web apps with racks of servers and yet lacks the resources to administrate them such that it would justify an appliance as a shortcut. For certain very specialized domains there might be an argument for it, but not for generic applications like MySQL and memcached.

Specialized appliances find their sweet spot in the market as an abstraction layer for complex functionality that fits poorly in vanilla server hardware (think core routers) or by using the appliance as an interface to unique functionality that offers more than just first-order convenience (e.g. some database analytics appliances). Simple convenience as the abstract selling point for an appliance is a hard position to defend over any length of time; someone will inevitably separate the convenience from the hardware, and sell it at a significantly lower price.

I’m not banging these guys at Schooner, specifically, all power to them – as if my opinion matters at all. The general trend has been for application specific boxes, like XML accelerators, to just never get traction in the market.

That said, there is a problem with today’s n-tier model, not actually the model, but the way it has been pushed into the field. That connection between application server / logic, and database is just such a mess, and it has spawned these bastardized tool-sets to cure the illness. I’m just not sure that custom boxes are the way to address this crappy coupling of database to app server.

See Openlinksw.com, where they solved the issue of coupling years ago. They got no respect for the brilliant and elegant solution of vertically integrating the app server, language hosting run time environment, and the database server. As a company, they have solved so many legacy problems and moved on, now to the CEO’s evangelism of Linked data, which I completely fail to comprehend; Kingsley lost me two years ago at RDFS.