Patent Description:
For simplicity and illustrative purposes, the present disclosure is described by referring mainly to embodiments.

Services, such as web applications, email applications, etc., are often updated over time to improve the services, enhance security on the services, etc. Technical issues, such as disruptions in the computing nodes that host the services, incompatibility of client access to the services, etc., are often encountered in conventional systems and methods for rolling out of the updates across large-scale networked systems. That is, for instance, conventional systems and methods for updated services across large-scale networked systems may result in computing nodes being unavailable and/or failing to provide the services according to client requests. Additionally, if there is a disaster, e.g., a crash, a transient network error, a misconfiguration, coding error, etc., during the update, the service code may be destroyed, which may result in the service being unavailable for an extended period of time.

Disclosed herein are methods and apparatuses for upgrading a version of a service that do not suffer from the technical issues of conventional systems and methods. Particularly, the methods and apparatuses disclosed herein may upgrade a version of a service in a safe manner while enabling backward compatibility to an existing or older version of the service. In addition, the methods and apparatuses disclosed herein may maintain the existing version of the service and thus remain available to be bound to client requests during upgrade of the service version. In this regard, the methods and apparatuses disclosed herein may afford technical solutions to the technical issues discussed above. The technical solutions may include that at least some of the computing nodes that host an earlier or existing version of the service are maintained in an operational state in the event of disasters to the computing nodes that host the newer version of the service and thus, the methods and apparatuses disclosed provide improved fault tolerance as compared with conventional systems and methods. In other words, the states of the services provided by networked computing nodes may be maintained in the event of breaking changes and/or disasters during the rollout of the service upgrade.

Generally speaking, the methods disclosed herein may include the communication of an instruction to a host device to pre-spawn a number of first host processes configured to provide a first version of the service in a computing node and to pre-spawn a number of second host processes configured to provide a second version of the service. In addition, the number of first host processes and the number of second host processes may be defined in a first scaling constraint. As used herein, the terms "first host process" and "second host process" are not intended to respectively denote an initial and a second host process. Instead, the terms "first host process" and "second host process" are used herein to distinguish these host processes from each other. In addition, the number of first host processes and the number of second host processes may each be greater than or equal to one.

The methods disclosed herein may also include the receipt of an indication that each of the second host processes is operating properly. In response to receipt of the indication, the methods may further include the communication of an instruction to the host device to decrease the number of first host processes and to increase the number of second host processes as defined in a second scaling constraint. A number of first host processes that provide the first version of the service may be maintained to enable backward compatibility to client requests for the first version and the number of second host processes that provide the second version may be increased following validation of the second host processes.

According to examples, the increase in second host processes may not occur until the second host processes are validated, e.g., determined to be operating properly. In this regard, the second version of the service may not be fully deployed until the second host processes have been determined as operating properly (or equivalently, operating normally). In addition, the methods disclosed herein may be applied to pre-spawn second host processes in computing nodes across multiple data centers and the increase in second host processes may not occur until the second host processes across the multiple data centers are validated. In this regard, the second version of the service may not be fully deployed until a determination is made that the second host processes are operating properly.

To avoid disrupting client sessions that are bound to host processes, the host device may incrementally pre-spawn the second host processes. That is, the host device may identify and terminate first host processes that become unbound from client sessions until a count of the identified first host processes is equal to the number of first host processes as defined in the first scaling constraint. In addition, the host device may incrementally, as the identified first host processes are terminated, pre-spawn second host processes until a count of the second host processes is equal to the number of second host processes as defined in the first scaling constraint. Similar procedures may be implemented to terminate the first host processes and incrementally pre-spawn the second host processes until the counts of the first host processes and the second host processes equal the numbers defined in the second scaling constraint.

Reference is made first to <FIG> and <FIG>. <FIG> shows a block diagram of an infrastructure <NUM> in which an upgrade apparatus <NUM> may be implemented to upgrade a service, which may be an application, an email service, a search engine service, a web site, or the like, across one or more data centers <NUM>-<NUM> to <NUM>-N, in accordance with an embodiment of the present disclosure. <FIG> shows a block diagram of one of the data centers <NUM>-<NUM> depicted in <FIG> in accordance with an embodiment of the present disclosure. It should be understood that the infrastructure <NUM> and the data center <NUM>-<NUM> respectively depicted in <FIG> and <FIG> may include additional components and that some of the components described herein may be removed and/or modified without departing from scopes of the infrastructure <NUM> and the data center <NUM>-<NUM>.

As shown in <FIG> and <FIG>, an upgrade apparatus <NUM> may be in communication with the data centers <NUM>-<NUM> to <NUM>-N, in which the variable "N" may represent an integer value greater than one, via an external network <NUM>, which may be, for example, a local area network (LAN) or the Internet. The upgrade apparatus <NUM> may be located in one of the data centers <NUM> or another location and may be a processor, a microprocessor, a computing device, a server computer, or the like, and may handle the upgrading of services executed in the data centers <NUM>. The upgrade apparatus <NUM> may also be a distributed set of machines. In any regard, the upgrade apparatus <NUM> may implement and coordinate the upgrading of a version of a service in one or more of the data centers <NUM> such that a second (e.g., newer or different) version of the service may be safely rolled out while providing compatibility back to a first (e.g., older or current) version of the service. Various manners in which the upgrade apparatus <NUM> may operate are discussed in greater detail herein.

