Cloud infrastructure management

Abstract

A method (500) for managing a cloud infrastructure (50) includes receiving, from a user (12) of a user device (10), a cloud infrastructure modification request (20) requesting a modification of the cloud infrastructure. The cloud infrastructure modification request includes abstract configuration data (22) derived from a user interaction (24) with a graphical user interface (GUI) (14) executing on a user device. The method includes converting abstract configuration data into configuration commands (210). The configuration command describes a configuration of the cloud infrastructure. The method includes updating a configuration file (152) with a configuration command. The method includes provisioning the cloud infrastructure using the updated configuration file (152U).

Description

Technical Field

[0001] The present disclosure relates to cloud infrastructure management. Background Art

[0002] Infrastructure as Code (IaC) enables developers or operations teams to automatically manage, monitor, and provision resources instead of manually configuring cloud resources. Infrastructure as Code is sometimes referred to as programmable or software-defined infrastructure. Configuration state / manifest files are stored and versioned in source control management (SCM) such as Gitlab, and can be referred to as git operations (i.e., GitOps). Conventional user interfaces (UIs) for cloud infrastructure management typically enable developers or operations teams to manually manage, monitor, and configure cloud resources, which can be referred to as click operations (i.e., ClickOps). These click operations and UIs are effective methods for manually managing cloud resources. Summary of the invention

[0003] One aspect of the present disclosure provides a computer-implemented method performed by data processing hardware, the computer-implemented method causing the data processing hardware to perform operations for managing a cloud infrastructure. The operations include receiving a cloud infrastructure modification request from a user of a user device requesting a modification to a cloud infrastructure executed on the data processing hardware. The cloud infrastructure modification request includes abstract configuration data derived from user interaction with a graphical user interface (GUI). The operations include converting the abstract configuration data into configuration commands. The configuration commands describe a configuration of the cloud infrastructure. The operations include updating a configuration file with the configuration commands. The operations include configuring the cloud infrastructure using the updated configuration file.

[0004] Implementations of the present disclosure may include one or more of the following optional features. In some implementations, the operation also includes: after updating the configuration file with the configuration command, generating an approval request requesting a second user of the second user device to approve the update of the configuration file; and before configuring the cloud infrastructure, receiving an approval response from the second user device approving the update of the configuration file. In some of these implementations, the operation also includes: receiving a second cloud infrastructure modification request from a user of the user device requesting modification of the cloud infrastructure, wherein the second cloud infrastructure modification request includes second abstract configuration data derived from a second user interaction with a GUI executed on the user device; converting the second abstract configuration data into a second configuration command; updating the configuration file with the second configuration command; generating a second approval request requesting a second user of the second user device to approve the update of the configuration file; receiving a rejection response from the second user device rejecting the update of the configuration file; and sending a notification including the rejection response to the user device. In some of these implementations, the operations further include: receiving a second cloud infrastructure modification request from a user of the user device requesting a modification to the cloud infrastructure, the second cloud infrastructure modification request including second abstract configuration data derived from a second user interaction with a GUI executed on the user device; converting the second abstract configuration data into a second configuration command; determining a merge conflict between the second configuration command and an existing configuration command of the configuration file; and sending a notification including the merge conflict to the user device. In some of these implementations, the approval request includes a difference between the configuration file before the update is made and the configuration file after the update is made.

[0005] In some examples, the operations further include retrieving the configuration file from a source control management system before updating the configuration file with the configuration command. In some of these examples, updating the configuration file includes merging the configuration command with the configuration file using the source control management system.

[0006] Optionally, after configuring the cloud infrastructure, the operations further include: receiving updated configuration commands from a second user of a second user device; updating a configuration file with the updated configuration commands; configuring the cloud infrastructure using the configuration file; and sending a GUI update command to the user device. The GUI update command, when executed by the user device, causes the user device to display a visual element representing the updated configuration command on a GUI executed on the user device. In some of these examples, the updated configuration command is derived from an update made by the second user to a copy of the configuration file stored at the second user device. The configuration file may include infrastructure as code (IaC). In some examples, the GUI is executed on the user device. Optionally, the configuration file includes one or more cloud infrastructure specifications for the cloud infrastructure and is controlled by a source control management system.

[0007] Another aspect of the present disclosure provides a system for managing cloud infrastructure. The system includes data processing hardware and memory hardware, the memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include receiving a cloud infrastructure modification request from a user of a user device requesting modification of a cloud infrastructure executed on the data processing hardware. The cloud infrastructure modification request includes abstract configuration data derived from user interaction with a graphical user interface (GUI). The operations include converting the abstract configuration data into configuration commands. The configuration commands describe the configuration of the cloud infrastructure. The operations include updating a configuration file with the configuration commands. The operations include configuring the cloud infrastructure using the updated configuration file.

