Incarnation Selection for Application Hosting in Remote Service Environments

Abstract

One embodiment provides a computer-implemented method that includes receiving an application including a plurality of services to be hosted in a remote service environment; obtaining a resource profile that identifies resource usage by a given service of the plurality of services over a period of time; dividing the given service into a plurality of service slices based on the resource profile corresponding to the given service; selecting, for each of the plurality of service slices, an incarnation that meets resource demand requirements and service performance offerings, the incarnation having an aggregate demand value based on resource capacity of nodes in the remote service environment; and assigning, for each of the plurality of service slices, the selected incarnation to at least one node in the remote service environment based on the resource capacity of the at least one node.

Description

[Background technology]

[0001] With the proliferation of remote computing or service environments, such as remote network environments and cloud computing environments, more users and entities are moving the hosting of their applications and other services to remote service environments. By moving the hosting of their applications and other services to remote service environments, users and other entities can reduce the use of internal resources (e.g., infrastructure, computing resources, human resources, etc.) and reduce other costs associated with their applications and other services. In addition, because remote service environments typically have significantly more resources, particularly computing resources, than users or entities have locally, users or entities can scale applications hosted in remote service environments. Summary of the Invention

[0002] In summary, one aspect of the present invention provides a computer-implemented method that includes receiving an application including a plurality of services to be hosted in a remote service environment; obtaining a resource profile that identifies resource usage by a given service of the plurality of services over a period of time; dividing the given service into a plurality of service slices based on the resource profile corresponding to the given service; selecting, for each of the plurality of service slices, an incarnation that meets resource demand requirements and service performance offerings, the incarnation having an aggregate demand value based on resource capacity of nodes in the remote service environment; and assigning, for each of the plurality of service slices, the selected incarnation to at least one node in the remote service environment based on the resource capacity of the at least one node.

[0003] Another aspect of the present invention provides an apparatus including at least one processor and a computer-readable storage medium having computer-readable program code embodied and executable by the at least one processor, the computer-readable program code configured to receive an application including a plurality of services to be hosted in a remote service environment, the computer-readable program code configured to obtain a resource profile identifying resource usage by a given service of the plurality of services over a period of time, the computer-readable program code configured to partition the given service into a plurality of service slices based on the resource profile corresponding to the given service, the computer-readable program code configured to select, for each of the plurality of service slices, an incarnation that meets resource demand requirements and service performance offerings, the incarnation having an aggregate demand value based on resource capacity of nodes in the remote service environment, and the computer-readable program code configured to assign, for each of the plurality of service slices, the selected incarnation to at least one node in the remote service environment based on the resource capacity of the at least one node.

[0004] A further aspect of the present invention provides a computer program product including a computer-readable storage medium having computer-readable program code embodied thereon, the computer-readable program code being executable by a processor, the computer-readable program code being configured to receive an application including a plurality of services to be hosted in a remote service environment, the computer-readable program code being configured to obtain a resource profile identifying resource usage by a given service of the plurality of services over a period of time, the computer-readable program code being configured to partition the given service into a plurality of service slices based on the resource profile corresponding to the given service, the computer-readable program code being configured to select, for each of the plurality of service slices, an incarnation that meets resource demand requirements and service performance offerings, the incarnation having an aggregate demand value based on resource capacity of nodes of the remote service environment, and the computer-readable program code being configured to assign, for each of the plurality of service slices, the selected incarnation to at least one node in the remote service environment based on the resource capacity of the at least one node.

[0005] For a better understanding of the exemplary embodiments of the present invention, together with other and further features and advantages thereof, reference is made to the following description taken in conjunction with the accompanying drawings, in which the scope of the embodiments of the invention as claimed in the appended claims is pointed out. [Brief explanation of the drawings]

[0006] [Figure 1] A method for selecting at least one incarnation of an application's services to host the application in a remote service environment is shown. [Figure 2] Here is an example of the steps to split a service into service slices: [Figure 3] We present an example of steps to identify possible incarnations and select an incarnation for a service slice. [Figure 4] An example of the steps to apply a service slice to a node in a remote service environment is shown below. [Figure 5] Showing a computer system. DETAILED DESCRIPTION OF THE INVENTION

