As drivers of those motorized behemoths known as sport utility vehicles (SUVs) know, every yin has its yang, every benefit has a cost. For every few feet further a driver can see from on high, there's a greater likelihood of rolling over in a crash. For every off-road adventure, there's the six-miles-to-the-gallon gas mileage the rest of the time, a particularly nasty "yang" during times when oil prices refuse to fall below $50 per gallon.

The same is true in server and storage utility pricing vehicles (SSUpV). The main benefit of SSUpV is an increased likelihood that you'll pay only for what you get (and can get only what you need). But what does it cost to employ an SSUpV? Is there a six-miles-to-the-gallon problem lurking beneath the surface?

The two main costs of SSUpV are: (1) the costs of collecting pricing metrics; and (2) the costs of establishing the credibility of metric schemes and figures.

The software required to collect utility pricing metrics is not particularly complex. Over the past decade or so, capacity management technologies have been incorporated directly into microprocessor chips. Almost all processors today employ one or another scheme for capturing and reporting very rich usage data.

However, as server and storage infrastructure components are increasingly networked in scalable cluster configurations, they devote significantly greater cycles to performing tasks related to interacting with other infrastructure components: synchronizing memories, finding active copies of data, acknowledging readiness, broadcasting state, etc.

Generally, advances in the performance of memory, microprocessor, disk drive, and interconnect components have risen faster than the overhead associated with performing internal hardware administration tasks, so application execution times continue to fall (or performance rise) with successive generations of technology.

But the fact remains: as you add more infrastructure components to a scalable complex, the costs of performing low-level, administrative tasks can rise geometrically.

In other words, the effective benefit of an additional increment of capacity can go down pretty quick, even as costs scale.

Different SSUpVs manifest this problem to different degrees. Schemes based on standby machines, whereby you inventory a supplier's machines until you "need them," are the worst offenders - the Hummers of the SSUpV world, so to speak. The standby machine approach makes no effort to accommodate the costs of infrastructure complexity, and should only be employed in very simple configurations.

Virtual pay-per-use schemes can take very sophisticated approaches to trying to factor the costs of infrastructure complexity. However, there are two problems with these approaches. First, the programs required to generate virtual pay-per-use prices can themselves consume important marginal resources (which then have to be factored by the monitoring programs, which then consume resources, and so on). Second, these tools can spit out reams of data on system performance, but that often has little to do with application performance, let alone business performance or goals.

Which raises the above mentioned issue of metric credibility. The last thing IT needs today is another new concept that makes it appear further removed from understanding and working toward business goals. The virtual pay-per-use model is best employed at the extreme high end of infrastructure scalability, and then mainly when the concern isn't clarifying chargeback costs to the business, but in detailing pricing with suppliers.

If an IT organization's goal is to credibly and cheaply assess monthly application bills to business users, then the simplest and best approach to gathering metrics is the component pay-per-use. This approach tracks costs and reports pricing based on the addition of server and storage processing elements (not whole machines) to application pools, typically factoring marginal capacity available to applications. It's reasonable and simple, which makes it relevant to the business.

That closes this series on the straight line from business value to infrastructure pricing. Along the way, we've seen that:

• The problem with the business value of IT is that it can create business value, but sometimes doesn't;
• The management practices associated with applying information technology typically are more important than the technologies themselves;
• The new mantra of infrastructure technology is "do no harm," which most often means minimize cost, maximize flexibility, maximize automation, and minimize excess capacity;
• Superior infrastructure pricing mechanisms must break the rigid link between hardware configuration and application delivery, reduce the lag between infrastructure investment and application benefit, and support "pseudo prices" to better rationalize infrastructure capacity; and
• For the broadest range of application and infrastructure scale, a component pay-per-use pricing mechanism makes the most sense.

» posted by abennett

Appergy, Inc.

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine