Revision safe upgrade in a hybrid cloud landscape

Techniques are described for automatically scheduling and performing upgrades in a hybrid cloud scenario. Advantages to these techniques include revision safe system upgrades and that the process is automated, thus reducing expensive operation costs. Techniques include receiving a landscape model describing changes to a customer landscape, identifying a customer-side system within a customer landscape to upgrade based on the landscape model, and identifying a server-side system within the server landscape that is associated with the customer-side system, and scheduling the customer-side system and the server-side system for upgrade.

BACKGROUND

A hybrid cloud scenario is a modern computer system landscape which includes several computer systems. Some of the computer systems run on the customer side while other computer systems run on the service provider side. The customer side systems are configured to perform a set of functionality that interfaces with the service provider systems which are configured to perform another set of functionality. Together the two sides can perform a task or goal.

When software within a computer system is upgraded, interface dependencies between the system and other systems must be maintained if the hybrid cloud scenario is to perform as expected. As a result, other computer systems must also be upgraded along with the computer system. In one example, upgrading a computer system on the customer side can trigger the upgrade of another computer system on the service provider side. Managing and scheduling the proper time to perform these upgrades can be confusing and require high operation costs.

SUMMARY

In one embodiment, a computer-implemented method receives, by a processor, a landscape model describing changes to a customer landscape, the customer landscape including a plurality of customer-side systems, automatically identifies, by the processor, a customer-side system within the customer landscape to upgrade based on the landscape model, identifies, by the processor, a server-side system within a server landscape that is associated with the customer-side system, and schedules, by the processor, the customer-side system and the server-side system for upgrade.

In one example, the server-side system is configured to communicate with the customer-side system.

In another example, an upgrade of the customer-side system is to an interface for communication between the customer-side system and the server-side system.

In another example, scheduling comprises determining, by the processor, a first time slot which is available to upgrade the customer-side system, determining, by the processor, a second time slot which is available to upgrade the server-side system, determining, by the processor, a period of time that overlaps between the first time slot and the second time slot; and scheduling the upgrade of the customer-side system and the server-side system during the period of time. In one example, determining the first time slot comprises executing, by the processor, a predefined boundary condition that specifies a period of downtime for the customer-side system and identifying, by the processor, the first time slot based on the execution. In another example, determining the second time slot comprises executing, by the processor, a predefined boundary condition that specifies an active period of the server-side system and identifying, by the processor, the second time slot based on the execution.

In another example, the method further comprises synchronizing a clock of the customer-side system and the server side system.

In another embodiment, a non-transitory computer readable storage medium stores one or more programs comprising instructions for receiving a landscape model describing changes to a customer landscape, the customer landscape including a plurality of customer-side systems, automatically identifying a customer-side system within the customer landscape to upgrade based on the landscape model, identifying a server-side system within a server landscape that is associated with the customer-side system, and scheduling the customer-side system and the server-side system for upgrade.

In another embodiment, a computer implemented system comprises one or more computer processors and a non-transitory computer-readable storage medium. The non-transitory computer-readable storage medium comprises instructions, that when executed, control the one or more computer processors to be configured for receiving a landscape model describing changes to a customer landscape, the customer landscape including a plurality of customer-side systems, automatically identifying a customer-side system within the customer landscape to upgrade based on the landscape model, identifying a server-side system within a server landscape that is associated with the customer-side system, and scheduling the customer-side system and the server-side system for upgrade.

DETAILED DESCRIPTION

Described herein are techniques for automatically scheduling and performing upgrades in a hybrid cloud scenario. Advantages to these techniques include revision safe system upgrades and that the process is automated, thus reducing expensive operation costs.

FIG. 1illustrates hybrid cloud scenario for upgrading systems on the service provider side and on the customer side according to one embodiment. Scenario100includes service provider landscape110which includes systems112and114. Service provider landscape110is configured to host a variety of computer systems on the service provider side. Each computer system can be configured to perform functions on the service provider side. Exemplary functions can include business functions such transferring funds within bank accounts or updating employee information. Scenario100further includes customer landscape120which includes systems122,124, and126. Similar to customer landscape110, customer landscape120is configured to host a variety of computer systems on the customer side. Each computer system can be configured to perform functions on the customer side. These functions can include a human resource system, a docketing system, a payroll system, and a benefits system. Computer systems within customer landscape120can communicate with computer systems within service provider landscape110through a business communication channel105. In one example, a payroll system within customer landscape120can communicate monthly payroll data to a financial system within the service provider. The financial system can transfer funds between bank accounts according to instructions provided by the payroll system. Since the systems in both landscapes communicate with one another, it is important that the different interfaces use to communicate within each system is shared, thus allowing systems to interoperate with one another. Each system within both landscapes can include landscape data that describes the configuration of systems within the landscape. For example, landscape data can describe a system by providing details on the system, a proxy associated with the system, or the software release version of the system. In one embodiment, the service provider side and the customer side can include multiple landscapes. For example, the service provider side can include a development, quality assurance, and production landscape. Each landscape can be sandboxed, which means that changes in one do not affect the other landscapes.

