Relocation of applications to optimize resource utilization

Concepts and technologies are disclosed herein for relocation of applications to optimize resource utilization. A processor executing a relocation management application can receive a request to relocate an application. The processor can identify a utilization associated with the application, identify prospective host resources capable of hosting the application, determine utilizations associated with the prospective host resources, and project prospective host resource utilizations based upon the utilization associated with the application and the utilizations associated with the prospective host resources. The processor can select a prospective host resource from the prospective host resources by selecting a resource that offers a most consistent projected utilization.

BACKGROUND

Virtualization of communications networks can be used to allow hardware and software to be decoupled from one another. Decoupling hardware and software can be used to give networks, network operators, network engineers, and/or other entities greater flexibility with regard to application placement, hardware placement, and the like. In particular, some network functions traditionally may have been tightly coupled to specific hardware. For example, routing functions may be tightly coupled to hardware such as a hardware router.

Modern trends in networking, however, may allow these functions and their corresponding hardware to be decoupled from one another. Thus, a generic server computer may host a virtual machine, and a function for a particular service or function can be loaded to and/or hosted by the server computer to provide the functionality associated with the previously-tightly-coupled-together hardware and software.

Because of the flexibility that may be granted by virtualization, network operators and/or planners may relocate applications, services, or other functionality from time to time for various purposes. For example, if demand for a service exceeds capabilities of hardware resources currently allocated to support the functionality, the service may be moved to other resources, the resources may be scaled, or the like. Scaling resources, relocating services, and/or instantiating new resources to support a service or other functionality can be expensive in terms of computing power, storage resources, bandwidth, or the like. Thus, network operators and/or other entities may attempt to carefully select hardware resources to host applications or other functionality before instantiating the resources to reduce costs associated with those resources and/or applications.

SUMMARY

The present disclosure is directed to relocation of applications to optimize resource utilization. A server computer can execute a relocation management application. The server computer can be configured, via execution of the relocation management application, to provide the functionality illustrated and described herein for relocating applications to optimize resources. In various embodiments, the server computer can receive a request to relocate an application. The request can be received at the server computer as a program or function call, as an explicit request, combinations thereof, or the like.

In response to receiving the request, the server computer can obtain utilization data. The utilization data can indicate a load and/or utilization (e.g., processor consumption, storage consumption, bandwidth consumption, and/or other needs) associated with the application. The load and/or utilization can be determined by obtaining information relating to the host resource, in some embodiments. The server computer can identify prospective host resources from any number of resources. The server computer can identify the prospective host resources as resources that are capable of hosting the application. The server computer can determine a utilization and/or load associated with the prospective host resources identified by the server computer.

The server computer can project utilization, load, or other performance metrics such as bandwidth, compute resources, storage resources, or the like for each of the prospective host resources identified by the server computer. The server computer can analyze the projected utilizations for each of the identified prospective host resources and select the prospective host resources that will host the application. In some embodiments, the server computer can select the prospective host resource that offers the most consistent projected utilization, though this is not necessarily the case. In some embodiments, the server computer can select the resource that offers the most consistent projected utilization because this prospective host resource may be the easiest or cheapest to operate and may reduce or eliminate expensive scaling or instantiation of resources, which may be expensive.

According to one aspect of the concepts and technologies disclosed herein, a method is disclosed. The method can include receiving, at a processor executing a relocation management application, a request to relocate an application. The method also can include identifying, by the processor, a utilization associated with the application, identifying, by the processor, prospective host resources capable of hosting the application, determining, by the processor, utilizations associated with the prospective host resources, projecting, by the processor, prospective host resource utilizations based upon the utilization associated with the application and the utilizations associated with the prospective host resources, and selecting, by the processor, a prospective host resource from the prospective host resources. The prospective host resource can be selected as a resource that offers a most consistent projected utilization.

In some embodiments, the application can be executed by a host resource, and the utilization can include a utilization of the host resource. In some embodiments, the request can be received as a service call by the relocation management application. In some embodiments, the utilization associated with the application can be identified by analyzing utilization data obtained from a resource monitor. In some embodiments, average projected utilizations can be determined for the prospective host resources, and total deviations from the average projected utilizations can be calculated to identify the resource that offers the most consistent projected utilization.

In some embodiments, the method also can include issuing commands to relocate the application to the resource. The commands can include a first command that can be issued to a host resource that executes the application, and a second command that can be issued to the prospective host resource selected. The commands can initiate relocation of the application from the host resource to the resource. In some embodiments, the first command can cause the host resource to store state information associated with the application, and the second command can cause the resource to use the state information to resume execution of the application. In some embodiments, the method also can include storing, at a data store, utilization data relating to the utilization.

