Cost estimation on a cloud-computing platform

A cloud-management system intercepts API calls from a client application. Based on the expected amount of cloud resources required to service the API call, and given the terms of the client's billing plan, the system estimates the cost to service the call. The system embeds this cost into its response to the API call and the client application, or an IDE hosting the application, keeps a running total of API-related costs incurred by the application. The system can also run in an emulation mode, estimating the application's API resource-consumption costs without actually consuming cloud resources. In this mode, the system replaces each GET and PUT call in the intercepted API call with an equivalent HEAD call that does not consume resources. The system still, however, predicts the actual cost of the original API call by returning the cost of each original GET and PUT.

BACKGROUND

The present invention relates in general to cloud-management platforms and in particular to user-activity monitoring by a cloud-management application.

An important requirement for today's cloud-computing platforms is the ability to determine billing information for clients that use a cloud service.

One way in which cloud-computing implementations may price their services is to set fees as a function of each user's API-call usage. Such billing systems, however, cannot easily provide accurate billing estimates, making it difficult for clients to predict and compare cloud-computing costs. Similarly, dynamic characteristics of a client's API usage make it difficult to derive and report the true costs—either to the client or to the service-provider—of specific tasks in an interactive, real-time cloud-computing environment.

For example, a cloud service that simply charges a flat $10 fee for 10,000 API calls does not account for potentially great differences in resource consumption between different types of API calls. Similarly, it can be difficult for a cloud-management platform to derive and display actual user billings in real time when the user subscribes to a promotional plans that offers a certain number of introductory API calls at a reduced rate during a particular time period or that clusters different types of API calls or certain quantities of API calls into different billing tiers.

In all these cases, merely tracking a user's actual number of API calls cannot accurately predict the user's true billings and does not accurately identify the service-provider's true cost to service those calls.

SUMMARY

An embodiment of the present invention is a cloud-management system of a cloud-computing platform comprising a processor, a memory coupled to the processor, and a computer-readable hardware storage device coupled to the processor, the storage device containing program code configured to be run by the processor via the memory to implement a method for improved cost estimation on the cloud-computing platform, the method comprising:

the processor intercepting an API call that requests services from the cloud-computing platform,

where the API call is issued by a client application provisioned in a virtualized computing environment hosted by the cloud-computing platform,

where the API call is characterized as a particular type of API call, and

where cloud-resource consumption costs incurred by servicing the API call are billed by the cloud-management system to a client account;

the processor retrieving client data from a cloud-system data repository,

where the client data identifies terms of a billing plan associated with the client account;

the processor predicting as a function of the client data a billing cost that would be incurred by servicing the particular type of API call under the terms of the billing plan; and

the processor embedding the billing cost as metadata into a response to the API call.

Another embodiment of the present invention is a method for improved cost estimation on a cloud-computing platform, the method comprising:

intercepting, by a cloud-management system of the cloud-computing platform, an API call that requests services from the cloud-computing platform,

where the API call is issued by a client application provisioned in a virtualized computing environment hosted by the cloud-computing platform,

where the API call is characterized as a particular type of API call, and

where cloud-resource consumption costs incurred by servicing the API call are billed by the cloud-management system to a client account;

retrieving client data, by the cloud-management system, from a cloud-system data repository,

where the client data identifies terms of a billing plan associated with the client account,

predicting as a function of the client data, by the cloud-management system, a billing cost that would be incurred by servicing the particular type of API call under the terms of the billing plan; and

embedding, by the cloud-management system, the billing cost as metadata into a response to the API call.

Yet another embodiment of the present invention is a computer program product, comprising a computer-readable hardware storage device having a computer-readable program code stored therein, the program code configured to be executed by a cloud-management system of a cloud-computing platform comprising a processor, a memory coupled to the processor, and a computer-readable hardware storage device coupled to the processor, the storage device containing program code configured to be run by the processor via the memory to implement a method for improved cost estimation on a cloud-computing platform, the method comprising:

the processor intercepting an API call that requests services from the cloud-computing platform,

where the API call is issued by a client application provisioned in a virtualized computing environment hosted by the cloud-computing platform,

where the API call is characterized as a particular type of API call, and

where cloud-resource consumption costs incurred by servicing the API call are billed by the cloud-management system to a client account;

the processor retrieving client data from a cloud-system data repository,

where the client data comprises: terms of a billing plan associated with the client account, an estimate of an amount of cloud resources expected to be consumed by servicing an API call of the particular type, and a relative cost of the amount of cloud resources;

the processor predicting as a function of the client data a billing cost that would be incurred by servicing the particular type of API call under the terms of the billing plan; and

the processor embedding the billing cost as metadata into a response to the API call.

DETAILED DESCRIPTION

Embodiments of the present invention comprise systems and methods for an improved cloud-management platform that is capable of more quickly and accurately monitoring and determining fees to be billed to a user of services hosted by a cloud-computing environment.

As described in the BACKGROUND, when a cloud-computing platform bills a client as a function of that client's API usage, known cloud-management technology is unable to estimate, monitor, or report the client's cost to use a cloud-computing service while the client is working within a hosted cloud-computing environment. Instead, the client receives a statement at the end of a billing period listing fees that may be unexpectedly high or that may not reflect a service provider's true cost.

For example, a cloud pricing model that derives a monthly billing as a simple function of a user's total number of API calls cannot reliably compensate a service provider for the true cost of servicing those API calls. The amount of resources consumed by various types of API calls varies greatly, making a straightforward API-call count an inadequate way to determine the service provider's cost to service the customer.

A more nuanced billing system, however, may consider additional parameters that allow a service provider to more accurately measure the actual resource costs incurred by the user's API calls. Such a system might, for example, distinguish between different types of API calls, charging more for calls that consume greater storage space or computing power, that themselves trigger other API calls, or that require new virtual resources to be provisioned.

Accounting for such considerations in real time are generally beyond the scope of billing components and user interfaces comprised by current cloud-management technologies. These types of billing models require detailed after-the-fact accounting to determine a user's cumulative amount of resource usage. Because much of the data needed to make such a determination is not available while an API call is being serviced, this type of mechanism cannot be used to interactively report usage costs to users.

This is a significant drawback of current cloud-management systems and is an intrinsic limitation of the architecture of such systems. A cloud-management platform simply cannot track actual magnitudes of each type of resource usage incurred by each API call, and instead must infer cumulative usage over an extended time period by analyzing periodically aggregated summary logs.

This is a significant problem for developers that wish to estimate cloud-computing costs when budgeting the cost of a projected project or when attempting to select a most cost-effective pricing plan, development application, interactive development environment (IDE), programming platform, or development methodology. Without the ability to estimate the cost of various alternatives, it is impossible for the developer to select the lowest-cost approach.

This deficiency of current cloud-management platforms is also a problem for users who desire to limit variable cloud-service costs. Today's cloud-management systems could conceivably report estimated usage costs to users subscribed to a simple per-call billing plan, but it would be impossible for a current cloud-management platform to determine how many resources are being consumed and report a running total.

Embodiments of the present invention improve current cloud-management systems by addressing this problem, which arises from architectural limitations of current cloud-management technology. These embodiments implement this improvement by adding a new API-server module to current cloud-management systems that allows the capture and publication of resource-consumption statistics as metadata packaged with each API response. This metadata can then be aggregated and reported by an IDE client plug-in or by another type of application plug-in or by additional components of the cloud-management platform. In some embodiments, the present invention may be implemented by adding a novel “cloud API” layer to existing cloud-management stacks. This cloud API layer can intercept API calls and append consumption metadata to the cloud platform's response to each API call.

Regardless of implementation details, however, all embodiments improve the operation of known cloud-management systems in a manner that is not well-understood, routine, conventional activity known by skilled artisans in the field of cloud-computing.