Generally speaking, each of the data centers <NUM> provides cloud computing services and/or distributed computing services. According to examples, the data centers <NUM> may be located in different geographical locations with respect to each other. For instance, the data centers <NUM> may be located in different counties, in different states, in different countries, etc. In other examples, some of the data centers <NUM> may be located in the same geographical location but may be located in separate buildings, separate rooms, etc..

The data center <NUM>-<NUM> is depicted in <FIG> as including a plurality of computing nodes <NUM>-<NUM> to <NUM>-K, e.g., servers, blades, etc., a host device <NUM>, routers/switches <NUM>, and a Domain Name System (DNS) server <NUM>. Each of the other data centers <NUM>-<NUM> to <NUM>-N may have similar configurations and thus the description of the data center <NUM>-<NUM> may also pertain to the other data centers <NUM>-<NUM> to <NUM>-N. The host device <NUM> may manage the computing nodes <NUM> and may distribute requests and workloads over the computing nodes <NUM> such that client requests are directed to the computing nodes <NUM> that host the appropriate services and versions of the services for the client requests. For instance, the host device <NUM> may distribute requests and workloads to avoid situations in which any of the computing nodes <NUM> may become overloaded and may also maximize available capacity and performance of the computing nodes <NUM>. The host device <NUM> may further implement service version upgrades across the nodes <NUM>. The routers/switches <NUM> support data traffic between the computing nodes <NUM> and between the data center <NUM>-<NUM> and external resources and users (not shown) via the external network <NUM>.

The computing nodes <NUM> may be standalone computing devices and/or the computing nodes <NUM> may be configured as individual blades in a rack of one or more server devices. The computing nodes <NUM> have an input/output (I/O) connector <NUM> that manages communication with other data center <NUM>-<NUM> to <NUM>-N entities. One or more host processors <NUM> on each computing node <NUM> run a host operating system (O/S) <NUM> that may support multiple virtual machines (VM) <NUM>-<NUM> to <NUM>-M, in which the variable "M" represents an integer value greater than one and may differ for different ones of the data centers <NUM>. Each VM <NUM> may run its own O/S so that each VM O/S <NUM> on a computing node <NUM> is different, or the same, or a mix of both. The VM O/S's <NUM> may be, for example, different versions of the same <NUM>/S (e.g., different VMs running different current and legacy versions of the Windows® operating system). In addition, or as another example, the VM O/S's <NUM> may be provided by different manufacturers (e.g., some VMs run the Windows® operating system, while others VMs run the Linux® operating system).

Each VM <NUM> may also run host processes <NUM>-<NUM> to <NUM>-P that provide one or more services or applications (App) <NUM> and/or versions of the one or more services or applications. It should be noted that services and applications may be used interchangeably herein and that the variable "P" represents a value greater than one and may differ for different ones of the VMs <NUM>-<NUM> to <NUM>-M. Each of the computing nodes <NUM> may also include storage <NUM> (e.g., hard disk drives (HDD)) and memory <NUM> (e.g., RAM) that the host processors <NUM> and the VMs <NUM> may access and use for storing software code, data, etc..

The data center <NUM>-<NUM> provides pooled resources on which applications <NUM> may dynamically be provisioned and scaled as needed without having to add servers or additional networking. This allows clients to obtain computing resources without having to procure, provision, and manage infrastructure on a per-application, ad-hoc basis. The data center <NUM>-<NUM> generally allows resources to be scaled up or scaled down dynamically to meet client needs.

The host device <NUM> may control various aspects of the VMs <NUM>, such as which of the host processes <NUM> of the VMs <NUM> provides which version of a service, which host process <NUM> is to be bound to which client session, etc. For instance, the host device <NUM> may pre-spawn a certain number of the host processes <NUM> that provide a current version of the service. As used herein, pre-spawning a host process <NUM> may be defined as launching the instance of the host process <NUM> in the underlying operating system <NUM> containing the binaries of the service <NUM> for a specific version. A host process <NUM> may be deemed to be pre-spawned because the host process <NUM> may be spawned before a client actually requests the instance of the service <NUM>, which may improve latency in binding the host process <NUM> to a client session. In one regard, all of the pre-spawned host processes may always be in an unbound state, e.g., not connected to a client session.

The host device <NUM> may pre-spawn a host process by initializing the host process that provides the version of the service. In addition, the certain number of the host processes <NUM> may be based upon, for instance, a number of instances of the service that are to be pre-spawned as set forth in a service level agreement between a client and a cloud services provider. The host device <NUM> may maintain and update a journal <NUM> that identifies which of the pre-spawned host processes <NUM> provide which version of the service. Generally speaking, pre-spawning the host processes <NUM> that provide a particular version of a service may reduce the latency associated with binding client sessions to the host processes <NUM>. In other words, pre-spawning the host processes <NUM> may enable the host processes <NUM> to be bound to client sessions in a relatively more time-efficient manner as compared with binding the host processes <NUM> to client sessions without pre-spawning the host processes <NUM>, e.g., spawning the host processes <NUM> when the host processes <NUM> are bound to the client sessions.

When the host device <NUM> receives a request for a service <NUM>, the host device <NUM> may select one of the host processes <NUM> of the VMs <NUM> to be bound to a client session corresponding to the request. The host device <NUM> may select the host process <NUM> to be bound to the client session based upon various factors such as the version of the requested service <NUM>, availabilities of the host processes <NUM>, load balancing considerations across the computing nodes <NUM>, etc. Once the host device <NUM> has selected the host process <NUM>, the host device <NUM> may bind the selected host process <NUM> to the client session. In some examples, the request may specify the version of the service to which the request is to be bound and the host device <NUM> may select a pre-spawned host process <NUM> that provides the identified version of the service. In other examples, the request may not specify the version of the service and the host device <NUM> may select a pre-spawned host process <NUM> that provides one of the versions of the service to be bound to the client request.

