QoS and billing for cloud resources

 

Abstract:

Many cloud solutions written by customers of public cloud services rely on billing and costing of their resources from the service provider, but they have absolutely no differentiation over their usages. The pay-as-you-go billing model is inherently dependent on the monitoring of the underlying cloud resources and that for the logic deployed by the customer but the differentiation of the usages cannot be made by the cloud infrastructure unless it is specified by the end-user application. Even if it did, there is no inherent mechanism to color the usages across the cloud resources to provide enhanced billing.  This article provides a glimpse into the service which could honor customer differentiation of usages which could pave the way for assignment of quality of service over the public cloud resource consumption.

Description:

Central to this proposal is the notion of classification and quota management for the end-usages where the classification is not only performed by the cloud resource provider based on connection attributes but also helpfully tagged by the customer applications using those resources. Customers can augment any resource usage with custom web request headers that introduce tags in the values with which to classify. They also set the user defined rules with which to classify. There is a clear separation between the classification rules and the resource plans. This is because the classification rules are dynamic in nature and could change for assigning the connections to different groups. Groups of connections share the same pool of resources. The cloud only needs to keep track of the resource plans. These plans are determined by the customer for the public cloud and are actively looked up by the cloud when assigning resources to workload. To the public cloud, the requests do not matter, they belong to a group, but the resources matter since the cloud must account for all resources and divide them between groups. The groups are a label for different connections and was an identifier to denote how much resources could be guaranteed to the cloud. The default guarantee is all inclusive and permissible with the customer provided tags used for accounting. The rules are for connections and connections are transient. In comparison, the resource plans are more stable, and cloud defined. Second the connections could have different characteristics and the classification based on connection properties could change with the next connection. The classifier is a simple user defined function with system defined rules included that assigns the incoming connection to a group. The classifier has visibility into the tags provided. This function evaluates the connections based on program order and in the form of a decision tree. This classifier function can be modified and updated independently from the resource plans. By its nature, the classifier is code while the resource plan is data. Furthermore, the resource plan data for the cloud is constantly read when assigning the resources and require cloud reconfiguration at resource provider level after each change since it affects resource throttling, monitoring and billing for incoming connections. However, the cloud does not need to know anything about the connections or persist any connection properties since these have been evaluated to a group. The group is a label for the cloud that is used to assign incoming connections on which a policy is applied as defined by the resource plans. The groups can be hierarchical as well while the resource plans are discrete and flat.  The resource plans also must tally up to the full cloud capability. Therefore, it is owned and enforced by the cloud. The user connections, on the other hand, are mapped only once to different pools. In addition, it is written as any other user defined function. Although in practice this is done by the administrator and requires cloud reconfiguration since the cloud needs to know that the memberships to the groups have changed, the classifier is connection facing and hence qualifies as just one other user defined function. The decision to reconfigure the cloud at the resource provider level after every classifier change is an important one. It is not merely sufficient to change the classifier to impact the next incoming connection, it is important for the cloud to know that the memberships to groups are being redefined. This means that connections that were previously coming to a group might now be classified to another group and the plans for that may deny resources or switch billing categories to the new connection. The cloud treats the classifier and the plan definitions as together constituting the resource management policy. So, if one of them changes the cloud's resource management behavior changes. In a way this is a way to tell the cloud that the policy has changed and is intended as a control for the administrator. Lastly, the policies and the plans are different because there are checks placed on the plan whereas the policies are arbitrary and have no relevance to the cloud. The checks on the plan, however, determine whether the next billing cycle is changed. The calculations by the resource provider are dependent on the plan information and this is a state that's persisted so that the cloud can automatically pick up the state between restarts. Thus, the resource policies and plans are treated differently. This feature differs from the Azure resource manager in that ARM has multiple resources, role-based access control, custom tagging and self-service templates which affect create, update and delete of resources whileresource usage management is the focus of this feasibility study.