Embodiments and examples of the present invention are described in greater detail inFIGS. 4 and 5.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

FIG. 3shows a structure of a computer system and computer program code that may be used to implement a method for improved cost estimation on a cloud-computing platform in accordance with embodiments of the present invention.FIG. 3refers to objects301-315.

InFIG. 3, computer system301comprises a processor303coupled through one or more I/O Interfaces309to one or more hardware data storage devices311and one or more I/O devices313and315.

Hardware data storage devices311may include, but are not limited to, magnetic tape drives, fixed or removable hard disks, optical discs, storage-equipped mobile devices, and solid-state random-access or read-only storage devices. I/O devices may comprise, but are not limited to: input devices313, such as keyboards, scanners, handheld telecommunications devices, touch-sensitive displays, tablets, biometric readers, joysticks, trackballs, or computer mice; and output devices315, which may comprise, but are not limited to printers, plotters, tablets, mobile telephones, displays, or sound-producing devices. Data storage devices311, input devices313, and output devices315may be located either locally or at remote sites from which they are connected to I/O Interface309through a network interface.

Processor303may also be connected to one or more memory devices305, which may include, but are not limited to, Dynamic RAM (DRAM), Static RAM (SRAM), Programmable Read-Only Memory (PROM), Field-Programmable Gate Arrays (FPGA), Secure Digital memory cards, SIM cards, or other types of memory devices.

At least one memory device305contains stored computer program code307, which is a computer program that comprises computer-executable instructions. The stored computer program code includes a program that implements a method for improved cost estimation on a cloud-computing platform in accordance with embodiments of the present invention, and may implement other embodiments described in this specification, including the methods illustrated inFIGS. 1-5. The data storage devices311may store the computer program code307. Computer program code307stored in the storage devices311is configured to be executed by processor303via the memory devices305. Processor303executes the stored computer program code307.

In some embodiments, rather than being stored and accessed from a hard drive, optical disc or other writeable, rewriteable, or removable hardware data-storage device311, stored computer program code307may be stored on a static, nonremovable, read-only storage medium such as a Read-Only Memory (ROM) device305, or may be accessed by processor303directly from such a static, nonremovable, read-only medium305. Similarly, in some embodiments, stored computer program code307may be stored as computer-readable firmware305, or may be accessed by processor303directly from such firmware305, rather than from a more dynamic or removable hardware data-storage device311, such as a hard drive or optical disc.

Thus the present invention discloses a process for supporting computer infrastructure, integrating, hosting, maintaining, and deploying computer-readable code into the computer system301, wherein the code in combination with the computer system301is capable of performing a method for improved cost estimation on a cloud-computing platform.

Any of the components of the present invention could be created, integrated, hosted, maintained, deployed, managed, serviced, supported, etc. by a service provider who offers to facilitate a method for improved cost estimation on a cloud-computing platform. Thus the present invention discloses a process for deploying or integrating computing infrastructure, comprising integrating computer-readable code into the computer system301, wherein the code in combination with the computer system301is capable of performing a method for improved cost estimation on a cloud-computing platform.

One or more data storage units311(or one or more additional memory devices not shown inFIG. 3) may be used as a computer-readable hardware storage device having a computer-readable program embodied therein and/or having other data stored therein, wherein the computer-readable program comprises stored computer program code307. Generally, a computer program product (or, alternatively, an article of manufacture) of computer system301may comprise the computer-readable hardware storage device.

In embodiments that comprise components of a networked computing infrastructure, a cloud-computing environment, a client-server architecture, or other types of distributed platforms, functionality of the present invention may be implemented solely on a client or user device, may be implemented solely on a remote server or as a service of a cloud-computing platform, or may be split between local and remote components.