The host device <NUM> may also receive an instruction from the upgrade apparatus <NUM> to begin providing a second (or equivalently, new, upgraded, etc.) version of a service <NUM>. For instance, the upgrade apparatus <NUM> may communicate the second version of the service <NUM> through a configuration update file <NUM> to the host device <NUM>. In other examples, the host device <NUM> may receive or access the second version of the service <NUM> from a source other than the upgrade apparatus <NUM>. In any regard, the configuration update file <NUM> may include a scaling constraint (also referenced as a first scaling constraint) that defines the number of first host processes <NUM> in the VMs <NUM> of a computing node <NUM> that provide the first version of the service <NUM> and the number of second host processes <NUM> in the VMs <NUM> of the computing node <NUM> that provide the second version of the service <NUM>. In response to receipt of the configuration update file <NUM>, the host device <NUM> may pre-spawn a number of second host processes <NUM> in the VMs <NUM> on one or more of the computing nodes <NUM> to host the second version of the service <NUM> according to the number of host processes identified in the configuration update file <NUM>.

As discussed in greater detail herein, instead of automatically terminating a first host process <NUM> that provides a first version of the service <NUM> that is currently bound to a client session, the host device <NUM> may terminate host processes <NUM> that are unbound to client sessions or may wait until the client sessions on the host processes <NUM> have ended before terminating the host processes <NUM>. The host device <NUM> may also incrementally pre-spawn the second host processes <NUM> to host the second version as the first host processes <NUM> become unbound from client sessions and are terminated. In this regard, the host device <NUM> may not disrupt any current client sessions in order to pre-spawn the second host processes <NUM>. Additionally, as the number of pre-spawned second host processes <NUM> increases, the host device <NUM> may maintain some of the first host processes <NUM> and thus maintain backward compatibility for clients that request the first version of the service <NUM>.

The upgrade apparatus <NUM> may communicate the upgrade configuration file to the host devices <NUM> in each of the data centers <NUM> for which the service <NUM> is to be upgraded. In this regard, each of the host devices <NUM> may pre-spawn a number of second host processes <NUM> on one or more of the computing nodes <NUM> according to the number of host processes identified in the configuration update file <NUM>. A number of first host processes <NUM> in each of the data centers <NUM> may also provide the first version of the service <NUM> following the pre-spawning of the second host processes <NUM>. For instance, the scaling constraint may define that each of the computing nodes <NUM> is to contain a larger number of first host processes <NUM> than the number of second host processes <NUM>. By way of particular example in which a VM <NUM> contains <NUM> host processes, the scaling constraint may define that the VM <NUM> is to execute <NUM> pre-spawned first host processes <NUM> and to execute two pre-spawned second host processes <NUM>.

Following the pre-spawning of the host processes <NUM> according to the scaling constraint set forth in the configuration update file <NUM>, the pre-spawned second host processes <NUM> may be validated. The second host processes <NUM> may be validated through execution of runners on the host processes <NUM>. That is, runners, which may be test scripts, may be executed on the second version instances of the service <NUM> to determine whether the service instances are operating properly, e.g., as intended, according to specifications, normally, etc. If a determination is made that a service instance is not operating properly, the host device <NUM> may return an indication of the error to the upgrade apparatus <NUM>. The upgrade apparatus <NUM> may cease the upgrading operation until a determination is made that the error has been corrected. However, if the host device <NUM> determines the pre-spawned second host processes <NUM> are validated, e.g., operating properly, operating normally, etc., the host device <NUM> may send an indication that the second host processes <NUM> are validated to the upgrade apparatus <NUM>.

The upgrade apparatus <NUM> may receive the validation or error indications from the host devices <NUM> for which the service <NUM> is to be upgraded. In response to receipt of validations from the host devices <NUM> for which the service <NUM> is to be upgraded, the upgrade apparatus <NUM> may communicate a second configuration update file <NUM> to the host devices <NUM>. The second configuration update file <NUM> may include a second scaling constraint that defines a number of host processes <NUM> in the VMs <NUM> of the computing node <NUM> that is to host the first version of the service <NUM> and the number of host processes <NUM> in the VMs <NUM> of the computing node <NUM> that is to host the second version of the service <NUM>. In response to receipt of the second configuration update file <NUM>, the host devices <NUM> may pre-spawn a number of second host processes <NUM> on one or more of the computing nodes <NUM> that provide the second version of the service <NUM> according to the second scaling constraint identified in the second configuration update file <NUM>. The host devices <NUM> may also pre-spawn the second host processes <NUM> incrementally as discussed herein, e.g., as the first host processes <NUM> become unbound to client sessions and are terminated.

A number of host processes <NUM> may also provide the first version of the service <NUM> following the pre-spawning of the second host processes <NUM>. For instance, the first scaling constraint may define that each of the computing nodes <NUM> is to run a larger number of first host processes <NUM> than second host processes <NUM>. By way of particular example in which a VM <NUM> contains <NUM> host processes, the first scaling constraint may define that the VM <NUM> is to execute <NUM> first host processes <NUM> and to execute two second host processes <NUM>.