[0007] It will be readily understood that the components of the embodiments of the present invention, as generally described and illustrated in the figures herein, could be arranged and designed in a wide variety of configurations in addition to the exemplary embodiments described. Thus, the following more detailed description of the embodiments of the present invention, as represented in the figures, is not intended to limit the scope of the embodiments of the present invention as claimed, but is merely representative of exemplary embodiments of the invention.

[0008] References throughout this specification to "one embodiment" or "an embodiment" (and the like) mean that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. Thus, the appearances of phrases such as "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment.

[0009] Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in at least one embodiment. In the following description, numerous specific details are provided to provide a thorough understanding of embodiments of the present invention. However, those skilled in the relevant art will readily recognize that embodiments of the present invention may be practiced without one or more of the specific details, or may be practiced with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the present invention.

[0010] The illustrated embodiments of the present invention will be best understood by referring to the drawings. The following description is intended by way of example only and illustrates certain selected exemplary embodiments of the invention claimed herein. It should be noted that the flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, apparatus, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of code that includes at least one executable instruction for implementing the specified logical function(s).

[0011] It should also be noted that in some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a dedicated hardware-based system or a combination of dedicated hardware and computer instructions that performs the specified functions or operations.

[0012] Specific reference will now be made below to Figures 1-5. It should be appreciated that the processes, equipment, and products broadly illustrated in the Figures may be implemented on or in accordance with essentially any suitable computer system or set of computer systems, which may include, as an illustrative and non-limiting example, a system or server such as that shown at 12' in Figure 5. According to example embodiments, most, if not all, of the process steps, components, and outputs discussed with respect to Figures 1-4 may be performed or utilized using one or more processing units and system memories, such as those shown at 16' and 28', respectively, in Figure 5, either on a server computer, on a client computer, on a node computer of a distributed network, or any combination thereof.

[0013] When moving an application or application service to be hosted in a remote service environment, the user or entity moving the application or service must pay a hosting fee. Typically, an application entity purchases a set of nodes on a hosting entity for the application or service. This set of nodes is commonly referred to as a cluster. The cluster must have sufficient resources to run the application and provide the desired performance. However, application entities prefer to minimize cluster costs by purchasing the minimum number of nodes or nodes that may have lower performance capabilities. If an application entity purchases too few nodes or nodes with too low performance capabilities to run its application, the application entity will violate service level agreements with its customers. These violations will result in losses to the business, either in the form of payments to unsatisfied customers or lost revenue. On the other hand, if an application entity purchases too many nodes or nodes with excess performance capabilities, the application entity will end up paying more than necessary for services in the remote service environment.

[0014] One problem with estimating the correct number of nodes is that applications or application services typically have resource usage values that fluctuate over time. For example, an application may experience an increase in transactions per second (TPS) during peak hours and a decrease in TPS during off-peak hours. Therefore, this application does not always require the same amount of resources. Therefore, if node performance or capacity values are selected based on average resource usage, the nodes will not be able to meet peak performance demands. One conventional technique involves monitoring the resource usage of an application or service after it has been moved to a remote service environment. The problem with this technique is that by this point, the application or service has already been moved to the remote service environment, meaning the nodes have already been purchased. Even if the conventional system later determines that fewer nodes are needed, the application entity has already paid for the extra nodes for a certain period of time, resulting in unnecessary increased costs for the application entity.

[0015] Accordingly, one embodiment provides a system and method for selecting at least one incarnation for a service of an application for hosting the application in a remote service environment. The system receives an application including multiple services to be hosted in a remote service environment (e.g., a remote network environment, a cloud environment, etc.). For ease of reading, a cloud environment will be the primary example of a remote service environment used throughout this specification. However, this is not intended to limit the scope of this application in any way. For each service of the application, a resource profile is obtained that identifies resource usage (e.g., transactions per second (TPS), memory, database accesses, etc.) over a period of time. For ease of reading, the primary resource example will be TPS. However, this is not intended to limit the scope of this application in any way.