According to another aspect of the concepts and technologies described herein, a system is disclosed. The system can include a processor and a memory. The memory can store computer-executable instructions that, when executed by the processor, cause the processor to perform operations. The operations can include receiving a request to relocate an application, identifying a utilization associated with the application, identifying prospective host resources capable of hosting the application, determining utilizations associated with the prospective host resources, projecting prospective host resource utilizations based upon the utilization associated with the application and the utilizations associated with the prospective host resources, and selecting a prospective host resource from the prospective host resources, wherein the prospective host resource is selected as a resource that offers a most consistent projected utilization.

In some embodiments, the application can be executed by a host resource, and the utilization can include a utilization of the host resource. In some embodiments, average projected utilizations can be determined for the prospective host resources, and total deviations from the average projected utilizations can be calculated to identify the resource that offers the most consistent projected utilization. In some embodiments, the computer-executable instructions, when executed by the processor, can cause the processor to perform operations further including issuing commands to relocate the application to the resource.

In some embodiments, the commands can include a first command that can be issued to a host resource that executes the application, and a second command that can be issued to the prospective host resource selected. The commands can initiate relocation of the application from the host resource to the resource. In some embodiments, the first command can cause the host resource to store state information associated with the application, and the second command can cause the resource to use the state information to resume execution of the application.

According to another aspect of the concepts and technologies disclosed herein, a computer storage medium is disclosed. The computer storage medium can have computer-executable instructions stored thereon that, when executed by a processor, cause the processor to perform operations. The operations can include receiving a request to relocate an application, identifying a utilization associated with the application, identifying prospective host resources capable of hosting the application, determining utilizations associated with the prospective host resources, projecting prospective host resource utilizations based upon the utilization associated with the application and the utilizations associated with the prospective host resources, and selecting a prospective host resource from the prospective host resources, wherein the prospective host resource can be selected as a resource that offers a most consistent projected utilization.

In some embodiments, the application can be executed by a host resource, and the utilization can include a utilization of the host resource. In some embodiments, average projected utilizations can be determined for the prospective host resources, and total deviations from the average projected utilizations can be calculated to identify the resource that offers the most consistent projected utilization. In some embodiments, the computer-executable instructions, when executed by the processor, can cause the processor to perform operations further including issuing commands to relocate the application to the resource. In some embodiments, the commands can include a first command that can be issued to a host resource that executes the application, and a second command that can be issued to the prospective host resource selected. The commands can initiate relocation of the application from the host resource to the resource.

DETAILED DESCRIPTION

The following detailed description is directed to relocation of applications to optimize resource utilization. In practice, a server computer can execute a relocation management application. The server computer can be configured, via execution of the relocation management application, to provide the functionality illustrated and described herein for relocating applications to optimize resources. In various embodiments, the server computer can receive a request to relocate an application. The request can be received at the server computer as program or function call, as explicit requests, combinations thereof, or the like. In response to receiving the request, the server computer can obtain utilization data. The utilization data can indicate a load and/or utilization (e.g., processor consumption, storage consumption, bandwidth consumption, and/or other needs) associated with the application. The load and/or utilization can be determined by obtaining information relating to the host resource, in some embodiments.

The server computer can identify prospective host resources from any number of resources. The server computer can identify the prospective host resources as resources that are capable of hosting the application. The server computer can determine a utilization and/or load associated with the prospective host resources identified by the server computer. The server computer can project utilization, load, or other performance metrics such as bandwidth, compute resources, storage resources, or the like for each of the prospective host resources identified by the server computer. The server computer can analyze the projected utilizations for each of the identified prospective host resources and select the prospective host resources that will host the application. The server computer can select the prospective host resource that offers the most consistent projected utilization, though this is not necessarily the case, as this prospective host resource may be the easiest or cheapest to operate (as scaling resources can be expensive).

Referring now toFIG. 1, aspects of an operating environment100for various embodiments of the concepts and technologies disclosed herein for relocation of applications to optimize resource utilization will be described, according to an illustrative embodiment. The operating environment100shown inFIG. 1includes a server computer102. The server computer102can operate in communication with and/or as part of a communications network (“network”)104.

According to various embodiments, the functionality of the server computer102may be provided by one or more server computers, desktop computers, mobile telephones, laptop computers, set-top boxes, other computing systems, and the like. It should be understood that the functionality of the server computer102can be provided by a single device, by two similar devices, and/or by two or more dissimilar devices. For purposes of describing the concepts and technologies disclosed herein, the server computer102is described herein as a server computer. It should be understood that this embodiment is illustrative, and should not be construed as being limiting in any way.

The server computer102can execute an operating system (not shown inFIG. 1) and one or more application programs such as, for example, a relocation management application106. The operating system can include a computer program for controlling the operation of the server computer102. The relocation management application106can include an executable program configured to execute on top of the operating system to provide various functionality illustrated and described herein for relocating applications to optimize resource utilization.

