US9521188B1 - Scheduled execution of instances - Google Patents

Abstract

Techniques are disclosed for a client-and-server architecture where the client makes scheduled execution of instances to the server. The server may then launch occurrences as indicated by one of these API calls at each of the scheduled times. The server may also implement operations to selectively execute particular occurrences, such as executing a new occurrence only when no other occurrences are still running. In other embodiments, the server may implement pricing information in a determination of whether to execute a particular occurrence.

Description

BACKGROUND

An application programming interface (API) is a specification that sets forth routines that may be invoked, and how those routines may be invoked. Calls to a particular API may then be used to effectuate the performance of certain actions. For instance, a client computer and a server computer may be communicatively coupled via a network, and the client may send the server calls in an API that the server implements. In turn, the server may receive these calls, and perform the associated processing.

BRIEF DESCRIPTION OF DRAWINGS

Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which:

FIG. 1 depicts an example system in which scheduled execution of instances may be implemented;

FIG. 2 depicts example operating procedures for a server processing a scheduled execution of an instance from a client;

FIG. 3 depicts example operating procedures for a server processing a scheduled execution of an instance from a client while incorporating spot pricing;

FIG. 4 depicts example operating procedures for a server processing a scheduled execution of an instance from a client while incorporating history information;

FIG. 5 depicts an example system that may carry out interrelated actions based on a scheduled execution of an instance;

FIG. 6 depicts additional example operating procedures for a server processing a scheduled execution of an instance from a client while incorporating spot pricing;

FIG. 7 depicts a computing system for launching virtual machine instances; and

FIG. 8 depicts a computing system diagram that illustrates a configuration for a data center for launching virtual machine instances.

DETAILED DESCRIPTION

This document describes techniques for scheduling execution of an instance, as well as other actions, among various embodiments. (For example, the instance may be a virtual machine instance or an instance that runs on bare hardware without use of a hypervisor.) In an example embodiment, a computing service may receive a request from a user that specifies an action (e.g., to run an instance), and a schedule to execute that action (e.g., at 12:30 am each day). In response to this request, the computing service may determine that a time at which the instance is scheduled to run has been reached (e.g., it is 12:30 am on some day), and then determine whether other requirements are met. For instance, a requirement may be that only one of these instances may run at a time; that no more than a threshold number of these instances may run at a time; that no more than a threshold number of instances have run within a recent period of time; or that a current cost of running the instance is below a maximum allowed cost.

In other embodiments, history information about how previous instances have run may be used to determine the requirements for running the present instance. For example, it may be that these instances function as black boxes—that it may be determined that they are running, but it may not be determined whether they are still progressing towards successful completion. In such cases, history information about for how long instances run may be used to determine how long it normally takes for an instance to successfully complete. Then, where the present instance runs for significantly longer than what is normal, it may be considered to have failed, and be terminated.

Embodiments of the present disclosure are directed to techniques for allowing interaction with a web service, such as a data storage service or a computing service. For example, a computing service that offers processing (through the use of instances) and data storage services is accessible through one or more application programming interfaces (APIs) that is usable by requestors of the computing service to access various capabilities of the computing service. Requestors may, for instance, use the one or more APIs to store data, retrieve stored data, or run instances, such as to process data or to perform other operations.

In an embodiment, one or more APIs of a computing service allow users to upload or select virtual machine volumes from a catalog, start and execute instances of these virtual machine volumes and take snapshots of these virtual machine volumes. An API call may, for example, include a location where the virtual machine volume is to be uploaded from along with parameters for its storage.

A customer may request the performance of any of the above operations by sending API requests to the computing service. Similarly, the computing service may provide responses to customer requests. Such requests and responses may be submitted over any suitable communications protocol, such as Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP) and the like, in any suitable format, such as Representational State Transfer (REST), Simple Object Access Protocol (SOAP) and the like. The requests and responses may be encoded, for example, using Base 64 encoding, encrypted with a cryptographic key or the like.

The following is an example API call and response to determine the status of two virtual machine instances, i-43a4412a and i-23a3397d. An API call may be made via a HTTPS (hypertext transfer protocol secure) protocol using a URL (uniform resource locator), as follows:

https://[example website].com/?Action=MonitorInstances&InstanceId.1=i-43a4412a &InstanceId.2=i-23a3397d&AUTHPARAMS

This request enables the monitoring of the status of a running virtual machine instance. The request may identify an endpoint of the service to which the API call is directed ([example website].com), the type of API call that is requested (Monitorinstances) and an identifier of the two instances for which monitoring is requested (i-43a4412a andi-23a3397d). The type of API call that is requested, as well as the identifier of the two instances for which monitoring is requested are contained within a query string in the URL—the portion to the right of the “?” in the URL. A server that receives such a URL may run a program and pass the query string to the program for processing.

After performing processing in accordance with the query string, the server may return a result to the requestor. The following is an example result that the server may return to the requestor:

<MonitorInstancesResponse xmlns=“http://
[example website].com/doc/2012-08-15/”>
<requestId>59dbff89-35bd-4eac-99ed-be587EXAMPLE</requestId>
<instancesSet>
<item>
<instanceId>i-43a4412a</instanceId>
<monitoring>
<state>pending</state>
</monitoring>
</item>
<item>
<instanceId>i-23 a3397d</instanceId>
<monitoring>
<state>pending</state>
</monitoring>
</item>
</instances Set>
</MonitorInstancesResponse>