[0016] Using the resource profile, the system divides each service into service slices. These service slices represent the areas where resource usage was uniform during an interval. In other words, the system determines the intervals during which the service has consistent resource demand values. The system treats each service slice as an individual service for the purpose of selecting an incarnation. Therefore, based on the service slices, the system generates multiple incarnations that can satisfy the resource demand values of each service slice. The incarnations are based on the resource capacity of available nodes in the remote service environment. Based on the resource capacity of various nodes, the system can identify multiple incarnations, or node sets, that will satisfy the resource demand requirements of the service slice.

[0017] Once an incarnation is selected, for example, based on the incarnation with the lowest total demand value, the system assigns the incarnation to a node in the remote service environment. The assignment is based on identifying nodes with specified resource capacity that are large enough for the service slice. Once assignments have been made for all service slices for all services, applications can be migrated to the remote service environment by scheduling application jobs to run in the remote service environment.

[0018] Such a system provides a technical improvement over current systems for transferring applications to remote service environments. The described systems and methods can identify the exact number of nodes or clusters required to run an application at the desired performance before the application is transferred to the remote service environment. By determining the correct number of nodes and required node performance values before moving the application to the remote service environment, the described systems provide a significant technical improvement in the field of remote service environments over conventional systems that can only make the determination after the application has been moved to the remote service environment. Additionally, by making the determination before moving an application or service to the remote service environment, the application entity can ensure that enough nodes are purchased to meet service level agreements with customers while minimizing cluster costs by not overpurchasing nodes.

[0019] FIG. 1 illustrates a method for selecting at least one incarnation for a service of an application for hosting in a remote service environment. At 101, the system receives an application including multiple services to be hosted in the remote service environment. The application may be an application that an application entity (i.e., an entity that owns, created, or otherwise controls the application) wants to move or relocate to be hosted in a cloud service environment. An application may be composed of or include various services, and each service may run independently of other services in the application. In other words, each service in an application may run in a different part of the cloud service environment without affecting the performance of the application. However, all services are required for the application as a whole to run correctly and perform its intended function.

[0020] Thus, receiving the application may be receiving any indication from an application entity regarding a desire to move the application to the cloud services environment. For example, receiving the application may include a user or application entity providing a link corresponding to the application to the system, uploading the application to the system, etc. Additionally, if the described system is part of a cloud services environment, receiving the application may include receiving the application in the cloud services environment. The system may then perform the described method upon receiving the application in the cloud services environment. In other words, receiving the application may be performed via any technique for receiving, accessing, or otherwise obtaining an application or information that enables an application or service of the application to be accessed.

[0021] At 102, the system obtains a resource profile for each service in the application. The resource profile identifies the resource usage by that service over a period of time. The obtained resource profile is a profile of the resource of interest. Typically, the resources selected are resources that affect the performance of the application or are of interest to the application entity's customers. For example, an application entity may have a service level agreement with a customer that requires the application entity to provide some base level of performance. To meet this base level of performance, the application entity may be interested in resources directly related to meeting this base level of performance. Because an application entity may be interested in multiple resources, the system may obtain multiple resource profiles, each for a different resource. Some example resources include transactions per second (TPS), memory usage, database access, etc. The primary example used throughout this section will be TPS.

[0022] Obtaining the resource profile may be accomplished via any one or more of a variety of techniques. One technique for obtaining the resource profile is to run the service and monitor the service's resource usage over a period of time, such as a day, a week, or a few hours. Another technique for obtaining the resource profile is to receive the resource profile from a user or other entity that has already generated a resource profile. A resource profile may also be obtained by identifying a service similar to the target service that already has a resource profile and using the resource profile of that similar service for the target service.

[0023] At 103, the system divides each service into multiple service slices. The system takes the resource profile obtained at 102 and discretizes the profile. In other words, the system represents the profile as a discrete quantity, such that the profile now has discrete values at various intervals. The system then slices the discretized profile into service slices. Each service slice represents consistent or uniform demand over an interval, such as a time interval, a start and end interval of demand, etc. Each service slice is treated as an independent service for incarnation selection purposes. In other words, the system can take each service slice and determine when resources should be allocated and deallocated to that service slice.