In particular, the relocation management application106can be configured to relocate an application108from a host resource110to one of multiple prospective host resources112A-112N (hereinafter collectively and/or generically referred to as “prospective host resources112”). In particular, the relocation management application106can be configured to detect a request to relocate the application108. The request to relocate the application108can be received at the relocation management application106as an explicit command and/or implicitly by the relocation management application106detecting a request to analyze an application108and/or one or more prospective host resources112or the like.

In particular, the relocation management application106can detect a request to relocate the application108, and obtain utilization data114. The utilization data114can be created by a resource monitor116or other network device, which can monitor and/or analyze activity associated with one or more of the host resource110, the prospective host resources112, and/or the application108. Additionally, or alternatively, the utilization data114can be generated by the host resource110and provided to the server computer102. Because other entities can generate the utilization data114, it should be understood that these examples are illustrative and therefore should not be construed as being limiting in any way. According to various embodiments, the utilization data114can include load and/or utilization information, which can be analyzed by the relocation management application106to identify usage and/or consumption associated with the application108and/or one or more resources that host (or can host) the application108.

According to various embodiments, the resource monitor116can monitor utilization and/or load associated with the host resource110and/or the prospective host resources112. It can be appreciated that by monitoring the host resource110, the resource monitor116can determine a load or utilization associated with a resource that hosts the application108. While the host resource110may host other applications or modules, the load and/or utilization associated with the application108can be determined and/or reported by the host resource110and/or the resource monitor116.

When generating the utilization data114, the resource monitor116and/or the host resource110can determine a load and/or utilization at various time increments. Thus, for example, a load and/or utilization can be determined at intervals of one or more milliseconds, one or more seconds, one or more minutes, one or more hours, one or more days, or the like. It can be appreciated that various time intervals may be chosen and/or used based upon fluctuation of load and/or utilization associated with application108. Similarly, a utilization or load associated with the prospective host resources112can be determined and/or reported at various increments such as milliseconds, seconds, minutes, hours, days, or the like.

The server computer102can analyze the utilization data114associated with the application108and/or the prospective host resources112to identify one of the prospective host resources112that should host the application108when the application108is relocated. The prospective host resource112that should host the application108can be identified in various manners. In some embodiments, the prospective host resource112that should host the application108can be determined by determining which of the prospective host resources112would, when hosting the application108, provide the most consistent utilization and/or load. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

It can be appreciated that selecting the prospective host resource112with the most consistent projected load and/or utilization may offer benefits over some other approaches for selecting the prospective host resource112. In particular, it should be understood that some relocation technologies may rely upon identifying a host with the lowest utilization and/or load. The concepts and technologies described herein, however, can identify a prospective host resource112based upon a projected combined load or utilization and/or the associated consistency thereof. In particular, a projected combined load of a prospective host resource112and the application108can be determined for multiple prospective host resources112. The projected combined load for two or more prospective host resources112(hosting the application108) can be compared to identify the prospective host resource112with a most consistent projected combined load (compared to the other prospective host resources112).

Thus, while the prospective host resource112that is identified as the ideal host may have a total load that is higher than another prospective host resource112, the consistency of load and/or utilization associated with the identified ideal prospective host resource112will be, according to various embodiments of the concepts and technologies described herein, more consistent than projected loads and/or utilizations associated with other prospective host resources112. These and other aspects of the concepts and technologies described herein for selecting an ideal prospective host resource112will be more clearly understood with reference toFIGS. 2-4Bbelow.

According to various embodiments, the server computer102can identify the prospective host resource112that should host the application108based upon analysis of the utilization data114. In some embodiments, the server computer102can store the utilization data114at a data storage device such as, for example, a data store118. According to various embodiments, the functionality of the data store118can be provided by one or more databases, server computers, desktop computers, mobile telephones, laptop computers, other computing systems, network devices, and the like. In the illustrated embodiment, the functionality of the data store118is provided by a server computer that can host and/or store the utilization data114. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

The server computer102can analyze one or more instances of utilization data114for the application108, the host resource110, and/or the prospective host resources112to identify the prospective host resource112that should host the application108. The server computer102also can generate one or more commands120A-120B (hereinafter collectively and/or generically referred to as “commands120”). The server computer102can issue the commands120to the host resource110and the prospective host resource112that is identified as the prospective host resource112that should host the application108. The commands120can include instructions for relocating the application108from the host resource110to the prospective host resource112. As shown in the illustrated embodiment ofFIG. 1, the commands120can be issued to the host resource110and the prospective host resource112A to effect or initiate relocation of the application108from the host resource110to the prospective host resource112A. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