As depicted, the result is formatted in XML (extensible markup language)—a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. The first line of the response identifies the type of response (MonitorInstancesResponse) and defines the namespace for the XML file (xmlns=“http://[example website].com/doc/2012-08-15”). A namespace is generally an identifier that allows for the disambiguation of homonym identifiers. A tag and associated value identifies the request being responded to (<requestId>59dbff89-35bd-4eac-99ed-be587EXAMPLE</requestId>). This may enable the requestor to distinguish between responses where the requestor makes multiple Monitorinstances requests. Then, there is a section that identifies each instance (e.g., <instanceId>i-43a4412a</instanceId>) along with an associated state of that instance (<state>pending</state>).

FIG. 1 depicts an example system in which scheduled execution of instances may be implemented. As depicted, three computers are connected throughnetwork104. These three computers areclient102, external facingserver106 andexternal server112. In turn, two computers and a database are connected to external facingserver106 via an internal network (not illustrated)—instance manager108,host110, anddatabase114. External facingserver106,instance manager108,host110 anddatabase114 may all be part of the same entity's infrastructure—e.g., they may operate in concert to implement services for an entity. In an embodiment, external facingserver106 may interact with outside computers (such as client102) via anetwork104 and issue instructions toinstance manager108 andhost110. For example, the external facingserver106 could be a web server.Instance manager108 andhost110 may then perform actions in response to those instructions. For instance,instance manager108 maintain a list of servers that can host instances and use the list to select host machines to run instances andhost110 may host instances.

Given this architecture, whenclient102 issues requests to external facingserver106 to start a virtual machine instance, external facingserver106 may issue instructions toinstance manager108 andinstance manager108 may selecthost110 to host the virtual machine. For instance, external facingserver106 may receive a request to launch an instance and route the request toinstance manager108 to start a virtual machine instance. Afterinstance manager108 selects a host to host the virtual machine instance, e.g.,host110,instance manager108 may issue a request to host110 to launch the virtual machine instance.

In this manner,client102 may send external facingserver106 an API call specifying an action, such as a launch instance command, along with a schedule andinstance manager108 and theinstance manager108 may perform the action at the times indicated by the API call without additional input fromclient102.

That is, embodiments may include using separate services to carry out functions like launching instances and generating snapshots within a service provider environment. More generally,FIG. 1, as well as the other figures, depicts simplified embodiments to illustrate concepts, and specific implementations may vary.

In embodiments, the procedures for scheduled execution of instances may be implemented on external facingserver106,instance manager108,host110, or a combination of those computers. For instance, external facingserver106 may receive an API call to schedule an action fromclient102 and store an indication of the call (such as an action to perform and the schedule at which to perform it) indatabase114. Then external facingserver106 may send an indication toinstance manager108 to checkdatabase114 for this indication of the call, andinstance manager108 performs the operations to perform instances of the call. In other embodiments,instance manager108 may periodically checkdatabase114 for indications of calls that have been stored there by external facingserver106, andinstance manager108 may then discover new calls to perform without being directly informed of these new calls by external facingserver106.

FIGS. 2-4 and 6 depict example operating procedures for embodiments of the present disclosure. It may be appreciated that there are embodiments of the disclosure that implement fewer, or more, operating procedures than the ones depicted inFIGS. 2-4 and 6. For example, there may be embodiments that implement either operation210 oroperation212 ofFIG. 2, but do not implement both of these operations. It may also be appreciated that there are embodiments that implement the operating procedures ofFIGS. 2-4 and 6 in a different order than is depicted inFIGS. 2-4 and 6. In embodiments, the operations ofFIGS. 2-4 and 6 may be implemented in external facingserver106,instance manager108, host110 ofFIG. 1, or a combination thereof.

As used herein, identifying particular instances of an object or thing as being “first” or “second” is not intended to limit the number of those instances or to imply that the one marked as being the “first” one is the first instance that has occurred. Rather, these terms are used to distinguish instances from each other. Additionally, it is written that occurrences of actions are performed. Where the same action is being performed multiple times (e.g., start an instance every hour), an occurrence of an action is used to refer to one time that this action is performed.

FIG. 2 depicts example operating procedures for a server processing an API call to perform a scheduled action from a client. The call is referred to herein as being a call to perform a scheduled action, because the action specified in the call is then scheduled to execute multiple times. Where these are referred to in the plural form—as API calls to perform scheduled actions—that is to indicate that a client may send multiple such calls to a server, and each one of these calls may be scheduled to run periodically for multiple times. It may be appreciated that these techniques may be applied to calls that are scheduled to run multiple times, even if these scheduled times are not strictly periodic. An embodiment of where scheduled, periodic calls may be implemented may be to start an instance that receives data from the INTERNET or a storage service, uses that data to update a web page (e.g., with an indication of whether a particular server is running where the received data follows from the instance pinging that server) and then shuts down. Since the instance is not constantly retrieving data and updating the web page, the instance does not need to constantly run (at a cost of processing resources), and so may be run only at some times.

Another example of scheduled execution of instances would be to start up and tear down entire cloud-computing systems. For example, a business may not just use one instance, or even multiple instances operating independently. A business may use multiple instances operating in concert. In such a situation, a business's instances may be started just before the start of the business day, and the business's instances may be shut down at the close of the business day. This may be more broadly extended to forming cloud computing resources at a scheduled time, where the resources work with each other—e.g., one instance performs a federation services role, one instance performs a login role and one instance performs a mail server role, and accessing the mail server involves coordinated action from all three instances. Such embodiments are described in more detail with reference toFIG. 5, below.

The operating procedures ofFIG. 2 begin withoperation202, which depicts receiving a request. In embodiments, an API call may be received from a client computer (such asclient102 ofFIG. 1). In a conventional manner, the client would send an API call each time the client desires that the API call be implemented. In contrast, inFIG. 2, the client may send one API call that identifies multiple times at which an associated action is to be processed.

In embodiments, an API call comprises a hypertext transfer protocol (HTTP) or hypertext transfer protocol secure (HTTPS) uniform resource locator (URL)—e.g., https://[example website].com/?Action=RunInstances&ImageId=i-43a4412a &MaxCount=1&MinCount=1&AUTHPARAMS. In embodiments, a parameter of such an asynchronous API call is found within the query string of that URL—the portion of that URL to the right of the “?”. In addition, in embodiments of the disclosure information such as the schedule to perform the action may also be contained within the query string of the URL.

Afteroperation202, the process flow moves tooperation204, which depicts determining whether a first time indicated in the schedule has been reached. Determining whether the first time has been reached may involve, for example, executing a process that keeps track of both the current time, when the first time is and compares the two to determine if the current time has exceeded the first time. For example, when the API call indicates that the associated action should be processed once per hour, this first time may be one hour after that API call is received. In an embodiment, after the external facingserver106 receives the request a record can be created indatabase114 that includes the information that the computing service uses to launch the instance according to the schedule, for example, the record could identify the action (e.g., run instance), the schedule, the customer ID that submitted the request, instance identifiers for the request, the authorization parameters for the request, etc. The instance manager can periodically access the database and read the record. If this first time of the period time has not yet been reached, then the process flow waits atoperation204 until this first time has been reached. If this first time of the period of time has been reached, then the process flow moves tooperation206.

Operation206 depicts starting a first occurrence of the action. This may comprise performing the action as indicated in the API call. For instance, the API call may identify the action as starting an instance, which, once started, will perform some operations before terminating. Where this is the case,operation206 may comprise starting an instance as indicated by the API call. For example, theinstance manager108 can read the record and determine the parameters for launching the virtual machine. Theinstance manager108 can select a server to host the virtual machine and send a RunInstance command to the selected host. In response to the command, the host can launch the instance.

After a first occurrence of the action has been started inoperation206, the process flow moves tooperation208, which depicts determining whether a second time specified by the schedule has been reached.Operation208 may be implemented in a manner similar to howoperation204 is implemented. Continuing with the example of the action being scheduled to be processed every hour, the first time may be one hour after the API call is received, and the second time may be one hour after the first time—or two hours after the API call is received. If this second time has not yet been reached, then the process flow waits atoperation208 until this second time has been reached. If this second time of the period of time has been reached, then the process flow moves to operation210.

Turning now to operation210, while there are generally embodiments that implement fewer operations than are depicted inFIG. 2, in particular, operation210 (as well asoperations212,216, and218) may be considered optional operations, and are indicated as such withinFIG. 2 by being represented via dashed lines. Operation210 depicts determining whether the first occurrence of the action is still running. For instance, where performing the first occurrence of the action comprises executing a process (such as an instance), operation210 may comprise determining whether this process is still executing. Operation210 may be implemented in embodiments where there is to be a limit of how many occurrences of a given action are allowed to be performed concurrently. It may be that there is a desire by the client to limit the number of occurrences of an action running concurrently because multiple occurrences may read to and write from the same data, and their concurrent execution may cause inconsistent state problems. It may also be that there is a desire by the client to limit the number of occurrences of an action running because running each action costs money and the client is operating on a budget. If the first occurrence of the action is still running, then the process flow moves tooperation220, where the process flow ends. If the first occurrence of the action is no longer running, then the process flow moves tooperation212.

Operation212 depicts determining whether the number of occurrences currently running is below a maximum number of occurrences allowed to run concurrently. For instance, for budget reasons similar to those stated for operation210, the client may specify the maximum number of concurrently-running occurrences at 3. Where there are only two concurrently-running instances when the second time is reached, then another occurrence of the action may be begun. Where there are three or more concurrently-running instances when the second time is reached, then another occurrence of the action may not be begun, even though the second time has been reached. If the number of occurrences currently running is not below a maximum number of occurrences allowed to run concurrently, then the process flow moves tooperation220, where the process flow ends. If the number of occurrences currently running is not below a maximum number of occurrences allowed to run concurrently, then the process flow moves tooperation214.

Operation212 may be more generally expressed as consulting a policy to determine whether to start the second occurrence of the action, beyond merely determining that the time to start the second occurrence of the action has been reached. In this sense, then determining whether the number of occurrences currently running is below a maximum number of occurrences allowed to run concurrently is a case where the policy specifies the maximum number of occurrences that are allowed to run concurrently. Other policies may include whether any other occurrence of the action is still running (e.g., where the maximum number of occurrences that are allowed to run concurrently is one); whether the most recently started occurrence is still running (though previously started occurrences may still be running); whether a budget has been exceeded (where there is a charge associated with performing occurrences of the action); whether it is likely that a budget will be exceeded in performing this occurrence of the action; and whether it is likely that this occurrence of the action will be completed within a given amount of time.

Another example of a policy incorporates pricing information, as described in more detail with respect toFIGS. 3 and 6. There may be a spot market where customers can bid on computing resources and be able to use those resources as long as their bid exceeds the current spot price. The spot price may vary over time, such as based on supply of and/or demand for those computing resources. There may also be the option to execute occurrences of an action on-demand, where computing capacity is guaranteed at a set time, without regard to the spot market. In embodiments, the on-demand price may be generally higher than the spot-market price, since the on-demand price guarantees access to computing resources, while the spot-market price does not (because the customer's bid may not be sufficient to secure those resources). In this case, the policy may be to attempt to secure computing resources to perform an occurrence of the action on the spot market, and if that fails, fall back on using on-demand resources.

Operation214 depicts starting a second occurrence of the action.Operation214 may be implemented in a similar manner asoperation206—starting the first occurrence of the action—is implemented.

Afteroperation214, the process flow moves tooperation216, where it is determined if a maximum time for the second occurrence of the action to run has been reached. It may be that it is difficult to determine directly whether an occurrence of an action has been successfully completed. For instance, where the action involves starting an instance that performs various operations, it may be possible to determine whether the instance is functioning, but not whether those various operations performed within the instance have been successfully performed. In the absence of this direct information about whether the occurrence has been successfully completed, an amount of time that the occurrence has run for may be used as indirect information about the success of the occurrence. For instance, a client may indicate that no action should run for more than 30 minutes, because the action almost always completes successfully before 30 minutes of running. Here, the maximum time for the second occurrence of the action (and other occurrences of the action) to run may be set at 30 minutes, and when 30 minutes passes since the starting of the second occurrence of the action, that occurrence may be determined to have failed, and the occurrence should be terminated.

In other embodiments, the user that sent the API call may specify a time-to-live (TTL) value in the call, which indicates how long an occurrence of an instance may run before it is to be terminated. Determining whether the maximum time has been reached inoperation216 may comprise determining whether this TTL value has been exceeded by the amount of time the occurrence of the instance has run.

If the maximum time for the second occurrence of the action to run has not been reached, then the process flow moves tooperation220, where the process flow ends. If the maximum time for the second occurrence of the action to run has been reached, then the process flow moves tooperation218.

Operation218 depicts ending the second occurrence of the action. In other embodiments, rather than ending the second occurrence of the action, a computer that implements these operations may send a notification to the client that the second occurrence is still running after the expiration of the TTL described with respect tooperation216. Afteroperation218 completes, the process flow moves tooperation220, where the process flow ends.

FIG. 3 depicts example operating procedures for a server processing a scheduled API call from a client while incorporating spot pricing. It may be appreciated that aspects of embodiments regarding determining whether a time to start a periodic action has been reached have been omitted for the sake of clarity. These aspects of embodiments are depicted inFIG. 2. The operating procedures ofFIG. 3 may be implemented in concert with the operating procedures ofFIG. 2, to collectively implement embodiments where pricing information is factored into processing periodic actions.

In other embodiments, there may be fees associated with performing actions indicated by API calls. Different customer accounts may pay different fees, or one customer account may pay different fees for different actions. For instance, there may be a higher fee for a guarantee that a call will be processed at a given time, and a lower fee for a guarantee only that a call will be processed only if possible after processing all high-priority calls. Then, when a scenario occurs where too much processing requested at a given time, a server may perform a triage on the requested calls. Given the two-status embodiment above (higher fee and lower fee), it may be initially determined that the lower fee calls will not be processed in favor of the higher fee calls, until the projected processing is below a maximum amount. In embodiments, there may be a bidding system for resources at a given time, so that a requestor that is sufficiently motivated and funded may ensure that its request will be executed at that time.

The operating procedures ofFIG. 3 begin withoperation302, which depicts receiving a request to invoke an action at scheduled times.Operation302 may be implemented in a manner similar tooperation202 ofFIG. 2. Inoperation302, the query string may additionally include pricing information, such as a maximum price at which to start an occurrence of the action (as is used in, for example, operation304). Pricing information may identify a price per amount of processing resources used (e.g., data storage or central processing unit (CPU) runtime).

The operating procedures ofFIG. 3 may be integrated with the operating procedures ofFIG. 2. When a computing service attempts to run a scheduled action, the computing service may check the spot price and use spot resources instead of (possibly more expensive) on-demand instances or reserved instances when the spot price is low, and the computing service has confidence that the action will complete before the spot price goes up. This confidence that the action will complete in time may be based on a history of how long the action takes to complete, and a history of the spot price (e.g., it is Monday morning, and the spot price is generally low on Monday mornings).

Afteroperation302, theinstance manager108 can read the schedule and determine to launch an instance and the process flow moves tooperation304, which depicts determining whether the price identified in the request ofoperation302 is below the current spot price. The current spot price is the prevailing price at which an action may use processing resources. When the identified price is above the spot price it means that the prevailing price is less than the client is willing to spend, and that the action should be started. When the identified price is below the spot price it means that the prevailing price is more than the client is willing to spend, and that the action should not be started. Where the identified price is above the spot price, then the process flow moves tooperation314, where the process flow ends. In this case, theinstance manager108 may check the spot price at a later time any try to launch the instance again. Alternatively, theinstance manager108 may launch the instance from a pool of on-demand instances (i.e., from a pool of fixed priced instances). For example, theinstance manager108 could execute the process described with respect toFIG. 2. Where the identified price is below the spot price, then the process flow moves tooperation306.

Operation306 depicts determining whether starting another instance of the action would cause the frequency of the action to be performed above an allowable frequency at which the action may be performed. There may be a maximum rate at which occurrences of the action are performed, and this may be less than the rate indicated by the period in the request. For example, the period indicated in the request may be to check every 30 minutes whether the spot market is below the identified price, and if that is the case, and if no more than two occurrences have been started in the past 3 hours, then start another occurrence. Where starting another instance of the action would cause the frequency of the action to be performed above an allowable frequency at which the action may be performed, the process flow moves tooperation314, where the process flow ends. Where starting another instance of the action would cause the frequency of the action to be performed below an allowable frequency at which the action may be performed, the process flow moves tooperation308.

Operation308 depicts starting an occurrence of the action.Operation308 may be implemented in a manner similar tooperation206 ofFIG. 2.

Afteroperation308, the process flow moves tooperation310, which depicts determining whether the spot price is now above a maximum allowable price for the action. There may be two prices indicated in a request—a price at which an occurrence of an action may be started, and a price that, if reached during execution of the action, the action should be immediately stopped, regardless of how close the action is to completion (other embodiments may factor in how close the action is to completion in determining the maximum price). Where the spot price is above a maximum allowable price for the action, the process flow moves tooperation312—where the occurrence of the action that was started inoperation308 is ended—and then tooperation314, where the entire process flow ends. When the spot price remains below a maximum allowable price for the action, the process flow moves tooperation316.

Operation316 depicts determining whether the occurrence of the action has been completed. For instance, where the action involves starting an instance that will terminate itself upon completion of the rest of the action,operation316 may comprise determining if that instance is still running. Where the occurrence of the action has been completed, the process flow moves tooperation314, where the process flow ends. Where the occurrence of the action has not been completed, then the process flow moves back tooperation310, which continues to monitor whether the spot price exceeds the maximum allowable price for the action. In this manner,operations310 and316 form a decision loop, which terminates when either the occurrence of the action is complete or the spot price exceeds the maximum allowable price for the action.

FIG. 4 depicts an example operating procedures for a server processing a scheduled API call from a client while incorporating history information. Where the associated action is scheduled to run multiple times, information about how the action has been processed in the past (e.g., how long it takes to process) may be determined in a way that does not exist where an action is only being processed a single time. It may be appreciated that aspects of embodiments regarding determining whether a time to start a periodic action has been reached have been omitted for the sake of clarity. These aspects of embodiments are depicted inFIG. 2. The operating procedures ofFIG. 4 may be implemented in concert with the operating procedures ofFIG. 2, to collectively implement embodiments where history information is factored into processing periodic actions.

Operation402 depicts determining whether a first occurrence of the action has been completed. When the first occurrence of the action has not been completed, the process flow loops onoperation402 until the first occurrence of the action has been completed. Where the first occurrence of the action has been completed, then the process flow moves tooperation404.

Operation404 depicts recording information regarding execution of the first occurrence of the action. This information may indicate how long the first occurrence of the action lasted (in total time and/or processor time), how much bandwidth was used in executing the first occurrence of the action or whether the first occurrence of the action completed successfully or failed (or likely completed successfully or failed). In embodiments, the client that originally sent the API call can send an API call to the instance manager indicating whether the occurrence of the action completed successfully. Alternatively, after the instance completes the action it can be configured to send the API call to the computing service. This may be implemented via a callback API call that the client sends to the computing service in a similar manner as how the client sent the server the original API call. In an embodiment, the computing service may be informed of whether the occurrence completed successfully because the computing service may not have an agent running within the virtual machine that can determine whether the code running within the instance competed the action. This information may be stored by the server, and either combined with information about executing additional occurrences (such as in operation408) or used as the history information on its own.

Upon completion ofoperation404, the process flow moves tooperation406, which depicts determining whether a second occurrence of the action has been completed.Operation406 may be implemented in a similar manner asoperation402. Where the second occurrence of the action has not been completed, the process flow loops onoperation406 until the second occurrence of the action has been completed. Where the second occurrence of the action has been completed, then the process flow moves tooperation408.

Operation408 depicts recording information regarding execution of the second occurrence of the action.Operation408 may be implemented in a similar manner asoperation404.

Upon completion ofoperation404, the process flow moves tooperation406, which depicts compiling the information regarding the execution of the first and second occurrences of the action that was recorded inoperations404 and408. For instance, compiling the information may include determining an average execution time, a standard deviation of the execution time or a rate at which occurrences of the action successfully completed.

Upon completion ofoperation408, the process flow moves tooperation412, which depicts using the compiled information to determine whether the client is tolerant of the action failing. For instance, where the action is to launch an instance, the launched instance may then perform some operation that may complete successfully or fail. Here, the action may be considered to have failed, even though the act of launching the instance itself completed successfully, because the operation that is part of the action failed to complete. An action may be determined to be fault tolerant where the client has configured the action (via the request in the API call) such that the action completes successfully relatively rarely. That the action rarely completes successfully may be taken as an indication that it is fault tolerant—that the client does not believe that the action must complete successfully a high amount of the time. Likewise, where an action usually completes successfully, that may be taken as an indication that the action is not fault tolerant—that the client does believe that the action must complete successfully a high amount of the time. Where it is determined that the action is fault tolerant, the process flow moves tooperation414. Where it is determined that the action is not fault tolerant, the process flow moves tooperation416.

Operation414 depicts placing future occurrences of the action on hardware in response to determining that the action is fault tolerant. The hardware that a fault-tolerant action may be placed on may be hardware that is relatively likely to be the cause of a fault (such as by failing during execution of the action). This may be older or less-reliable hardware that is more likely to fail during execution of an occurrence of the action than other hardware that is available for execution of the action. Placing the action on hardware based on fault-tolerance may allow for the use of hardware that is otherwise unusable due to the risk that a highly-fault-tolerant action would be placed on it were it to be in service.

Operation416 depicts placing future occurrences of the action on hardware in response to determining that the action is not fault tolerant. The hardware that not a fault-tolerant action may be placed on may be hardware that is highly reliable and is relatively unlikely to be the cause of a fault.

FIG. 5 depicts an example system that may carry out interrelated actions based on a scheduled execution of an instance.Client502 may send an API call that indicates a scheduled execution of an instance toweb services platform500. Carrying out this scheduled execution of an instance may involve performing interrelated actions, such as launching two instances that need to know a network address for each other so that they can communicate, even though an instance may not be assigned a network address until it is launched. The depicted components and their function will first be discussed, and this will be followed by a discussion of how these components may carry out interrelated actions based on a scheduled execution of an instance.

Web services platform500 comprisesfront end504, and hosts508aand508b. This is a simplified embodiment to illustrate these aspects ofweb services platform500, and it may be appreciated that there are embodiments of a web services platform that include more (or fewer components). In turn, withinweb services platform500, each host comprises a host manager and one or more instances. That is, host508acompriseshost manager506a, andinstances510a,510b, and510c. Likewise, host508bcompriseshost manager506b, andinstances510d,510e, and510f. In other embodiments, hosts508aand508bmay be implemented in a similar manner ashost110 ofFIG. 1 and carry out similar functions ashost110.

Host managers506aand506bmay execute within the host partition of their respective host.Host managers506aand506bmay configure, launch, and terminate instances. Where instance images are stored somewhere other than on the host,host managers506aand506bmay retrieve and configure these instance images in the process of configuring and launching instances.Host managers506aand506bmay also create and remove firewalls for use in processing the network communications of instances.

Instances510a,510b,510c,510d,510e, and510fmay comprise a virtualized hardware configuration and an operating system that runs on that virtualized hardware configuration. This virtualized hardware configuration may include an amount of virtual memory, a number and type of virtual processors (e.g., 32-bit or 64-bit processors, and an associated architecture), an amount of virtual storage, and a level of I/O performance.

Front end504 may execute within an instance, or may execute in the host partition of a host.Front end504 may host APIs used as an interface betweenweb services platform500 andclient502.Front end504 may receive API calls fromclient502, and based on those calls, determine whether there is sufficient capacity of a specific kind (e.g., a specific hardware class with which to execute a particular instance type) to fulfill the action indicated by those calls.Front end504 may also be in communication withhosts508aand508band determine which host will carry out the action specified in a call. Where these actions are scheduled for some time after the calls are received,front end504 may store an indication of these actions and monitor when the scheduled time to carry out these actions occurs. When the scheduled time does occur,front end504 may determine which host amonghosts508aand508bwill carry out the action, and indicate to that host to carry out that action. In other embodiments,front end504 may be implemented in a similar manner as external facingserver106 ofFIG. 1 and carry out similar functions as external facingserver106.

Front end504 may receive API calls fromclient502 that indicate an action, such as performing a scheduled API call of an instance. These actions may be interrelated. For instance, the action may involve launchinginstances510aand510dwhere these instances are configured to communicate with each other. That is, the action may involve launching each instance, and configuring each instance both with its own network address and an indication of the other instance's network address. Where an instance is typically assigned a network address while it is being launched, it may be that neither instance can be fully launched and configured before the other instance has been configured (since fully configuring one instance requires knowledge of the other instance's network address). In such a scenario,front end504 orhost manager506aor506bmay reserve a network address for each instance. Then each instance may be configured and launched using these reserved network addresses.

In other embodiments, one instance may be configured until it is assigned a network address. Then, the other instance may be configured with both its own network address and the network address of the first instance (which has already been assigned). Finally, the configuring the first instance may resume and it may be configured with the network address of the other instance, which has already been assigned.

In other embodiments, launching the two instances so that they may communicate with each other may include configuring a firewall on each ofhost manager506aand506b. When launching the two instances, front end504 (or another component of web services platform500) may have an indication that each instance is to be able to communicate with the other instance. Then,front end504 may instructhost manager506ato configure its firewall to allowinstance510aonhost508ato communicate withinstance510d, and instructhost manager506bto configure its firewall to allowinstance510donhost508bto communicate withinstance510a.

FIG. 6 depicts additional example operating procedures for a server processing a scheduled execution of an instance from a client while incorporating spot pricing. The operating procedures ofFIG. 6 are similar to those ofFIG. 3 in that they both deal with spot pricing. The operating procedures ofFIG. 3 generally depict embodiments where instances are started based on a current spot price, and where a maximum frequency of starting occurrences is capped. In contrast, the operating procedures ofFIG. 6 generally depict embodiments where history information on how occurrences of an action execute (such as history information gathered through the operating procedures ofFIG. 4) are used to project whether executing another occurrence of the action will meet pricing parameters, and determining whether the execute this additional occurrence based on this projection.

The operating procedures ofFIG. 6 begin withoperation602, which depicts receiving a request. In embodiments, an API call may be received from a client computer (such asclient102 ofFIG. 1). In a conventional manner, the client would send an API call each time the client desires that the associated action be implemented. In contrast, inFIG. 6, the client may send one API call that identifies multiple times at which the associated action is to be processed.

Afteroperation602, the process flow moves tooperation604, which depicts determining whether a first time of the period time has been reached. Determining whether the first time has been reached may involve, for example, executing a process that keeps track of both the current time, when the first time is, and compares the two to determine if the current time has exceeded the first time. For example, when the API call indicates that the associated action should be processed once per hour, this first time may be one hour after that API call is received. If this first time of the period time has not yet been reached, then the process flow waits atoperation604 until this first time has been reached. If this first time of the period of time has been reached, then the process flow moves tooperation606.

Operation606 depicts starting a first occurrence of the action. This may comprise performing the action as indicated in the API call. For instance, the API call may identify the action as starting an instance, which, once started, will perform some operations before terminating. Where this is the case,operation606 may comprise starting an instance as indicated by the API call.

After a first occurrence of the action has been started inoperation606, the process flow moves tooperation608, which depicts determining whether a second time of the period time has been reached.Operation608 may be implemented in a manner similar to howoperation604 is implemented. Continuing with the example of the action being scheduled to be processed every hour, the first time may be one hour after the API call is received, and the second time may be one hour after the first time—or two hours after the API call is received. If this second time of the period time has not yet been reached, then the process flow waits atoperation608 until this second time has been reached. If this second time of the period of time has been reached, then the process flow moves tooperation610.

Operation610 depicts estimating a cost of running a second occurrence of the action. This estimate may be based on the actual cost of running the first occurrence of the action, and of running other occurrences of the action. For instance, occurrences of the action run at night may use more processing resources than occurrences of the action running during the day. It may be that the action incorporates conditional logic such that it performs additional operations at night (e.g., during the day, the action checks several websites and gathers information from them, and at night the action both checks those websites and gathers information from them, and performs analysis of the data gathered over the course of the day).

In other embodiments, running previous occurrences of the action, including the first occurrence, may be done on different types of hardware (e.g., the different sizes of computing resources discussed with respect toFIG. 7), and data may be gathered on how much time and cost is involved with running the action on these different hardware configurations. In such embodiments, estimating a cost of running a second occurrence of an action may then comprise estimating a cost of running a second occurrence of the action based on available hardware configurations.

Where occurrences of the action are run using virtual machine instances, these virtual machine instances may vary (such as in number of virtual CPU cores, virtual memory, virtual disk space, or CPU architecture—e.g. x32 or x64). In embodiments, running previous occurrences of the action, including the first occurrence, may be done on different types of virtual machines, and data may be gathered on how much time and cost is involved with running the action on these different virtual machine configurations. In such embodiments, estimating a cost of running a second occurrence of an action may then comprise estimating a cost of running a second occurrence of the action based on available virtual machine configurations.

There may also be a maximum amount of time for which an occurrence of the action may run, as indicated by the customer or otherwise determined. In these embodiments, estimating the cost of running a second occurrence comprises estimating the cost of running the second occurrence on those hardware configurations where it is estimated that the action will complete within the maximum amount of time. In some embodiments, a customer may indicate a preference for running the action as quickly as possible as long as the cost does not exceed a threshold amount. In other embodiments, a customer may indicate a preference for running the action as cheaply as possible as long as the time does not exceed the maximum allowable amount. In all of these embodiments, it is the history of how the action has run in previous occurrences (based on, e.g., the type of hardware it was run on, the time of day/week/month/etc. it was run, the cost it incurred while running, and the amount of time it took to run) that is used in determining whether, and how, to run the current instance of the action.

This history information based on how previous occurrences of the action may be used to determine placement of the current occurrence of the action among multiple physical hosts, such as theserver computers802A-802N ofFIG. 8. These physical hosts may be heterogeneous—they may be made of different hardware, or they may currently be experiencing different loads. Given that these physical hosts are different, an estimate of how much the current occurrence of the action will cost on these different physical hosts may be used in placing the current occurrence of the action on the host on which the action may be run the most cheaply. Similar determinations may be made for placing the current occurrence of the action on a host such that the action completes as quickly as possible without exceeding a cost limit, or completes as cheaply as possible without exceeding a time limit.

Operation612 depicts determining whether it is likely that the cost of running a second occurrence of the action will be below a threshold amount. If the cost is estimated to be above the threshold amount, the process flow moves tooperation616, where the process flow ends. If the cost is estimated to be below the threshold amount, the process flow moves tooperation614.

Operation614 depicts starting a second occurrence of the action.Operation614 may be implemented in a similar manner asoperation606—starting the first occurrence of the action—is implemented.

Afteroperation614, the process flow moves tooperation616, where the process flow ends.

FIG. 7 and the following description are intended to provide a brief, general description of a suitable computing environment in which the embodiments described herein may be implemented. In particular,FIG. 7 is a system and network diagram that shows anillustrative operating environment700 that includes a programmable execution service (“PES”) platform708 (which may be referred to as a “PES708”) for providing on-demand access to computing resources, such as virtual machine instances. In embodiments,PES708 may be implemented with multiple occurrences ofweb services platform500 ofFIG. 5, or the combination of external facingserver106,instance manager108,host110, anddatabase114 ofFIG. 1 (where this combination orweb services platform500 each serve as a data center702). As will be described in greater detail below, the computing resources may be launched or otherwise instantiated based upon an expected cost and value of the computing resources to an operator of thePES platform708.

ThePES platform708 can provide computing resources for executing applications on a permanent or an as-needed basis. The computing resources provided by thePES platform708 may include various types of resources, such as data processing resources, data storage resources, data communication resources, and the like. Each type of computing resource may be general-purpose or may be available in a number of specific configurations. For example, data processing resources may be available as virtual machine instances. The instances may be configured to execute applications, including Web servers, application servers, media servers, database servers, and the like. Data storage resources may include file storage devices, block storage devices, and the like.

Each type or configuration of computing resource may be available in different sizes, such as large resources, consisting of many processors, large amounts of memory, and/or large storage capacity, and small resources consisting of fewer processors, smaller amounts of memory, and/or smaller storage capacity. Customers may choose to allocate a number of small processing resources as Web servers and/or one large processing resource as a database server, for example.

The computing resources provided by thePES platform708 are enabled by one ormore data centers702A-702N (which may be referred herein singularly as “a data center702” or in the plural as “the data centers702”). The data centers702 are facilities utilized to house and operate computer systems and associated components. The data centers702 typically include redundant and backup power, communications, cooling, and security systems. The data centers702 might also be located in geographically disparate locations. One illustrative configuration for a data center702 that implements the concepts and technologies disclosed herein for launching virtual machine instances will be described below with regard toFIG. 8.

The customers and other consumers of thePES platform708 may access the computing resources provided by the data centers702 over a wide-area network (“WAN”)706. Although a WAN is illustrated inFIG. 7, it should be appreciated that a local-area network (“LAN”), the Internet, or any other networking topology known in the art that connects the data centers702 to remote customers and other users may be utilized. It should also be appreciated that combinations of such networks might also be utilized.

Thecustomer computing system704 is a computer utilized by a customer or other consumer of thePES platform708. For instance, thecustomer computing system704 may be a server computer, a desktop or laptop personal computer, a tablet computer, a wireless telephone, a PDA, an e-reader, a game console, a set-top box, or any other computing device capable of accessing thePES platform708.

As will be described in greater detail below, thecustomer computing system704 may be utilized to configure aspects of the computing resources provided by thePES platform708. In this regard, thePES platform708 might provide a Web interface through which aspects of its operation may be configured through the use of a Web browser application program executing on thecustomer computing system704. Alternatively, a stand-alone application program executing on thecustomer computing system704 might access an application programming interface (“API”) exposed by thePES platform708 for performing the configuration operations. Other mechanisms for configuring the operation of thePES platform708, including launching new virtual machine instances on thePES platform708, might also be utilized.

According to embodiments disclosed herein, the capacity of purchased computing resources provided by thePES platform708 can be scaled in response to demand. In this regard, scaling refers to the process of instantiating (which may also be referred to herein as “launching” or “creating”) or terminating (which may also be referred to herein as “de-scaling”) instances of computing resources in response to demand. In this manner, the capacity of resources purchased by a customer of thePES platform708 can be scaled on-demand.

Auto scaling is one mechanism for scaling computing resources in response to increases or lulls in demand for the resources. Auto scaling allows customers of thePES platform708 to configure theplatform708 to scale their purchased computing resources according to conditions defined by the customer. For instance, rules may be defined for scaling up capacity in a particular manner in response to the occurrence of specified conditions, such as a spike in demand. Similarly, rules might also be defined to scale down capacity in a particular manner in response to the occurrence of other conditions, such as a lull in demand. The mechanisms disclosed herein for launching virtual machine instances might be utilized when instances are manually launched by a customer or when instances are launched by an auto scaling component in thePES platform708.

ThePES platform708 may also be configured with a deployment component to assist customers in the deployment of new instances of computing resources. The deployment component may receive a configuration from a customer that includes data describing how new instances should be configured. For example, the configuration might specify one or more applications or software components that should be installed in new instances, provide scripts and/or other types of code to be executed in new instances, provide cache warming logic specifying how an application cache should be prepared, and other types of information. The deployment component utilizes the customer-provided configuration and cache warming logic to launch, configure, and prime new instances of computing resources.

FIG. 8 depicts a computing system diagram that illustrates one configuration for adata center802 that implements aPES platform708, including the concepts and technologies disclosed herein for launching a virtual machine instance. Theexample data center802 shown inFIG. 8 includesseveral server computers802A-802N (which may be referred herein singularly as “aserver computer802” or in the plural as “theserver computers802”) for providing computing resources for executing an application. Theserver computers802 may be standard tower or rack-mount server computers configured appropriately for providing the computing resources described above. For instance, in one implementation theserver computers802 are configured to provideinstances806A-806N of computing resources.

In one embodiment, theinstances806A-806N (which may be referred herein singularly as “aninstance806” or in the plural as “theinstances806”) are virtual machine instances. As known in the art, a virtual machine instance is an instance of a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. In the example of virtual machine instances, each of theservers802 may be configured to execute aninstance manager808 capable of executing the instances. Theinstance manager808 might be a hypervisor or another type of program configured to enable the execution ofmultiple instances806 on asingle server802, for example. As discussed above, each of theinstances806 may be configured to execute all or a portion of an application.

It should be appreciated that although the embodiments disclosed herein are described primarily in the context of virtual machine instances, other types of instances can be utilized with the concepts and technologies disclosed herein. For instance, the technologies disclosed herein might be utilized with instances of storage resources, instances of data communications resources, and with other types of resources. The embodiments disclosed herein might also execute all or a portion of an application directly on a computer system without utilizing virtual machine instances.

Thedata center802 shown inFIG. 8 also includes aserver computer804 reserved for executing software components for managing the operation of thedata center802, theserver computers802, and theinstances806. In particular, theserver computer804 might execute amanagement component810. As discussed above, a customer of thePES platform808 might utilize thecustomer computing system804 to access themanagement component810 to configure various aspects of the operation ofPES platform808 and theinstances806 purchased by the customer. For example, the customer may purchase instances and make changes to the configuration of the instances. The customer might also specify settings regarding how the purchased instances are to be scaled in response to demand. The customer might also provide requests to launch instances to themanagement component810.

As also described briefly above, anauto scaling component812 scales theinstances806 based upon rules defined by a customer of thePES platform808. In one embodiment, for instance, theauto scaling component812 allows a customer to specify scale up rules for use in determining when new instances should be instantiated and scale down rules for use in determining when existing instances should be terminated.

Theauto scaling component812 may execute on asingle server computer804 or in parallel acrossmultiple server computers802 in thePES platform808. In addition, theauto scaling component812 may consist of a number of subcomponents executing ondifferent server computers802 or other computing devices in thePES platform808. Theauto scaling component812 may be implemented as software, hardware, or any combination of the two. Theauto scaling component812 may monitor available computing resources in thePES platform808 over an internal management network, for example.

As discussed briefly above, thedata center802 may also be configured with adeployment component814 to assist customers in the deployment ofnew instances806 of computing resources. Thedeployment component814 may receive a configuration from a customer that includes data describing hownew instances806 should be configured. For example, the configuration might specify one or more applications that should be installed innew instances806, provide scripts and/or other types of code to be executed for configuringnew instances806, provide cache warming logic specifying how an application cache should be prepared, and other types of information.

Thedeployment component814 utilizes the customer-provided configuration and cache warming logic to configure, prime, and launchnew instances806. The configuration, cache warming logic, and other information may be specified by a customer using themanagement component810 or by providing this information directly to thedeployment component814. Other mechanisms might also be utilized to configure the operation of thedeployment component810.

In theexample data center802 shown inFIG. 8, anappropriate LAN806 is utilized to interconnect theserver computers802A-802N and theserver computer804. TheLAN806 is also connected to theWAN706 illustrated inFIG. 7. It should be appreciated that the network topology illustrated inFIGS. 7 and 8 has been greatly simplified and that many more networks and networking devices may be utilized to interconnect the various computing systems disclosed herein. Appropriate load balancing devices or software modules might also be utilized for balancing a load between each of thedata centers802A-802N, between each of theserver computers802A-802N in eachdata center802, and betweeninstances806 purchased by each customer of thePES platform808. These network topologies and devices should be apparent to those skilled in the art.

It should be appreciated that thedata center802 described inFIG. 8 is merely illustrative and that other implementations might be utilized. In particular, functionality described herein as being performed by themanagement component810, theauto scaling component812, and thedeployment component814 might be performed by one another, might be performed by other components, or might be performed by a combination of these or other components. Additionally, it should be appreciated that this functionality might be implemented in software, hardware, or a combination of software and hardware. Other implementations should be apparent to those skilled in the art.

The various embodiments further can be implemented in a wide variety of operating environments, which in some cases can include one or more user computers, computing devices or processing devices which can be used to operate any of a number of applications. User or client devices can include any of a number of general purpose personal computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols. Such a system also can include a number of workstations running any of a variety of commercially available operating systems and other known applications for purposes such as development and database management. These devices also can include other electronic devices, such as dumb terminals, thin-clients, gaming systems and other devices capable of communicating via a network. These devices may be considered to be computing nodes, along with each virtual machine of one or more virtual machines that executes on such devices.

Most embodiments utilize at least one network that would be familiar to those skilled in the art for supporting communications using any of a variety of protocols, such as TCP/IP, OSI, FTP, UPnP, NFS, CIFS and AppleTalk. The network can be, for example, a local area network, a wide-area network, a virtual private network, the Internet, an intranet, an extranet, a public switched telephone network, an infrared network, a wireless network and any combination thereof.

In embodiments utilizing a Web server, the Web server can run any of a variety of server or mid-tier applications, including HTTP servers, FTP servers, CGI servers, data servers, JAVA servers and business application servers. The server(s) also may be capable of executing programs or scripts in response requests from user devices, such as by executing one or more Web applications that may be implemented as one or more scripts or programs written in any programming language, such as JAVA C, C# or C++ or any scripting language, such as Perl, Python or TCL as well as combinations thereof. The server(s) may also include database servers, including without limitation those commercially available from Oracle®, Microsoft®, Sybase® and IBM®.

The environment can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In a particular set of embodiments, the information may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers or other network devices may be stored locally and/or remotely, as appropriate. Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus, the elements including, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, controller, touch screen or keypad) and at least one output device (e.g., a display device, printer or speaker). Such a system may also include one or more storage devices, such as disk drives, optical storage devices and solid-state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash cards, etc.