Although particular reference is made herein to the host processes <NUM> being pre-spawned to provide either a first version or a second version of the service <NUM>, it should be understood that the host processes <NUM> may be pre-spawned to provide other versions of the service <NUM> without departing from scopes of embodiments disclosed herein. That is, for instance, the first scaling constraint included in the first configuration update file <NUM> may define a number of first host processes <NUM>, a number of second host processes <NUM>, a number of third host processes <NUM> that provide a third version of the service <NUM>, and so forth. Additionally, the second scaling constraint included in the second configuration update file <NUM> may define a number of first host processes <NUM>, a number of second host processes <NUM>, a number of third host processes <NUM>, and so forth. One or more of the numbers of host processes <NUM> in the second scaling constraint may differ from corresponding numbers of host processes <NUM> in the first scaling constraint, for instance, to increase the number of host processes <NUM> that are pre-spawned to provide newer versions or the newest version of the service <NUM>.

The Domain Name System (DNS) server <NUM> resolves domain and host names into IP addresses for all roles, applications, and services in the data center <NUM>-<NUM>. A DNS log <NUM> maintains a record of which domain names have been resolved by role. It will be understood that DNS is used herein as an example and that other name resolution services and domain name logging services may be used to identify dependencies. For example, in other embodiments, IP or packet sniffing, code instrumentation, or code tracing may be used to identify dependencies.

<FIG> depicts a block diagram of a cluster <NUM> composed of N nodes <NUM>, which may represent different servers, processors, or VMs. For example, in the example illustrated in <FIG>, servers <NUM>, host processors <NUM>, or VMs <NUM> may correspond to the different nodes <NUM>. The nodes <NUM> may operate as part of a cluster <NUM> that manages various instances of services <NUM>-<NUM>, e.g., different versions of the service instances <NUM>-<NUM>. The cluster <NUM> controls the service instances <NUM>-<NUM> running on the nodes <NUM> and may balance the service loads among the nodes <NUM>. The cluster <NUM> also provides backup and redundancy for the service instances <NUM>-<NUM>. In a data center environment, tens of thousands of service instances may be deployed on a cluster <NUM>.

Users may access the service instances <NUM>-<NUM> deployed on the cluster <NUM> via a client <NUM>, which may be, for example, an application running on a desktop, laptop, tablet computer, mobile device, etc. The client <NUM> may communicate with the cluster <NUM> through a network <NUM>, which may be a public or private data network, such as the Internet, an intranet, or a LAN. The client <NUM> accesses the service instances <NUM>-<NUM> running on the cluster <NUM> though a gateway <NUM>, which is the entry point for the client <NUM> to access the nodes <NUM>. In order to access a service instance <NUM>, the client <NUM> connects to a gateway <NUM> and may register a filter to determine an endpoint assigned to a target service instance <NUM> running on the cluster <NUM>. The client <NUM> then communicates with the target service instance <NUM>-<NUM>.

The cluster <NUM> may be supported by a distributed services platform <NUM> that understands available infrastructure resources and requirements of the service instances <NUM>-<NUM> running on the cluster <NUM>. The distributed services platform <NUM> generally provides comprehensive runtime and lifecycle management capabilities and enables automatic updating and self-healing to ensure delivery of highly available and durable services via the cluster <NUM>. The distributed services platform <NUM> supports microservices in which complex applications are composed of small, independently versioned services running at very high density on a shared pool of nodes <NUM>, such as the cluster <NUM>. In one example, the distributed services platform <NUM> may be the Azure Service Fabric provided by Microsoft Corporation®. The distributed services platform <NUM> manages the service instance endpoints in the cluster <NUM>. A distributed services platform <NUM>, such as Microsoft Corporation's Service Fabric®, is a framework for hosting services. In any regard, the distributed services platform <NUM> may include the host device <NUM> and the nodes <NUM> may be operated under a microservices framework.

When a new service is started on the cluster <NUM>, the service instance is assigned an endpoint. For example, in <FIG>, a first instance of Service <NUM>, Version <NUM> (<NUM>) is assigned an endpoint on the first node <NUM> (<NUM>-<NUM>). A second instance of Service <NUM>, Version <NUM> (<NUM>) is assigned an endpoint on the second node N (<NUM>-K). Other service instances, Service <NUM>, V2 (<NUM>) and Service <NUM>, V2 (<NUM>) are respectively assigned endpoints on the first node <NUM>-<NUM> and the second node <NUM>-K. The client <NUM> connects to a gateway <NUM> and obtains the endpoint of a target service. The service instances <NUM>-<NUM> may be spread across multiple nodes <NUM>-<NUM> and <NUM>-K as illustrated in <FIG>. Over time, services may be moved due to node failure, load balancing, service upgrades, and/or variations in user demand. Accordingly, the endpoint for a target service may change over time.

Turning now to <FIG>, there is shown a block diagram of an upgrade apparatus <NUM> according to an embodiment of the present disclosure. The upgrade apparatus <NUM> may be equivalent to the upgrade apparatus <NUM> discussed above with respect to <FIG> and the description of the upgrade apparatus <NUM> is made with respect to <FIG> and <FIG>. As shown in <FIG>, the upgrade apparatus <NUM> may include a processor <NUM> that may control operations of the upgrade apparatus <NUM>. The processor <NUM> may be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or other hardware device. The processor <NUM> may access a data store <NUM>, which may be a Random Access Memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, and the like. The processor <NUM> may also access an interface <NUM> through which the processor <NUM> may communicate instructions to a host device and/or to a plurality of host devices in multiple data centers. The interface <NUM> may be any suitable hardware and/or software that enables the processor <NUM> to communicate the instructions over a network <NUM> (shown in <FIG> and <FIG>).