[0008] This aspect may include one or more of the following optional features. In some implementations, the operations also include: after updating the configuration file with the configuration command, generating an approval request requesting a second user of the second user device to approve the update of the configuration file; and before provisioning the cloud infrastructure, receiving an approval response from the second user device approving the update of the configuration file. In some of these implementations, the operations also include: receiving a second cloud infrastructure modification request from a user of the user device requesting modification of the cloud infrastructure, wherein the second cloud infrastructure modification request includes second abstract configuration data derived from a second user interaction with a GUI executed on the user device; converting the second abstract configuration data into a second configuration command; updating the configuration file with the second configuration command; generating a second approval request requesting a second user of the second user device to approve the update of the configuration file; receiving a rejection response from the second user device rejecting the update of the configuration file; and sending a notification including the rejection response to the user device. In some of these implementations, the operations further include: receiving a second cloud infrastructure modification request from a user of the user device requesting a modification to the cloud infrastructure, the second cloud infrastructure modification request including second abstract configuration data derived from a second user interaction with a GUI executed on the user device; converting the second abstract configuration data into a second configuration command; determining a merge conflict between the second configuration command and an existing configuration command of the configuration file; and sending a notification including the merge conflict to the user device. In some of these implementations, the approval request includes a difference between the configuration file before the update is made and the configuration file after the update is made.

[0009] In some examples, the operations further include retrieving the configuration file from a source control management system before updating the configuration file with the configuration command. In some of these examples, updating the configuration file includes merging the configuration command with the configuration file using the source control management system.

[0010] Optionally, after configuring the cloud infrastructure, the operations further include: receiving updated configuration commands from a second user of a second user device; updating a configuration file with the updated configuration commands; configuring the cloud infrastructure using the configuration file; and sending a GUI update command to the user device. The GUI update command, when executed by the user device, causes the user device to display a visual element representing the updated configuration command on a GUI executed on the user device. In some of these examples, the updated configuration command is derived from an update made by the second user to a copy of the configuration file stored at the second user device. The configuration file may include infrastructure as code (IaC). In some examples, the GUI is executed on the user device. Optionally, the configuration file includes one or more cloud infrastructure specifications for the cloud infrastructure and is controlled by a source control management system.

[0011] The details of one or more implementations of the present disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a schematic diagram of an example system for managing a cloud infrastructure.

[0013] Figure 2 yes Figure 1 Schematic diagram of exemplary components of a system.

[0014] Figure 3 is a diagram of an approval manager used to generate approval requests.

[0015] FIG. 4A to FIG. 4C is a schematic diagram of an exemplary graphical user interface (GUI) executed on a user device for managing a cloud infrastructure.

[0016] Figure 5 is a flow diagram of an example arrangement of operations of a method of managing a cloud infrastructure.

[0017] Figure 6 is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.

[0018] Like reference numbers in the various drawings indicate like elements. DETAILED DESCRIPTION

[0019] Infrastructure as code (IaC) enables developers or operations teams to automatically manage, monitor and configure resources instead of manually configuring cloud resources. Infrastructure as code is sometimes referred to as programmable or software-defined infrastructure. Configuration state / manifest files are stored and versioned in source control management (SCM) such as Gitlab, and can be referred to as git operations (i.e., GitOps). Conventional user interfaces (UIs) for cloud infrastructure management typically enable developers or operations teams to manually manage, monitor and configure cloud resources, which can be referred to as click operations (i.e., ClickOps). These click operations and UIs are effective methods for manually managing cloud resources. However, in order to manage cloud resources on a large scale and automate the deployment process, IaC is generally more desirable, and is therefore a common practice in the modern software industry. Conventionally, IaC and UI are two different tracks and cannot interoperate. Therefore, in order to implement IaC, customers usually have to invest in software engineering teams to use technology to implement IaC, which is both expensive and time-consuming.

[0020] The implementation of this paper includes a system that provides an interoperable model between ClickOps and GitOps. The system also provides a mechanism for clients or customers to implement IaC without investing in a team of software engineers. The system receives user interactions from a graphical user interface (GUI) executed on a user device and converts user actions into configuration commands. The system generates or updates configuration files with configuration commands and uses configuration files to configure or deploy cloud infrastructure. The system interfaces with a source control management system (SCMS) to provide robust approval and version control functionality without requiring users to interact directly with configuration files.

[0021] refer to Figure 1 In some implementations, the system 100 for managing the cloud infrastructure 50 includes a remote system 140 that communicates with one or more user devices 10 via a network 112. The remote system 140 can be a single computer, multiple computers, or a distributed system (e.g., a cloud environment) with scalable / elastic resources 142, including computing resources 144 (e.g., data processing hardware) and / or storage resources 146 (e.g., memory hardware). Data storage (i.e., remote storage) can be overlaid on the storage resources 146 to allow one or more of the clients (e.g., user devices 10) or computing resources 144 to scalably use the storage resources 146. The remote system 140 can execute and / or communicate with the cloud infrastructure 50.

