Andy Dean - Fotolia
Computing costs money, yet most business unit managers have no concrete idea what their computing utilization actually costs the company. This happens because computing has always been a general expense absorbed by the business. And since computing has traditionally been "free," there was no incentive for business managers to watch computing usage -- or waste. Often old or unused applications are never retired; they simply linger, consuming resources and adding to the organization's backup and disaster recovery burden.
But times are changing. Cost-sensitive businesses are calculating the costs of internal computing use and communicating those costs to business unit managers through a showback or chargeback policy. The goal of both approaches is to make business leaders aware of computing costs and provide an incentive to mitigate those costs.
Do we need a showback or chargeback policy?
If you don't need to pay for something, you don't care about how much you use (or how much you waste). We're all guilty of this -- it's a basic flaw in our human psyche -- and this has translated into a serious problem with modern business computing.
Consider a typical business paradigm: A new application is justified and budgeted, a new server is purchased and installed, the application is purchased and licensed, and the application goes online. Eventually, the application falls into disuse in favor of a new or alternative application, but the business unit manager hangs on to the old application "just in case." This makes sense; the manager wants to cover the business by ensuring a rollback path in case of problems with the new application or old data needs to be accessed later. The problem is that the server still burns energy, the unused application is still probably costing annual maintenance fees, and the server is still being backed up or replicated -- even though none of that is actually benefiting the business.
The problem got even worse with the advent of virtualization. Server virtualization vastly improves server utilization, allowing one system to host multiple VMs that can be provisioned in a matter of minutes (instead of weeks). Unfortunately, the speed and simplicity of VM provisioning made it even easier to consume computing resources, further accelerating resource usage (and waste) in a phenomenon called VM sprawl.
The best way to combat resource waste is to raise awareness of resource use and its financial impact to the business. There are two approaches: showback and chargeback. Showback is simply cost reporting that informs managers of their unit's computing usage. Chargeback actually hands managers the bill for those resources, making computing costs an actual budget item for each business unit. Once business leaders become aware of the costs involved in computing, they are able to make better critical decisions about compute priorities and spending, which can translate into overall IT cost savings for the company.
How does chargeback affect IT budgets?
A chargeback policy does not affect IT budgets since IT is neither paying the chargeback bills nor receiving the proceeds of any reimbursements. It is the individual business-unit or departmental budgets -- the groups that actually get the bills -- that will be impacted by chargeback. And if chargeback is implemented properly, the impact will subtly change the way that business groups consume computing resources.
However, the actual degree of impact is usually modest. Consider that a small VM might cost about $100 per month and a large VM might cost about $300 per month. A department with only a few VMs will probably not be unduly burdened with exorbitant IT expenses. It will depend on the amount of computing and the total size of the departmental budget. Small departments with lots of VMs (such as test and development groups) might see more impact than larger departments with only a few VMs (such as service or sales departments).
Nobody wants more expenses. Savvy business leaders will seek to mitigate their IT expenses by keeping a closer eye on application workloads and making critical decisions about which workloads to keep and which to retire. That's the whole point of showback and chargeback.
What are some obstacles to adopting a chargeback policy?
Chargeback is a controversial idea. It is sometimes seen as unfair for a business to back-bill its own departments for computing use. Why not also bill units for electricity, water, office space, telephone service, interoffice mail delivery and so on? As a consequence, there is often political pushback from business leaders that delay or blunt chargeback policy deployment.
Costing accuracy and transparency are other issues that can obstruct chargeback adoption. Chargeback is a reporting and accountability mechanism and is not intended to be a profit center. Excessive, arbitrary or unclear cost assessments can easily stoke the political pushback that can shelve a chargeback initiative.
Finally, showback and chargeback are highly automated processes requiring management tools, such as VMware vCenter, that can track VM provisioning and perform the associated accounting and reporting. Provisioning and chargeback are increasingly linked to overarching VM lifecycle management initiatives that proactively review VMs for business relevance. This helps to ensure that VMs are necessary and beneficial to the enterprise and streamlines the removal of old or unneeded VMs so those resources can be freed for reallocation.
How do we calculate the cost of a VM?
In order for a showback or chargeback policy to be effective, it is necessary to assign a cost to computing resources like storage, network bandwidth, memory and processors. However, the actual process of calculating such costs can be complex and differ dramatically between organizations. Consequently, there is no single cost or approach to calculating costs used in showback or chargeback platforms, but there are some common ideas to consider.
First, it is important to understand the fixed and recurring costs involved with virtual server deployment. Fixed costs include the server hardware, hypervisor (such as VMware vSphere) and operating system licenses, management platform costs (such as vCenter), and storage array cost. Remember to multiply those costs times the number of systems. For example, if there are 100 servers, multiply those fixed costs by 100. Recurring costs include server and software maintenance agreements, along with monthly network and storage connectivity. Business types will also want to know the total number of years over which those costs will be recovered. For example, a recovery period of three to five years is common for hardware and software product lifecycles (before new fixed investments are required). With this data, you can estimate the total life, annual and monthly costs of the compute environment.
Once you understand the costs, figure the available compute capacity of your virtual environment. This usually includes the number of processors and amount of memory per host, the processor speed (in gigahertz[GHz]), storage available (in gigabytes [GB]), network bandwidth available (in gigabytes per second[Gbps]) and so on per-server. For each item, remember to include any reservation and overcommit factors.
For example, suppose you have eight servers and one of those eight is in a two-server cluster. This means you have seven servers available. If each server has 128 GB of memory with a 20% reserve and 10% overcommit, you wind up with more than 112 GB of allocable memory per server. With seven effective servers, this offers more than 788 GB of allocable memory. It's a similar game for processor cycles. If a server uses two two-core processors operating at 1 GHz, that's a total of 4 GHz of processing power per server. With a 20% reserve and 80% overcommit, that's a total of 5.76 GHz of allocable processor cycles per server, and 40.32 GHz of total cycles over seven servers. You can repeat this for network bandwidth and storage.
Now decide how many hours per month the environment will be available, the percentage of cost that is recovered through memory use and processor use, and the total number of virtual machines (VMs) you plan to allocate across that hardware environment. As an example, a 24/7 data center may provide 744 hours per month of service, plan to provision 300 VMs across the virtualized servers, and charge 70% of the hardware cost for memory and 30% of the hardware cost through processor cycles.
So, you can start figuring hourly costs for memory and processor cycles. For example, if the servers cost $139,000 over a three-year lifespan and 70% of that cost is allocated to 788 GB of allocable memory, the cost for memory would be ([$139,000/788 GB] x 0.7) or $123 per GB over three years. This translates to $41 per year, $3.42 per month or $0.0046 per hour per GB. For processor cycles, it's the same $139,000 for servers, and 30% of that cost is allocated to the 40.32 GHz of allocate-able processor cycles. That's about $1034 per GHz over three years, $344 per GHz per year, $28 per GHz per month, or $0.038 per GHz per hour. Do this for storage as well (and network bandwidth if you choose). Also figure the monthly fixed cost per VM. For example, if the total fixed costs for servers, connectivity, licensing and storage over three years are $250,000, that's more than $6900 per month -- if you plan on those 300 VMs, that's more than $23 per month per server in fixed costs.
You haven't not got the information you need to estimate the monthly cost per VM. Suppose you allocate a VM with 1 GB of memory and 2 GHz of processor cycles. That's $3.42 memory + $56 processor + $23 fixed, or $82.42 per VM per month (more if you add storage and network costs). Some organizations might also add a one-time installation cost per VM. If you allocate more memory, processor, storage or bandwidth, the cost would be higher.
Clearly, this is not a quick or simple process, but there are some worksheets that can help put these gyrations into better perspective. For example, VMware offers an Excel worksheet that you can use for this kind of exercise. It's a terrific place to start and experiment with different costs, recovery periods, VM counts, license fees, and other cause-and-effect cost relationships.
Remember that VM costing can be a complex exercise. A successful chargeback initiative requires that costs be determined fairly and transparently with a high degree of scrutiny. Computing hardware is always advancing and software licensing continues to evolve. This means IT's cost structure is dynamic, so cost calculations should be revisited and adjusted on a regular basis -- perhaps annually or during each new technology refresh cycle -- to ensure continued accuracy. IT leaders should also weigh the calculated VM costs against alternatives like public cloud instances to gauge any financial benefits of potential cloud deployments.