In practice, the server computer102can receive a request to relocate an application such as the application108. The request can be received at the server computer102via a function, program, or service call, or an explicit request from one or more of an application, a network device, a network operator, a network engineer, a network planning device, or other entity. In response to receiving the request, the server computer102can determine a host for the relocated application108.

In determining the host for the relocated application108, the server computer102can obtain utilization data114. The utilization data114can indicate a load and/or utilization (e.g., processor consumption, storage consumption, bandwidth consumption, and/or other needs) associated with the application108. The load and/or utilization associated with the application108can be determined by the server computer102by obtaining information relating to the host resource110, in some embodiments.

The server computer102also can identify prospective host resources112. The prospective host resources112can be identified by locating available host resources in a particular geographic area or region, in a particular section or portion of the network104, by identifying hosts with available resources, or the like. Thus, the server computer102may identify, from any number of resources, prospective host resources112that are capable of hosting the application108in terms of compute capabilities, storage capabilities, bandwidth and/or data transfer capabilities, combinations thereof, or the like.

The server computer102can determine a utilization and/or load associated with the prospective host resources112identified by the server computer102. The server computer102can obtain utilization data114associated with the prospective host resources112, for example, or query the prospective host resources112, which may respond in some embodiments with the utilization data114or other information that may indicate loads, utilizations, capabilities, or the like. Thus, the server computer102can determine a utilization and/or availability associated with each of the identified prospective host resources112. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

The server computer102can project utilization, load, or other performance metrics such as bandwidth, compute resources, storage resources, or the like for each of the prospective host resources112identified by the server computer102. In projecting the utilization for the prospective host resources112, the server computer102can be configured to model the known utilization associated with the application108, which may be determined by analyzing the utilization data114, for example, on top of the known utilization associated with the prospective host resources112. Thus, for example, if a utilization of one of the prospective host resources112at 12:00 AM on a particular date is a value of x1and a utilization associated with the application108at 12:00 AM on the same date is a value of x2, the server computer102can calculate the projected utilization at 12:00 AM for that date as being x1+x2. Because projected utilizations can be determined in additional and/or alternative manners, it should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

The server computer102can analyze the projected utilizations for each of the identified prospective host resource112and select the prospective host resource112that will host the application108as the prospective host resource112of the prospective host resources112that offers the most consistent projected utilization. It can be appreciated that various embodiments of analyzing the projected utilizations are possible and are contemplated. In some embodiments, the server computer102can calculate an average utilization for the prospective host resource112, and then calculate a total deviation from the average utilization. After repeating this analysis for each of the identified prospective host resources112, the server computer102can select the prospective host resource112that has the smallest total deviation from the average, which can indicate a least amount of fluctuation from the average (and therefore a most consistent utilization). Because the prospective host resource112can be selected in additional and/or other ways, it should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

After determining the prospective host resource112that should host the application108, the server computer102can issue one or more commands120to move the application108to the identified prospective host resource112. In particular, the server computer102can issue one or more commands120to the host resource110to cease execution of the application108and/or to release resources used to support the application108. The commands120also can include commands120to the prospective host resource112to allocate resources for the application108and/or to begin execution of the application108when the application108is loaded to the resources.

Although not illustrated inFIG. 1, it should be understood that the host resource110can store state information before relocating the application108, and can provide the state information to the prospective host resource112selected to host the relocated application108. The host resource110can provide the state information to the prospective host resource112, and the prospective host resource112can load the state information to the prospective host resource112before or upon executing the application108. Thus, the relocated application108can operate in a manner that can be substantially identical to the operation of the application108prior to relocation. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

FIG. 1illustrates one server computer102, one network104, one host resource110, two prospective host resources112, one resource monitor116, and one data store118. It should be understood, however, that various implementations of the operating environment100can include zero, one, or more than one server computer102; zero, one, or more than one network104; zero, one, or more than one host resource110; zero, one, two, or more than two prospective host resources112; zero, one, or more than one resource monitor116; and/or zero, one, or more than one data store118. As such, the illustrated embodiment should be understood as being illustrative, and should not be construed as being limiting in any way.

Thus, it should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These states, operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof. As used herein, the phrase “cause a processor to perform operations” and variants thereof is used to refer to causing a processor of a computing system or device, such as the server computer102to perform one or more operations and/or causing the processor to direct other components of the computing system or device to perform one or more of the operations.

For purposes of illustrating and describing the concepts of the present disclosure, the methods disclosed herein are described as being performed by the server computer102via execution of one or more software modules such as, for example, the relocation management application106. It should be understood that additional and/or alternative devices and/or network nodes can provide the functionality described herein via execution of one or more modules, applications, and/or other software including, but not limited to, the relocation management application106. Thus, the illustrated embodiments are illustrative, and should not be viewed as being limiting in any way.