[0022] The remote system 140 includes and / or communicates with a source control management system (SCMS) 150. The SCMS 150 provides version control (i.e., revision control, source control, source code management, etc.) of one or more configuration files 152, 152an. The configuration files 152 define the deployment and / or configuration of the cloud infrastructure 50. The configuration files 152 may include IaC and / or one or more cloud infrastructure specifications 154 (i.e., specifying the deployment / configuration of the cloud infrastructure 50). The SCMS 150 may interact with a data store 160 to store, manage, and maintain the configuration files 152.

[0023] The remote system 140 is configured to receive a cloud infrastructure modification request 20 from a user device 10 associated with a corresponding user 12 via, for example, a network 112. The user device 10 may correspond to any computing device, such as a desktop workstation, a laptop workstation, or a mobile device (i.e., a smart phone). The user device 10 includes computing resources 18 (e.g., data processing hardware) and / or storage resources 16 (e.g., memory hardware). The user 12 may construct the modification request 20 using a graphical user interface (GUI) 14 executed on the user device 10. The modification request 20 requests the remote system 140 to generate and / or update one or more configuration files 152, 152an stored at a memory (e.g., at a data storage device) in communication with the remote system. The modification request 20 may include abstract configuration data 22 derived from user interactions 24, 24a-n with the GUI 14 executed on the user device 10. For example, the user 12 interacts with the GUI 14 by adjusting a slider, selecting a button, inputting a text box, etc. The interaction represents the user 12's intention to modify the configuration or deployment of the cloud infrastructure 50. For example, the abstract configuration data 22 indicates that the user 12 requests to change the size of the deployment of the cloud infrastructure 50 via one or more user interactions 24. Notably, the abstract configuration data 22 is at a higher level (i.e., more abstract) than traditional cloud infrastructure configuration commands. For example, the GUI 14 can provide a "no-code" environment to allow the user 12 to configure the cloud infrastructure 50 without requiring technical skills required for low-level code generation or tuning.

[0024] The remote system 140 executes a cloud infrastructure manager 200 that receives the modification request 20. The cloud infrastructure manager 200 converts the abstract configuration data 22 into one or more configuration commands 210 ( Figure 2). The cloud infrastructure manager 200 updates the configuration file 152 (e.g., retrieved from the SCMS 150) with the converted configuration commands 210. The configuration file 152 represents low-level "source" code that includes the configuration commands 210 required to configure and / or provision the cloud infrastructure 50. For example, the configuration file 152 includes a YAML configuration file. Thus, the cloud infrastructure manager 200 converts abstract "high-level" intents from the user 12 (i.e., user interactions 24 when interacting with the GUI 14) into a "low-level" configuration file 152. This allows the user 12 to modify or request modifications to the cloud infrastructure 50 without requiring the technical knowledge necessary to directly generate the configuration file 152. The cloud infrastructure manager 200 can use the updated configuration files 152, 152U to provision the cloud infrastructure 50. For example, the updated configuration file 152 changes the deployment size of the cloud infrastructure 50.

[0025] Reference now Figure 2 In some implementations, the cloud infrastructure manager 200 includes a UI converter 220. The UI converter 220 receives abstract configuration data 22 derived from user interactions 24. For example, a first user 12, 12a uses a first user device 10, 10a to interact with a first GUI 14, 14a. The user device 10 may send these user interactions 24 (e.g., interactions generated by the user 12a interacting with the GUI 14a via a mouse, keyboard, touch, voice, etc.) as abstract configuration data 22 derived from the user interactions 24 to the UI converter 220.

[0026] The UI converter 220 converts the abstract configuration data 22 into one or more configuration commands 210. For example, the UI converter 220 uses a lookup table, a machine learning algorithm, or other model to generate the configuration commands 210 from the abstract configuration data. The configuration commands 210 represent the "low-level" code required to implement the additions or changes to the cloud infrastructure 50 requested by the user 12 via the user interaction 24.

[0027] In some examples, the SCM manager 300 receives the configuration command 210 from the UI converter 220. The SCM manager 300 communicates with the SCMS 150. The SCM manager 300 retrieves from the SCMS 150 any appropriate configuration files 152 that the configuration command 210 may update. For example, when the configuration command 210 modifies or adds a cloud infrastructure specification 154 of an existing configuration file 152, the SCM manager 300 retrieves the configuration file from the SCMS 150 before updating the configuration file 152. In other examples, the SCM manager 300 generates a new configuration file 152 (e.g., when the configuration command 210 does not modify an already existing configuration file 152 but requires a completely new configuration file 152). The SCM manager 300 updates the retrieved configuration file 152 with the configuration command 210 received from the UI converter 220. In some examples, updating the configuration file 152 includes merging the configuration command 210 with the configuration file 152. Merging the configuration command 210 may include adding new lines, deleting lines, and / or modifying existing lines based on the configuration command 210 and existing lines within the configuration file 152. In some examples, SCM manager 300 uses SCMS 150 to merge configuration commands 210. For example, SCM manager 300 sends a merge command to SCMS 150.

