On 11/18/09 1:59 PM, "James Vincent" <[email protected]> wrote: > Our charge-back model is that there is a basic monthly charge for the server > and support, tiered by what level of support and high-availability you want. > I believe there are three or four basic server "models" you can select from; > from non-HA with "when we get to it" support to full HA w/DR and 24/7 support. > > All of those include a basic amount of CPU time, memory and storage. Anything > added/used over and above those basics are additional charges. > > For instance, we include 15 MIPS for zLinux servers in the base price. If > they want to be silly and leave jvms running that are looping or poorly > written, and the server consumes 50 MIPS every day, they get charged more for > the 35 extra MIPS. > > The ones that are "funny" are the loopers; they leave apps looping for days on > end and then wonder why their bill is so high. The charge-back does help them > understand that they need to pay attention to their applications more. > > We also charge per 256M of virtual memory defined over the base. Storage is a > flat rate per MB or GB and is no different than any other platform.
This is very close to what we recommend to our clients as well. It's logical in that you can pretty easily explain to someone what the components of their bill are, and (even nicer) it applies to virtual and non-virtual servers equally well. I like it also because it makes clear the cost of actually maintaining the system -- one thing we add to the mix is a "aging" element -- older servers and older software cost increasingly more over a 5 yr span -- to prevent the case where you have an application dependent on an old release of a OS or compiler or old hardware that can no longer be maintained. I think it's also important that there be some basic profiles to choose from -- you get into a cooperative design effort with the developers when they know what they have to choose from, and can also put feedback into the server/software profile so that they better match your apps. The idea of a matrix of S/M/L vs support effort works really well because you look really supportive without giving away support for free -- and puts the user in control of what they're willing to pay for. Of course, you need backing when the user goes cheap and then blames you, but you have a signed statement that that's what they picked. 8-) -- db