The upgrade apparatus <NUM> may also include a memory <NUM> that may have stored thereon machine readable instructions <NUM>-<NUM> (which may also be termed computer readable instructions) that the processor <NUM> may execute. The memory <NUM> may be an electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. The memory <NUM> may be, for example, Random Access memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, and the like. The memory <NUM>, which may also be referred to as a computer readable storage medium, may be a non-transitory machine-readable storage medium, where the term "non-transitory" does not encompass transitory propagating signals.

The processor <NUM> may fetch, decode, and execute the instructions <NUM> to instruct a host device <NUM> to pre-spawn a number of first host processes <NUM> that provide a first version of a service <NUM> in a computing node <NUM> and to pre-spawn a number of second host processes <NUM> that provide a second version of the service <NUM> in the computing node <NUM>, in which the number of first host processes <NUM> and the number of second host processes <NUM> are defined in a first scaling constraint. The processor <NUM> may also execute the instructions <NUM> to instruct host devices <NUM> in a plurality of data centers <NUM> to each pre-spawn host processes <NUM> according to the first scaling constraint. The processor <NUM> may fetch, decode, and execute the instructions <NUM> to determine whether the pre-spawned host processes <NUM> are validated, e.g., performing as intended. In some embodiments, the processor <NUM> may execute the instructions <NUM> to determine whether the pre-spawned host processes <NUM> that provide the second version of the service <NUM> are validated. The processor <NUM> may fetch, decode, and execute the instructions <NUM> to instruct the host device <NUM> to pre-spawn host processes <NUM> according a second scaling constraint in response a determination that the pre-spawned host processes <NUM> are validated.

Various manners in which the upgrade apparatus <NUM> may operate are discussed in greater detail with respect to the method <NUM> depicted in <FIG>. Particularly, <FIG> depicts a flow diagram of a method <NUM> for upgrading a version of a service according to an embodiment of the present disclosure. It should be understood that the method <NUM> depicted in <FIG> may include additional operations and that some of the operations described therein may be removed and/or modified without departing from a scope of the method <NUM>. The description of the method <NUM> is made with reference to the features depicted in <FIG> for purposes of illustration.

At block <NUM>, the processor <NUM> may execute the instructions <NUM> to instruct a host device <NUM> to pre-spawn a number of first host processes <NUM> that provide a first version of a service <NUM> in a computing node <NUM> and to pre-spawn a number of second host processes <NUM> that provide a second version of the service <NUM> in the computing node <NUM>, in which the number of first host processes <NUM> and the number of second host processes <NUM> are defined in a first scaling constraint. The processor <NUM> may also execute the instructions <NUM> at block <NUM> to instruct host devices <NUM> in a plurality of data centers <NUM> to pre-spawn host processes <NUM> according to the first scaling constraint. The plurality of data centers <NUM> may be data centers <NUM> that house computing notes <NUM> on which instances of the service <NUM> are executed. The instances of the service <NUM> may initially be the first version or multiple versions of the service <NUM>.

As part of the instruction at block <NUM> or as a separate communication, the processor <NUM> may communicate a first configuration update file <NUM> to the host device <NUM>. The first configuration update file <NUM> may include a first scaling constraint that defines the number of first host processes <NUM> and the number of second host processes <NUM>. That is, the first scaling constraint may define the number of first host processes <NUM> in a computing node <NUM> and/or a VM <NUM> in the computing node <NUM> that are to host the first version of the service <NUM> and the number of second host processes <NUM> in the computing node <NUM> and/or the VM <NUM> that are to host the second version of the service <NUM>. In addition or in other embodiments, multiple host devices <NUM> may pre-spawn the first and second host processes <NUM> in multiple computing nodes <NUM> and/or multiple VMs <NUM> in respective data centers <NUM> according to the first scaling constraint. Various manners in which a host device <NUM> may pre-spawn the first and second host processes <NUM> according to the first constraint are discussed in greater detail with respect to <FIG> and <FIG> below.

At block <NUM>, the processor <NUM> may receive an indication regarding a validation of the second host processes <NUM>. That is, the second host processes <NUM> that provide the second version of the service <NUM> may be validated and the processor <NUM> may receive an indication as to whether the second host processes <NUM> are validated. The indication may be that the second host processes <NUM> are validated, e.g., the second host processes <NUM> are operating as intended, or that the second host processes <NUM> are not validated, e.g., the second host processes <NUM> are not operating as intended.

At block <NUM>, the processor <NUM> may execute the instructions <NUM> to determine whether the pre-spawned second host processes <NUM> are validated. In response to a determination that the processor <NUM> received an indication that one or more of the second host processes <NUM> are not validated, the processor <NUM> may attempt to troubleshoot and/or correct a problem that may have led to the validation failure as indicated at block <NUM>. The processor <NUM> may additionally inform an operator of the validation failure. The processor <NUM> may also receive indications from multiple host devices <NUM> across multiple data centers <NUM> and may determine that a second host process <NUM> in any of the multiple data centers <NUM> is not validated at block <NUM>.