[0028] In some implementations, the user 12 interacts directly with the SCMS 150 to "manually" add, remove, or edit the configuration file 152. For example, the second user 12, 12b using the second user device 10, 10b interacts with the second GUI 14, 14b, which communicates directly with the SCMS 150 or directly communicates via the cloud infrastructure manager 200. In this case, the second user 12b interacts directly with the "low-level" code by, for example, directly modifying the configuration file 152 in a text editor or other development environment (e.g., at least partially executed locally on the second user device 10b). The SCM manager 300 can receive updated configuration commands 210, which are derived from updates made by the second user 12b to the copy of the configuration file 152 at the second user device 10b. For example, the SCM manager 300 receives these manual updates to the configuration file 152 from the SCMS 150 by the SCMS 150 "pushing" changes or the SCM manager 300 "pulling" changes. The SCM manager 300 may provide the changes (e.g., using the configuration commands 210) to the UI converter 220. The UI converter 220 may convert the configuration commands 210 generated by the second user 12b into the abstract configuration data 22. The first GUI 14a may receive the abstract configuration data from the UI converter 220 (e.g., via a GUI update command) and update the GUI 14a to reflect the changes propagated by the second user 12b. That is, the first user 12a may observe a reflection of the GUI 14 or visual elements representing the changes to the configuration file 152 generated by the second user 12b via the first GUI 14a, wherein the visual elements are displayed in an abstract manner (i.e., in a manner that is more abstract than the low-level code of the configuration file 152).

[0029] In this way, the cloud infrastructure manager 200 allows users 12 of the first GUI 14a (i.e., an abstract or "high-level" representation of the configuration file 152) and the second GUI 15b (i.e., a "low-level" representation of the configuration file 152) to collaborate and coexist. The cloud infrastructure manager 200 can update or configure the cloud infrastructure 50 based on updates made to the configuration file 152 by the second user 12b.

[0030] In some implementations, cloud infrastructure manager 200 includes infrastructure manager 240. Infrastructure manager 240 uses configuration commands 210 and / or configuration files 152 to communicate with UI translator 220 and / or SCM manager 300 to configure cloud infrastructure 50. That is, when changes to configuration files 152 (either from abstract configuration data 22 or from direct modifications to configuration files 152) require corresponding changes to cloud infrastructure 50 (i.e., configuration of various cloud infrastructure elements, such as servers, load balancers, virtual machines, etc.), infrastructure manager 240 interacts with cloud infrastructure 50 to make the necessary changes.

[0031] Reference now Figure 3 In some implementations, the SCM manager 300 includes an approval manager 310. The approval manager 310 generates an approval request 312 requesting approval of an update or addition to the configuration file 152 before the update or addition is committed to the SCMS 150. For example, when the first user 12a generates a modification request 20 ( Figure 1 and Figure 2 ), the approval manager 310 generates an approval request 312 requesting the second user 12b to approve the modification to the configuration file 152. Before provisioning the cloud infrastructure 50, the approval manager 310 receives an approval response 314, 314a from the second user 12b approving the modification to the configuration file 152. In other examples, the approval manager 310 receives a rejection response 314, 314b from the second user device 10b rejecting the modification to the configuration file 152. In these examples, the approval manager 310 sends a notification 320 to the first user device 10a (i.e., to the user 12a that generated the modification request 20) that includes the rejection response 314b or otherwise notifies the user 12a of the rejection.

[0032] The approval manager 310 may generate an approval request 312 for each approver of the modification request 20. The approval manager 310 may determine the appropriate approvers for the modification request 20 based on a variety of factors. For example, the modification request 20 may reference one or more approvers. In another example, the approval manager 310 may select the owner or other responsible party of the configuration file 152 as the approver. In yet other examples, the approval manager 310 may determine the approver from a predetermined list (e.g., an administrator) based on the requester, based on the scope of the modification request 20, etc. The approval manager 310 may always generate an approval request 312 (i.e., updates or additions to the configuration files 152 always require approval), or only a portion of the modification requests 20 may require approval (e.g., the addition of new configuration files 152 does not require approval, while modifications to existing configuration files 152 require approval).

[0033] In some examples, the SCM manager 300 determines whether there are merge conflicts 330 between the new configuration command 210 (e.g., generated from the modification request 20) and any existing configuration commands 210 of the configuration files 152. A merge conflict 330 occurs when the proposed change to the configuration file 152 is incompatible with the version of the configuration file 152 to be updated in some way. For example, a merge conflict 330 occurs when the configuration command 210 changes the deployment size of a deployment that does not exist in the configuration file 152 (e.g., because a previous modification removed the deployment). The approval manager 310 can determine whether there are merge conflicts 330 based on communication with the SCMS 150. That is, in some implementations, the SCM manager 300 determines the merge conflicts 330 (e.g., by analyzing the new configuration command 210 and the existing configuration files 152), or the SCM manager 300 relies on the SCMS 150 to determine whether there are any merge conflicts 330 (e.g., by performing a "dry-run" or test commit to the SCMS 150). In some examples, SCM manager 300 determines whether there are any merge conflicts 330 before generating any approval requests 312. In these examples, SCM manager 300 may send notification 320 to user 12 who generated modification request 20 to notify user 12 of merge conflicts 330. User 12 may be required to correct merge conflicts 330 before seeking approval for the modification.

