Updating a cloud service with farms grouped for a same update deployment stage

1 . An orchestrator for orchestrating software updates, comprising:

an orchestrator service host computer comprising a processor and memory, the memory comprising computer executable instructions that, when executed by the processor, cause the orchestrator service host computer to:

identify systems of a software service that are in scope for receiving the software updates;

determine a respective level of usage for each of the systems;

place the systems of the software service into a plurality of stages of an update to the software service based on the level of usage and based on a grouping table identifying groups of the systems to be placed in a same stage, the placing of the systems including

determining a first placement of the systems into a first stage based on the level of usage of the systems and a desired size of the first stage, and

in response to a determination that a first group of the systems in the grouping table will be split between the first stage and subsequent stages, determining a second placement by altering the first placement by removing the systems of the first group from the first stage and placing the systems of first group into a second stage subsequent to the first stage; and

applying the update to the software service based on the second placement, including

applying the update to systems placed in the first stage of the second placement, and

after applying the update to systems in the first stage of the second placement, applying the update to the systems in the second stage subsequent to the first stage in the second placement.

2 . The orchestrator of claim 1 , wherein the placing of the systems further includes determining when a requested percentage of a userbase for a next update stage, based on the usages of the individual systems, would split the first group of systems grouped in the grouping table into different update stages and,

in response, holding the first group of systems for placement in a subsequent stage that will not split the first group of systems.

3 . The orchestrator of claim 2 , wherein, when holding the first group of systems for the subsequent stage, the placing of the systems fills a current stage with other systems that are not grouped in groups large enough to be split due to the requested percentage of the userbase.

4 . The orchestrator of claim 1 , further comprising an Application Programming Interface (API) through which the orchestrator requests an identification of the systems for each stage of the update.

5 . The orchestrator of claim 4 , wherein the systems are grouped in a hierarchy using labels and names, with a system label comprising a plurality of systems with different system names.

6 . The orchestrator of claim 5 , wherein the API comprises:

a first API for when the systems for update in a common stage are grouped by the system label; and

a second API for when the systems for update in the common stage are grouped by the different system names.

7 . The orchestrator of claim 5 , wherein the orchestrator performs synchronization of updates to grouped system names as part of a cross-regional controller network move.

8 . A method of deploying an update for a software service that is supported by a population of computer systems, the update being deployed in a series of stages that successively include a larger percentage of a userbase, the method comprising:

identifying a customer of the software service with tenants of the software service in different regions such that the tenants are at risk of being placed in different stages of the update resulting in a potential difference in software service version for different parts of the customer;

for the identified customer, identifying systems of the software service that are in scope for receiving the software updates;

determining a respective level of usage for each of the systems;

placing the systems of the software service into a plurality of stages of an update to the software service based on the level of usage and based on a grouping table identifying groups of the systems to be placed in a same stage, the placing of the systems including

determining a first placement of the systems into a first stage based on the level of usage of the systems and a desired size of the first stage, and

in response to a determination that a first group of the systems in the grouping table will be split between the first stage and subsequent stages, determining a second placement by altering the first placement by removing the systems of the first group from the first stage and placing the systems of first group into a second stage subsequent to the first stage, and

applying the update to the software service based on the second placement, including

applying the update to systems placed in the first stage of the second placement,

and after applying the update to systems in the first stage of the second placement, applying the update to the systems in the second stage subsequent to the first stage in the second placement.

9 . The method of claim 8 , further comprising:

determining when a requested percentage of a userbase for a next update stage would, based on the usages of the individual systems, split the first group of systems grouped in the grouping table into different update stages and,

in response, holding the first group of systems for placement in a subsequent stage that will not split the first group of systems.

10 . The method of claim 9 , further comprising, when holding the first group of systems for the subsequent stage, filling a current stage with other systems that are not grouped in groups large enough to be split due to the requested percentage of the userbase.

11 . The method of claim 8 , further comprising an Application Programming Interface (API) through which an orchestrator service requests an identification of the systems for each stage of the update.

12 . The method of claim 11 , wherein the systems are grouped in a hierarchy using labels and names, with a system label comprising a plurality of systems with different system names.

13 . The method of claim 12 , wherein the API comprises:

a first API for when the systems for update in a common stage are grouped by system label; and

a second API for when the systems for update in the common stage are grouped by system name.

14 . The method of claim 12 , wherein synchronization of updates to grouped system names is performed as part of a cross-regional controller network move.

15 . The method of claim 8 , wherein use of the grouping table is subject to an expiration date or user input to end synchronization of updates to grouped systems.

16 . The method of claim 8 , wherein grouping the systems for the customer in the grouping table is provided based on customer type.

17 . A processing system comprising:

a processor;

a network interface to a service bus in communication with a population of computer systems supporting a software service;

a memory storing executable instructions which, when executed by the processor, cause the processor, alone or in combination with other processors, to:

identify the systems of the software service that are in scope for receiving the software updates;

determine a respective level of usage for each of the systems;

place the systems of the software service into a plurality of stages of an update to the software service based on the level of usage and based on a grouping table identifying groups of the systems to be placed in a same stage, the placing of the systems including

determining a first placement of the systems into a first stage based on the level of usage of the systems and a desired size of the first stage, and

in response to a determination that a first group of the systems in the grouping table will be split between the first stage and subsequent stages, determining a second placement by altering the first placement by removing the systems of the first group from the first stage and placing the systems of first group into a second stage subsequent to the first stage; and

applying the update to the software service based on the second placement, including

applying the update to systems placed in the first stage of the second placement, and

after applying the update to systems in the first stage of the second placement, applying the update to the systems in the second stage subsequent to the first stage in the second placement.