Such devices also can include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device, etc.) and working memory as described above. The computer-readable storage media reader can be connected with, or configured to receive, a computer-readable storage medium, representing remote, local, fixed and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting and retrieving computer-readable information. The system and various devices also typically will include a number of software applications, modules, services or other elements located within at least one working memory device, including an operating system and application programs, such as a client application or Web browser. It should be appreciated that alternate embodiments may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets) or both. Further, connection to other computing devices such as network input/output devices may be employed.

Storage media and computer-readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer-readable instructions, data structures, program modules or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage devices or any other medium that can be used to store the desired information and that can be accessed by the a system device. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.

Other variations are within the spirit of the present disclosure. Thus, while the disclosed techniques are susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions and equivalents falling within the spirit and scope of the invention, as defined in the appended claims.

The use of the terms “a” and “an” and “the” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including” and “containing” are to be construed as open-ended terms (i.e., meaning “including, but not limited to,”) unless otherwise noted. The term “connected” is to be construed as partly or wholly contained within, attached to or joined together, even if there is something intervening. Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g., “such as”) provided herein, is intended merely to better illuminate embodiments of the invention and does not pose a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the invention.

Preferred embodiments of this disclosure are described herein, including the best mode known to the inventors for carrying out the invention. Variations of those preferred embodiments may become apparent to those of ordinary skill in the art upon reading the foregoing description. The inventors expect skilled artisans to employ such variations as appropriate, and the inventors intend for the invention to be practiced otherwise than as specifically described herein. Accordingly, this invention includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.

