Normally when you read or hear someone talk about application environments running on cloud platforms a lot of focus is put on provisioning and elasticity. Mainly the claims are that you should be able to very quickly provision full application environments on the cloud platform and that those environments should grow, and shrink, based on the demands on the system.

I certainly have no argument that those capabilities are important functionality for a cloud platform, but based on some recent conversations with several different users I'm beginning to think we aren't talking enough about another important feature for these solutions. That feature is the degree to which the application environments running on cloud platforms can be audited.

Auditing of the application environments running in a cloud has many facets, but let's just consider it as it relates to one of the basic tenets of cloud computing: utility-based pricing. If you are thinking of either using or constructing a cloud application platform within your enterprise, chances are utility-based pricing is important to you. You either expect to be charged for only the resources you use, or you want to allocate costs back to teams or users based on usage of your platform.

Your usage charges may be for the number of hours that an environment runs in the cloud (the Amazon EC2 pricing model), or it may mean something even finer-grained such as paying for the utilization of compute resources like CPU, memory, and storage. Any way you account for usage, the implication is that the cloud platform, or associated tooling, provides or enables you in some way to extract and filter the relevant data about the environments running on said platform in order to produce meaningful reports.

The best-case scenario is that the cloud platform directly provides you with your reports. For instance, if you decided to charge for use of your cloud platform solely based on usage hours, then the cloud platform solution might provide you with a report that showed the breakdown of usage hours for each user or team over a specified period of time. In this case, you don't have to do anything to extract, filter, or otherwise massage the data. You tell the solution you want a usage report, and it gives you just what you need.

Obviously, this turnkey reporting capability is not likely to be there for everything you need because there is no way for a solution provider to anticipate and provide every meaningful report for every user right out of the box. What do you do when you encounter a solution that you otherwise like, but doesn't necessarily give you the reporting you need right out of the box? Simple. You ensure that the cloud platform solution provides a mechanism by which you can extract audit data to support your own custom reporting.

The solution may enable you to extract data by providing a robust CLI, REST interface, web services interface, or query building capability. Regardless of the data extraction interface, if custom reporting is important to you, you'll want to ensure that not only can you extract the data, but that you can also filter and shape the data to fit your needs. If you can't filter the data, you're left with little more than a pile of meaningless bytes and bits. Just as importantly, if it looks too hard to filter the data, you'll want to consider whether it's worth the investment to write the necessary data mining logic.

The bottom line is that when you look at a cloud platform solution, be sure to look past that solution's approaches to provisioning and elasticity. Take a hard look at how it helps you to audit the application environments it will support. It's better to understand and accept those capabilities upfront instead of being disappointed once you put the solution in place.