Typically we take in the server data, categorize it (e.g., physical, hypervisor, or virtual), send it on to its respective object in the model based on server type, and then on up to the supported application based on a separate feed that shows app/server relationship.

Virtual machines (VMs) spin up/down more than once/month and an application may not sit on one particular VM the entire month.  Yet, when we pull the data prior to doing the monthly data loads, if an application shows as being associated with a particular VM, then it gets the dollars associated with that VM.

Does anyone get more granular?  What if a customer or application owner complains that they were only on said VM for two days, yet it appears the application receives the cost of that VM for the entire month (given the monthly feeds and the monthly reporting)?

Anyone run into that?  What do you do?  Do you then act like a cloud provider and maybe charge based on some sort of metering?  Like ingest the app/server relationship data daily, and then arrive at a weight based on the number of days an application appeared to be associated with a particular VM?  Seems like that would be a TON of rows...

Would love to hear your thoughts, experiences, and/or suggestions - thank you!! 

We don't get more granular than reading our CMDB once a month and take a snapshot of who is using what at that particular moment.

So far we have not got the question to be more granular than that, but I would not be surprised if it comes when we move into being more cloud based. We are just in the starting blocks for that race.

Note, we don't use Apptio for billing. We have an home built application for that, but with the same principles.

Thanks, @Lars Peterson! 

@Rhonda Keller, @Chris Davidson, have y'all run into this situation w/any customers?

One of our VP reps from another OpCo will likely bring it up Monday, and then they'll likely bring OpCo chargebacks into the conversation.  We take a monthly snapshot in time, but they're going to look at that like they're paying for a VM for the full month when they've only been on it a few days.  But on the other hand, they're likely not seeing dollars for many other VMs they've touched during the month because the app/server relationships didn't show them at the time of the data export/download.  I'm not sure how else to go about explaining it to folks - I don't want people to stop having confidence in TBM and stop using it as a result!   And if I pull in the app/server relationships daily and do some sort of logic to show that they were on the VM for x amount of days, that gets crazy messy - especially when the rest of our feeds are monthly.  If we attempted the daily deal, knowing my luck, they would come back with: "Oh, we were only on that VM for x hours that day."  LOL...

Yes, some Apptio users use a more granular setup.

For example, if we know server uptime per month, we can weight per-server cost proportionally by this. A server powered on for the entire month might receive twice as much allocated cost as a similarly configured server running for just half the month.

Indeed we could use daily server/app relationship data to improve infra cost model defensibility. We could even use hourly data. I have not yet seen other Apptio users doing this, but it might be worth trying if you're specifically facing questions about how cost rolls up through the infra objects of the cost model.

Thank you, @Chris Davidson!  Unfortunately, uptime doesn't work for us because those things stay on until they come down for maintenance or there's an issue.  Since you haven't seen others use the daily server/app relationship, I'm going to stick w/the monthly.  If they have heartburn over the fact that there's one VM that appears for one entire month, I'll mention how there's other VMs they've been on/used that are not appearing that particular month, so it's likely a wash either way.

Like you said, they're probably also not getting some cost of the VMs.

For your meeting, maybe you could probably:

    1. Run a report of all the  VMs they used for the month

      - How many VMs were built and decommed (including dates) 

      - Which Applications they're associated against and when it was removed

      - Identify how many VMs were not billed against their Apps

    2.  Provide them an alternate option i.e. having a dedicated test VM to use so no need to spun an new VM instance every couple of day (I'm sure you already mentioned this option)

Thanks for this everyone, very useful. Can I ask does everyone go through physical servers and then off to VMs or do any of you push VM related costs straight from ITRT to Hypervisors or Servers? Thanks

Hypervisor is also a Physical Server but going through the below flow will allow you to better analyze Server costs i.e. Physical vs VMs, Apps to Server costing, etc..

We've always send our costs of a server via the following :

1. ITRT -> Data Center to Physical Servers

2. ITRT -> Physical Servers to Servers (Logical/App Server)

3. ITRT -> Physical Servers to Hypervisors to Servers (VMs)

Hope this helps

Thanks that's what we are putting in, was wondering if we could simplify (so pushing things like VM licence costs direct to hypervisors instead of via physical).

Yep, we go straight from ITRT to physical servers, then whichever of those are ESX/hypervisors, they go to that object.  True physicals continue straight up to servers as do VMs.  VMs share the cost of the hypervisors.  So if one hyper costs 1000 and there are 100 VMs associated w/it, then each of those VMs show as $10, as an example.  We thought about weighting the VM dollars based on memory, but when we did the before/after, it wasn't much of a change, so we left it as an even spread.  Just as FYI, while on the subject, we weight servers overall based on CPU and OS.  The more CPU, the more $ -- the older the OS, the more $$.

Thanks Jenny, we are planning the same here. Weighting is an interesting topic, from looking at it, for OpEx, it is really only data center power, and hardware depreciation that the cost seems related to the specs. Should other Opex be more expensive for higher CapEx servers? Labor and vendor (licences and support mostly) don't seem to be meaningfully related to CPU or RAM. That being said we don't really want to be having multiple paths from ITRT to Physical based on cost nature so will do a probably manufacture something to get a depreciation related weighting. Why older more $$ can I ask?

Older OS not CPU - corrected above.  It acts as an incentive for folks to get off the old stuff if they receive a bigger hit.  We've been kicking around taxing on age as well, but that didn't go over well bc the app owners don't have a say in what servers get built (most don't).  That may change the OS conversation later, too.  Prob going to look into those situations where someone is sitting on a physical server (or storage array) by themselves and put the weight on them to get them to move.  So many times people put down roots and don't want to risk any sort of outage.  They'll put a call into their VP to get special permission to stay on the existing (old) hardware without regard to the impacts of our valuable and shrinking white space.

Hi Jenny. Thanks for the feedback.

If you have one VM consuming 10% of the Hypervisor or Cluster (1000$) and receives the full cost because it's the only VM and directs the cost to App 1 (1000$).

Another example is where you have 10 VMs, each consuming 10%  of the Hypervisor or Cluster (1000$) and this translates to: App 2 getting 100$.

Any Application Owner/Business can say that it's not their fault in the first place, because they don't decide how IT Infra allocates VMs. How do you explain this?

Thanks.

Interesting ... kind of blurs the costing vs pricing line.

@Jenny Franklinthanks!  My team was just talking about this the other day 

@Peggy Cantu - Check this out, per our conversation with Steve