The method200begins at operation202. At operation202, the server computer102can receive a request to relocate an application such as the application108. The request to relocate the application108can be received from various sources and/or entities. In some embodiments, for example, the server computer102can receive a request from an entity such as a network operator or network engineer to relocate the application108from a first resource (e.g., the host resource110) to a second resource (e.g., one of the prospective host resources112). In some other embodiments, the server computer102can receive an instruction to provide the functionality illustrated and described herein in response to detecting a relocation process associated with the application108.

In some other embodiments, the server computer102can receive the request as a function or service call. Thus, though not shown inFIG. 1, it should be understood that that the server computer102can be configured (via execution of the relocation management application106) to expose an application programming interface (“API”) to make the relocation management application106function as a callable service. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

From operation202, the method200proceeds to operation204. At operation204, the server computer102can determine a host for the relocated application108. Thus, in operation204, the server computer102can identify a particular host that will execute the relocated application108. The server computer102can identify the host from any number of hosts. Various details regarding the functionality of the server computer102for determining the host for the application108are illustrated and described in more detail below with reference toFIG. 3.

From operation204, the method200proceeds to operation206. At operation206, the server computer102can initiate relocation of the application108. According to various embodiments, the server computer102can issue one or more commands120to relocate the application108. Thus, the server computer102can issue one or more commands120to the host resource110to cease execution of the application108and/or to release resources associated with the application108. The server computer102also can issue one or more commands120to the identified resource such as one of the prospective host resources112to allocate resources and/or to begin execution of the application108.

It can be appreciated that the commands120also can include commands for capturing state data, storing state data, and/or transmitting the state data from a host resource110to the prospective host resource112identified or determined in operation204. Additionally, the commands120can include commands120for using the state data to resume execution of the relocated application108at the determined host, combinations thereof, or the like. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

From operation206, the method200proceeds to operation208. The method200ends at operation208.

Turning now toFIG. 3, aspects of a method300for determining a host for a relocated application108will be described in detail, according to an illustrative embodiment. It can be appreciated with reference toFIG. 2that the operations illustrated and described herein with reference toFIG. 3can be performed by the server computer102in conjunction with execution of operation204inFIG. 2. Because this is not necessarily the case, it should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

The method300begins at operation302. At operation302, the server computer102can determine a load or utilization associated with the application108. As explained above, the load or utilization can include various performance metrics associated with the application108such as computing resource demands, storage resource demands, bandwidth demands, combinations thereof, or the like. The utilization associated with the application108can be determined based upon utilization data114, for example. The utilization also can be determined by accessing a resource monitor116and receiving a response from the resource monitor116, by querying a host resource such as the host resource110and receiving utilization information in response, by accessing utilization data114stored in the data store118, combinations thereof, or the like. It can be appreciated that the host resource110that is queried by the server computer102can correspond to a host for the application108. Because the server computer102can determine the utilization of the application108in additional and/or alternative manners, for example by querying or receiving data from other entities, it should be understood that these examples are illustrative and therefore should not be construed as being limiting in any way.

From operation302, the method300proceeds to operation304. At operation304, the server computer102can identify one or more prospective host resources such as the prospective host resources112shown inFIG. 1. The prospective host resources112can be identified as host resources that have the ability and/or capacity to host and/or execute the application108. Thus, for example, the prospective host resources112can be identified from a group of host resources based upon a determination that a throughput, bandwidth, processor requirements, memory requirements, and/or the like associated with the prospective host resources112are sufficient to host and/or execute the application108. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

The prospective host resources112also can be determined based upon geographic locations of the prospective host resources112, ownership of the prospective host resources112, or the like. Thus, the server computer102can identify the prospective host resources112by searching a geographic location for resources, or the like, by receiving identifications of the prospective host resources112, by querying a list of available host resources, combinations thereof, or the like. Because the prospective host resources112can be identified in additional and/or alternative manners, it should be understood that these examples are illustrative and therefore should not be construed as being limiting in any way.

From operation304, the method300proceeds to operation306. At operation306, the server computer102can determine a utilization associated with each of the prospective host resources112identified in operation304. Thus, operation306can correspond to the server computer102determining utilization availability associated with each of the prospective host resources112. To provide the functionality illustrated with respect to operation306, the server computer102can analyze utilization data114and/or other information that can reflect how much of various resources associated with the prospective host resources112is used and/or available.

Although not illustrated inFIG. 3, it should be understood that the server computer102can determine, after calculating a utilization for a prospective host resource112, if another prospective host resource112exists. If the server computer102determines that another prospective host resource112exists, the server computer102can determine a utilization for the next prospective host resource112. As such, it can be appreciated that the server computer102can repeat operation306of the method300until a utilization has been determined for each identified prospective host resource112. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