System100further includes service provider management system130. Service provider management system130is configured to manage the state of each system within service provider landscape110. Service provider management system130can process landscape data received from service provider landscape110. Service provider management system130further includes system upgrade tools135. System upgrade tools135can include tools configured to upgrade computer systems within service provider landscape110. In on embodiment, system planning tools135can recognize the changes to systems within customer landscape120due to an upgrade on the customer side. System upgrade tools135can adopt to the changes within customer systems to ensure that systems within service provider landscape120can properly interface with the upgraded systems within customer landscape120.

System100further includes customer management system140. Customer management system140is configured to manage the state of each system within customer landscape120. Customer management system130can process landscape data received from customer landscape120. Customer management system130further includes system upgrade tools135. System upgrade tools145can include tools configured to upgrade computer systems within customer landscape120. In on embodiment, system planning tools145can recognize the changes to systems within service provider landscape110due to an upgrade on the server side. In one embodiment, system upgrade tools145can notify the customer of changes that need to be made in order for customer landscape120to properly interface with service provider landscape110. In another embodiment, system upgrade tools145can automatically update software code for systems in customer landscape120to ensure that the systems can properly interface with service provider landscape110.

System100further includes service marketplace150. Service marketplace150is a system on the service provider side that is configured to automate upgrades of systems in service provider landscape110and customer landscape120. The customer can communicate with service marketplace150for the processing of system upgrades on service provider landscape110or customer landscape120. In one embodiment, service marketplace150can be utilized to model customer landscape120. Landscape modeling is the process of evaluating and upgrading one or more systems that make up customer landscape120. In another embodiment, service marketplace150can be utilized to schedule system upgrades. For example, service marketplace150can identify time slots to upgrade systems on service provider landscape110and time slots to upgrade systems on customer landscape120. Service marketplace150can also group systems so that they are upgraded at substantially the same time. Service marketplace150includes downtime planning tool155which is configured to identify time slots which are available for a system upgrade and to schedule the system upgrades. Service marketplace150can receive landscape data from service provider management system130. The landscape data can be analyzed to identify systems within customer landscape120that are to be updated and to identify time slots that would be convenient to upgrade systems within service provider landscape110.

FIG. 2illustrates a process flow for upgrading multiple landscapes according to one embodiment. Some hybrid cloud scenarios can be configured to include multiple landscapes so that different groups within the organization can be sandboxed within a landscape. As shown, process200begins at step210by upgrading the development landscape. Upgrading the development landscape can include modeling the development landscape, planning upgrades in the development landscape, scheduling when the upgrades shall be performed, and performing the upgrades. Once the development landscape has been upgrades, process200can continue to step220by upgrading the quality assurance landscape. Upgrading the quality assurance landscape can include the same or similar techniques applied when upgrading the development landscape. Once the quality assurance landscape has been upgraded, process200can continue to step230by upgrading the production landscape. Upgrading the production landscape can include the same or similar techniques applied when upgrading the development landscape. Once all three landscapes have been upgraded, process200ends.

In some embodiments, upgrading the systems in a landscape can include two processes; a preparation process where the systems to upgrade are identified and the upgrades are schedules and an execution process where the scheduled system upgrades are executed.

FIG. 3illustrates a preparation process according to one embodiment. As shown, process/s300includes steps which are performed on the customer side and steps which are performed on the service provider side. Process300can begin with the service provider collecting landscape data at step310. In one embodiment, the service provider management system130can collect landscape data from systems within service provider landscape110. For example, service provider management system can periodically query systems within service provider landscape110for landscape data associated with those systems. Service marketplace150can query service provider management system130for the landscape data or a reduced version of the landscape data. The reduced version can contain metadata that is used when upgrading systems. Other metadata that is associated with managing the systems rather than the system upgrades can remain within service provider management system130.

