Here’s a story about unexpected behavior prompted by some chargeback rules at Pfizer. (By 'chargeback' I mean the budgeting scheme where IT resources are metered, then costs are attributed to the business units that consume them.)
Larry Cannell notes that when department budgets were squeezed, users moved Sharepoint files to non-Sharepoint systems "all to avoid internal chargebacks. In the end...a lot of extra work...but no impact on the bottom line." For HP Bladesystem, tools that let IT departments implement chargeback are nothing new. There are ways to both measure resource utilization, and to implement high-level chargeback policies.
HP has even added some ground-breaking capabilities here -- bringing continuous capacity planning tools into the x86 space, for example. We’ve also added server power consumption as a resource that can be tracked historically for chargeback calculation – or even capped so businesses can predict their spend.You have to think like a non-IT guy, though, to predict how your internal customers will react to your chargeback rules. Put yourself in the shoes of a line-of-business manager:
People will order from the "Value Menu". If someone thinks he could squeak by with some minimal level of service, he’s going to try.
Square pegs will wind up in round holes. To an HR guy, using a USB key as the primary backup device for your employee payroll database seems reasonable.
Exceptions have legs. That handshake agreement to charge a little less because the legal department promised they’d use minimal bandwidth? Ten minutes later, every other department will demand “the “low bandwidth deal”.
Don’t put nametags on hardware. Especially with bladed infrastructure, you need to use language that avoids the impression that groups have “bought a server”. They’re paying you for a service…How you deliver that is up to you, not them.
We've been on the Adaptive Infrastructure journey at HP for several years now. This week we are announcing an important milestone: BladeSystem Matrix. We've been really thinking a lot about how customers use IT and ways we can optimize IT infrastructure to make it work better for them. We recognize that infrastructure exists for applications, which exist for the business. So we've taken a business and application perspective on how an infrastructure ought to operate.
Deploying an application typically requires an IT architect or team of architects to carefully design the entire infrastructure - servers, storage, network, virtual machines - and then hand off the design to a team of people to deploy, which typically takes several weeks. This length of time is mostly an artifact of the way IT infrastructure is designed. So we decided to change this with BladeSystem Matrix. Now an architectural design is saved out as a template - servers, storage, virtual machines, network, server software image. Then when it is time to provision an application, it's as easy as saying "make it so" - and in a matter of minutes, the Matrix's converged virtualized infrastructure is automatically configured and the application is ready to run. In other words, the way it ought to be.
BladeSystem Matrix is the culmination of several years work at HP - creating an Adaptive Infrastructure that is simpler to buy, deploy and keep running optimally. Applications are easier to provision, maintain, and migrate. We've spent years proving out this architecture, not just in our labs but in real-world environments, with BladeSystem, Virtual Connect, and Insight Software - so we could learn how IT really operates - and more importantly - how it ought to operate.
Some people tell me Matrix's virtualization sounds sort of like a mainframe. Others say that the portal interface reminds them of cloud IT. I guess in a way they are all correct. But unlike those environments, Matrix will run off-the-shelf x86 applications. So I guess I've decided that Matrix is it's own thing.
John Allspaw, Operations Engineer at Flickr posted a great presentation yesterday about the unique capacity planning and management needs of web operations. My favorite quip was, "Clouds need planning too".
He argues that you must know with certainty your infrastructure ceilings - the preverbial "out of gas" signal where work starts to degrade or fail. Forget benchmarks according to John. Instead, he offers a few "Stupid Capacity Tricks" (which are actually quite cleaver) to get rid of wandering bottlenecks and to keep the cloud running.
John has a lot more to say on the topic in his blog, the Kitchen Soap, so check him out.
PS: I have to also tip my hat to John for showing the big savings from replacing 26 Dell PE860 servers with 8 ProLiant DL140's. Wait until he gets a load of the ProLiant BL2x220c 2-in-1 server blade!