From operation306, the method300proceeds to operation308. At operation308, the server computer102can project, for each of the identified the prospective host resources112, a utilization that would result from relocation of the application108to that prospective host resource112. As such, operation308can correspond to the server computer102projecting how relocation of the application108to a particular prospective host resource112could or will affect utilization of that prospective host resource112. As noted above, some embodiments of the concepts and technologies described herein can combine a utilization associated with the application108with a utilization associated with the prospective host resources112. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

Although not illustrated inFIG. 3, it should be understood that the server computer102can determine, after calculating a projected utilization for a first prospective host resource112, if another prospective host resource112exists. If the server computer102determines that another prospective host resource112exists, the server computer102can determine a projected utilization for the next prospective host resource112. As such, it can be appreciated that the server computer102can repeat operation308of the method300until a projected utilization has been determined for each identified prospective host resource112. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

From operation308, the method300proceeds to operation310. At operation310, the server computer102can select the prospective host resource112that offers the most consistent predicted utilization. In some embodiments, the server computer102can calculate an average or mean utilization for the prospective host resource112based upon the projected utilization, and determine a deviation over time from the mean or average. The server computer102can be configured to identify a prospective host resource112that has a highest deviation from the mean or average as being the least favorable resource to host the relocated application108.

Similarly, the server computer102can be configured to identify a prospective host resource112that has a lowest deviation from the mean or average as being the most favorable resource to host the relocated application108. Because the most consistent projected utilization can be determined in additional and/or alternative manners, it should be understood that this example is illustrative and therefore should not be construed as being limiting in any way. The server computer102can be configured to consider all of the identified prospective host resources112and select the ideal host from that set of resources.

From operation310, the method300proceeds to operation312. The method300ends at operation312.

Turning now toFIGS. 4A-4B, additional aspects of the concepts and technologies described herein for relocation of applications108to optimize resource utilization will be illustrated and described in detail. In particular,FIGS. 4A-4Billustrate example graphs400A,400B for showing utilization U over time t. It should be understood that the example graphs400A,400B are illustrative and are provided to illustrate and describe additional aspects of the concepts and technologies described herein. As such, the example graphs400A,400B should be understood as being examples and should not be construed as being limiting in any way.

Referring first toFIG. 4A, the example graph400A illustrates two server utilization lines402A,402B, and an application utilization line404. The server utilization line402A can correspond to server utilization or load over time for a first server, for example “server A,” and can be determined and/or can reflect utilization data114as illustrated and described above. Thus, the server utilization line402A is labeled as Utils-a. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

Similarly, the server utilization line402B can correspond to server utilization or load over time for a second server, for example “server B,” and can be determined and/or can reflect utilization data114as illustrated and described above. Thus, the server utilization line402B is labeled as Utils-b. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

The application utilization line404can correspond to a utilization or load over time for a generic server that is hosting and/or executing an application108. It can be appreciated that the application108for which utilization is depicted can correspond to an application108that is being considered for relocation as illustrated and described herein, though this is not necessarily the case. At any rate, the application utilization line404can be determined and/or can reflect utilization data114as illustrated and described above. Thus, the application utilization line404is labeled as Utilapp. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

It can be appreciated with reference toFIG. 4Athat the utilization of the application108can vary over time. Similarly, in the illustrated example, the server utilization Utils-aassociated with the server called “server A” can vary over time. The server utilization Utils-bassociated with the server called “server B” also can vary over time, but seemingly with less fluctuation than the server utilization associated with the server called “server A.” Of course, this example is illustrative and should not be construed as being limiting in any way.

It can also be appreciated with reference toFIG. 4Athat an actual utilization Utils-aof the server called “server A” may be higher at some points in time than the actual utilization Utils-bof the server called “server B.” This, too, is illustrative and should not be construed as being limiting in any way. At any rate, the concepts and technologies described herein can be used to relocate applications108based upon an average utilization and/or to reduce fluctuation of a combined utilization of the applications108and prospective hosts, and therefore spikes in actual utilization may or may not be of importance when determining how to relocate applications108. These and other aspects of the concepts and technologies described herein will be more clearly understood with reference toFIG. 4B.

Referring now toFIG. 4B, two projected utilization lines406A,406B are illustrated. The projected utilization line406A can correspond to server utilization or load over time for a server, for example “server A,” if the application108is relocated to that server. Of course, a resource being considered to host and/or execute a relocated application108may or may not be a server, so this example should not be construed as being limiting in any way. The projected utilization illustrated by the projected utilization line406A can be based upon combining the server utilization line402A and the application utilization line404along each point represented by data used to generate those lines. Thus, the projected utilization line406A is labeled as Utilproj-a. Because the projected utilization line406A and/or the underlying data can be determined in additional and/or alternative manners, it should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