[0034] In some implementations, merge conflicts 330 reflect only conflicts that would result in invalid configuration files 152. In other implementations, merge conflicts 330 extend to valid but undesirable configurations. For example, an organization may impose specific rules or restrictions (e.g., maximum deployment size, maximum cost, etc.). The SCM manager 300 may mark a violation of a rule or restriction as a merge conflict 330 requiring correction. In some examples, when a merge conflict 330 exists, the SCM manager 300 generates an approval request 312 and notifies the approver of the merge conflict 330.

[0035] Reference now Figure 4A, schematic 400a includes an exemplary user device 10 executing a GUI 14. Here, the GUI 14 solicits user interaction 24 from the user 12 by providing one or more input fields 410, 410an. In this example, the GUI 14 provides a slider 410a and a text box 410b, however, any type of input field (e.g., radio buttons, check boxes, list selections, drop-down boxes, voice input, etc.) can be provided. Specifically, in this example, the user 12 selects that the deployment should include 28 servers by adjusting the slider 410a via the user interaction 24. The GUI 14 can solicit any number of user interactions 24 from the user 12 to collect all the abstract configuration data 22 required to generate the modification request 20. For example, the GUI 14 solicits an identifier, user credentials (e.g., username, password, etc.), approvers, etc.

[0036] Reference now Figure 4B , schematic 400b includes another exemplary user device 10 executing a GUI 14. Here, the GUI 14 displays pending and closed modification requests 20 (i.e., “merge requests”). For example, the GUI 14 displays any number of modification statuses 412. Here, the modification status 412 includes a status 412, 412a (e.g., opened or pending, merged or completed, and / or closed or rejected), a title 412, 412b, an author 412, 412c of the modification request 20, and a reviewer 412, 412d (i.e., an approver) of the modification request 20. The GUI 14 may allow the user 12 to search, filter, and / or view details of the modification requests 20. In some implementations, the GUI 14 allows the user 12 to approve one or more modification requests 20. Here, via the user interaction 24, the user 12 may interact with an approval user input 420 (e.g., a button). The interaction with the approval user input 420 generates an approval response 314a ( Figure 3 ), thereby allowing SCM manager 300 to merge updated configuration files 152 into the repository via SCMS 150. In some examples, user 12 selects any one of modification requests 20 to obtain additional details of the corresponding modification request 20.

[0037] Reference now Figure 4C , schematic diagram 400c includes Figure 4B10 of a user device 10 executing a GUI 14. Here, the user 12 has selected a modification request 20 titled "Assignment #3," and the GUI 14 responds by displaying a detailed view of the modification request 20. The GUI 14 may provide a variety of different views (e.g., an overview view, a commit view, and a change view) with different types and levels of detail. Here, the change view includes an approval request 312 that includes a difference 430 between the configuration file 152 (i.e., the original configuration file 152) before being updated with the new configuration command 210 and the updated configuration file 152. For example, the difference highlights any added, deleted, and / or changed rows to the user 12, thereby allowing the user 12 to quickly review the specific changes to the configuration file 152 before approving, rejecting, or editing the modification request 20. After reviewing the changes to the configuration file 152, the user 12 may dispose of the modification request 20 by selecting to approve the user input 420, reject the modification request 20, or modify the modification request 20. In some implementations, user 12 modifies modification request 20 by directly editing configuration file 152 or changing other parameters of modification request 20 (e.g., changing name, changing approvers, etc.). Modified modification request 20 may require approval from another user 12 (e.g., the original author of modification request 20 or a third user 12).

[0038] Thus, in some implementations, the cloud infrastructure manager 200 automatically generates configuration changes based on one or more user actions (i.e., user interactions 24 with the GUI 14 executed on the user device 10). For example, the user 12 provides credentials to the cloud infrastructure manager 200 and then performs one or more operations on the GUI 14 (e.g., clicks a create button). This causes the user device 10 to generate a modification request 20 (e.g., to a gateway server, etc.). The cloud infrastructure manager 200 generates or updates one or more configuration files 152 in response to receiving the modification request 20. After creating or updating the configuration files 152, in some examples, the cloud infrastructure manager 200 generates a merge request for the SCMS 150 that includes the generated / updated configuration files 152.

[0039] In some examples, the cloud infrastructure manager 200 provides an approval process and source control management as a single source of truth for configuration management. For example, an administrator provides credentials to the cloud infrastructure manager 200 in order to view all modification requests 20 that have been created. In addition, with appropriate permissions, the administrator can review, approve and / or reject the modification request 20. When the administrator (or other approver) approves the modification request 20, in some examples, the cloud infrastructure manager 200 performs a "dry run" of the new or updated configuration 152. When the dry run is successful, the cloud infrastructure manager 200 can notify the SCMS 150. The SCMS 150 merges the update into, for example, a master branch of the configuration file 152. When the dry run fails, the cloud infrastructure manager 200 can instead send a notification of the failure to the user 12 via the GUI 14.