However, in response to a determination at block <NUM> that the pre-spawned second host processes <NUM> are validated, the processor <NUM> may execute the instructions <NUM> to instruct the host device <NUM> to modify the number of pre-spawned second host processes <NUM> and the number of pre-spawned first host processes <NUM> in the computing node <NUM> at block <NUM>. That is, for instance, the processor <NUM> may communicate an instruction to the host device <NUM> to decrease the number of first host processes <NUM> and to increase the number of second host processes <NUM>. Additionally, the processor <NUM> may not communicate the instruction at block <NUM> to the host device <NUM> unless or until the processor <NUM> determines that each of the second host processes <NUM> in the computing node <NUM> are validated. In other embodiments, the processor <NUM> may not communicate the instruction at block <NUM> to the host device <NUM> unless or until the processor <NUM> determines that each of the second host processes <NUM> in multiple computing nodes <NUM> in one or in multiple data centers <NUM> are validated.

As part of the instruction at block <NUM> or as a separate communication, the processor <NUM> may communicate a second configuration update file <NUM> to the host device <NUM>. The second configuration update file <NUM> may include a second scaling constraint that defines the number of first host processes <NUM> and the number of second host processes <NUM>, in which t the numbers differ from those in the first scaling constraint. For instance, the second scaling constraint may flip the numbers of first host processes and the second host processes as compared with the numbers of these host processes in the first scaling constraint. The host device <NUM> may pre-spawn the host processes <NUM> in multiple computing nodes <NUM> and/or multiple VMs <NUM> according to the second scaling constraint. Various manners in which the host device <NUM> may pre-spawn the host processes <NUM> according to the second constraint are discussed in greater detail with respect to <FIG> and <FIG> below.

Following implementation of the method <NUM>, validated instances of the second version of the service <NUM> may be provided by VMs <NUM> in one data center <NUM> or across multiple data centers <NUM>. In addition, instances of the first version of the service <NUM> may also be provided by VMs <NUM> in one data center <NUM> or across multiple data centers <NUM>. In this regard, the second version of the service <NUM> may safely be deployed across one or more data centers <NUM> while also enabling backward compatibility to the first version of the service <NUM>. The host devices <NUM> may also begin binding the host processes <NUM> that provide the second version of the service <NUM> to client sessions.

Turning now to <FIG>, there is shown a block diagram of a host device <NUM> in accordance with an embodiment of the present disclosure. The host device <NUM> may be equivalent to the host device <NUM> of a data center <NUM> discussed above with respect to <FIG> and <FIG> and the description of the host device <NUM> is made with respect to those figures. As shown in <FIG>, the host device <NUM> may include a processor <NUM> that may control operations of the host device <NUM>. The processor <NUM> may be a semiconductor-based microprocessor, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), and/or other hardware device. The processor <NUM> may access a data store <NUM>, which may be a Random Access memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, and the like. The processor <NUM> may also access an interface <NUM> through which the processor <NUM> may communicate with other host mangers <NUM>, the upgrade apparatus <NUM>, etc. The interface <NUM> may be any suitable hardware and/or software that enables the processor <NUM> to communicate with the upgrade apparatus <NUM> over a network <NUM> (shown in <FIG> and <FIG>).

The host device <NUM> may also include a memory <NUM> that may have stored thereon machine readable instructions <NUM>-<NUM> (which may also be termed computer readable instructions) that the processor <NUM> may execute. The memory <NUM> may be an electronic, magnetic, optical, or other physical storage device that contains or stores executable instructions. The memory <NUM> may be, for example, Random Access memory (RAM), an Electrically Erasable Programmable Read-Only Memory (EEPROM), a storage device, an optical disc, and the like. The memory <NUM>, which may also be referred to as a computer readable storage medium, may be a non-transitory machine-readable storage medium, where the term "non-transitory" does not encompass transitory propagating signals.

The processor <NUM> may fetch, decode, and execute the instructions <NUM> to access a first configuration update file <NUM>. The processor <NUM> may fetch, decode, and execute the instructions <NUM> to pre-spawn host processes <NUM> according to a first scaling constraint contained in the first configuration update file <NUM>. The processor <NUM> may fetch, decode, and execute the instructions <NUM> to determine whether second host processes are validated. The processor <NUM> may fetch, decode, and execute the instructions <NUM> to communicate an indication of a validation result. The processor <NUM> may fetch, decode, and execute the instructions <NUM> to access a second configuration update file <NUM>. The processor <NUM> may fetch, decode, and execute the instructions <NUM> to modify the host processes <NUM> according to a second scaling constraint contained in the second configuration update file <NUM>.

Various manners in which the host device <NUM> may operate are discussed in greater detail with respect to the methods <NUM> and <NUM> respectively depicted in <FIG> and <FIG>. Particularly, <FIG> depicts a flow diagram of a method <NUM> for upgrading a service in accordance with an embodiment of the present disclosure and <FIG> depicts a flow diagram of a method <NUM> for incrementally pre-spawning a number of host processes that provide a second version of a service in accordance with an embodiment of the present disclosure. It should be understood that the methods <NUM> and <NUM> may include additional operations and that some of the operations described herein may be removed and/or modified without departing from the scopes of the methods <NUM> and <NUM>. The descriptions of the methods <NUM>, <NUM> are made with reference to the features depicted in <FIG>, <FIG>, <FIG>, and <FIG> for purposes of illustration.

At block <NUM>, the processor <NUM> may execute the instructions <NUM> to access a first configuration update file <NUM>. The first configuration update file <NUM> may include a first scaling constraint that defines a number of first host processes <NUM> that provide a first version of a service <NUM> and a number of second host processes <NUM> that provide a second version of the service <NUM>. As discussed above, the first scaling constraint may define the number of first and second host processes <NUM> in a computing node <NUM> and/or a VM <NUM> on the computing node <NUM> that are to provide the first version of the service <NUM> and the number of host processes <NUM> in the computing node <NUM> and/or the VM110 that are to provide the second version of the service <NUM>.

