Utility Computing & Software Licensing Costs

In my previous article on utility computing I didn't talk at all about software licensing costs. In thinking about software licensing the key question I care about is: are software licensing costs a technology or a business challenge?

Most companies tend to run one application per machine in their data centers. A consequence of this situation is that per-CPU licensing costs for software makes a lot of sense. After all, the most expense component on most boxes is the CPU and all the CPUs are dedicated to a single application so it's pretty easy to do the licensing math on this basis.

Sure, there is an extra challenge when one is capacity planning and needs a bunch of idle machines for peak capacity. It's bad enough that one has to pay the expensive hardware related costs for idle machines, but having to pay software licensing costs for machines that generally aren't doing anything just seems to be adding insult to injury. In practice however, this really isn't that big a deal. Most companies know how to negotiate licenses and they generally will negotiate a pretty serious discount in their licensing costs to take account of the fact that many of the machines they are licensing won't be running all that often.

But utility computing offers the promise that any machine could be configured to run any software at any time. Furthermore utility computing makes it very easy to scale up and scale down systems completely dynamically. Suddenly sizing calculations get significantly more complex. One can imagine a number of software licensing models that could be used to address the situation. For example, customers who want absolutely predictable costs who aren't willing to pay for an 'all you can eat' licensing deal can purchase CPU licenses ahead of time and whenever software is deployed/sized/etc. the system will make sure to credit a license against the license pool. Customers willing to take a less predictable but potentially cheaper route can choose a utilization based charging model where software is only paid for when in use. It's pretty easy to imagine a mind boggling array of variations on the previous two possibilities. Just check out the licensing options at your local cell phone providers for a good idea of where this will all probably end up.

But in either case I don't believe that the licensing issues are really a technical issue. There is nothing inherent in the licensing problems that drives any significant aspect of the utility computing architecture. At worst one will either need a protocol to acquire a license from the pool or alternatively one will need a notification system and reliable logs to record and later bill for usage. Neither solution is technically onerous.

In fact, the whole licensing issue rather misses the point. Customers don't pay for CPU utilization or run time when they buy software. As BEA's Craig Chapman puts it – customers buy value. All the licensing cost issues are nothing more than a proxy for the value that customers are buying from software providers. It turns out to be really hard for customers to just agree on a number, justify it based on value and call it day. So instead we get to go through all these gyrations around per CPU or per cycle or per core or per bogomip or per whatever licensing. But we shouldn't let any of that obscure the reality that at the end of the day the software adds a certain value to the customer and that's what they are going to pay for, regardless of the proxy chosen.

Leave a Reply

Your email address will not be published. Required fields are marked *