Why Anybody Wants to Meter a Multitenant Application?

I remember the times when I started to work for my first job at a big company. It was a large multinational telecommunications company, and one of the earliest concepts I have ever learned was “metering”. Up to that time, I was assuming everything one measures on a telephone switch is all about charging customers, and to understand how many minutes they have spent on the phone. Upon pouring over the code that runs on the switch and the peripherals, I came to realize the code was measuring the use of many things, and all was because of understanding the resource use of various different features, which also happens to be including the speech channels utilized.

Having a ubiquitous measuring of the resources a solution is using, that does not get in the way of the actual operations of it becomes even a more important concept, if the solution is utilizing resources from a different system, and potentially being charged for them. The urge to learn and analyze the tenants’ respective indirect utilization of Windows Azure resources the ISV is paying for the solution may have many different reasons. A few of the first that may come to mind can be:

  • How can I enforce quotas for tenants, or do I have tojQuery1520412992729106918_1337901680773
  • Are there any tenants consuming most of the resources?
  • Do we need to introduce pricing tiers?
  • How does the cost of goods for our solution get affected per tenant?
  • Are certain tenants causing starvation for other tenants?
  • Is my system behaving accordingly? Are we experiencing any resource usage anomalies?

The metering application block (which can be found at http://cnmb.codeplex.com), attempts to provide a solution to the ISVs asking those questions to themselves about their solution. The goal of the application block is to generate data where an ISV can compare the resource usage among the tenants.

Of course, given the wide range of pricing packages Microsoft provides, and possible changes Microsoft may take in their pricing policies, it would not be possible to calculate monetary values for those resource usages. It is also important to point out that the collected data is not the equivalent of the data Microsoft uses to calculate the bills at the end of each month. There can surely be differences in the output, since Microsoft billing has a different goal (to bill the customers) than the Cloud Ninja Metering block (to track relative usages across tenants for major resources).

What to Meter and Why

We have started with mentioning that, the CNMB is not a mechanism to analyze and double check your Azure bill details, however it is meant to provide the relative resource usage of the tenants. But what exactly do we need to measure to see the relative usage patterns? A good starting point is whatever is already there, provided by the Windows Azure page as the main pivots for a pricing discussion.

To make our point about metering not being related with the pricing, we also included a provider that measures the ingress data (data coming to the data center), which is not charged by Microsoft. The reason we chose to provide this is, heavy incoming data traffic by certain tenants may indicate additional data usage on certain other resources, such as compute time.

You can obviously start measuring many different metrics; however the block comes with 5 default providers that map to the major pivots:

  • Blob size: Measured by the blob store size provider
  • Database size: Measured by the database size provider
  • Bandwidth : Measured by the IIS bandwidth provider, the database bandwidth provider and the blob bandwidth provider

Of course it goes without saying that depending on the solutions needs, there may be needs for measuring other aspects. Number of documents processed, active users, queue lengths could be among those.

In designing the block, we concentrated on four tenets:

  • Block can be easily hosted in any hosting application, and does not depend on Azure runtime
  • Does not require a code change for the related application, and be application agnostic
  • Rely heavily on configuration, not coding
  • Easily extensible

You can reach us at info@fullscale180.com for further questions/comments.

Have a great day!

Leave a Reply