[0040] In some implementations, the cloud infrastructure manager 200 applies the configuration changes (ie, configuration synchronization). For example, after the modification request 20 is successfully merged into the main branch, the cloud infrastructure manager 200 automatically applies the generated configuration to the cloud infrastructure 50 (eg, container orchestration system).

[0041] Optionally, the user 12 creates and / or updates the cloud resources / infrastructure 50 using the GUI 14 executed on the user device 10. For example, the user 12 creates a fleet. In this example, the cloud infrastructure manager 200 automatically transforms the user action (i.e., the user interaction 24 between the user 12 and the GUI 14) into a code change in the configuration file 152. Before the configuration change is merged into the main branch of the SCMS 150, one or more other users 12 may be required to approve the configuration change. After approval (when required), the code change is merged and becomes the true source of the cloud infrastructure 50. In some examples, the cloud infrastructure manager 200 initiates a configuration synchronization pipeline before applying the configuration change. The infrastructure code (converted from the user action) can be cloned to create more cloud resources (e.g., the fleet in this example).

[0042] Figure 51 is a flow chart of an exemplary arrangement of operations of a computer-implemented method 500 for managing a cloud infrastructure. The method 500, when executed by the data processing hardware 144, causes the data processing hardware 144 to perform operations. The method 500 includes, at operation 502, receiving a cloud infrastructure modification request 20 from a user 12 of a user device 10 requesting a modification to a cloud infrastructure 50 executed on the data processing hardware 144. The cloud infrastructure modification request 20 includes abstract configuration data 22 derived from a user interaction 24 with a GUI 14 (e.g., executed on the user device 10). The method 500 includes, at operation 505, converting the abstract configuration data 22 into configuration commands 210, and updating a configuration file 152 with the configuration commands 210 at operation 506. The configuration file 152 may include one or more cloud infrastructure specifications 154 for the cloud infrastructure 50, and may be controlled by a source control management system 150. The method 500 includes, at operation 508, configuring the cloud infrastructure 50 using the updated configuration file 152U.

[0043] Figure 6 600 that can be used to implement the systems and methods described in this document. Computing device 600 is intended to represent various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers. The components shown here, their connections and relationships, and their functions are intended to be exemplary only, and are not intended to limit implementations of the inventions described and / or claimed in this document.

[0044] The computing device 600 includes a processor 610, a memory 620, a storage device 630, a high-speed interface / controller 640 connected to the memory 620 and a high-speed expansion port 650, and a low-speed interface / controller 660 connected to a low-speed bus 670 and the storage device 630. Each of the components 610, 620, 630, 640, 650, and 660 is interconnected using various buses and can be installed on a common motherboard or installed in other ways as appropriate. The processor 610 can process instructions for execution within the computing device 600, including instructions stored in the memory 620 or on the storage device 630, to display graphical information of a graphical user interface (GUI) on an external input / output device (such as a display 680 coupled to the high-speed interface 640). In other implementations, multiple processors and / or multiple buses and multiple memories and multiple types of memories can be used as appropriate. In addition, multiple computing devices 600 can be connected, each of which provides a portion of the necessary operations (for example, as a server farm, a group of blade servers, or a multi-processor system).

[0045] Memory 620 stores information non-temporarily within computing device 600. Memory 620 may be a computer-readable medium, a volatile memory unit, or a non-volatile memory unit. Non-temporary memory 620 may be a physical device for storing programs (e.g., sequences of instructions) or data (e.g., program state information) on a temporary or persistent basis for use by computing device 600. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable read-only memory (EEPROM) (e.g., typically used for firmware, such as bootloaders). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase change memory (PCM), and disk or tape.

[0046] The storage device 630 is capable of providing mass storage for the computing device 600. In some implementations, the storage device 630 is a computer-readable medium. In various implementations, the storage device 630 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device or device array (including devices in a storage area network or other configuration). In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product includes instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer or machine-readable medium, such as the memory 620, the storage device 630, or a memory on the processor 610.

[0047] The high-speed controller 640 manages bandwidth-intensive operations of the computing device 600, while the low-speed controller 660 manages less bandwidth-intensive operations. This allocation of responsibilities is exemplary only. In some implementations, the high-speed controller 640 is coupled to the memory 620, the display 680 (e.g., through a graphics processor or accelerator), and the high-speed expansion port 650 that can accept various expansion cards (not shown). In some implementations, the low-speed controller 660 is coupled to the storage device 630 and the low-speed expansion port 690. The low-speed expansion port 690, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), can be coupled to one or more input / output devices, such as a keyboard, a pointing device, a scanner, or a networking device, such as a switch or a router, for example, through a network adapter.