All references, including publications, patent applications and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

While the present disclosure has been made in connection with preferred embodiments, as illustrated in the various figures, it is understood that other similar aspects may be used or modifications and additions may be made to the described aspects for performing the same function of the present disclosure without deviating there from. Therefore, the present disclosure should not be limited to any single aspect, but rather construed in breadth and scope in accordance with the appended claims. For example, the various procedures described herein may be implemented with hardware or software, or a combination of both. Aspects of the disclosure may be implemented with computer-readable storage media, which do not include signals, and/or computer-readable communication media. Thus, the invention, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible, or non-transitory, media, such as floppy diskettes, CD-ROMs, hard drives or any other machine-readable storage medium. Likewise, certain aspects or portions of the disclosure may be embodied in propagated signals, or any other machine-readable communications medium. Where the program code is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus configured for practicing the disclosed embodiments. In addition to the specific implementations explicitly set forth herein, other aspects and implementations will be apparent to those skilled in the art from consideration of the specification disclosed herein. It is intended that the specification and illustrated implementations be considered as examples only, and not considered as encompassing all aspects of the disclosure.

Claims (14)

What is claimed is:

1. A non-transitory computer-readable storage medium bearing computer-executable instructions that, when executed upon a computer, cause the computer to perform operations comprising:

receiving an indication of an action to perform from a client computing device across a communications network, the action comprising launching a virtual machine instance by instantiating the virtual machine;