The first scaling constraint may define the number of first host processes <NUM> to be greater than the number of second host processes <NUM>. By way of particular example in which the first scaling constraint defines the number of host processes <NUM> in a VM <NUM> that is able to execute <NUM> host processes <NUM>, the first scaling constraint may define the number of first host processes <NUM> to be <NUM> host processes and the number of second host processes <NUM> to be two host processes.

At block <NUM>, the processor <NUM> may execute the instructions <NUM> to pre-spawn host processes <NUM> according to the first scaling constraint. That is, the processor <NUM> may pre-spawn the number of first host processes <NUM> as defined in the first scaling constraint. In some examples, all of the host processes <NUM> on a VM <NUM> may already provide the first version of the service <NUM> and thus, the pre-spawning of the first host processes <NUM> may include reducing the number of first host processes <NUM>. The processor <NUM> may also pre-spawn the number of second host processes <NUM> as defined in the first scaling constraint.

According to examples, the processor <NUM> may incrementally pre-spawn the first host processes <NUM> and the second host processes <NUM>. That is, the processor <NUM> may not automatically pre-spawn the first and second host processes <NUM> as defined in the configuration update file <NUM> as that may result in existing client sessions being dropped. Instead, in the method <NUM> shown in <FIG>, at block <NUM>, the processor <NUM> may deploy the configuration update file changes to initiate the pre-spawning process at block <NUM>.

In addition, at block <NUM>, the processor <NUM> may determine whether the number of first host processes <NUM> is equal to a first number of host services defined in the first scaling constraint, in which the first number defines the number of first host processes <NUM>. The determination at block <NUM> may also be a determination as to whether the number of second host processes <NUM> is equal to a second number of host processes defined in the first scaling constraint, in which the second number defines the number of second host processes <NUM>. In response to a determination that the number of first host processes <NUM> is equal to the first number and/or that the number of second host processes <NUM> is equal to the second number, the method <NUM> may end as indicated at block <NUM>. The method <NUM> may end at block <NUM> as the number of first host processes <NUM> and the number of second host processes <NUM> may have reached the defined numbers in the first scaling constraint.

However, in response to a determination that the number of first host processes <NUM> is not equal to the first number and/or that the number of second host processes <NUM> is not equal to the second number, the processor <NUM> may determine, at block <NUM>, whether any of the first host processes <NUM> is unbound to a client session. In response to a determination that none of the first host processes <NUM> is unbound to a client session, the processor <NUM> may wait for a period of time as indicated at block <NUM>. The processor <NUM> may wait for a period of time, e.g., a second, a minute, an hour, etc., before making another determination at block <NUM>. The processor <NUM> may repeat blocks <NUM>-<NUM> until the processor <NUM> determines that one of the first host processes <NUM> is unbound to a client session at block <NUM>.

In response to a determination at block <NUM> that a first host process <NUM> is unbound to a client session, the processor <NUM> may terminate that first host process <NUM>, as indicated at block <NUM>. In addition, at block <NUM>, the processor <NUM> may pre-spawn a second host process <NUM> that provides the second version of the service <NUM>.

Following block <NUM>, the processor <NUM> may repeat block <NUM> to determine whether the termination of the first host process <NUM> at block <NUM> and the pre-spawning of the second host process <NUM> at block <NUM> resulted in the numbers of the first and second host processes <NUM> equaling the numbers for the first and second host processes <NUM> defined in the first scaling constraint. As above, in response to the numbers of first and second host processes <NUM> equaling the numbers defined in the first scaling constraint, the method <NUM> may end at block <NUM>. However, in response to the numbers of first and second host processes <NUM> not equaling the numbers defined in the first scaling constraint, blocks <NUM>-<NUM> may be repeated until the numbers of the first and second host processes <NUM> are determined to equal the numbers defined in the first scaling constraint.

Through implementation of the method <NUM>, the first host processes <NUM> that are currently bound to client sessions may be gradually terminated to avoid disrupting the client sessions.

With reference back to <FIG>, following block <NUM>, the processor <NUM> may execute the instructions <NUM> to determine, at block <NUM>, whether the second host processes <NUM> are validated. That is, the processor <NUM> may execute runners, e.g., test scripts, on the second host processes <NUM> to determine whether the second host processes <NUM> are operating as intended. In other examples, another element may perform the validation and the processor <NUM> may receive results of the validation from the other element. In response to a determination that the second host processes <NUM> are validated, the processor <NUM> may execute the instructions <NUM> to communicate an indication that the second host processes <NUM> are validated to the upgrade apparatus <NUM>, <NUM>.

In addition, at block <NUM>, the processor <NUM> may execute the instructions <NUM> to receive a second configuration update file <NUM> from the upgrade apparatus <NUM>, <NUM>. As discussed above, the processor <NUM> may receive the second configuration update file <NUM> when the processor <NUM> in the upgrade apparatus <NUM> determines that the second host processes <NUM> have been validated, e.g., on a computing node <NUM>, on multiple computing nodes <NUM>, across data centers <NUM>, etc. Thus, for instance, the processor <NUM> may not receive the second configuration update file <NUM> unless the each of the second host processes <NUM> have been validated.

