Chapter 6. Intercloud Accounting and Billing
This chapter covers the following topics:
Accounting and Billing in the Intercloud: This section covers the accounting and billing taxonomy for cloud/Intercloud used in the industry, billing considerations for the Intercloud, services typically billed in the Intercloud, and the division of responsibility between service providers and service users for IaaS, PaaS, and SaaS. Also, the items that can be billed in IaaS, PaaS, and SaaS are detailed. In addition, revenue considerations when the resources are federated and consumed are discussed in detail.
Intercloud Accounting and Billing Architecture: This section covers in detail the architecture of the Intercloud with federation of services from various cloud providers and billing considerations for those services. Two example use cases are provided. Also, billing architecture is shown using a layered approach to illustrate how the information collected from the infrastructure equipment is transformed into a final bill for the consumer.
Key Performance Indicators (KPIs) and Business Intelligence (BI): This section covers some of the KPIs from the BI perspective for Intercloud services. The BI for Intercloud requires data mining of network, compute, storage, and applications. The data required for the KPIs is presented to the user on a dashboard in the form of analytics. Some key KPI parameters that should be considered for Intercloud services are presented.
Service providers have been offering new cloud services of IaaS, PaaS, and SaaS, and many application vendors host on the service provider platforms and offer content services. From a service perspective, cloud providers typically have agreements with the hosted partners, and the revenues collected from the consumers are shared between the service providers and the content providers (hosted applications) based on agreements that are done much before the service is offered. Though the cloud environment is slightly more complex than the traditional monopolistic telecommunications environment, it can still be accomplished based on the prior agreements. Most of these cloud services are based on isolated cloud management frameworks (CMFs) of the cloud provider’s choice. In an Intercloud scenario, the clouds would be federated, and each cloud provider would use its own CMF, creating heterogeneous federated clouds. It is not fair to expect these cloud providers to use any single standard framework, and most likely the heterogeneous federated cloud would be the way business will be conducted. This is not anything new; telephone companies and mobile operators have dealt with this type of difficulty in the past. For example, the old Bell Telephone companies dealt with heterogeneous types of signaling by creating Signaling Transport Protocol (STP) gateways between incompatible signaling protocols. Of course, this does not mean we should not have standardization, and the standardization effort must continue toward open standards. The purpose of bringing federated clouds together (Intercloud) is not to make everyone switch to a common solution, but rather to allow service providers to keep what they have and still be able to provide access to various cloud environments, provide uniform access to provision cloud resources, and offer services to end customers.
Cloud federation is the hottest topic for researchers and for cloud providers. The main goal of federation in clouds or the Intercloud is to be able to communicate and collaborate among clouds so that resources can be located in different locations and platforms and used to stitch together a single service for a user/customer. Cloud federation provides a way to obtain more capacity and is the ideal solution to the cloud burst problem. Resources are borrowed from remote clouds when the home cloud is void or near void of resources, then offered to remote clouds when the resources are idle. This is a good way to obtain additional revenue for the providers so the resources are efficiently used. This is similar to telephone companies using idle trunk/circuit capacities and airlines selling their excess seat capacity through various other channels. So, how does billing come into play here? Well, the resources are always tied to billing. But the provider has to make sure the resources provisioned in the remote cloud meet the SLAs and pricing considerations. In a federated cloud, ideally the selection of remote cloud and resources to be provisioned in the remote cloud is done in a dynamic fashion. In other words, prior agreement between providers is not a necessary condition, and the cloud broker function should be able to determine the remote cloud that has the required resources and capabilities and stitch services together at the price point that is profitable to the cloud providers and meets the expectations of the customer in terms of pay per use and SLAs. This allows the marketplace to dictate the price of resources and would offer flexibility to pass on the savings to the consumers.
Accounting and Billing
All utility companies such as telecom, water, and power have had accounting and billing functions, and now Internet/cloud/Intercloud do too. In single-provider cloud billing, the resources consumed by the user are the means of billing customers on pay-per-use basis. Accounting and billing for service providers using the Intercloud are more complicated since they involve multiple cloud providers, and collecting and distributing the monies back to several cloud providers based on their involvement in providing the service. The taxonomy of the future Internet accounting is provided in reference 1. In the following section, we will describe accounting and billing taxonomy from an Intercloud perspective.
Accounting and Billing Taxonomy in the Intercloud
Table 6-1 provides the accounting and billing taxonomy from the perspective of Intercloud services.
Accounting and Billing in the Intercloud
Intercloud service providers must be creative in creating new services through marketplace and service portals and tie these services to creative billing methods in order to charge for the services rendered. These creative billing methods not only help the service providers to be competitive but also help the content providers to provide new content. This will spur competition among providers, and ultimately the consumers will benefit because they can purchase services from providers that offer the best price/performance.
Cloud service providers need to move away from the traditional monolithic billing systems which slow down the introduction of new and exciting services using the Intercloud. Managing the partners/content providers, consumers, and revenue generation is at the core of the Intercloud business, and Intercloud billing systems should consider the following requirements:2
A focus on the customer and offering new services quickly and easily without too much manual intervention
Flexible subscription models and payment options
Easy integration into the self-service catalog, service brokering, and assurance systems for offering Intercloud services
Integration into CRM
Management of charging, pricing, bill rendering, bill collection, and distribution of revenues among Intercloud partners
Reduction of the costs of servicing clients with a built-in, customizable, customer-facing web portal, with online bill payment, presentation, and reporting
Promotion of customer loyalty by being proactive to meet the needs of customers and Intercloud partners
Intercloud Services Model
The cloud services rendered, whether they are in a single cloud or the Intercloud, are the same. The Intercloud allows more choice than a single vendor, since no single vendor may have all of the services customers need. In addition, a single vendor cloud can borrow resources from remote clouds when the home cloud is void or near void of resources.
Figure 6-1 shows the cloud delivery model and the typical services offered by cloud/Intercloud, and Table 6-2 shows the typical activities performed in each of those services. Later in the chapter, we will discuss for what items within in each of these services service providers can charge customers.
Intercloud Billing Considerations
Cloud computing is a charge-by-usage model whereby consumers access resources through the Internet. The user pays according to a usage model for the services consumed rather than owning resources locally and having to pay for licenses and annual operating expenses. The usage needs to be available on demand and can fluctuate up or down, and the cloud/Intercloud billing systems need to account for the granularity of the business models. The following sections further describe the billing considerations for the Intercloud service models (IaaS, PaaS, and SaaS).
Figure 6-2 shows the customer and cloud provider responsibilities. The areas that are managed by the cloud provider(s) for the three verticals of cloud services (IaaS, PaaS, and SaaS) will have to be configured, maintained, and billed for by the local provider, which borrows resources from remote cloud providers and provides the services to the customer. In the case of Intercloud billing, the shaded areas for the three vertical services may be provided by various cloud vendors. The local cloud vendor stitches together the cloud services and bills the customer for the service order. The local provider, after collecting the revenue from the customer, has to distribute it to all the cloud providers whose resources are used in providing the service to the customer.
The customer is interested only in obtaining the services and pays the bill for the services consumed to the local cloud provider. The interrelationships between the local cloud provider and the remote cloud providers need to be established in advance. In an ideal situation, the brokering of the services between cloud providers would take place automatically in real time during provisioning.
IaaS Billing Resources
As a part of IaaS, an Intercloud provider uses resources available locally and borrows the resources that are in limited supply locally to provide the service to its customers. Intercloud customers choose from these items in a services catalog. Table 6-3 lists the IaaS resources that IaaS customers can select through the services catalog. The local cloud provider in turn uses some of the resources available locally and selects other resources from other cloud providers. The billing models should consider the IaaS resources listed in the table that are available locally and from other cloud providers.
The local provider most likely would use a cloud broker when selecting the resources from a remote cloud provider. The following items need to be considered when selecting remote cloud resources for IaaS:
Virtual machine (VM): The number of VMs supplied from the local cloud, and the number of VMs supplied by the remote cloud providers. The VM availability, performance, and price may vary, and the local cloud providers need to take these things into consideration before putting them into the service.
CPU: CPUs are differentiated by power and number of CPU cores and may be differentiated further by time zone and peak and off-peak resources.
Server type: Since the service can be deployed on either a low-cost server or a high-availability, high-end server, the price point of the server should be a consideration in fixing the customer price.
Server mode: Standard or high availability.
Operating system (Windows, Linux, and so on): Since different operating systems may be placed on servers, use of the same server may be charged at different prices based on the operating system.
Storage (size): Price considerations for storage vary based on location, and whether storage is deployed in a standard or high-end unit. Also, for storage and for data processing, certain data sovereignty issues need to be considered before pulling together services from various cloud providers.
Disaster recovery (DR): The charges may also depend on the availability of the applications (five nines, three nines, and so on). If a disaster strikes one of the data centers from which IaaS is provisioned, the time window when the IaaS is made available from a redundant data center is a critical factor in selection and pricing.
SLAs: Based on several KPIs and key quality indicators (KQIs), SLAs are made, and credits may be applied for any SLA violations.
Power, space, security (high/medium/low): Network capacity may also be built into the infrastructure pricing.
Billing Resources for PaaS
The PaaS cloud providers provide the computing platform and solution stack as a service. The PaaS offerings may include facilities for application design, application development, testing, deployment, and hosting as well as application services such as team collaboration and web service integration. As a part of PaaS, an Intercloud provider uses resources available locally and borrows the resources that are in limited supply locally to provide the service to its customers. Intercloud customers can choose these items from a services catalog. Table 6-4 lists the PaaS resources that can be selected through the services catalog. The local cloud provider uses the resources available locally and selects additional resources required to fulfill the service from remote cloud providers. The billing models should consider the PaaS resources listed in the table that are available locally and from the remote cloud providers.
The local cloud provider most likely would use a cloud broker when selecting the resources from a remote cloud provider. The following items need to be considered when selecting remote cloud resources for PaaS:
Different hardware architectures with different server sizes
Support for multitenant architecture by providing applications to support many concurrent users, concurrency management, scalability, fail-over, and security
Web-based user interface creation tools to allow interfaces to be defined for different user profiles by function or expertise
Ease of creation of user interfaces, either based on standards such as HTML and JavaScript or based on other rich Internet application technologies like Adobe Flex and Flash
Utility-grade instrumentation to provide developers insight into the inner workings of their applications and the behavior of their users.
Some PaaS offerings use information about user behavior to enable pay-per-use billing. Historical/usage evidence may help:
Determine whether services are of value to users/customers
Compare the value of different services
Track activity-based costs and revenues
Billing Resources for SaaS
The Intercloud SaaS delivery model is where software and its associated data are hosted in multiple clouds, and the data is accessed by cloud users using a thin client, normally a web browser over the Internet. The SaaS delivery model has become common for most business applications such as accounting, collaboration, CRM, ERP, and invoicing.
In SaaS, the Intercloud provider is responsible for everything (infrastructure, platform, and applications), and Intercloud customers simply use the applications. However, there may be cases where customizations can be done, and the Intercloud provider could charge for the customizations. Table 6-5 lists some possible customizations.
The local cloud provider most likely will use a cloud broker when selecting the applications from a remote cloud provider, and all the items mentioned for IaaS and PaaS are applicable to SaaS since SaaS basically rides on top of PaaS and IaaS.
Revenue-Sharing Considerations
In order to understand Intercloud pricing, let’s first examine traditional cloud pricing. In any cloud service, the users are looking for cloud services such as IaaS, PaaS, and SaaS that require resources such as CPU, storage, network, and applications. The definition of cloud is that the services and the underlying resources are provided upon request by the provider, and the services are billed on a pay-per-use basis. The resources are what need to be provisioned dynamically when a request for a service comes through a service order. The underlying resources may or may not be available all the time in a data center/cloud, and the resources would then need to be borrowed from other data centers/clouds. There may be instances when the resources are idle and the service providers can sell the idle capacity to optimize resources and make additional revenue.
Figure 6-3 shows the traditional model of obtaining services from service provider public clouds or enterprise private clouds, and the pricing/billing model.
In traditional cloud-provided services, the service providers that operate public clouds bill the users or enterprises for the resources used on pay-per-use basis. The enterprise IT organizations that operate private clouds do not bill the enterprise users, but there is a charge-back to the business unit (BU). Many times the enterprise users of the BUs go to other service providers for additional services and pay for those services through separate licenses or a pay-per-use basis. Also, enterprises may obtain resources from a public cloud for cloud services that are not available in the private cloud and also for cloud bursting, capacity augmentation, and disaster recovery. The service provider bills enterprise users for the services provided based on a fixed price or pay-per-use of the resources.
Figure 6-4 shows the pricing methodology that can be used in an Intercloud scenario. First, it should be understood that all the brokering, pricing, and configuration of resources in all clouds are totally transparent to the end user. Users buy services through a marketplace or services catalog. Behind the scenes, there is a service-brokering function that determines the availability of resources when those requested resources are not readily available with the local service provider. For example, public service provider cloud A may not have all the resources available in its cloud to provide a certain service at a certain time for a service order coming from its users and could request the additional resources and any advanced functions required from public service provider cloud B or other public service provider clouds. The brokering function scans all the service providers to determine where the resources are available and also whether they meet the price/performance guarantees to meet the service order request. The service order is fulfilled by the originating service provider (in this case public service provider cloud A) using its native resources and the resources from cloud B and other service providers.
The cloud federation provides the opportunity for using the resources from other providers whenever a need exists, either because of a lack of resources or because certain functionality is not available locally and is required to fulfill a certain instance of a service order. The following list provides some of the revenue considerations for Intercloud providers:
The premise for using Intercloud services is that no one vendor has all the resources and functionalities to offer the services required by all consumers.
Pricing is an important part of the cloud services for CSPs, content providers, and end users and determines the success or failure of the Intercloud services. It is expected that the services stitched together using multiple cloud vendors should be more cost competitive than services that use all local resources. The reason Intercloud would be price competitive is that most service providers want to optimize their resources and would like to make their resources available during off-peak loads for a fee. This is a good way for providers to obtain additional revenue so that the resources are efficiently used. This is similar to telephone companies using idle trunk/circuit capacities and airlines selling their excess seat capacity through various other channels.
In a coalition of Intercloud providers, fairness is important. Each CSP should get revenue based on the work performed and resources/technologies provided. The stability of the coalition depends on how the CSPs work together to charge for the resources in an equitable manner. Geography and currencies can play a critical role in these situations. A good marketplace with a brokerage function along with prior arrangement of partnerships, price, and SLAs will go a long way toward ensuring the stability of the coalition.
In the simplest case, all of the partners provide the same services and similar/same pricing considerations. In addition, the service-level guarantees and penalties are the same. Prices can be kept the same among the partners, and the Intercloud is used basically for cloud bursting and capacity augmentation.
All of the partners may not offer the same services. Some CSPs may offer new/additional functionality such as analytics and advanced security features that may not be available with the local CSP. In this case the price for the new/additional functionality should be predetermined.
Private clouds can be joined with public clouds to form hybrid clouds in the Intercloud. In this scenario, enterprises can benefit from the resources of multiple cloud providers and can determine which public cloud to join based on price/performance. Also, the enterprise does not need to build up all the resources and keep only critical resources required in the private cloud.
Intercloud Accounting and Billing Architecture
In any accounting and billing architecture for utilities, the provider basically meters the usage and calculates the invoice based on the price for the usage. For electric bills it is basically number of kilowatts; for water bills it is the number of gallons of water used; telephone companies charge based on fixed charges or the number of calls placed for voice and the amount of data used.3
In cloud computing there are multiple resources such as network, compute, and storage that need to be accounted for. In addition, charges could also increase based on the level of security, the quality and availability of services (load balancers), and types of applications. The Intercloud adds a bit more complexity to traditional cloud computing since resources from a local cloud and remote clouds may be used. This situation requires collaboration and agreements with the remote cloud providers for fulfillment of a service order, as well as service assurance to ensure that the SLAs are maintained. Finally, the usage needs to be metered both by the local cloud provider and by the remote cloud providers. In the following sections, the architecture required in order to provision and collect usage information and billing is described.
Intercloud Federation for Services
Figure 6-5 shows an Intercloud federation model where several cloud providers can share resources among each other’s clouds.4 There should be a prior arrangement among these CSPs about how they should communicate; they may have common APIs to communicate among themselves or have some mediation mechanism so communication can be established between them dynamically in response to a service order from a CSU.
Intercloud Federation: Use Case 1
Figure 6-6 shows how a service is provided to CSU 1 for service order X using one primary CSP A and three remote CSPs: CSP B, CSP C, and CSP D. CSP A is local to CSU 1, and the other CSPs are remote to CSU 1. The CSP A will collaborate with CSP B, CSP C, and CSP D to complete service order X. The CSP A stitches together a service for CSU 1 by first using the primary resources (P) available locally in CSP A, and borrowed/shared resources (S) from CSP B, CSP C, and CSP D.
The primary CSP A has all the responsibilities for CSU 1 and will be the single point of contact (SPOC) for all communications, including price, QoS, SLAs, and so forth. The CSP A will have contracts with other CSPs for the resources it borrows from them. The CSU 1 does not necessarily know where the resources came from; the fact that primary resources come from CSP A and other resources from the secondary cloud providers is totally transparent to the user. The primary CSP A also has the responsibility to collect the accounting information from the secondary providers (CSP B, CSP C, and CSP D), render the bill to the consumer (CSU 1), collect the payment from the consumer, and distribute the payment to the secondary providers. In addition to collection and bill payment, CSP A also has the end-to-end responsibility of SLAs to the consumer, CSU 1.
Intercloud Federation with OpenStack/Open Source: Use Case 2
Use case 1, discussed in the preceding section, did not mention products, and it is possible to connect these cloud providers (CSP A, CSP B, and so on) if they all have common APIs. In cases where there are no common APIs, there needs to be a mediation to address the various protocol and format differences among the providers. The telecom industry has addressed this in the past using STP gateways between communications carriers with incompatible signaling protocols. A similar approach can be taken to address the incompatible APIs between Intercloud providers.
OpenStack is an open-source cloud operating system developed by a community of open-source developers and participating organizations. This initiative aims to deliver solutions for all types of clouds, whether public, private, or hybrid. The solutions are designed to be easy to implement, massively scalable, and comprehensive in features. An OpenSource platform means the user is never locked into a proprietary vendor. It also provides tremendous choice from an ecosystem of industry-leading technologies.
Figure 6-7 shows an OpenStack approach to connect two open-source cloud providers using an alliance approach.
The alliance approach involves establishing a prior relationship between providers. There is a trust among the cloud providers to provide services to consumers using the resources they have available. For example, if CSP A is the local provider to CSU 1, it will request resources from its alliance partners CSP B and CSP C. First there will be peering between the alliances providers (manual or automatic) to exchange security keys, service availability, and service exchange points for resources. Alliance service endpoints are required for service discovery and Intercloud token validations. There is work under way on the alliance between partners, and Cisco is leading this work in the open-source community. The alliance model can be used in any multicloud model, whether a hybrid cloud model or an IEEE Intercloud model.
Intracloud and Intercloud Communication
Figure 6-8 shows a high-level view of communication between two CSPs for setting up resources. The CSP A receives a service order from its customer. In response to the order, it looks in its configuration management database (CMDB) for all the resources available and reserves/configures the resources available using its management systems (OSS/BSS). For the resources that are not available, it looks toward its alliance partners and sends a request through a service broker for the required resources. The brokering function should be able to determine the best alliance partner based on price/performance considerations. Let’s say that alliance partner is CSP B; CSP B will reserve the resources for CSP A’s customer, and CSP A will complete the service order by provisioning the local resources in CSP A and remote resources in CSP B. The resources in both CSP A and CSP B are active for the service instance, and they are relieved at the completion of the service.
Both CSP A and CSP B will meter the accounting information from their respective resources for the cloud service instance, and CSP B will exchange the resource consumption, pricing, and billing information with CSP A. The CSP A integrates all the cloud resource consumption information, calculates the amount of the bill for the service instance, and presents the bill to the customer. The CSP A pays CSP B after the payment is collected from the customer, based on the resource usage from CSP B.
Billing Functional Architecture
Billing architecture requires that resource usage records be collected, measured, rated, assigned, and communicated between appropriate parties in intracloud and the Intercloud. The billing architecture provides interactions between network devices, compute devices, storage devices, accounting servers, and billing servers. The devices collect resource consumption data in the form of accounting metrics. In the case of a service provider, the data collection, correlation, and transformation of data into a usable format are accomplished through the billing mediation system. The transformed data passes through the rating and charging engine and the billing system for invoicing the customers for services rendered by the service provider.
Figure 6-9 shows details on billing architecture for an intracloud. In a provider cloud environment where there already is a high degree of complexity in the service or infrastructure, the mediation platform provides collection, correlation, and transformation of collected data.
Figure 6-9 shows the billing method for intracloud and Intercloud providers. The intracloud provider needs to consider only local resources consumption, whereas the Intercloud provider needs to consider the resources provided and consumed by the remote cloud providers. On the left side of Figure 6-9, metering, collection, accounting, charging, and billing layers are shown. Each of these layers is further described in the list that follows:
The resources layer contains all the physical and virtual infrastructure. Typically this includes devices such as network, compute, storage, load balancers, and firewalls.
The metering layer tracks and records usage of resources by observing the traffic flows, or usage records, and the metering policy used for configuring the metering layer specifies the attributes that need to be reported. In Cisco devices, for example, this might be the configuration of NetFlow records or NBAR2 type of flow records which are exported into NetFlow/IPFIX for additional processing.
The collecting layer accesses the data provided by metering entities as well as collecting charge-related events and forwards them for further processing to the accounting layer. This layer can collect information from virtual servers, physical servers, and so forth. For this reason, efforts to standardize data exchange format and protocol at this layer are beneficial. The collection policy will define where to collect the data, the type of data, and the frequency of collection.
The accounting layer consolidates the information from the collecting layer and creates service accounting data sets or records, which are passed to the charging layer for the assignment of prices. At this layer the service dependencies and service definitions need to be understood, so some integration with the services catalog and/or CMDB is required as is integration with application mapping and dependency software to understand in real time the actual configuration of the infrastructure. In the Intercloud, the accounting information from other providers and their pricing need to be collected and kept here. The charges from remote cloud providers may be different from those of the local cloud providers.
The charging layer derives session charges for the accounting records based on service-specific charging and pricing schemes, which are specified by the charging policy. This layer basically translates technical values (measured resource reservation and consumption) into monetary units using predetermined charging formulas.
The billing layer collects the charging information for a customer over a time period, such as one month, and includes subscription charges and possible discounts in a bill. There may be a need for on-demand billing also, and in such cases real-time accounting and billing need to be generated.
The major differentiator is in the metering, collection, and accounting layers, and this is where service providers should focus on providing value, as charging and billing will always be customer specific. If ultimately a set of service accounting records for virtual, physical, or hybrid services can be presented, it means that existing charging and billing applications should integrate seamlessly. In addition, consideration should be given to support mobile standards such as 3G/4G/5G to deliver real-time billing, as this is the model that will be most relevant for virtual or cloud-based services.
The key difference between intracloud and Intercloud is that the accounting consolidation involves combining the accounting information from measurements from several intraclouds as shown here:
Intercloud Accounting = 
, intracloud, where n represents the number of intraclouds
If we expand this equation to add details:
Intercloud Accounting = (Intracloud Accounting for Apps) + (Intracloud Accounting for Compute) + (Intracloud Accounting for Network) + (Intracloud Accounting for Storage) + (Intracloud Accounting for Security)
where
Intracloud Accounting for Apps comes from metering application usage for the length of time by the user
Intracloud Accounting for Compute comes from metering CPU usage, data usage, and other environmental conditions such as operating platform, availability, and so on
Intracloud Accounting for Network comes from metering LAN usage, load balancer usage, and other environmental conditions such as types of network equipment, SDN, and so on
Intracloud Accounting for Storage comes from metering SAN usage and other environmental conditions such as storage equipment, availability, and so on
Intracloud Accounting for Security comes from metering security usage and reporting and other environmental conditions such as best effort, medium security, and high security
The “Realizing the Billing Architecture” section describes this in more detail.
As IT departments consider the transition from physical infrastructure to virtualized or cloud-based services, there will be a need to review the billing model. Table 6-6 illustrates the differences between the two models when a new application is deployed.
Figure 6-10 shows the collaboration between two CSPs (A and B) for collecting the accounting and billing information and exchanging the information between the providers. The local cloud provider (the one that is delivering the service to the customer) will be responsible for aggregating the billing information and providing a consolidated billing statement to the local customer. The interactions between the service providers for any management and billing coordination will be transparent to the customer.
The two CSPs (CSP A and CSB B) as shown in Figure 6-10 will independently collect information about the resources that are used for a service, determine the charges, and communicate the accounting information to the originator of the service provider (in this case, CSP A). The originator of the service has the responsibility to determine the final bill, collect the amount of the bill from the customer, and distribute the revenue, based on the extent of resource usage, to all the providers whose resources are used in delivering the service.
Figure 6-11 shows the collaboration between multiple cloud provider resources using open-source clouds. The client requests a service from the local service provider, CSP A, for service, and the local/host provider sets up the resources available locally and requests the additional resources from remote clouds that are alliance partners. The following numbered steps identify high-level provisioning and billing aspects of the service shown in Figure 6-11:
1. The client requests a cloud service from CSP A. The CSP A checks the credentials using Keystone and creates a unique project ID “My Project” for the client. This unique ID must be maintained throughout the service with the host provider and the alliance partners. Also, the client enters the service order in the portal provided by CSP A, and this should be the only portal the client interacts with for any provisioning of the service instance.
2. Client A reserves the resources for the service from CSP A’s resources. This step should be done without any manual intervention, and there could be a time limit on when these resources will be reserved so that the client can initiate the service My Project. The reason for reserving and not configuring in CSP A is to ensure that the client will be able to provision end to end so that the order My Project can be executed. Otherwise, CSP A will start metering the partial resources and the client may not want to execute My Project without all the resources from other cloud vendors in place.
3. My Project will also be resourced with the alliance partners for additional resources that are needed to execute My Project. The resources in CSP B and CSP C will be made available to the client at the customer portal through a single pane of glass. The client should be able to provision resources required for My Project on the single pane of glass and start using the resources.
4. The resource consumption in CSP A, CSP B, and CSP C will be measured by the respective OSS/BSS systems for the time period My Project is active. The metered information with charges for the resources or alternatively the billing for My Project is sent by CSP B and CSP C to CSP A for aggregation to determine the final amount of the bill.
5. The bill is submitted to the client for collection. The revenue is distributed among the cloud providers based on a predetermined revenue formula according to the amount of usage of their resources, after the bill collection from the client.
It should be noted that the alliance feature is new and that Cisco has submitted it to the OpenStack organization. Other methods could also be used.
Realizing the Billing in the Intercloud
The first step in understanding billing architecture is to define what services are offered to cloud customers. A number of cloud initiatives are going on within Cisco and at other vendors, and most important in this is the application of billing for IaaS, which translates into a set of compute and storage devices connected to a network that can provide packet transportation, load balancing, and security services. Figure 6-12 illustrates this concept.
The meters that are required will depend heavily on what metrics are used for charging and billing; for example, if power consumption is not a chargeable metric, then from the charging perspective there is no point in enabling the metering and collection of it. The one exception to this is referred to as “ownership”; ultimately data is collected from infrastructure components and a service runs over those components, so it is important to understand who consumes resources on that component. In the case of a physical server this is fairly straightforward; the provider that uses the asset is the one that would be charged based on the extent of the usage. With a shared resource such as a LAN, this is a bit harder and will depend on application mapping to the resource at the time of usage.
The rest of the metrics will gather data on resource utilization such as CPU and disk either at a component level (a router) or a service context level (ACE security context, for example). This data will be collected and aggregated into various domains and then passed into a service accounting application which will use the service definitions to relate all the disparate data to specific services.
So the service providers need to understand which services to manage, what equipment makes up those services, and what metrics to use for charging for them; those criteria will then dictate what metering needs to extract and what mechanisms (NetFlow, Simple Network Management Protocol [SNMP], Service Control Engine [SCE], and so forth) will be used to extract the data. Existing collection devices may be used, but it is advisable to look to partners for the collection and accounting applications.
In an Intercloud, all the local charges need to be aggregated with the charges from the remote provider, and a final aggregate invoice will be presented to the cloud customer. After the collection of revenue from the cloud customer, the revenue will be distributed to all the cloud providers that are involved in providing the service. It should be remembered that the total cost of using the Intercloud should be less than the cost of having all the resources available and used locally. The charges for an IaaS that can be billed for an IaaS customer were shown in Table 6-3.
Billing User Experience Analytics
The true value of BI comes from business analytics, which provides consumer information to the consumers and revenue generation opportunities to the provider. The following list provides some of the areas that need to be considered as part of business analytics:
Billing analytics: Billing analytics should provide the best possible scenario to provision the services such that local service providers, remote service providers, and consumers benefit. The analytics also provide capacity planning for items that are often requested by local consumers and may be in short supply with remote service providers and for which the local service provider may want to beef up capacity.
Real-time financials: The CSP should be able to access and see exactly where the company stands in terms of revenue growth, receivables aging, credit and collections performance, as well as configure to obtain regulatory and compliance reports.
Revenue generation: The billing data analysis provides so much valuable information on customer habits, likes, and dislikes, and it can be used for new revenue generation. Customer data can be used to analyze top customers for targeted marketing of new services. Also, based on which services are used most and which ones are underused, advertisement and price adjustments may be made before retiring the underused services.
Product performance: Most business cloud users require SLAs and look for compensation in case of service disruption, not just credit for the time the service is not available. It is important to understand the product consumption, usage trends, and profit margins. The accounting information can be effectively used for determining product performance.
Analysis of SLAs: This can be used both to improve service where certain products are not meeting SLAs, and also to revise the architecture with new products.
Real-time billing: As service providers increasingly offer different types of services, subscribers will need to feel they have full control over their spending. Operators will also need to minimize credit risk by putting real-time cost control measures in place, which is particularly relevant when third-party partner payments are involved. The demand for real time is further driven by legislation that requires spending control for consumers, for example, the European Community directive for real-time data-roaming spending control for all customers.
Customer experience: Enhance customer experience with consolidated multiservice e-bills and reduce operational and support costs through paperless billing.
Reduce bill inquiries and speed payments: Simplify complex bills with comprehensive reporting and analytics capabilities.
Integration: Simplify integration with the services catalog and accelerate deployment of new services. Also, simplify integration with service assurance systems to ensure that proper billing credits are given for any SLA violations.
Business data/reports: Allow customers (in the case of service providers) and business units (in the case of enterprises) to view their data in a way that reflects the business value in their business hierarchy structure, and allow multi-access level controls over who can view sensitive data.
Key Performance Indicators (KPIs) and Business Intelligence (BI)
Key performance indicators (KPIs), also known as key success factors, provide a way to determine or to gauge the performance of an organization, business unit, enterprise, a particular activity, or even an employee. The KPIs are defined based on progress toward some strategic goals. As such the KPIs can vary widely from one department to another. For example, the KPIs for sales will be different from KPIs for manufacturing. So, choosing the right KPIs is important for a particular organization. The KPIs are always linked to some target goals, and the current-state KPIs provide an indication of whether the target goals will be met or not. Another way of looking at the KPIs is that they are metrics that represent distance to the target. If your organization’s goal is to increase sales by 20% year over year, you may want to know each month or quarter the status of your sales and whether you are on track to meet the target. That’s easy to see if a dashboard shows figures in green (“Pace will meet the target goal”), yellow (“Will meet, but only with additional staff”), or red (“Trouble and will not meet target goal”). If the KPIs indicate that a certain organization or service is falling behind the target goals, there may be a need for potential improvements; and as a consequence, performance indicators are routinely associated with “performance improvement” initiatives. It is better to take such performance improvement measures rather than fall behind. It is also possible that the target goals are set so high that they are not achievable and adjustments need to be made to set realistic targets. In this section we will look at some of the KPIs that are important from the BI perspective for cloud services. The KPIs have to be
Measurable in near real time using tools
Clearly defined and tied to organizational goals
Key to the performance and success of the organization
Monitored and shown on a dashboard so that remedial action can be taken, if necessary
The BI for cloud services may be defined as computer-based data mining of the activities performed by users. The cloud infrastructure, composed of network, compute, storage, and applications, has a tremendous amount of data pertaining to customers and their habits. This data can be searched for user activity and sorted according to some key indicators that provide BI. Though dashboards may have bells and whistles such as pressure gauges and tachometers, they are not useful unless KPIs are properly defined and anchored to high-quality data that is collected in near real time from the network and effectively analyzed. Obviously the KPIs need to be monitored to see the trends toward the organization’s objectives.
Cloud-based business analytics (dashboards) and reports offer a snapshot of KPIs and real-time trends. They allow key stakeholders to see key trends and take performance initiatives for any corrective action. Also, many dashboards provide drill-down capability from the summary level to greater detail to see real-time information.
Table 6-7 provides some BI KPIs that should be considered for cloud-based services. These are not exhaustive but can be a start for engaging in business requirements and development of a KPI dashboard for business analytics. Cisco NetFlow provides a lot of valuable real-time information such as traffic flow and bandwidth. This, in addition to application traffic and information from the CMDB and the services catalog, could be used to provide BI dashboards.
Summary
In the Intercloud (the cloud of clouds), a cloud provider borrows resources from a remote cloud provider when the home cloud is void or nearly void of resources and offers resources to remote clouds when the resources are idle. This is a good way for the providers to obtain additional revenue so the resources are efficiently used. This is similar to telephone companies using idle trunk/circuit capacities and airlines selling their excess seat capacity through various other channels.
This chapter covered Intercloud accounting and billing taxonomy and provided billable resources that can be billed in IaaS, PaaS, and SaaS within an Intercloud. In addition, revenue considerations when the resources are federated and consumed were discussed in detail.
Intercloud federation is a hot research topic that many researchers and standards bodies are still exploring. We have presented two cloud federation use cases where service requests are made by the CSU to the CSPs: Intercloud federation, and Intercloud federation with OpenStack. Also, an alliance approach for prior arrangement between cloud providers was discussed.
Also, a logical layered approach for billing for intracloud and Intercloud providers was provided. This logical layering model considered resources at the bottom layer: metering, collection, accounting, charging, and finally billing. Billing in clouds depends heavily on what metrics are used; for example, if power consumption is not a chargeable metric, then from the charging perspective there is no point in enabling the metering and collection of it. A detailed billing architecture showing areas of measurement for the Intercloud was provided.
Finally, billing analytics is a key area for the Intercloud and needs to be generated using KPIs and BI. We provided a BI-KPI dashboard showing all the key KPI parameters for the Intercloud.
Key Messages
Accounting and billing are more complex in Intercloud billing as opposed to single-cloud billing, because the usage measurements for all the resources in all clouds have to be accounted for to produce integrated billing.
In the Intercloud, the integrated billing that is presented to the user is a summation of billing records from the local/primary provider and all the remote/secondary clouds that have participated in the service instance.
The open-source architecture is the recommended approach for all clouds. However, open source does not have accounting and billing architecture details for Interclouds at the present time. This chapter provided information on how to use billing architectures and methodologies for Intercloud billing.
The KPIs and BI play a critical role for business and should be considered in order to monitor the business outcomes of each cloud and for optimization.
References
1. Igor Ruiz-Agundez, Yoseba K. Penya, and Pablo Garcia, “A Taxonomy of the Future Internet Accounting Practice,” Bringas DeustoTech, Deusto Institute of Technology, University of Deusto Bilbao, Basque Country, ADVCOMP 2010: The Fourth International Conference on Advanced Engineering Computing and Applications in Sciences.
2. Venkata Josyula, Malcolm Orr, and Greg Page, Cloud Computing: Automating the Virtualized Data Center (Cisco Press, 2012).
3. Francisco Airton Pereira da Silva, Paulo Anselmo da Mota Silveira Neto, Vinicius Cardoso Garcia, Fernando Antonio Mota Trinta, and Rodrigo Elia Assad, “Monext: An Accounting Framework for Infrastructure Clouds,” IEEE 12th International Symposium on Parallel and Distributed Computing, 2013.
4. Bo Hu and Naotaka Morita, “ITU-T Recommendation Y.3511, Inter-cloud Framework,” presentation at ITU Workshop on Cloud Computing Today and the Future Standards (Geneva, Switzerland, November 14, 2014).