What Data Center Designers Can Learn From Legos 210
1sockchuck writes "It takes most companies at least a year to build a new data center. Digital Realty Trust says it can build a new data center in just 20 weeks using standard designs and modular components that can be assembled on site. The company equates its 'building blocks' approach to data centers to building with Legos — albeit with customized parts (i.e. the Millennium Falcon Lego kit). Microsoft is taking a similar approach, packaging generators, switchgear and UPS units into pre-assembled components for rapid assembly. Is this the future of data center design?"
More Present Than Future ... (Score:5, Interesting)
Is this the future of data center design?
I'm going to assume you're talking very very large data centers here as it wouldn't make sense to streamline this for a few "blocks." But I think this is an already pretty pervasive idea. Why, we have already talked about Google's ideas on server 'blocks' [slashdot.org] and data 'pod' [slashdot.org] technology for their sharded databases. While I'm not sure if this high level design inherently affects relational databases negatively, it sure seems to be the future of data centers.
Google's strategy sounds even more like homogeneous Lego blocks than either of the two article's solutions.
No, the future is heavy customization. Psych! (Score:2, Interesting)
Someone's going to retort that this is only because America hasn't built a new nuke power plant in ages, but the fact of the matter is that nuke power in Canada and France is reliable, efficient, and cheap because they have settled on a standard plant design. Contrast this with the fully customized design for each American nuke plant and you can see why we still consider nuclear power to be expensive and dangerous.
Extend this to software design. Sure, using standard libraries may mean that you are possibly using a sub-optimal algorithm or pulling in too many unwanted/unused features. But the alternative is to spend a lot of time reinventing the wheel. When it comes down to brass tacks, the cost spent to optimize software pales in comparison to the cost of delaying the product.
Use your time wisely.
Demand matters (Score:4, Interesting)
"The company equates its "building blocks" approach to data centers to building with Legos -- albeit with customized parts (i.e. the Millennium Falcon Lego kit). Microsoft is taking a similar approach, packaging generators, switchgear and UPS units into pre-assembled components for rapid assembly. Is this the future of data center design?"
It only makes sense to maintain the infrastructure to build the building blocks so long as data centers are being rolled out at a furious pace - something that cannot continue forever.
I suspect the 'Lego' builders are betting on vendor lock-in to feed the bottom line over the long term. Once you buy their bricks, you're pretty much stuck with their interface and thus will be coming back to them for upgrades and renovation.
Re:More Present Than Future ... (Score:3, Interesting)
While I'm not sure if this high level design inherently affects relational databases negatively, it sure seems to be the future of data centers.
If you build apps using Google App Engine, the APIs offer you an API to BigTable [wikipedia.org], a non-relational data store. There is no relational database support.
I learned a lot from lego bricks (Score:5, Interesting)
I learned that given a large enough supply of Lego bricks, their flaws become readily apparent. We owned a day care centre, so I had literally twenty pounds or more Lego bricks at my disposal (after hours and then after we sold the centre).
Legos are heavily dependent on gravity, the gripping power of a brick is impressive (especially if they are new), but torque is more impressive. There is a limit to how far you can build a Lego ledge, and that includes shoring it up with Lego bracing (diagonal Lego bracing is more susceptible to torque). The torque doesn't apply well to a brick that's designed for straight down pressure.
Legos are heavily bound by gravity. The compressive forces of the walls provide grip. In my attempts to rebuild cathedral wall structures, the compression could not be balanced between the flying buttresses and the inner walls, so the buttresses mainly provided a stabilizing effect. The problem was that at about five or so feet, the bottom bricks would not hold because the weight of the bricks above expanded the plastic enough to negate the brick's grip.
Legos provide little resistance to upward pressure (by design this is how you release them, to a degree). This means that as structures sway, you effectively reduce the gripping power of some connection within the structure. This is the equivalent to stress related failure. A larger Lego structure must be glued or it will fail due to these internal forces.
Finally if you attempt to fix some of these issues by sandwiching critical joints, you add mass, which compounds the problem in other joints. Shoring up those eventually just increases the number of locations where failure could occur and statistics steps in and assures at least one failure, somewhere.
I won't even go into the issues with worn bricks, because those are obvious.
Few data centres expand to the size of our largest data centres, but by "designing like Lego" we will simplify things. The danger is that we might standardize on an architecture that has built-in limits. The architecture we currently have isn't as clean in vision as a Lego brick, but it already scales better than the Lego brick, even if it needs to do so by the default structure being slightly less elegant.
These Lego data centre visionaries have the right goal, making it simple, but they might be going about it in the wrong way. I've never heard a rational argument detailing how Lego bricks and data centre components are the same, so this might turn out to be a bad analogy implemented in hardware. Time will tell, but the centres we currently have did not come as the result of people deliberately trying to make data centres more complex.
Software design and buildings in general (Score:2, Interesting)
Why can't conventional buildings use this concept? Granted you wouldn't do it on a single family house, but when you start to build the bigger buildings once you have the structural integrity built, would it be worthwhile to slide in a building block that makes up a condo or a room or an office space?
It would make firewalls easier, and if the new "room block" had standardized connections for water, sewer, central air, electricity, and telecommunications, such connections could be made nearly instantly, and they could be metered. This would effectively lower the rent for all tenants, save the building owner on hefty utility bills, and pass along such costs to the tenant. Bearing the burden of utility bills has a marvelous effect on conservation.
Imagine what this could do for the new "green" building craze that's started up recently. Some "room blocks" could involve green technologies. Solar Panels on the exterior walls, or heat absorbent walls to allow the heating of water or whatever else a tenant might custom build into their "room-block" before ordering it from the room-block factory.
I think a lot would have to happen before economies of scale made this even remotely viable. A city would have to have dozens of very large buildings compatible with this system before anyone will be much interested in building a new building that is compatible with the system or develop a factory to manufacture them, or a transportation system that will swap them in and out on-demand and bring them to the warehouse to be refit.
Re:What is this LegOS? (Score:3, Interesting)
Certainly nothing to do with LEGO which are little plastic bricks, that aren't good for halon delivery systems.
No, u. [youtube.com]