[0024] An example of the steps for dividing a service into service slices is depicted in Figure 2. The original profile is depicted in 201. The system then discretizes the profile. This discretized profile is depicted in 202. As shown in the graph in 202, the discretization results in discrete values at intervals that encompass the actual profile values at the same intervals. The system then slices the discretized graph into various slices that represent the uniform demand of the resource over an interval, e.g., a time interval. The sliced graph is shown in 203 and contains four different slices: 1, 2, 3, and 4. As can be seen, each slice is the uniform demand over an interval in the graph.

[0025] At 104, the system determines whether a possible incarnation can be selected for each service slice of each service. Incarnations are based on the resource capacity of nodes in the remote service environment. Available nodes can have various resource capacities. For example, nodes can have a number of cores, an amount of associated memory, storage capacity, resource values (e.g., TPS provided by the node), etc. Because different available nodes have different resource capacities and capabilities, there are various options that can result in a set of nodes that will meet the requirements of the service slice. Each of these different options is referred to as an incarnation. For example, one incarnation can include three nodes with a particular resource capacity, while another incarnation can include two nodes with a different resource capacity.

[0026] Therefore, to identify possible incarnations, the system must determine how many nodes with a particular resource capacity are required to meet the resource needs of the service slice. To facilitate understanding of the process, a single node type is used as an example. However, multiple node types can also be utilized, as described in more detail below. The total number of nodes required is also referred to as the total demand of the incarnation. To determine the total demand of the incarnation, the system performs a correlation analysis between the resource capacity of the nodes and the resource demand of the incarnation.

[0027] An example analysis is shown in Figure 3. The capacity of a particular node type is 16 cores, 512 GB memory capacity, and 1 TB hard drive capacity. The TPS demand of the service slice is 3000. The various incarnations shown in the left table show the resource demand of each incarnation. The right table shows the aggregate demand of the incarnation based on the incarnation's demand considering the node type's resource capacity. The number of copies, also called replicas, is based on the incarnation's TPS demand considering the service slice's TPS demand. For example, incarnation 1 provides 500 TPS, while the service slice's TPS demand is 3000 TPS. Therefore, the number of replicas required is 6 (i.e., 3000 / 500). The total demand can then be calculated by multiplying the total demand by the number of replicas required.

[0028] If different resources or resource values, also referred to as dimensions, are of interest, the dimensions can be weighted in the calculation of total demand. For example, if an application entity is more interested in one resource than another, that resource can have a higher weighting during the calculation. Additionally, incarnations can be mixed; that is, any two incarnations can be associated with different node types. For multiple node types, similar techniques can be used as for single node types. Node type refers to the node's resource capacity and hardware / software configuration (e.g., operating system, chipset, memory technology, etc.). In other words, if one node has a different resource capacity than another node, the nodes are of different node types. For example, if one node has 16 cores and another node has 8 cores, the nodes are of different node types.

[0029] In the case of multiple node types, each node type is treated separately and the calculation for a single node type described above is used. Once the total demand calculation for that node type is done, the calculation for the next node type may be done. For each node type, the system identifies the cost of placing an incarnation on that particular node type. The system also identifies the benefit for that node type. The benefit may represent the sum of the resource demand across the number of replicas assigned to that node type. From the benefit and cost, the system determines the effectiveness of a particular node type. The effectiveness may be calculated by dividing the benefit by the cost. The node type selected to assign a particular incarnation may be the node type with the highest effectiveness value.

[0030] Once the total demand for each incarnation is determined, the system may select an incarnation for each service slice. The selected incarnation may be the incarnation with the lowest total demand value. The selected incarnation may also be the incarnation with the lowest total cost to the application entity. Because each node type has an associated cost, selecting different incarnations may result in different costs to the application entity. This may be particularly noticeable when utilizing multiple node types within a single incarnation. Therefore, the selected incarnation may be the cheapest incarnation while still meeting the resource demand requirements.