The second configuration update file <NUM> may include a second scaling constraint that defines the number of first host processes <NUM> in a computing node <NUM> and/or a VM <NUM> on the computing node <NUM> that are to host the first version of the service <NUM> and the number of second host processes <NUM> in the computing node <NUM> and/or the VM <NUM> that are to host the second version of the service <NUM>. The second scaling constraint differs from the first scaling constraint and in some embodiments, flips the numbers of first and second host processes <NUM>. Thus, with reference to the example provided above, the second scaling constraint may define the number of first host processes <NUM> to be two host processes and the number of second host processes <NUM> to be <NUM> host processes.

At block <NUM>, the processor <NUM> may execute the instructions <NUM> to modify the host processes <NUM> according to the second scaling constraint. That is, the processor <NUM> may modify, e.g., terminate, the first host processes <NUM> such that the number of first host processes <NUM> reaches the number of first host processes <NUM> that are to provide the first version of the service <NUM> as defined in the second scaling constraint. The processor <NUM> may also modify, e.g., pre-spawn, the second host processes <NUM> such that the number of second host processes <NUM> reaches the number of second host processes <NUM> as defined in the second scaling constraint.

According to examples, the processor <NUM> may incrementally modify the first host processes <NUM> and the second host processes <NUM> at block <NUM>. That is, the processor <NUM> may not automatically modify the host processes <NUM> as defined in the second scaling constraint as that may result in existing client sessions being dropped. Instead, in the method <NUM> shown in <FIG>, at block <NUM>, the processor <NUM> may deploy the configuration update file changes of the second configuration update file <NUM> to initiate the pre-spawning process at block <NUM>.

In addition, at block <NUM>, the processor <NUM> may determine whether the number of first host processes <NUM> is equal to a first number of host services defined in the second scaling constraint, in which the first number defines the number of first host processes <NUM>. The determination at block <NUM> may also be a determination as to whether the number of second host processes <NUM> is equal to a second number of host processes defined in the second scaling constraint, in which the second number defines the number of second host processes <NUM>. In response to a determination that the number of first host processes <NUM> is equal to the first number and/or that the number of second host processes <NUM> is equal to the second number, the method <NUM> may end as indicated at block <NUM>. The method <NUM> may end at block <NUM> as the number of first host processes <NUM> and the number of second host processes <NUM> may have reached the defined numbers in the second scaling constraint.

Additionally, the processor <NUM> may execute blocks <NUM>-<NUM> as discussed above until the numbers of the first and second host processes <NUM> are determined to equal the first and second numbers defined in the second scaling constraint. As also discussed above, in response to the numbers of host processes <NUM> equaling the numbers defined in the second scaling constraint, the method <NUM> may end at block <NUM>. In this regard, the first host processes <NUM> that are currently bound to client sessions may be gradually terminated and the second host processes <NUM> may be gradually spun up to avoid disrupting client sessions, while providing backward compatibility to the first version of the service <NUM>.

Following block <NUM>, the method <NUM> may end as indicated at block <NUM>. In addition, with reference back to block <NUM>, in response to a determination that one or more of the second host processes <NUM> was not validated, the processor <NUM> may communicate an indication to the upgrade apparatus <NUM>, <NUM> that not all of the second host processes <NUM> were validated, as indicated at block <NUM>. The method <NUM> may also end following block <NUM> as the upgrading of the service <NUM> may be stalled or ceased. The method <NUM> may be continued, for instance, following a subsequent validation of the second host processes <NUM>.

Although particular reference is made in the description of the methods <NUM>, <NUM> to host processes <NUM> on a single VM <NUM>, it should be understood that these descriptions are applicable to multiple VMs <NUM>. That is, the processor <NUM> and/or multiple processors <NUM> may execute the methods <NUM>, <NUM> on multiple VMs <NUM> in multiple computing nodes <NUM> and across multiple data centers <NUM>.

Some or all of the operations set forth in the methods <NUM>, <NUM>, and <NUM> may be contained as utilities, programs, or subprograms, in any desired computer accessible medium. In addition, the methods <NUM>, <NUM>, and <NUM> may be embodied by computer programs, which may exist in a variety of forms both active and inactive. For example, they may exist as machine readable instructions, including source code, object code, executable code or other formats. Any of the above may be embodied on a non-transitory computer readable storage medium.

Examples of non-transitory computer readable storage media include computer system RAM, ROM, EPROM, EEPROM, and magnetic or optical disks or tapes. It is therefore to be understood that any electronic device capable of executing the above-described functions may perform those functions enumerated above.

Claim 1:
A method for upgrading a version of a service (<NUM>-<NUM>), said method comprising:
instructing a host device (<NUM>) to:
pre-spawn (<NUM>; <NUM>; <NUM>; <NUM>) a number of first host processes configured to provide a first version (<NUM>) of the service in a computing node (<NUM>-<NUM>);
to avoid disrupting client sessions that are bound to the first host processes, pre-spawn (<NUM>; <NUM>) a number of second host processes configured to provide a second version (<NUM>) of the service in the computing node, wherein the number of first host processes and the number of second host processes are defined in a first scaling constraint and are each greater than or equal to one, wherein the host device pre-spawns the second host processes by:
identifying (<NUM>) a host process of the first host processes that becomes unbound from a client session;
terminating (<NUM>) the identified host process; and
incrementally pre-spawning (<NUM>) a second host process that provides the second version of the service as identified first host processes are terminated,
until a count of the second host processes is equal to the number of second host processes as defined in the first scaling constraint; and
in response to receiving an indication that each of the second host processes is operating properly, instructing (<NUM>; <NUM>) the host device to decrease the number of first host processes and to increase the number of second host processes as defined in a second scaling constraint.