While it is understood that program code307for a method for improved cost estimation on a cloud-computing platform may be deployed by manually loading the program code307directly into client, server, and proxy computers (not shown) by loading the program code307into a computer-readable storage medium (e.g., computer data storage device311), program code307may also be automatically or semi-automatically deployed into computer system301by sending program code307to a central server (e.g., computer system301) or to a group of central servers. Program code307may then be downloaded into client computers (not shown) that will execute program code307.

Alternatively, program code307may be sent directly to the client computer via e-mail. Program code307may then either be detached to a directory on the client computer or loaded into a directory on the client computer by an e-mail option that selects a program that detaches program code307into the directory.

Another alternative is to send program code307directly to a directory on the client computer hard drive. If proxy servers are configured, the process selects the proxy server code, determines on which computers to place the proxy servers' code, transmits the proxy server code, and then installs the proxy server code on the proxy computer. Program code307is then transmitted to the proxy server and stored on the proxy server.

In one embodiment, program code307for a method for improved cost estimation on a cloud-computing platform is integrated into a client, server and network environment by providing for program code307to coexist with software applications (not shown), operating systems (not shown) and network operating systems software (not shown) and then installing program code307on the clients and servers in the environment where program code307will function.

The first step of the aforementioned integration of code included in program code307is to identify any software on the clients and servers, including the network operating system (not shown), where program code307will be deployed that are required by program code307or that work in conjunction with program code307. This identified software includes the network operating system, where the network operating system comprises software that enhances a basic operating system by adding networking features. Next, the software applications and version numbers are identified and compared to a list of software applications and correct version numbers that have been tested to work with program code307. A software application that is missing or that does not match a correct version number is upgraded to the correct version.

A program instruction that passes parameters from program code307to a software application is checked to ensure that the instruction's parameter list matches a parameter list required by the program code307. Conversely, a parameter passed by the software application to program code307is checked to ensure that the parameter matches a parameter required by program code307. The client and server operating systems, including the network operating systems, are identified and compared to a list of operating systems, version numbers, and network software programs that have been tested to work with program code307. An operating system, version number, or network software program that does not match an entry of the list of tested operating systems and version numbers is upgraded to the listed level on the client computers and upgraded to the listed level on the server computers.

After ensuring that the software, where program code307is to be deployed, is at a correct version level that has been tested to work with program code307, the integration is completed by installing program code307on the clients and servers.

Embodiments of the present invention may be implemented as a method performed by a processor of a computer system, as a computer program product, as a computer system, or as a processor-performed process or service for supporting computer infrastructure.

FIG. 4shows an architecture of a system for improved cost estimation on a cloud-computing platform in accordance with embodiments of the present invention.FIG. 4shows elements400-420. In certain client/server-based embodiments (in certain virtual client-server topologies provisioned on a virtualized computing platform), objects400and405may be considered to be located on the client side of the client/server architecture and objects410-420may be considered to be located on the server side of the client/server architecture.

Client application400is a virtualized software application running in a cloud-computing environment. Application400makes API calls to its host operating system, which are serviced by components of the virtualized cloud platform on which the application and operating system are provisioned.

API usage store405is a local database associated with client application400, such as a virtual hard drive, that stores information specific to application400's API usage.

Cloud API manager410is a novel component of the cloud-management platform that intercepts each API call of application400and inserts metadata into corresponding API responses. This metadata identifies user data and API usage information.

In some embodiments, cloud API manager410may also help maintain the contents of cloud system data storage420by storing costs or characteristics of each API call in the system data storage420.

Cloud API manager410may be implemented as a layer of a cloud-management stack, as an independent component or service of a cloud-computing platform, as a component of a client application, as a component of a cloud service, or in any other form known in the art.

Cloud services415each provide a service of the cloud-computing platform. The cloud responds to each API call of application400by providing one or more services415to the calling application400.

Cloud system data storage420is a data repository used by the cloud-management platform to globally store information about each cloud user/client and about each user's API usage. This system storage data is updated by each cloud service415whenever that service415services a user API call.