receiving an indication of a periodic time at which to perform the action;

beginning to perform a first occurrence of the action upon reaching a first time indicated by the periodic time;

beginning to perform a second occurrence of the action in accordance with one or more constraints expressed in a policy upon reaching a second time indicated by the periodic time;

receiving a price at which occurrences of the action may be performed; and

wherein beginning to perform the second occurrence of the action comprises beginning to perform the second occurrence of the action in response to determining that a current price is less than the price at which occurrences of the action may be performed.

2. The non-transitory computer-readable storage medium ofclaim 1, further bearing computer-executable instructions that, when executed upon a computer, cause the computer to perform operations comprising:

receiving a maximum price at which occurrences of the action may be performed; and

after beginning to perform the second occurrence of the action, and in response to determining that the current spot price is now above the maximum price, ending performing the second occurrence of the action.

3. The non-transitory computer-readable storage medium ofclaim 1, further bearing computer-executable instructions that, when executed upon a computer, cause the computer to perform operations comprising:

receiving an indication of a maximum frequency at which occurrences of the action may run; and

wherein beginning to perform the second occurrence of the action comprises beginning to perform the second occurrence of the action in response to determining that beginning to perform the second occurrence of the action would not exceed the maximum frequency at which occurrences of the action may be run.

4. The non-transitory computer-readable storage medium ofclaim 1, further bearing computer-executable instructions that, when executed upon a computer, cause the computer to perform operations comprising:

in response to reaching a third time indicated by the periodic time, and upon determining that the second occurrence of the action is still being performed, determining not to begin performing a third occurrence of the action at the third time.

5. The non-transitory computer-readable storage medium ofclaim 1, further bearing computer-executable instructions that, when executed upon a computer, cause the computer to perform operations comprising:

determining whether performing the first and second occurrences of the action succeeded or failed; and

selecting a first computer of a plurality of computers on which to perform a third occurrence of the action based on whether performing the first and second occurrences of the action succeeded or failed.

6. The non-transitory computer-readable storage medium ofclaim 1, wherein the indication of an action and the periodic time at which to perform the action are embedded in a hypertext transfer protocol (HTTP) or hypertext transfer protocol secure (HTTPS) uniform resource locator (URL).

7. The non-transitory computer-readable storage medium ofclaim 6, wherein the indication of the action and the periodic time comprise at least a part of a query string of the URL.

8. The non-transitory computer-readable storage medium ofclaim 1, wherein a constraint expressed in the policy relates to a maximum number of concurrent occurrences of the action and wherein beginning to perform the second occurrence of the action in accordance with the one or more constraints expressed in the policy further comprises:

determining whether a maximum number of concurrent occurrences of the action are still being performed.

9. A system, comprising:

a memory bearing instructions that, upon execution by a processor, cause the system to at least:

receive an indication of an action to perform from a client computing device across a communications network, the action comprising launching a virtual machine instance;

receive an indication of a periodic time at which to perform the action;

begin to perform a first occurrence of the action upon reaching a first time indicated by the periodic time;

begin to perform a second occurrence of the action upon reaching a second time indicated by the periodic time, and consulting a policy to determine whether to start the second occurrence of the action at the second time;

receive a price at which an occurrence of the action may be performed; and

begin to perform the second occurrence of the action in response to determining that a current price for processing resources is less than the price at which occurrences of the action may be performed.

10. The system ofclaim 9, wherein the memory further bears instructions that, upon execution by the processor, cause the system to at least:

receive an indication of a periodic time at which to end the action; and

end performing the second occurrence of the action upon reaching a time indicated by the periodic time at which to end the action.

11. The system ofclaim 9, wherein the memory further bears instructions that, upon execution by the processor, cause the system to at least:

in response to determining that the second occurrence of the action has run for a threshold amount of time, terminating and retrying the second occurrence of the action.

12. The system ofclaim 11, wherein the memory further bears instructions that, upon execution by the processor, cause the system to at least:

determining the threshold amount of time based how long it has taken to perform occurrences of the action in the past.

13. The system ofclaim 9, wherein the memory further bears instructions that, upon execution by the processor, cause the system to at least:

in response to determining that the second occurrence of the action has run for a threshold amount of time, and in response to determining that a maximum number of attempts to perform the second occurrence of the action has been reached, determining not to retry to perform the second occurrence of the action again.

14. The system ofclaim 9, wherein the instructions that, upon execution by the processor, cause the system to at least consult the policy to determine whether to start the second occurrence of the action at the second time comprises further cause the system to at least:

determine whether a maximum number of occurrences of the action are still operating, or determining whether the first occurrence of the action is still operating.

Images