The danger of controlling too much of your stack ...

This is related to an issue we ran in to, today, and several other times. It sounds strange, but if you maintain rigid control over a huge swath of your stack, you run a fairly serious risk of being unable to respond to changing environments as quickly as your competition. The law of un-intended consequences bites you, fairly hard. Worse, you rarely, if ever, realize it, until it is too late. For example. Suppose you are an iSCSI stack provider. You want to build iSCSI stacks. So you build a target and an initiator. But you decide you really want to make peoples lives simpler, by removing the complexity (read as “choices available”) in using your stack. So you decide to adopt a single platform. Time goes on, that platform that you are locked to ages, and isn’t updated as quickly (you are locked to it, but you don’t own it) as you might like. So you start falling behind in systems support. All the while, more nimble competitors are grabbing up mind share and market share, as they are focused upon provide great tools, not a platform. Sounds strange, but there is danger, fairly significant danger, in providing a complete solution platform.

The issue is that platforms require maintenance and upkeep to enable them to leverage newer systems. You can easily lose out providing 2+ year old kernels which don’t do a good job of supporting the latest motherboards/RAID/network/… cards. Which is what we ran head first into, today. In order to accommodate a particular older kernel for a specific platform that an application stack is locked to, we have to make some engineering decisions to use a different and older card than we had planned. This is because this older kernel lacks driver support for the newer card. It lacks many other things as well. The application vendor effectively owns their stack, they are responsible for it. It doesn’t look like it would be hard for them to migrate to a modern kernel and user space. That would certainly help everyone. Slipstreaming drivers into application appliance stacks can work, but the appliance software vendor would be loathe to support that. We are caught in something of a maze on this. I have a path that will work, though it is not what we had been hoping for. It could work. But this path is being forced upon us by a vertically integrated application stack. I’ll see if we can install their stack, update their kernel, and go from there. Chances are they won’t like it. There is a cost to every decision.