Components and Commodities

Matt Micene has a great example of the confusion that comes when you start thinking about IT infrastructures as a collection of components. It’s a great starting point for a discussion of commoditization, resuable parts, and lock-in in an IT shop.

The word “components” is being used a little too casually. I’ll take responsibility for this, since I used it very casually in the Mil-OSS presentation that inspired Matt’s post. So let me introduce a little discipline: components are discrete, reusable parts. They’re useful because they’re well-defined and they’re modular. Having discrete, reusable operating system configurations makes sense. If we can’t distinguish between an application and an operating system, we have a maintenance nightmare. Likewise, having components like application servers, web servers and databases makes sense. A component isn’t naturally open, though. It can be closed, proprietary, and available from only one vendor. Ensuring that everything in your infrastructure is understood as a component is a great first step, but it’s just that: a first step.

Once you solve enough low-order problems through componentization, you’ve crawled your way up to very high-order components and you start getting nervous. These reusable components start looking a lot like the inflexible, brittle monoliths you were trying to avoid. Matt’s automobile metaphor is useful: a car is filled with components, and all cars more or less accomplish the same task, but I wouldn’t dream of suggesting that all cars are components.

So components are useful, as far as they go. But what we’re really after is commodities. Let’s think about commodities as a special kind of component. They’re special because they’re not special: an undifferentiated good. Commodities have all the qualities of a component, but anyone can make one and you can buy them from many vendors. Because you can compete them, the cost is very low.

So to the treehouse. A treehouse is composed of commodities like nuts, bolts, and pine 2×4’s, but the overall system can’t be usefully called a commodity or even a component. That’s fine, as long as you’re after a hand-crafted item that’s specific to your family. But that’s not what we want in an IT shop. It’s too expensive, and creates too much risk. The cost of materials might be low because we’re using commodities, but the cost of labor and system complexity — the operational debt — in the overall system is high. Saying that I want treehouses to be commodities, I don’t mean we should use monolithic systems. Just the opposite. To the extent that we can commoditize higher-order components which are themselves composed of commodities, we’ll be saving ourselves a lot of heartbreak. The Open Compute Project is a great example of what I’m talking about. The challenge I presented to the Mil-OSS folks was this: how can we make it as easy as possible to decompose these handmade, bespoke IT systems into reusable, repeatable commodities?