Most organizations track availability and performance metrics as key indicators of a service’s effectiveness. Cost metrics should also be tracked as a key metric, but this has historically been challenging for organizations when running services on-premise. It’s now much easier to obtain the costs associated with running a service in public cloud making it practical to create and track cost metrics. Like availability and performance metrics each team responsible for running a service should also be responsible for collecting cost metrics and analyzing the trend over time.
The best way to go about tracking cost metrics is to identify one or more unit costs that represent the value you are getting per dollar spent on running your service. A unit in this case should be a measure of what the service is providing to its users and an indicator of the amount of work done by the service for a user..
For example, if you were a rideshare company, then one of your cost metrics should be “cost per ride”. As a ride represents work done by your service for your user. From an engineering PoV servicing a ride leverages your web front end, some queuing system, a database, plus other components that deliver your service.
The metric “cost per user” is less useful as an overall indicator of the cost effectiveness of your ridesharing service. You could have many inactive users and the total user count doesn’t represent the value your service is providing. From an engineering PoV storing a user is just measuring storage costs and represents a minimal part of running your service.
While cost per user metric isn’t worthless it’s best to start with metrics that are better indicators of the work done by your service for your users.
Elasticity is one of the key benefits of public cloud and services ideally should scale to meet their demand. This means both scaling up and scaling down. Tracking your unit costs over time can give you a good indicator on the elasticity of your service. The more elastic your service is, the more stable your unit cost will be.
For example, say you have a static environment where you have deployed enough resources to handle your peak load. In this case your cost per unit will vary widely based on the actual usage of the service. You cost per unit will be its lowest at peak and will increase as demand decreases. The highest cost per unit will be during the period of lowest demand. With a static environment you are amortizing a fixed cost over a changing number of units. With a dynamic environment the amount of resources is added and removed based on demand. In this case cost should rise and fall with demand giving you a much smaller variance in your cost per unit.
A lower cost per unit variance represents a more elastic, and more cost-efficient service. A high unit cost variance is a good indicator that you should investigate architecture changes to your service allowing you to use more elastic components. Do you want to be able to better understand you cost per unit? Do you want to make sure your service is as cost-efficient as possible? BlueChipTek’s Blue Print for Cost Management can help you tackle understanding your cloud spend. Though SaaS base services, proven methodology and effective consulting services we can help empower your team to track cost metrics and improve your service cost-efficiency.
Fill out the contact form or email email@example.com to learn how you can get your copy of our Blue Print for Cost Management.