Process300continues with the customer utilizing the service marketplace150to model customer landscape120at320. In one embodiment, the customer can utilize an application within service marketplace150to model customer landscape120. Modeling can include evaluating the systems within customer landscape120. A customer can model customer landscape120based on the customer's specific needs.

Once modeling has been completed on customer landscape120, process300can continue with upgrade planning at step330. Upgrade planning can be performed within the service marketplace. In one embodiment, the customer can specify the systems to upgrade during the upgrade planning step. In another embodiment, service marketplace330can automatically identify customer side systems to upgrade based on the landscape model. For example, systems that have changed in the model landscape (and thus require an upgrade) and systems that depend on the changed systems can be included in the upgrades list. In one example, the upgrades list can be a stack XML file. In one embodiment, service marketplace150can automatically determine which systems are to be upgraded based on the landscape planning.

Once the customer's upgrades list has been determined, process300can continue by identifying systems on the service provider landscape110that are to be upgraded. In one embodiment, service marketplace150can automatically generate a service provider's upgrades list based on the customer's upgrades list. For example, systems within service provider landscape110that are in communication with systems in the customer's upgrades list may need to be upgraded to ensure that the interface between systems on service provider landscape110and customer landscape120can properly communicate with one another.

Once the upgrades list for both landscapes (service provider and customer) are generated, process300can continue by syncing upgrade timing at step350. In one example, service marketplace150can group systems to be upgraded. The systems to be upgraded can be grouped base on correlation of modules within the systems which are to be upgraded. In some embodiments, service marketplace150(or alternatively service provider management system130) can evaluate the systems to be upgraded and identify time slots which are available to perform the upgrades. For example, each system can have different business hours of operation. As such, each system can be upgraded during certain times during the day. In one example, a system can only be upgraded during non-business hours. In another example, the system can only be upgraded during business hours. As a result, the timing information can be generated to specify time slots in which the server-side systems can be upgraded.

Once the timing information has been generated for upgrade systems on service provider landscape110, process300can continue by preparing for the upgrade timing of upgrade systems on the customer side at360. Service marketplace150can receive customer's upgrades list and service provider's timing information. The timing information can include a selection of time slots that are available for performing each scheduled upgrade on service provider systems while the customer's upgrades list can include a list of customer systems that are scheduled for an upgrade. For each customer system to be upgraded, service marketplace150can first determine a first list of time slots which are available for upgrading the customer system. The first list can contain time slots which the customer system is offline or non-business hours, thus allowing the upgrade to be performed during downtime of the customer system. The time slots for the first list can be determined from metadata on the customer system. In some embodiments, service marketplace150can also determine a second list of one or more time slots for a service provider system is to be upgraded at substantially the same time as the customer system. The second list can be from the timing information of the service provider. Service marketplace150can prepare the upgrade timing of the customer system by correlating time slots within the first list with time slots within the second list. The correlated time slots are time slots in which the customer system and the corresponding service provider system which communicated with the customer system can be upgraded. The correlated time slots can be presented to the customer, who in turn selects one of the correlated time slots. Alternatively, service marketplace150can automatically select the earliest time slot which is available. Once the upgrade of the customer system has been selected, process300can continue by scheduling the upgrade timing for the customer at370and scheduling the upgrade timing for the service provider at380. Scheduling the upgrade timing can include communicating with the customer management system140and service provider management system130to schedule when the system upgrades will take place.

In one embodiment, service marketplace150can determine the first list of time slots according to predefined boundary conditions from the customer side. The predefined boundary conditions can provide rules which define when an upgrade can be performed on the customer side. A boundary condition can specify that an upgrade should occur during non-productive times within the customer's organization. Non-productive times can be periods of customer downtime. For example, the customer's organization may experience downtime during the holidays, weekends, and evenings. Downtime can be a period of time in which users within the customer's organization are not utilizing the customer system, thus making the period of time ideal for upgrading the customer system.

In another embodiment, service marketplace150can determine the second list of time slots according to other predefined boundary conditions from the service provider side. The predefined boundary conditions can provide rules which define when an upgrade can be performed on the service provider side. In one example, the boundary condition can specify that the upgrade should be performed during the service provider's business hours of operation. In some examples, the multiple upgrades can be clustered to reduce support efforts. Clustered system upgrades can be evaluated together to determine time slots which would satisfy the boundary conditions for each of the clustered systems. In another example, upgrades between different customers can be grouped. For instance, customers who share a similar infrastructure can be grouped together so that upgrades can be performed for similar customers at the same time.