Similarly, the projected utilization line406B can correspond to server utilization or load over time for a server, for example “server B,” if the application108is relocated to that server. The projected utilization illustrated by the projected utilization line406B can be based upon combining the server utilization line402B and the application utilization line404along each point represented by data used to generate those lines. Thus, the projected utilization line406B is labeled as Utilproj-b. Because the projected utilization line406B and/or the underlying data can be determined in additional and/or alternative manners, it should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

As can be appreciated with reference to the graph400B shown inFIG. 4B, the projected utilization line406A has less fluctuation than the projected utilization line406B. This is evident from the relative consistency (in terms of utilization) of the projected utilization line406A. Meanwhile, the projected utilization line406B fluctuates up and down (in terms of utilization) to a greater degree than the projected utilization line406A. Thus, of these two options, namely relocating the application108to the server called server A or the server called server B, the best option would be using the server called server A as this server provides a more consistent load than the server called server B. In particular, if an average value for the utilization depicted by the projected utilization line406B is determined, the deviation of the projected utilization line406B from that average may be greater than a deviation from the projected utilization line406A from the average projected utilization. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way.

Thus, while it may seem counterintuitive that the server called server A is a better option for relocation of the application108than the server called server B, because of the fact that the actual utilization of server A spikes higher than the actual utilization of server B at some times, the concepts and technologies described herein can suggest the use of the server called server A instead of the server called server B.

As explained above, the server called server A can be chosen because that server may give a more consistent utilization over time with less fluctuation than server B. According to various embodiments of the concepts and technologies described herein, network planning may be more difficult when loads and/or utilizations fluctuate than when overall loads or utilizations are high because of the need for elastic load requirements, scaling, and the like. Scaling can cost more in terms of computing power, bandwidth, and/or storage resources than merely instantiating a server or other resource with a particular capacity (high or low). Thus, embodiments of the concepts and technologies described herein can be configured to exercise a preference for consistency in load and/or utilization over an overall or average load or consistency. It should be understood that this example is illustrative and therefore should not be construed as being limiting in any way

Turning now toFIG. 5, additional details of the network104are illustrated, according to an illustrative embodiment. The network104includes a cellular network502, a packet data network504, for example, the Internet, and a circuit switched network506, for example, a publicly switched telephone network (“PSTN”). The cellular network502includes various components such as, but not limited to, base transceiver stations (“BTSs”), Node-B's or e-Node-B's, base station controllers (“BSCs”), radio network controllers (“RNCs”), mobile switching centers (“MSCs”), mobile management entities (“MMEs”), short message service centers (“SMSCs”), multimedia messaging service centers (“MMSCs”), home location registers (“HLRs”), home subscriber servers (“HSSs”), visitor location registers (“VLRs”), charging platforms, billing platforms, voicemail platforms, GPRS core network components, location service nodes, an IP Multimedia Subsystem (“IMS”), and the like. The cellular network502also includes radios and nodes for receiving and transmitting voice, data, and combinations thereof to and from radio transceivers, networks, the packet data network504, and the circuit switched network506.

A mobile communications device508, such as, for example, a cellular telephone, a user equipment, a mobile terminal, a PDA, a laptop computer, a handheld computer, and combinations thereof, can be operatively connected to the cellular network502. The cellular network502can be configured as a 2G GSM network and can provide data communications via GPRS and/or EDGE. Additionally, or alternatively, the cellular network502can be configured as a 3G UMTS network and can provide data communications via the HSPA protocol family, for example, HSDPA, EUL (also referred to as HSUPA), and HSPA+. The cellular network502also is compatible with 4G mobile communications standards as well as evolved and future mobile standards.

The packet data network504includes various devices, for example, servers, computers, databases, and other devices in communication with one another, as is generally known. The packet data network504devices are accessible via one or more network links. The servers often store various files that are provided to a requesting device such as, for example, a computer, a terminal, a smartphone, or the like. Typically, the requesting device includes software (a “browser”) for executing a web page in a format readable by the browser or other software. Other files and/or data may be accessible via “links” in the retrieved files, as is generally known. In some embodiments, the packet data network504includes or is in communication with the Internet. The circuit switched network506includes various hardware and software for providing circuit switched communications. The circuit switched network506may include, or may be, what is often referred to as a plain old telephone system (POTS). The functionality of a circuit switched network506or other circuit-switched network are generally known and will not be described herein in detail.