[0048] The computing device 600 can be implemented in many different forms, as shown. For example, the computing device can be implemented as a standard server 600a or multiple times in a group of such servers 600a, as a laptop computer 600b, or as part of a rack server system 600c.

[0049] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuitry, integrated circuit systems, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system that includes at least one programmable processor, which may be special-purpose or general-purpose, coupled to receive data and instructions from and send data and instructions to a storage system, at least one input device, and at least one output device.

[0050] A software application (i.e., software resource) may refer to computer software that enables a computing device to perform tasks. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and gaming applications.

[0051] These computer programs (also referred to as programs, software, software applications or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages ​​and / or in assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, non-transitory computer-readable medium, device and / or means (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0052] The process and logic flow described in this specification can be performed by one or more programmable processors (also referred to as data processing hardware), which execute one or more computer programs to perform functions by operating on input data and generating output. The process and logic flow can also be performed by a dedicated logic circuit system, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). For example, a processor suitable for executing a computer program includes both a general-purpose microprocessor and a special-purpose microprocessor, and any one or more processors of any kind of digital computer. Generally, the processor will receive instructions and data from a read-only memory or a random access memory or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices for storing data, such as a magnetic disk, a magneto-optical disk, or an optical disk, or be operably coupled to receive data from one or more mass storage devices or transfer data to one or more mass storage devices or both. However, a computer does not have to have such a device. Computer-readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media, and memory devices, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks; and CD ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated in special purpose logic circuitry.

[0053] To provide interaction with a user, one or more aspects of the present disclosure may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube), an LCD (liquid crystal display) monitor, or a touch screen) for displaying information to the user, and optionally a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the computer. Other kinds of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including sound, voice, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user; for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0054] A variety of implementations have been described. However, it should be understood that various modifications may be made without departing from the spirit and scope of the present disclosure. Therefore, other implementations are within the scope of the appended claims.

Claims

1. A computer-implemented method (500) executed by data processing hardware (144), characterized in that: The computer-implemented method causes the data processing hardware (144) to perform operations comprising: receiving a cloud infrastructure modification request (20) from a user (12) of a user device (10) requesting modification to a cloud infrastructure (50) executing on the data processing hardware (144), the cloud infrastructure modification request (20) comprising abstracted configuration data (22) derived from user interaction (24) with a graphical user interface (GUI) (14); converting the abstract configuration data (22) into configuration commands (210), the configuration commands (210) describing the configuration of the cloud infrastructure (50); updating a configuration file (152) with the configuration command (210); and The cloud infrastructure (50) is configured using the updated configuration file (152U).

2. The method (500) according to claim 1, characterized in that: The operations also include: After updating the configuration file (152) with the configuration command (210), generating an approval request (312) requesting a second user (12) of a second user device (10) to approve the update of the configuration file (152); and Prior to configuring the cloud infrastructure (50), an approval response (314a) is received from the second user device (10) approving the update to the configuration file (152).

3. The method (500) of claim 2, characterized in that: The operations also include: receiving a second cloud infrastructure modification request (20) from the user (12) of the user device (10) requesting modification to the cloud infrastructure (50), the second cloud infrastructure modification request (20) comprising second abstracted configuration data (22) derived from a second user interaction (24) with the GUI (14) executed on the user device (10); Converting the second abstract configuration data (22) into a second configuration command (210); Updating the configuration file (152) using the second configuration command (210); generating a second approval request (312) requesting the second user (12) of the second user device (10) to approve the update to the configuration file (152); receiving a rejection response (314b) from the second user device (10) rejecting the update of the configuration file (152); and A notification (320) including the rejection response (314b) is sent to the user device (10).

4. The method (500) of claim 2, characterized in that: The operations also include: receiving a second cloud infrastructure modification request (20) from the user (12) of the user device (10) requesting modification to the cloud infrastructure (50), the second cloud infrastructure modification request (20) comprising second abstracted configuration data (22) derived from a second user interaction (24) with the GUI (14) executed on the user device (10); Converting the second abstract configuration data (22) into a second configuration command (210); determining a merge conflict (330) between the second configuration command (210) and an existing configuration command (210) of the configuration file (152); and A notification (320) including the merge conflict (330) is sent to the user device (10).

5. The method (500) according to any one of claims 2 to 4, characterized in that: The approval request (312) includes differences between the configuration file (152) before the update is performed and the configuration file (152) after the update is performed.

6. The method (500) according to any one of claims 1 to 5, characterized in that: The operations also include retrieving the configuration file (152) from a source control management system (150) prior to updating the configuration file (152) with the configuration command (210).

7. The method (500) of claim 6, characterized in that: Updating the configuration file (152) includes using the source control management system (150) to merge the configuration commands (210) with the configuration file (152).