Cloud storage420may, for example, store terms of each user's billing plan. A billing plan may, for instance, specify a pre-defined charge for each type of API call, or may organize possible API calls into “heavy,” “medium,” and “light” categories or resource consumption, associating each category of API calls with a distinct category-specific per-call fee as a function of an amount of resources consumed by each call.

In one example, a cloud system data storage repository420might store: i) a listing of the cloud resources consumed by each possible API call; ii) a listing of billing plans, where each billing plan assigns a specific, predefined price each API call that consumes a specific amount or combination of cloud resources; and iii) a listing of the billing plan or plans associated with each user account, including any promotional offers or user-specific discounts.

Regardless of the exact type of data stored in cloud system data storage420, all embodiments of the present invention will be able to use information stored in the cloud storage repository420to estimate a specific user's cost when an application owned by that user calls a particular API.

FIG. 5is a flow chart that illustrates the steps of a method for improved cost estimation on a cloud-computing platform in accordance with embodiments of the present invention.FIG. 5contains steps500-600which may be performed by embodiments that incorporate the structures ofFIGS. 2-4.

In some embodiments, the method ofFIG. 5is performed only if the client application400or a user of client application400, an integrated development environment (IDE), or another type of service requestor, has enabled the API consumption-tracking functionality of the present invention. This enablement may be implemented by any means known in the art, such as by setting a variable “APIConsumptionTracking.” If tracking has not been enabled, the novel features of the present invention are not performed and the cloud services the API call in a traditional manner.

One class of embodiments of the method ofFIG. 5is performed during an application-development procedure, to support a developer testing an application400under development in an integrated development environment (IDE). In such embodiments, the system computes, records, and aggregates the cost of each API call made by application400, but does not actually service the application's API calls. This allows the developer to estimate the real-world cost to run application400. If the developer sets a threshold cost, the system may continue to estimate API-call costs until the threshold is reached, allowing the developer to estimate types of usage and durations of time during which use of the application400will not exceed a budgetary constraint.

Another class of embodiments is performed during actual production usage of application400. In such embodiments, the system derives real costs incurred by actually running each API call made by application400. Some embodiments of this type may add features like a real-time display or live feed of current or cumulative API-consumption costs, or alarms that warn users when their API-consumption costs exceed various types of thresholds.

Many other embodiments of the present invention are possible, wherever it is necessary to, interactively or not, monitor real-world consumption costs incurred by an application's or service's API calls in a computing environment. Although examples and embodiments described in this document are limited to virtualized computing environments, such as cloud-computing platforms, embodiments of the present invention are flexible enough to provide analogous cost-estimation benefits in any computing environment where an application must make API calls or system calls to extrinsic server entities.

In some embodiments, steps510-590are performed repeatedly, once for each API call intercepted from client application400. In such embodiments, step500initiates this iterative procedure, repeating the procedure until either no more API calls are received or until a total accumulated API-consumption cost exceeds a threshold value.

In step510, cloud API manager410intercepts, through means known in the art, an API call made by client application400. Depending on embodiment, this API call may have been received directly from application400or from an IDE that is hosting and testing an instance of application400.

In some embodiments, a novel module of application400or of the IDE may have substituted a HEAD API call for a GET call or a POST call that would normally have been made by application400. This substitution may have been performed because application400, the IDE, or another software component hosted by the cloud-computing environment has been configured to require only an estimate of API-consumption costs, rather than an actual performance of analogous API calls. Such a configuration may be made when, for example, application400is being run only for the purpose of estimating actual API consumption costs.

In traditional API calls, such as a call to the standard REST (Representational State Transfer) API, a GET request is used to retrieve information from an information source, such as retrieving a URL from a Web server. Conversely, a POST request is used to send data to a server, such as submitting user input entered into an HTML forms. Both methods consume system resources and are capable of transferring significant amounts of data across a network or making significant updates to an information repository like a database.