FIG. 4illustrates an execution process according to one embodiment. Process400can be performed after execution of the preparation process described inFIG. 3. At the scheduled downtime for the customer and service provider system, the customer system and the service provider system can be upgraded at substantially the same time. Service provider management system130can perform the actions related to the service provider while customer management system140can perform the actions related to the customer. In some embodiments, service provider management system130and customer management system140can automatically begin upgrading the systems within their respective landscapes at the scheduled time.

Process400begins by upgrading the development systems at step410. During the upgrade, customer management system140can recognize changes made by the customer to the software provided by the service provider. For example, the customer can modify the software to add in additional functionality or features. At step420, customer management system140can test and make changes to the development system. For example, the additional functionality or features can be tested to ensure that they are compatible with the service provider systems. If upgrades made by the customer do not conform to certain predefined rules (such as defined interfaces between the customer and the service provider), the customer management system140can request the customer to fix these changes and adopt the new delivered software.

At substantially the same time as the customer is upgrading the development systems, the service provider can also upgrade its corresponding development systems at step415. During the upgrade, service provider management system130can recognize changes made by the customer to the software provided by the service provider and modify the software on the service provider.

Once the customer has tested and made changes to the development system, the customer can release the changes to the development system in charm. Charm is a communication channel between service provider management system130and customer management system140. Both management systems can utilize the charm communication channel to communicate changes to computer systems. Here, customer management system140can transmit development system changes to service provider management system140, which collects the changes at step440. Based on the changes received from the customer, service provider management system can in turn upgrade the QA systems at step445.

After releasing the development changes, customer management system130can upgrade the QA systems at430. Upgrading the QA system can include upgrading test suits and test cases according to the development changes. At435, customer management system140can test the QA system. If testing is unsuccessful, then the process can be repeated where the development system is tested and changes are made. This iterative process can continue until QA testing is successful. In one embodiment, the development changes can be released in each iteration to the service provide so that the service provider management system130can piecemeal upgrade the QA systems. This can result in improved turnaround time.

Once all the QA system has been successfully tested, customer management system130can release the QA changes in charm at450. The QA changes can be collected by service provider management system130at455. Lastly, customer management system140can upgrade product systems at460and service provider management system130can upgrade product systems at465.

An exemplary computer system500is illustrated inFIG. 5. Computer system510includes a bus505or other communication mechanism for communicating information, and a processor501coupled with bus505for processing information. Computer system510also includes memory502coupled to bus505for storing information and instructions to be executed by processor501, including information and instructions for performing the techniques described above, for example. This memory may also be used for storing variables or other intermediate information during execution of instructions to be executed by processor501. Possible implementations of this memory may be, but are not limited to, random access memory (RAM), read only memory (ROM), or both. A storage device503is also provided for storing information and instructions. Common forms of storage devices include, for example, a hard drive, a magnetic disk, an optical disk, a CD-ROM, a DVD, a flash memory, a USB memory card, or any other medium from which a computer can read. Storage device503may include source code, binary code, or software files for performing the techniques above, for example. Storage device and memory are both examples of computer readable mediums.

Computer system510may be coupled via bus505to a display512, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. An input device511such as a keyboard and/or mouse is coupled to bus505for communicating information and command selections from the user to processor501. The combination of these components allows the user to communicate with the system. In some systems, bus505may be divided into multiple specialized buses.

Computer system510also includes a network interface504coupled with bus505. Network interface504may provide two-way data communication between computer system510and the local network520. The network interface504may be a digital subscriber line (DSL) or a modem to provide data communication connection over a telephone line, for example. Another example of the network interface is a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links are another example. In any such implementation, network interface504sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

Computer system510can send and receive information, including messages or other interface actions, through the network interface504across a local network520, an Intranet, or the Internet530. For a local network, computer system510may communicate with a plurality of other computer machines, such as server515. Accordingly, computer system510and server computer systems represented by server515may form a cloud computing network, which may be programmed with processes described herein. In the Internet example, software components or services may reside on multiple different computer systems510or servers531-535across the network. The processes described above may be implemented on one or more servers, for example. A server531may transmit actions or messages from one component, through Internet530, local network520, and network interface504to a component on computer system510. The software components and processes described above may be implemented on any computer system and send and/or receive information across a network, for example.