Occasionally, I trip across a clever word to describe a relatively complex concept.
This one comes from Kartik, one of our field CTO types.
And I think it's a handy way to describe many aspects of tomorrow's IT infrastructure.
Static Vs. Dynamic
Much of IT resource planning these days is what I'd call "worst case".
Buy a server that's big enough to handle the load, because it's a pain to get more server resources.
Provision enough storage ahead of time, because if you run out, you'll have a very bad day.
Ditto for networks and other hardware-based infrastructure.
I'm involved in a few projects now, and the natural tendency is to attempt to worst-case predict, and overprovision in the process.
I think that's the result of two problems: how hard it is to predict, and how hard it is to change things if you're wrong.
Predicting In The New IT World
I can remember sizing exercises for traditional applications with traditional users. How many users? How many transactions? How much performance? And so on.
We would apply some best-practices juju to our guesstimates, and arrive at a system configuration.
And, more often than not, we were wrong. We either overshot (and wasted a bunch of money), or undershot (and wasted a bunch of time).
Well, the world we live in doesn't have traditional applications and traditional users, does it?
SOA-based applications are notoriously difficult to size. Your database server may be supporting dozens of applications and business processes, and lord-knows how many users.
And, if you've really embraced the SOA-based Web 2.0 mash-up thing, well, traditional sizing methodologies are unrealistic, aren't they?
Another example is predicting storage capacity. In the transactional world, new information show up at a relatively predictable rate -- it's roughly limited by new transactions, which you can kind of get a handle on, sort of.
In the digital content world, new information can show up in huge globs and all at once. One day a file system looks empty, the next day someone has decided to store their training video collection. And then publish a web page over it.
Even if it's for a good reason, traditional storage capacity planning methodologies crumble in this world.
To stick with the tried-and-true "well, let's plan for the worst case, and put lots of stuff in" will end up in progressively more and more waste as these trends take hold in the market.
Thin IT Infrastructure -- aka Thinfrastructure
Another way of attacking the problem is thinking in terms of just-in-time infrastructure.
Now, this is not only making sure the enabling technology is in place, in my mind there's two essential process loops that have to be built as well.
The enabling technology is pretty easy to understand. For servers, it's things like VMware and DRS -- the ability to pool server resources, and get very dynamic when you need more, or you need faster. For databases, it's things like Oracle 10g RAC that lets you add "more database crunch" when you need.
[note: funny that Oracle has come out and endorsed Xen rather than VMware. There's an interesting story there -- I don't know if I'm courageous enough to tell it ;-)]
For storage, it's a combination of dynamic QoS, tiering and a smattering of thin provisioning. Most people think of storage capacity as a scarce resource -- they're right, but the game is moving to storage performance as a scarce resource.
As an example, I can use terabyte-class drives, and data dedupe to make capacity really, really cheap. But, at the same time, QoS isn't all there. The expensive bits will be the fast bits (or highly protected bits), and that's what's going to have to be dynamic in the future.
But putting these technologies in place will be a disaster unless there are two key feedback loops in place.
Feedback Loop #1 -- IT Resource Management
Let's face it -- when you're provisioning "thin" infrastructure, you're often writing a check you hope your user won't cash.
Banks do the same thing -- they'll loan out your deposits several times over. But they have processes in place to protect themselves if they have a bad day, and everyone wants their money.
The corresponding thought it IT is "active resource management". We're not talking about running utilization reports once a month to see what the trend line might be. We're talking about active threshold monitoring and alerting.
Having the people to do all of this can be expensive. Yes, better monitoring, modelling and automation tools will help (BTW, this is a big theme in the Smarts product family), but make no mistake -- IT assumes a new, important responsibility in a "thinfrastructure" world.
Feedback Loop #2 -- Make the Goodies Available To Users
I can't count the number of times I've met a customer who has implemented one sort of dynamic resource technology or another (e.g. VMware ESX, storage on demand, etc.) and not told the users about it.
While I can understand the concern at an IT level, at a business consulting level, that's just plain nuts as far as I can see.
Business users want IT to be transparent and flexible. Business users can't easily predict what they'll need in the future, either. And an IT infrastructure that's thin and flexible is inherently more valuable to them than one that's bulky and brittle.
Why not expose your capabilities to the people who need them?
Have We Coined A New Buzzword Here?
I'd like to think so.
I hereby define "thinfrastructure" as a "dynamically provisioned resource environment" consisting of "server, database, storage and network" that incorporates two essential process loops: (1) active resource monitoring, and (2) exposure of dynamic capabilities back to business users for exploitation.
Thanks, Kartik, for the buzzword. I think I've expanded the definition a bit, but haven't lost the spirit!
Let me know your thoughts!
Hi Chuck,
I always enjoy reading your blog. You've stirred up my curiosity. Be brave and tell the Oracle Xen v VmWare story the way you see it. I did some search with Google and I'm not sure that I got it.
Best Wishes ! and take a shot of whisky if required.
Cheers,
Fred
Posted by: Fred San | November 01, 2007 at 03:23 AM