Resource pooling, the sharing of computing capabilities, leads to increased resource utilization rates. This means you need fewer resources and thus save costs. This animation shows how that works (using virtualization).
Pooling resources on the software level means that a consumer is not the only one using the software. The software must be designed to partition itself and provide scalable services to multiple unrelated tenants. This is not a new concept: in the 1960s and 1970s, in mainframe environments, this was called time sharing. In the 1990s, the term in vogue was Application Service Provider (ASP). Nowadays people speak of cloud services.
Billing and Metering
When multiple consumers share the same resources, the question arises who pays for them. Billing and metering infrastructure automatically collects per tenant usage of resources. For this to work, each request must be assigned a unique transaction ID, that is related to the tenant. The transaction ID must be passed along to all sub-components, so that each can add their usage cost to the transaction.
The types of items to charge for span a continuum starting with low level services, like CPU usage, storage size, and network bandwidth, via intermediate services, like Virtual Machines hours and number of requests, to high-level services like number of concurrent users allowed. An additional flat monthly fee can be added too. And, of course, these metrics can be combined as well. What metrics to collect may depend on the particular service model.
It may make sense to store data from different tenants in different locations. For instance, storing data close to where it’s used may decrease latency and thereby improve performance for the cloud consumer. Data for different tenants may be combined into a shard.
|Previous: Broad Network Access||Next: Rapid elasticity|
2 thoughts on “Resource Pooling”