8. The method (500) according to any one of claims 1 to 7, characterized in that: After configuring the cloud infrastructure (50), the operations further include: receiving updated configuration commands (210) from a second user (12) of a second user device (10); updating the configuration file (152) with the updated configuration command (210); configuring the cloud infrastructure (50) using the configuration file (152); and A GUI update command is sent to the user device (10), and when executed by the user device (10), the GUI update command causes the user device (10) to display a visual element representing the updated configuration command (210) on the GUI (14) executed on the user device (10).

9. The method (500) of claim 8, characterized in that: The updated configuration commands (210) are derived from updates made by the second user (12) to a copy of the configuration file (152) stored at the second user device (10).

10. The method (500) according to any one of claims 1 to 9, characterized in that: The configuration file (152) includes Infrastructure as Code (IaC).

11. The method (500) according to any one of claims 1 to 10, characterized in that: The GUI (14) is executed on the user device (10).

12. The method (500) according to any one of claims 1 to 11, characterized in that: The configuration file (152): including one or more cloud infrastructure specifications (154) for the cloud infrastructure (50); and Controlled by the source control management system (150).

13. A system (100), characterized in that: include: Data processing hardware (144); as well as Memory hardware (146) in communication with the data processing hardware (144), the memory hardware (146) storing instructions that, when executed on the data processing hardware (144), cause the data processing hardware (144) to perform operations, the operations comprising: receiving a cloud infrastructure modification request (20) from a user (12) of a user device (10) requesting modification to a cloud infrastructure (50) executing on the data processing hardware (144), the cloud infrastructure modification request (20) comprising abstracted configuration data (22) derived from user interaction (24) with a graphical user interface (GUI) (14); converting the abstract configuration data (22) into configuration commands (210), the configuration commands (210) describing the configuration of the cloud infrastructure (50); updating a configuration file (152) with the configuration command (210); and The cloud infrastructure (50) is configured using the updated configuration file (152U).

14. The system (100) according to claim 13, characterized in that The operations also include: After updating the configuration file (152) with the configuration command (210), generating an approval request (312) requesting a second user (12) of a second user device (10) to approve the update of the configuration file (152); and Prior to configuring the cloud infrastructure (50), an approval response (314a) is received from the second user device (10) approving the update to the configuration file (152).

15. The system (100) of claim 14, wherein: The operations also include: receiving a second cloud infrastructure modification request (20) from the user (12) of the user device (10) requesting modification to the cloud infrastructure (50), the second cloud infrastructure modification request (20) comprising second abstracted configuration data (22) derived from a second user interaction (24) with the GUI (14) executed on the user device (10); Converting the second abstract configuration data (22) into a second configuration command (210); Updating the configuration file (152) using the second configuration command (210); generating a second approval request (312) requesting the second user (12) of the second user device (10) to approve the update to the configuration file (152); receiving a rejection response (314b) from the second user device (10) rejecting the update of the configuration file (152); and A notification (320) including the rejection response (314b) is sent to the user device (10).

16. The system (100) of claim 14, wherein: The operations also include: receiving a second cloud infrastructure modification request (20) from the user (12) of the user device (10) requesting modification to the cloud infrastructure (50), the second cloud infrastructure modification request (20) comprising second abstracted configuration data (22) derived from a second user interaction (24) with the GUI (14) executed on the user device (10); Converting the second abstract configuration data (22) into a second configuration command (210); determining a merge conflict (330) between the second configuration command (210) and an existing configuration command (210) of the configuration file (152); and A notification (320) including the merge conflict (330) is sent to the user device (10).

17. The system (100) according to any one of claims 14 to 16, characterized in that The approval request (312) includes differences between the configuration file (152) before the update is performed and the configuration file (152) after the update is performed.

18. The system (100) according to any one of claims 13 to 17, characterized in that The operations also include retrieving the configuration file (152) from a source control management system (150) prior to updating the configuration file (152) with the configuration command (210).

19. The system (100) of claim 18, wherein: Updating the configuration file (152) includes using the source control management system (150) to merge the configuration commands (210) with the configuration file (152).

20. The system (100) according to any one of claims 13 to 19, characterized in that After configuring the cloud infrastructure (50), the operations further include: receiving updated configuration commands (210) from a second user (12) of a second user device (10); updating the configuration file (152) with the updated configuration command (210); configuring the cloud infrastructure (50) using the configuration file (152); and A GUI update command is sent to the user device (10), and when executed by the user device (10), the GUI update command causes the user device (10) to display a visual element representing the updated configuration command (210) on the GUI (14) executed on the user device (10).

21. The system (100) of claim 20, wherein: The updated configuration commands (210) are derived from updates made by the second user (12) to a copy of the configuration file (152) stored at the second user device (10).

22. The system (100) according to any one of claims 13 to 21, characterized in that The configuration file (152) includes Infrastructure as Code (IaC).

23. The system (100) according to any one of claims 13 to 22, characterized in that The GUI (14) is executed on the user device (10).

24. The system (100) according to any one of claims 13 to 23, characterized in that The configuration file (152): including one or more cloud infrastructure specifications (154) for the cloud infrastructure (50); and Controlled by the source control management system (150).

Images