Cloud Computing – A Tale of Two Machines

Here are the slides with some commentary from the CloudCamp session “Metering the Cloud” I gave last week in Cologne at the WebHostingDay (WHD) conference.

The slides look at metering (and utility billing) from the perspective of two machines. The first being a washing machine representing the physical world and the second a virtual machine representing the virtual world in the cloud.

Locations: Today billing is typically assigned based on the address of a household (account or cost center). Every household has an on-site meter for each utility (electricity, water, gas).  This is also the case in the virtual world with companies receiving a single bill at the end of the month for the usage of computing capacity and/or services in the cloud.

Machines: In the near future we will see each of our household appliances being fitted with their own power meters that feed metering data into a local management system providing real-time reporting on electricity consumption.

This is also happening in the cloud computing space with itemized billing per virtual machine/appliance. In the cloud this is much easier at least when talking about CPU consumption (not necessarily power usage) because instrumentation is already built into the operating system for monitoring purposes.

This level of reporting, typical of what is provided by todays commercial and open source system management solution, is woefully insufficient for the purposes of cost management as well as performance-, capacity- and service-management as it is devoid of the actual execution context which is extremely important in managing the typical cloud application which has varying workload characteristics.

Programs: Todays household appliances are multi-purpose (multi-function) and offer an array of standard operating programs. With each program having potentially different utility (electricity, water) consumption levels customers will eventually demand that metering be reported at the individual program level within each appliance.

Similarly in the cloud customers will want to see their own metered resource usage and metered cloud service interactions to be reported at the program type and possibly program instance level. This could potentially lead to a radically (but hopefully beneficial) change in how software and technologies are evaluated for inclusion in the building of cloud applications as the once hidden operational cost plays a bigger role in the decision making process.

Activities: When selecting a standard washing program users have additional operational choices. The spin rate can be increased or decreased. The washing temperature lowered or raised. Each of these has the potential to alter the standard utility consumption. Ideally metering would be reported by activity within a program per application within a household.

Likewise standard software programs can operate significantly different (in terms of resource consumption) due to differences in the workload characteristics of the various activities bundled in the program. To effectively manage such programs customers will require much greater insight into the software activities executing within each program. Programs cannot appear to be black boxes with flat anemic management interfaces especially as programs (operating system processes) act as mere bootstrap containers for the real work (software activity) performed by worker threads acting on input.

Customers will want to meter the software activity across key input ports, processing points, and output sinks. If you are not metering it then you are not managing it.

Resources: A number of household appliances are multi-meter based. In the case of our washing machine the primary meters are electricity and water. But the washing powder used during a washing could also be modeled as a resource if the appliances could also track the quantities added and consumed during a programs run.

A virtual machine in the cloud can have many meters. Each of the cloud services (external) and cloud software (internal) utilized by a cloud application would be represented as a meter. The power consumption would also be a meter as well as the cpu/wall clock time elapsed during the lifetime of an activity (within a program, within a virtual machine, with a cloud). Unlike in our appliance example the metering of multiple resources (some global based) in the cloud must deal with concurrency, apportioning consumption across concurrent executing activities (as accurately as possible).

Cost Groups: Most household appliances operate upon a direct interaction with a member of the household. Being able to identify the member at the point of the interaction would allow for metering to not only model the costs in terms of operational activities but also in terms of cost groups. It should also be possible to associate one or more additional cost groups that indirectly initiated the interaction – i.e. the football club (cost group) tells me (cost group) it is my turn this week to clean the clothing.

There can be many cost groups associated with a cloud application (especially for multi-tenant deployments). The costs groups can have deep hierarchies. An user initiating a request can belong to a team, department, unit, organization, and company. Metering in the cloud must support the tracking of resource usage and costs across distinct cost hierarchies and within a cost hierarchy (path) across cost groups with a clear distinction between direct and indirect metering.

Services: When managing the household budget we look to group our utility costs into household services – heating, lighting, cooking. Unfortunately without activity level metering this is not always possible as one utility (resource) can be used by multiple appliances across different service groups. This problem is also compounded by the fact that appliances themselves are multi-purpose and can be connected (plumbing/wiring) to multiple appliances each of which can be in a different service group.

Luckily software is much easier to instrument & measure (meter) than hardware as long as meta-data can be associated with each software activity identify the service context for a metered execution and this service context can be passed across processing container boundaries.

I would like to point out that metering is not just for cost management purposes. The same model can be used for performance management, capacity planning, service level management even service value pricing.

More Information: If you are interested in learning more about activity based costing and how it can be applied to manage application performance, control computing costs, and enable fair and accurate charge back plans then please visit our website shown below.

DZone Link: Cloud Computing – A Tale of Two Machines