Notes and remarks:
The solution proposed in this article may not be the most optimized one and its only objective is to show an example of cost management in a VMware environment that could be adapted and enhanced according to organizations and users needs
Introduction:
Since Madrid Release, Cloud Insight is the solution that provides insight on Cloud spending for few providers today: Amazon and Azure
It consolidates data to visualize spending for particular cost centers and also provide capabilities around usage optimization.
This article focuses on cost management around VMware environment. Most of organizations' environments run on an on-premise VMware architecture where cost management and charge back aspects need to be handle independently and individually.
ServiceNow CPG and standard platform features provide opportunities to manage these concepts internally. As of today, There isn't an out of the box application in the platform that handles cost and charge back for end users for a VMware environment.
What I want to describe here is an implementation logic that manages a VMware resources cost report for the end user.
ServiceNow important notions:
When using ServiceNow CPG, several platform concepts are involved:
- Cloud Catalog Item (sn_cmp_bp_cat_item): It is the item that will be published to end user for request purposes. The Cloud Catalog Item will contain several information among which some will be important in our context:
- price: This is the field where the cloud admin will arbitrary set a fixed price for the catalog item. This price setting can evolve based on user choices in the form (example: the choice of a large VM instead of a medium one will increase the price of the catalog item...)
- Recurring price: This is the field where the cloud admin will arbitrary set a recurring price for the catalog item (monthly, annually...)
- Day2 operations (or lifecycle operations): this is a related list associated to the cloud catalog item that describes all action available for the Item after it has been requested (example: stop the stack, deprovision, modify end date...). Each time a day2 operation is requested it will generate an associated request and request item and each day2 operation can have a price associated to it (example: increasing the CPU of a resource can increase the total cost of the stack).
These prices can change over time based on offerings and services offered. The cloud admin can manage them in a version based control.
The request of a cloud catalog item will generate a stack, a request and request items that are important in the following steps.
- Stack (sn_cmp_stack): It is the main object generated when a user requests a cloud catalog item and that hosts information on what has been provisioned. The stack will contain all information from the original cloud catalog item and the associated deployed resources (Virtual machines, Network Interface, Disks...). It will contain in a related list all requested items associated to it (the original one from the first provisioning request and the other ones associated to the day2 operations). Each stack belongs to a user and a user group and has a cost field (which is not used by default).
- Request (sc_request):This is the object generated after each catalog item request. It is generally followed by agents to fulfil the user request and respond to some procedures like approvals etc... The request will contain associated requested item also
- Requested item (sc_req_item): The requested item is generated for each item requested by the user. For the objective of this article, the most important thing is that these requested items will host the pricing information coming from the original Cloud Catalog item for each step of the stack lifecycle (provisioning, CPU increase...). These requested items will be part of the Stack.
Logic:
Once the cloud admin has populated the price fields in the cloud catalog item and then end users has requested them, the resulted requested item objects can be used to consolidate the cost information and put the result on the associated stack object.
Let's take an example:
A Cloud catalog item has been generated and the cloud admin has defined prices for it:
A user connects to the service portal and open the cloud catalog item. He sees its price evolving as he chooses a bigger size for the VM (in that case a large VM with an increase of 10.00€ which result in a total price of 35.00€):
When the user requests the item it creates a corresponding user stack:
In this example we see that the stack is owned by a specific user and a specific group.
If we go to the related list we find the list of the requested items associated to this stack:
There are 2 requested item in this example:
- One requested item for the original provisioning request. This one has en associated fixed price which is 35.00€
- One requested item for the deprovisioning request. This one doesn't have an associated price as it is not chargeable
The idea is that each time a new requested item is created for this particular stack, an addition of all prices of each requested item of the stack is done. The result is put on the stack cost field as follow:
Finally you can generate a report by consolidating the cost of all stacks per user and per user group:
Implementation:
For simple reasons, I've decided not to take in account the recurring price option. I will only show how to restitute the cost information based on fixed prices of items. If you want to take in account recurring prices in the calculation of the total cost, you may need to link it with the duration of the requested item (duration since it has been created).
In my approach, I created a business rule which is triggered whenever a new requested item is created or updated.
For the conditions here is the details:
In the advanced section, the following script is in charge of adding the price of the newly created requested item to the existing current total cost of the associated Stack (you can find it attached also):
(function executeRule(current, previous /*null when async*/) {
//get the configuration item name and class from the requested item
var ciname = current.configuration_item.name;
var ciclass = current.configuration_item.sys_class_name;
//check if the configuration item is a stack
if(ciclass == 'sn_cmp_stack') {
//get the current total cost of the stack
var stacktotalcost = current.configuration_item.cost;
//get the current price of the requested item
var requestitemprice = current.price;
var stacktotalcostint = parseInt(stacktotalcost,10);
var requestitempriceint = parseInt(requestitemprice);
//calculate the new total cost of the stack
var newstacktotalcostint = stacktotalcostint + requestitempriceint;
//get the corresponding stack from the stack table
var st = new GlideRecord('sn_cmp_stack');
st.addQuery('name',ciname);
st.query();
if(st.next()) {
//add the new total cost to the stack
st.cost = newstacktotalcostint;
st.update();
}
}
})(current, previous);
Report Creation:
Specify the "sn_cmp_stack" table as the source data:
Choose the bar chart as you'll be able to combine it with other bar charts:
Finally configure the values as follow:
You will obtain the following results:
Benefits:
The end user will now have the opportunity to see its current spent while requesting new stacks and visualize if he doesn't reach the maximum allocated budget for its group (the maximum allocated budget per user group can be specified in the ServiceNow CPG quota section):