[0031] If an incarnation cannot be selected at 104, the system cannot do anything at 105. If there is no node that can satisfy the resource demand requirements, an incarnation may not be selected. The system may also notify the user or application entity that an incarnation cannot be selected. On the other hand, if an incarnation can be selected at 104, the system may assign the selected incarnation to a node in the remote service environment. In other words, once an incarnation is selected, the system may assign a service slice to a node corresponding to the incarnation.

[0032] To assign an incarnation, the system may sort the replicas of the incarnation based on the start time of each replica. The sorting may be done in ascending order of start time. The system may then assign the first replica (i.e., the replica that starts first) to a node in the cloud environment. The system then takes the next or subsequent replica and determines whether it can fit in the same node. If it can, the replica is assigned to the same node. If it cannot, the system opens a new node and assigns the replica to the newly opened node. This process continues repeatedly until all replicas are assigned to nodes. This process is completed for all service slices and all services in the application.

[0033] For more efficient allocation, for subsequent replicas, the system may first determine whether the subsequent replica can fit into the most full node. If it cannot fit into the most full node, the system may determine whether it can fit into the next most full node. The system may continue this process until it finds a node into which the replica can fit, even if it ends up being a new node. In the case of multiple node type allocation, the system assigns the incarnation to a node type that matches the incarnation.

[0034] An example allocation diagram is shown in FIG. 4. 401 indicates the incarnations to be selected. After performing analysis, the system determines that incarnations A, B, and C will go into node 1 402A, and incarnation D will go into node 2 402B. The allocation may also include scheduling the incarnations to run on nodes in the cloud service environment. In other words, the system creates node clusters and schedules jobs to effectively transfer or migrate applications to the cloud service environment.

[0035] As shown in FIG. 5, the computer system / server 12′ within the computing node 10′ is depicted in the form of a general-purpose computing device. Components of the computer system / server 12′ may include, but are not limited to, at least one processor or processing unit 16′, a system memory 28′, and a bus 18′ coupling various system components, including the system memory 28′, to the processor 16′. The bus 18′ represents at least one of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

[0036] The computer system / server 12' typically includes a variety of computer system-readable media, which may be any available media that can be accessed by the computer system / server 12' and includes both volatile and nonvolatile media, removable and non-removable media.

[0037] The system memory 28' may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 30' or cache memory 32', or both. The computer system / server 12' may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 34' may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, commonly referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to removable, non-volatile magnetic disks (e.g., "floppy disks"), and an optical disk drive may be provided for reading from and writing to removable, non-volatile optical disks, such as CD-ROMs, DVD-ROMs, or other optical media. In such cases, each may be connected to the bus 18' by at least one data medium interface. As further shown and described below, the memory 28' may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of embodiments of the present invention.

[0038] A program / utility 40' having a set (at least one) of program modules 42' may be stored in memory 28', as well as (by way of example and not limitation) an operating system, at least one application program, other program modules, and program data. Each of the operating system, at least one application program, other program modules, and program data, or any combination thereof, may comprise an implementation of a networking environment. The program modules 42' generally perform the functions and / or methodologies of embodiments of the present invention described herein.

[0039] The computer system / server 12' may also communicate with at least one external device 14', such as a keyboard, pointing device, or display 24', at least one device that allows a user to interact with the computer system / server 12', or any device (e.g., a network card, modem, etc.) that allows the computer system / server 12' to communicate with at least one other computing device, or a combination thereof. Such communication may occur via an I / O interface 22'. Additionally, the computer system / server 12' may communicate with at least one network, such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via a network adapter 20'. As shown, the network adapter 20' communicates with other components of the computer system / server 12' via a bus 18'. It should be understood that other hardware and / or software components, not shown, may also be used in conjunction with the computer system / server 12'. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0040] This disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limiting. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiments were chosen and described in order to explain the principles and practical applications and to enable others of ordinary skill in the art to understand the disclosure.