The illustrated cellular network502is shown in communication with the packet data network504and a circuit switched network506, though it should be appreciated that this is not necessarily the case. One or more Internet-capable devices510, for example, a PC, a laptop, a portable device, or another suitable device, can communicate with one or more cellular networks502, and devices connected thereto, through the packet data network504. It also should be appreciated that the Internet-capable device510can communicate with the packet data network504through the circuit switched network506, the cellular network502, and/or via other networks (not illustrated).

As illustrated, a communications device512, for example, a telephone, facsimile machine, modem, computer, or the like, can be in communication with the circuit switched network506, and therethrough to the packet data network504and/or the cellular network502. It should be appreciated that the communications device512can be an Internet-capable device, and can be substantially similar to the Internet-capable device510. In the specification, the network104is used to refer broadly to any combination of the networks502,504,506. It should be appreciated that substantially all of the functionality described with reference to the network104can be performed by the cellular network502, the packet data network504, and/or the circuit switched network506, alone or in combination with other networks, network elements, and the like.

FIG. 6is a block diagram illustrating a computer system600configured to provide the functionality described herein for relocation of applications to optimize resource utilization, in accordance with various embodiments of the concepts and technologies disclosed herein. The computer system600includes a processing unit602, a memory604, one or more user interface devices606, one or more input/output (“I/O”) devices608, and one or more network devices610, each of which is operatively connected to a system bus612. The bus612enables bi-directional communication between the processing unit602, the memory604, the user interface devices606, the I/O devices608, and the network devices610.

The processing unit602may be a standard central processor that performs arithmetic and logical operations, a more specific purpose programmable logic controller (“PLC”), a programmable gate array, or other type of processor known to those skilled in the art and suitable for controlling the operation of the server computer. As used herein, the word “processor” and/or the phrase “processing unit” when used with regard to any architecture or system can include multiple processors or processing units distributed across and/or operating in parallel in a single machine or in multiple machines. Furthermore, processors and/or processing units can be used to support virtual processing environments. Processors and processing units also can include state machines, application-specific integrated circuits (“ASICs”), combinations thereof, or the like. Because processors and/or processing units are generally known, the processors and processing units disclosed herein will not be described in further detail herein.

The memory604communicates with the processing unit602via the system bus612. In some embodiments, the memory604is operatively connected to a memory controller (not shown) that enables communication with the processing unit602via the system bus612. The memory604includes an operating system614and one or more program modules616. The operating system614can include, but is not limited to, members of the WINDOWS, WINDOWS CE, and/or WINDOWS MOBILE families of operating systems from MICROSOFT CORPORATION, the LINUX family of operating systems, the SYMBIAN family of operating systems from SYMBIAN LIMITED, the BREW family of operating systems from QUALCOMM CORPORATION, the MAC OS, iOS, and/or LEOPARD families of operating systems from APPLE CORPORATION, the FREEBSD family of operating systems, the SOLARIS family of operating systems from ORACLE CORPORATION, other operating systems, and the like.

The program modules616may include various software and/or program modules described herein. In some embodiments, for example, the program modules616include the relocation management application106. This and/or other programs can be embodied in computer-readable media containing instructions that, when executed by the processing unit602, perform one or more of the methods200,300described in detail above with respect toFIGS. 2-3. According to embodiments, the program modules616may be embodied in hardware, software, firmware, or any combination thereof. Although not shown inFIG. 6, it should be understood that the memory604also can be configured to store the application108, the utilization data114, the commands120, and/or other data, if desired.

The user interface devices606may include one or more devices with which a user accesses the computer system600. The user interface devices606may include, but are not limited to, computers, servers, personal digital assistants, cellular phones, or any suitable computing devices. The I/O devices608enable a user to interface with the program modules616. In one embodiment, the I/O devices608are operatively connected to an I/O controller (not shown) that enables communication with the processing unit602via the system bus612. The I/O devices608may include one or more input devices, such as, but not limited to, a keyboard, a mouse, or an electronic stylus. Further, the I/O devices608may include one or more output devices, such as, but not limited to, a display screen or a printer.

The network devices610enable the computer system600to communicate with other networks or remote systems via a network, such as the network104. Examples of the network devices610include, but are not limited to, a modem, a radio frequency (“RF”) or infrared (“IR”) transceiver, a telephonic interface, a bridge, a router, or a network card. The network104may include a wireless network such as, but not limited to, a Wireless Local Area Network (“WLAN”) such as a WI-FI network, a Wireless Wide Area Network (“WWAN”), a Wireless Personal Area Network (“WPAN”) such as BLUETOOTH, a Wireless Metropolitan Area Network (“WMAN”) such a WiMAX network, or a cellular network. Alternatively, the network104may be a wired network such as, but not limited to, a Wide Area Network (“WAN”) such as the Internet, a Local Area Network (“LAN”) such as the Ethernet, a wired Personal Area Network (“PAN”), or a wired Metropolitan Area Network (“MAN”).