Embodiments of the present invention may, however, substitute a HEAD request for each GET or POST request comprised by an API call intercepted in step510. A response to a HEAD request comprises a status line and header section identical to those returned by a GET request. However, a response to a HEAD request does not include the body of data comprised by a response to a GET request. In other words, a HEAD request returns a description of a response to an equivalent GET request (such as a relatively small amount of metadata), but does not consume the resources required to fully service that GET request. The difference is especially dramatic when a GET request is intended to return large media files, like images, entire documents, Web pages, or videos.

In step520, the cloud API manager410determines whether the intercepted API call is a HEAD call that should merely emulate the consumption costs of a GET or POST API call. If the API call is a GET or POST call that is to actually be serviced, the method ofFIG. 5continues with steps560-580. But if the system is configured to merely estimate a cost to service the API call, then the method ofFIG. 5continues instead with steps530-550.

This configuration may be determined by any means known in the art, either by a client-side method prior to step510or by a server-side component during a later step. These means may, for example, comprise a stored configuration file of application400, a plug-in component of an IDE that hosts application400, an internal setting of cloud API manager410, or a configuration of another component of the underlying cloud-management platform.

In step530, if the system is configured to operate in an emulation mode or to otherwise only estimate resource-consumption costs of the intercepted API call, cloud API manager410substitutes an HTTP HEAD request for any GET or POST request comprised the API call received in step510. If the receive API call is already a HEAD call, cloud API manager410performs no further substitution.

Embodiments of the present invention are flexible enough to accommodate implementations where this substitution is made at an earlier point in the procedure ofFIG. 5, if desired by an implementer. For example, the HEAD-call substitution may be made automatically on the client side of the system architecture shown inFIG. 4, such as by an IDE plug-in or an emulation module provided by the cloud service provider. In such a case, the method ofFIG. 5would not perform steps520-550, since the system could fully service all received API calls, including calls that had already been converted to HEAD calls before being received by cloud API manager410.

The cloud API manager410then forwards the HEAD request to one or more API servers415configured to access the requested cloud services. These servers, through means known in the art, perform tasks required in order to service the HEAD request. In general, these tasks comprise returning a header and status line to the cloud API manager410, but omitting the body of a response that would be returned by a GET request or submitted by a POST request.

In step540, the Cloud API manager410queries the cloud system data storage repository420in order to determine a normal production-environment cost that would have been associated with the original API call, had the API call not been converted to a HEAD call.

This estimated cost may be a function of the specific types of services that would have been consumed by the original API call, including the storage and network resources that would have been consumed by the body of the call or by the body of the response, had the HEAD call not been substituted for a GET or POST call.

The estimated cost may also be a function of which billing plan is associated with the user account for the hosted virtual environment of client application400. For example, a billing plan may charge a flat rate for each API call, or may specify a number of pricing tiers that assign a specific cost to any API call that falls within a certain tier. In such a plan, an API call may be assigned to a particular tier as a function of the type or amount of cloud resources consumed by servicing that API call.

In other examples, a billing system may associate a general level or resource consumption with each type or sub-type of API call. In some cases, different amounts of resource consumption may even be associated with the same API call, depending on which client application400invoked the call.

For example, a stock-tracking application400may typically consume fewer resources when it makes a certain type of data-handling API call than would a weather application400because the weather application400would normally require a response that comprises a much larger body of data than would the stock tracking application400. In such a case, the cloud system data storage420might identify a first estimated cost to service the data-handling API call if the call was made by the stock-tracking application400and would identify a second estimated cost to service the data-handling API call if the call was made by the weather application400.

In a most general case, cloud system data storage420might comprise a database that returns an estimated API resource-consumption cost as a function of: i) the type of API call and sub-type of API call; ii) the client application400that invoked the API call; iii) the user account associated with client application400; and iv) terms of the billing plan associated with the user account, including user-specific terms.

The cloud API manager410then estimates resource-consumption costs of the API call as a function of the user details and API details retrieved from the cloud system data storage420. This estimated cost is embedded into the header of the HEAD-call response as metadata and returned by cloud API manager410, through known methods of client-server communications, to client application400.