[0041] Although illustrative embodiments of the present invention are described herein with reference to the accompanying drawings, it is to be understood that embodiments of the present invention are limited to those precise embodiments, and that various other changes and modifications can be effected by those skilled in the art without departing from the scope or spirit of the present disclosure.

[0042] The present invention may be a system, a method, or a computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium or media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0043] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of further specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM, or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as transitory signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted over wires.

[0044] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, fiber optic transmission cables, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to a computer-readable storage medium within the respective computing / processing device for storage.

[0045] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages such as Smalltalk®, C++, and traditional procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0046] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions. These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute on the processor of the computer or other programmable data processing apparatus, produce means for performing the functions / acts specified in one or more blocks of the flowchart illustrations and / or block diagrams. These computer-readable program instructions can be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowchart illustrations and / or block diagrams.

[0047] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational acts on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions, executing on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0048] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations or executes a combination of special-purpose hardware and computer instructions.

Claims

1. receiving an application including a plurality of services to be hosted in a remote service environment; obtaining a resource profile that identifies resource usage by a given service of the plurality of services over a period of time; generating a plurality of service slice information for a given service based on the resource profile corresponding to the given service; selecting an incarnation that satisfies resource demand requirements and service performance offerings for each of the plurality of service slice information, the incarnation having a total demand value based on resource capacity of nodes in the remote service environment; for each of the plurality of service slice information, assigning the selected incarnation to at least one node in the remote service environment based on the resource capacity of the at least one node; 20. A computer-implemented method comprising:

2. The method of claim 1 , wherein the selecting step comprises generating a plurality of possible incarnations for each of the plurality of service slice information, each of the plurality of possible incarnations satisfying the resource demand requirement.

3. 3. The method of claim 2, wherein each of the plurality of possible incarnations has a corresponding total demand value, and the selected incarnation is the incarnation with the lowest total demand value.

4. The method of claim 1 , wherein the total demand value is based on the number of replicas of the incarnation needed to satisfy the resource demand requirements given the resource demand values provided by the incarnations.

5. The method of claim 4 , wherein the allocating step comprises sorting the number of replicas based on their start times.

6. the assigning step includes assigning a first replica of the number of replicas to a first node; repeating for each of the remaining number of replicas, determining whether a subsequent replica of the remaining number of replicas will be included in the first node, and in response to determining that the subsequent replica of the remaining number of replicas will be included in the first node, assigning the subsequent replica of the remaining number of replicas to the first node, and in response to determining that the subsequent replica of the remaining number of replicas will not be included in the first node, assigning the subsequent replica of the remaining number of replicas to a next node; The method of claim 5 , comprising:

7. The method of claim 1 , wherein the total demand value is based on a plurality of resource values, each of the plurality of resource values being weighted within the total demand value.

8. 2. The method of claim 1, wherein the assigning step comprises identifying a plurality of node types, and for each of the node types, identifying a cost of assigning a given incarnation to the given node type, and assigning the given incarnation to the node type with the greatest effectiveness.

9. The method of claim 1 , wherein the allocating step comprises scheduling the incarnation for execution on the at least one node.

10. The method of claim 1 , wherein the resource usage comprises transactions per second.

11. at least one processor; a computer-readable storage medium having computer-readable program code embodied therein and executable by said at least one processor; An apparatus comprising: the computer readable program code configured to receive an application including a plurality of services to be hosted in a remote service environment; the computer readable program code configured to obtain a resource profile identifying resource usage by a given service of the plurality of services over a period of time; the computer readable program code is configured to divide the given service into a plurality of service slice information based on the resource profile corresponding to the given service; The computer readable program code is configured to select, for each of the plurality of service slice information, an incarnation that satisfies resource demand requirements and service performance offerings, the incarnation having an aggregate demand value based on resource capacity of nodes in the remote service environment; the computer readable program code is configured to assign, for each of the plurality of service slice information, the selected incarnation to at least one node in the remote service environment based on the resource capacity of the at least one node. Device.

12. A computer program executed by a computer, said computer program causing said computer to carry out the method according to any one of claims 1 to 10.

Images