There is an important observation on how the cloud computing charge back happens. For most of the cloud based services, be it infrastructure, platform or software as a service, the charge back is based on compute hours, storage, network transfer size, number of transactions or application requests and number of users. The software as a service typically operates on the number of users, and storage per user or organization as a whole. For the SaaS provider, the number of users per application service with specific SLA’s translates indirectly into number of compute hours . So, without loss of generality, we can assume the three key parameters for the charge back at any level are.
- Compute hours
- Storage in specific units
- Data transfer in specific units like GB
Almost all of the public cloud vendors use the above parameters to charge back the customers whether it is at the infra, or platform or indirectly at software as service level.
For IaaS, Compute hours is typically charged from the time an instance is deployed till the time it is deactivated or shutdown. It is the same duration from the start of deploying an application and till such time the application is uninstalled in the case of platform as a service. In both scenarios, it is only the duration of the active instance or active application that is deployed and running. Even if there are no transactions hitting the active instance or application, the consumer will be charged. In the case where there is no load or the active instance/application is running only at a very low utilization, the consumers get impacted.
Is it really a “pay per usage” model? Yet another interesting scenario is how the enterprise admin could decide on the deployment configuration for a very big user base. Should it be based on number of users (as the SaaS model charge back) or should it be based on the number of user requests that actually hit the application instance?
Well, the above questions give rise to an interesting thought process. How, should the customers understand these utilization dynamics and make sure that their instances (infra or application) are running to some specific capacity? Any understanding of the load (or utilization) on the instances would
- Help them distribute the load against other instances running and ensure minimum load on each instance
- Help them to deactivate the instance(s) if the load pattern comes down
Yet another interesting option for the customers to consider is the tradeoff between a private cloud and public cloud based on the usage and period of service. Does it make sense to keep running the active instances on the public cloud for longer periods? Or it makes sense to setup their own private cloud and move the load back to the private cloud? An interesting internal exercise done by HCL revealed that any active instance (even running high on utilization/load) that has a projection to run for sufficiently longer duration, say 1 year or more, is a good candidate to be deployed on private cloud. The overall charges on the public cloud outweigh the infra and management cost specific to private cloud in this context. Customers need a work-load migration and management tool to optimize the resource utilization across the private and public clouds. The work-load management is one of the key features of any multi-cloud management platform. HCL’s OneCloud platform is a multi-cloud management tool that is uniquely positioned to address this business need.