In step550, the API consumption costs are extracted from the header and stored in the application400's API usage store405. This extraction and storage may be performed by the cloud API manager410, but may also be performed by a client-side module, such as the IDE plug-in or by a component of the present invention implemented as an internal module of the client application400.

In step560, if the cloud API manager410determined in step520that the intercepted API call is not a HEAD call, and that the system is not otherwise running in an emulation mode, the cloud API manager410submits the intercepted API call in a normal manner to the API server of the API service415. The resulting response, unlike the response of steps530-550, will contain a body section.

In step570, in a procedure analogous to that of step540, the Cloud API manager410queries cloud system data storage device420and derives from the retrieved user data resource-consumption costs incurred by servicing the original API call, including all GET and POST calls.

The cloud API manager410then estimates resource-consumption costs of the API call as a function of the user details and API details retrieved from the cloud system data storage420. This estimated resource-consumption cost of the API call is embedded into the header of the API-call response as metadata and returned by cloud API manager410, through known methods of client-server communications, to client application400.

In step580, much like step550, the API consumption costs are extracted from the API response header and stored in application400's API usage store405. As in step550, this extraction and storage may be performed by the cloud API manager410, but may also be performed by a client-side module, such as the IDE plug-in or by a component of the present invention implemented as an internal module of the client application400.

In step590, a client-side module of the present invention (such as an IDE plug-in or a customized component of client application400) incorporates the received consumption costs with costs that had previously been stored in the client API usage store405during earlier iterations of the iterative procedure of steps500-590.

If, for example, only a total cost of each API is tracked as a single number, that number may be added to the stored sum of all previously computed costs. If the stored costs are organized into separate sub-categories, the newly received costs may be added to each sub-category sum. In some embodiments, a weighting may be assigned to each such sub-category and a total API cost may be derived as a weighted sum of each sub-category sum. Other methods of computing a total cost are possible, as are known in the art.

In some cases, costs may be aggregated over a certain period of time. For example, a developer may want to determine whether a certain application400incurs higher API-consumption costs during typical usage patterns at different times of day. In such a case, an embodiment of the present invention might identify a distinct aggregate cost for each hour of a sequence of hour-long measurement periods. In this manner, a developer or potential user can estimate a total API-consumption cost of running an application during production under various types of usage patterns.

The iterative procedure of steps500-590concludes when a predetermined, implementation-dependent condition is met. For example, an embodiment may be run for 24 hours in order to gather enough data to provide a statistically meaningful cost result. In another case, an embodiment may be configured to run until an aggregated sum of API consumption costs reaches a certain threshold value. In this way, a user may be made aware that it is approaching, or has exceeded, a contractual or budgetary computing-cost limit.

In yet other embodiments, the procedure of step500-590may be performed for only one iteration, or for another fixed number of iterations, and then restarted after step600returns updated cost results to a user. Such an implementation would allow the embodiment to interactively provide users a live feed of a running total of API-consumption costs.

In step600, the IDE or client application400displays or otherwise communicates to a user, or to a downstream software application, the API-consumption costs derived during the most recent iteration of step590. This display or communication may be performed by any means known in the art, such as in an interactive onscreen dashboard, in a status area of an IDE, or as a message sent to a user's computer or mobile device.

Examples and embodiments of the present invention described in this document have been presented for illustrative purposes. They should not be construed to be exhaustive nor to limit embodiments of the present invention to the examples and embodiments described here. Many other modifications and variations of the present invention that do not depart from the scope and spirit of these examples and embodiments will be apparent to those possessed of ordinary skill in the art. The terminology used in this document was chosen to best explain the principles underlying these examples and embodiments, in order to illustrate practical applications and technical improvements of the present invention over known technologies and products, and to enable readers of ordinary skill in the art to better understand the examples and embodiments disclosed here.