User interface technology for infrastructure orchestration services

Abstract

Techniques for providing multiple user interfaces are disclosed. A computing system may execute a declarative infrastructure provisioner. The computing system may provide declarative instructions and instruct the declarative infrastructure provisioning to deploy multiple infrastructure resources and multiple artifacts. An example user interface may provide a global view of multiple infrastructure components and artifacts. Another example user interface may provide corresponding states and change activities of multiple infrastructure components and artifacts. Yet another user interface may be provided that presents similarities and / or differences between a locally generated security plan indicating a first change to a computing environment and a remotely generated security plan indicating a second change to the computing environment.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is a non-provisional application that claims the benefit of priority under 35 U.S.C. 119(e) to the following U.S. provisional application and U.S. non-provisional application, the entire contents of which are incorporated herein by reference for all purposes: U.S. Provisional Application No. 62 / 963,456, filed on January 20, 2020, entitled “USER INTERFACE TECHNIQUES FOR ANINFRASTRUCTURE ORCHESTRATION SERVICE”; U.S. Provisional Application No. 62 / 964,596, filed on January 22, 2020, entitled “USER INTERFACE TECHNIQUES FOR AN INFRASTRUCTURE ORCHESTRATION SERVICE”; U.S. Non-provisional Application No. 17 / 001,626, filed on August 24, 2020, entitled “USER INTERFACE TECHNIQUES FOR AN INFRASTRUCTURE ORCHESTRATION SERVICE”. Background Art

[0003] Today, cloud infrastructure services utilize many individual services to provision and deploy code and configuration (separately) across many regions of the cloud infrastructure service. These tools require a lot of manual effort to use, especially considering that provisioning is generally declarative and deploying code is necessary. In addition, cloud infrastructure services will need to continue to grow as the number of service teams and regions grows. The strategy of some cloud infrastructure services to deploy to a large number of smaller regions includes per-region expenses, which may not scale well. Summary of the invention

[0004] Disclosed herein are technologies for providing one or more user interfaces. In some embodiments, a method is disclosed. The method may include executing a declarative infrastructure provider by a computing system. The method may also include supplying, by the computing system, a first set of infrastructure components based at least in part on providing a first set of declarative instructions to the declarative infrastructure provider. The method may also include deploying, by the computing system, a second set of software artifacts based at least in part on providing a second set of declarative instructions to the declarative infrastructure provider. The method may also include providing, by the computing system, a user interface presenting a plurality of user interface elements, the plurality of user interface elements identifying at least a first state associated with the first set of supplied infrastructure components and a second state associated with the second set of deployed software artifacts.

[0005] In some embodiments, a system is disclosed. The system may include one or more processors and one or more memories storing computer executable instructions that, when executed by the one or more processors, cause the system to perform operations. The operations may include executing a declarative infrastructure provider. The operations may also include supplying a first set of infrastructure components based at least in part on providing a first set of declarative instructions to the declarative infrastructure provider. The operations may also include deploying a second set of software artifacts based at least in part on providing a second set of declarative instructions to the declarative infrastructure provider. The operations may also include providing a user interface presenting a plurality of user interface elements that at least identify a first state associated with the first set of supplying infrastructure components and a second state associated with the second set of deploying software artifacts.

[0006] In some embodiments, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium may include one or more processors and one or more memories storing computer-executable instructions, which, when executed by the one or more processors, cause a computing device to perform operations. The operations may include executing a declarative infrastructure provider. The operations may also include supplying a first set of infrastructure components based at least in part on providing a first set of declarative instructions to the declarative infrastructure provider. The operations may also include deploying a second set of software artifacts based at least in part on providing a second set of declarative instructions to the declarative infrastructure provider. The operations may also include providing a user interface presenting a plurality of user interface elements, the plurality of user interface elements at least identifying a first state associated with the first set of supply infrastructure components and a second state associated with the second set of deployed software artifacts.

[0007] In some embodiments, a computer-implemented method is disclosed. The method may include providing, by a computing system, a user interface presenting a plurality of user interface elements that at least identify a first state associated with provisioning a first set of infrastructure components and a second state associated with deploying a second set of software artifacts. The first set of infrastructure is provisioned at least in part based on a declarative infrastructure provisioner, and the second set of software artifacts is provisioned at least in part based on the declarative infrastructure provisioner.

[0008] In some embodiments, a system is disclosed. The system may include one or more processors and one or more memories storing computer executable instructions that, when executed by the one or more processors, cause the system to perform operations. The operations may include providing a user interface presenting a plurality of user interface elements that at least identify a first state associated with provisioning a first set of infrastructure components and a second state associated with deploying a second set of software artifacts. The first set of infrastructure is provisioned at least in part based on a declarative infrastructure provider, and the second set of software artifacts is provisioned at least in part based on the declarative infrastructure provider.

[0009] In some embodiments, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium may include one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause a computing device to perform operations. The operations may include providing a user interface presenting a plurality of user interface elements that at least identify a first state associated with a first set of provisioning infrastructure components and a second state associated with a second set of deployed software artifacts. The first set of infrastructure is provisioned at least in part based on a declarative infrastructure provider, and the second set of software artifacts is provisioned at least in part based on the declarative infrastructure provider.

[0010] In some embodiments, a device is disclosed. The device may include components for performing the steps of any method according to embodiments of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] To easily identify the discussion of any particular element or act, the most significant digit(s) in a reference number refers to the figure number in which the element is first introduced.

[0012] Figure 1 is a block diagram of an architecture for implementing at least some elements of cloud infrastructure orchestration services according to at least one embodiment.

[0013] Figure 2 is a block diagram of an architecture for implementing at least some elements of cloud infrastructure orchestration services according to at least one embodiment.

[0014] Figure 3 is a flow diagram illustrating an example cluster in accordance with at least one embodiment.

[0015] Figure 4 is a flow diagram illustrating an example cluster in accordance with at least one embodiment.

[0016] Figure 5is a schematic diagram illustrating an example user interface in accordance with at least one embodiment.

[0017] Figure 6 is a diagram illustrating an example user interface for providing information related to a selected posting in accordance with at least one embodiment.

[0018] Figure 7 is a diagram illustrating an example user interface for viewing the status of a posting in accordance with at least one embodiment.

[0019] Figure 8 is a diagram illustrating an example user interface for viewing the status of a posting in accordance with at least one embodiment.

[0020] Fig. 9 is a diagram illustrating an example user interface depicting execution target resources of a selected execution target in accordance with at least one embodiment.

[0021] Fig.10 is a diagram illustrating an example user interface for presenting information about a selected stage of a selected release in accordance with at least one embodiment.

[0022] Fig.11 is a diagram illustrating an example user interface depicting an execution graph for illustrating an execution order for executing a set of tasks in accordance with at least one embodiment.

[0023] Fig.12 is a diagram illustrating an example user interface depicting an example UI 1200 depicting execution status associated with one or more phases of a selected release in accordance with at least one embodiment.

[0024] Fig.13 is a diagram illustrating an example user interface showing an example safety plan in accordance with at least one embodiment.

[0025] Fig.14 is a flow chart describing an example process for generating a user interface for provisioning infrastructure in accordance with at least one embodiment.

[0026] Fig.15 is a block diagram of a distributed system according to at least one embodiment.

[0027] Fig.16 is a block diagram of one or more components of a system environment according to at least one embodiment through which services provided by one or more components of an embodiment system may be provided as a cloud service.

[0028] Fig.17 is a block diagram of an example computer system in which various embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION

[0029] In some examples, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In some examples, IaaS is one of the three main categories (or subcategories) of cloud computing services. Most people think of the other main categories as Software as a Service (SaaS) and Platform as a Service (PaaS), and sometimes SaaS can be considered a broader category that covers both PaaS and IaaS, and some people even think that IaaS is a subcategory of PaaS.

[0030] In the IaaS model, a cloud computing provider may host infrastructure components (eg, servers, storage devices, network nodes (eg, hardware), deployment software, platform virtualization (eg, hypervisor layer), etc.).

[0031] In some cases, IaaS providers may also offer various services to accompany these infrastructure components (e.g., billing, monitoring, logging, security, load balancing and clustering, etc.) Therefore, since these services can be policy-driven, IaaS users may be able to implement policies that drive load balancing to maintain application availability and performance.

[0032] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet, and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create a virtual machine (VM), install an operating system (OS) in each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software into the VM. Customers can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application problems, monitoring performance, managing disaster recovery, and more.

[0033] In most cases, the cloud computing model will require the involvement of a cloud provider. A cloud provider can be, but need not be, a third-party service that specializes in providing (e.g., selling) IaaS. An entity may also choose to deploy a private cloud and become its own provider of infrastructure services.

[0034] In some examples, IaaS deployment is the process of placing a new application or new version onto a prepared application server, etc. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider, below the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Thus, the customer may be responsible for handling (OS), middleware, and / or application deployment, etc. (e.g., on a self-service virtual machine (e.g., that can be started on demand)).

[0035] In some examples, IaaS provisioning can refer to obtaining a computer or virtual host for use, and even installing required libraries or services on it. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0036] In some cases, there are two distinct problems with IaaS provisioning. First, provisioning the initial set of infrastructure before anything is running is the initial challenge. Second, once everything has been provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both of these challenges can be addressed by enabling configuration that defines the infrastructure in a declarative manner. In other words, the infrastructure (e.g., which components are required and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which resources, and how they each work together) can be described in a declarative manner. In some cases, once the topology is defined, workflows can be generated to create and / or manage the different components described in the configuration files.

[0037] In some examples, the infrastructure can have many interconnected elements. For example, there can be one or more virtual private clouds (VPCs) (e.g., a potential on-demand pool of configurable and / or shared computing resources), also referred to as a core network. In some examples, one or more security group rules that are supplied to define how to set the security of the network, and one or more virtual machines (VMs) can also be provided. Other infrastructure elements, such as load balancers, databases, etc., can also be supplied. As more and more infrastructure elements are desired and / or added, the infrastructure can evolve step by step.

[0038] As described above, one way to provision infrastructure is to describe it in a declarative manner. As such, a configuration file may be a declarative file that simply describes each of the infrastructure components described above and how they interact. A configuration file may describe the resources and associated fields required to create an element, and then may describe other elements that reference previously described elements. In some examples, a provisioning tool may then generate a workflow for creating and managing the elements described in the configuration file.

[0039] In some cases, the workflow of the provisioning tool can be configured to execute various commands. One function that can be performed is view reconciliation, in which the provisioning tool can compare a view of the current infrastructure (e.g., the expected state of the infrastructure) with how the infrastructure is actually operating. In some cases, performing the view reconciliation function can include querying various resource providers or infrastructure resources to identify which resources are actually running. Another function that the provisioning tool can perform is plan generation, in which the provisioning tool can compare the infrastructure components that are actually running with what the provisioning tool wants the state to look like (e.g., the desired configuration). In other words, the plan generation function can determine what changes need to be made to bring the resources up to the latest expectations. In some cases, a third function is an execution (e.g., apply) function, in which the provisioning tool can execute the plan generated by the plan generation function.

[0040] Generally speaking, the provisioning tool can be configured to take a configuration file, parse the declarative information included therein, and programmatically / automatically determine the order in which resources need to be provisioned to execute the plan. For example, if the VPC needs to be started before the security group rules and VMs are started, the provisioning tool will be able to make that determination and implement the startup in that order without user intervention and / or without including that information in the configuration file.

[0041] In some cases, continuous deployment techniques can be employed to enable deployment of infrastructure code across various virtual computing environments. In addition, the described techniques can enable infrastructure management in these environments. In some examples, a service team can write code that is expected to be deployed to one or more but often many different production environments (e.g., across various different geographic locations, sometimes across the entire world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some cases, provisioning can be done manually, provisioning tools can be used to provision resources, and / or deployment tools can be used to deploy code once the infrastructure has been provisioned.

[0042] As described above, there are generally two different tools for handling each of the provisioning of infrastructure resources and the deployment of code that controls the infrastructure resources, where the orchestration between the two tools is performed manually. However, at scale, the manual implementation method always leads to deviations. Therefore, an automated tool that can both provision and deploy virtual infrastructure enables a more efficient and reliable technology to implement a virtual cloud environment.

[0043] In some examples, when two tools are used, problems may occur when the user manually changes the code between the supply stage and the deployment stage. As described herein, the technology of supplying and deploying using a single tool can alleviate this situation by automating the process, so that there is no opportunity to change the manual code. It is possible that a slight change to the user's coding method may cause major problems in the deployment stage. In some examples, when an operator performs an action (e.g., a spelling error in the code) in a new area for the first time, the object encoded with the spelling error can always be like this. If the application is deployed using the spelling error, and the application is not sensitive to the spelling error (e.g., it can still work), it is possible that at some time later, additional code changes will become sensitive to the spelling error and cause the entire system to collapse. Therefore, the technology provided herein can eliminate the gap between the supply and deployment that often causes problems.

[0044] Generally speaking, modeling deployments is declarative, such that configuration files can be used to declare infrastructure resources. For example, create, read, update, delete (CRUD) instructions are generally used to generate deployment files using common representational state transfer (REST) ​​concepts (e.g., REST application programming interfaces (APIs)). However, the deployments themselves generally do not follow the same concepts. In addition, while infrastructure provisioning tools tend to be very powerful and / or expressive, tools for deployments tend to have more restrictions on the operations they can perform (e.g., they are imperative rather than declarative). Therefore, there has long been a need for tools that can handle both functional requirements (e.g., provisioning and deployment of infrastructure elements) within a cloud environment.

[0045] In some examples, this document describes techniques for implementing a cloud infrastructure orchestration service (CIOS). As briefly described above, such techniques can be configured to manage both the provisioning and deployment of infrastructure assets within a cloud environment. In some cases, CIOS can include two types of services: central and regional components (e.g., CIOS Central and CIOS Regional). The following terms will be used throughout the document:

[0046] Infrastructure components - long-lived infrastructure that supports running code.

[0047] οExample: deploying applications, load balancers, Domain Name System (DNS) entries, object storage buckets, etc.

[0048] Artifacts - Code deployed to a deployment application or Kubernetes engine cluster, or configuration information applied to infrastructure components (hereinafter referred to as "configuration"). These can be read-only resources.

[0049] Deployment tasks - short-lived tasks often associated with deploying or testing code. Additionally, deployment tasks are modeled as resources whose lifecycle does not outlive the release that created them.

[0050] ο Examples: "Deploy $artifact to $environment", "Watch $alarm for 10 minutes", "Execute $testSuite", or "Wait for $manualApproval"

[0051] o For example, CIOS may model a deployment orchestrator deployment as the creation of resources that transition to a usable state upon completion.

[0052] o Because CIOS maintains the state of its cloud infrastructure service declarative providers, CIOS can control the lifecycle of these short-lived resources associated with a release.

[0053] Resources - CRUDable resources.

[0054] οCIOS models each of the constructs listed above as a resource. The next section discusses this modeling in detail.

[0055] Flock - A model of CIOS that encapsulates the control plane and all its components. Mainly used to model and point to the ownership of infrastructure components.

[0056] Cluster configuration - describes the collection of all infrastructure components, artifacts, and deployment tasks associated with a single service.

[0057] οEach swarm has only one swarm configuration. The swarm configuration is checked into source control.

[0058] ο Cluster configurations are declarative. They expect CIOS to provide realm, region, AD and artifact version as input.

[0059] o Clusters are fine-grained - a cluster consists of a single service and supporting infrastructure.

[0060] • State - a point-in-time snapshot of the state of each resource in the swarm.

[0061] Release - A tuple of a specific version of the swarm configuration and a specific version of each artifact it references.

[0062] ο Think of a release as describing a state that may not yet exist.

[0063] Release Plan - A collection of steps that a CIOS takes to transition all regions from their current state to the state described by the release.

[0064] ο Release plans have a finite number of steps and clearly defined start and end times.

[0065] Apply - This is a noun. A single attempt to execute a release plan. Executes changes to the current state of the group.

[0066] CIOS can be described as the orchestration layer that applies configuration to downstream systems (e.g., globally). It is designed to allow infrastructure provisioning and code deployment at a global scale without requiring manual effort from service teams (e.g., beyond initial approval in some cases). High-level responsibilities of CIOS include, but are not limited to:

[0067] Provide the team with visibility into the current state of resources managed by CIOS, including any ongoing change activities.

[0068] ·Help the team plan and release new changes.

[0069] ·Coordinate activities across various downstream systems within the region to execute approved release plans without manual intervention.

[0070] ·Coordinate activities across regions / domains to execute approved release plans globally.

[0071] In some examples, CIOS handles the onboarding process by enabling teams to provide configuration information to CIOS via check-in code. In addition, CIOS can automate more things, so it is more onerous work than previous implementations. In some cases, CIOS handles pre-deployment by providing teams with the ability to automatically deploy and test code. In some cases, CIOS can handle the writing of change management (CM) policies by enabling automatic generation plans to roll out new artifacts when teams build new artifacts (e.g., globally). It can do this by checking the current state of each region and the current CIOS configuration (which can itself be an artifact). In addition, teams can check these plans and can iterate on them by changing the CIOS configuration and asking CIOS to re-plan. Once the team is satisfied with the plan, they can create a "release" that references the plan. The plan can then be marked as approved or rejected. Although teams can still write CMs, they are just pointers to CIOS plans. Therefore, teams can spend less time reasoning about plans. Plans are more accurate because they are machine-generated. The plan is almost too detailed for human consumption; however, it can be displayed via a complex user interface (UI).

[0072] In some examples, CIOS can handle the execution of CM by automating the execution of deployment plans. Once a release plan has been created and approved, engineers will no longer be involved in CM unless CIOS initiates a rollback. In some cases, this may require the team to automate currently manual tasks. In some examples, when CIOS detects a degradation in service health while executing, CIOS can handle rolling back change management (CM) by automatically generating a plan to return the group to its original (e.g., pre-release) state. In some examples, CIOS can handle deployment emergency / tactical changes by receiving a release plan scoped to a subset of regions and / or a subset of resources managed by CIOS, and then executing the plan.

[0073] In addition, CIOS can support the primitives necessary to define fully automated global deployments. For example, CIOS can measure service health by monitoring alerts and executing integration tests. CIOS can help teams quickly define rollback behavior in the event of service degradation and then automatically execute it. CIOS can automatically generate and display release plans and can track approvals. In some cases, the language used by teams to describe desired deployment behaviors can be declarative. CIOS can combine the functionality of code deployment and infrastructure configuration (e.g., provisioning) in one system. CIOS also supports flexible sequencing of components across and within regions. Teams can express sequencing via check-in configurations. Teams can programmatically call CIOS's planning and release APIs.

[0074] Figure 1 An architecture 100 is depicted to illustrate techniques for implementing at least a CIOS center 102. In some examples, the CIOS center 102 may be a service that handles "cluster" level operations. The CIOS center 102 has some responsibilities, including but not limited to:

[0075] Serves as an authentication gateway for group metadata change and publish operations.

[0076] • Store the authoritative mapping of cluster metadata to the deployment artifacts and CIOS repositories for the cluster.

[0077] ·Coordinate global releases across phases and goals.

[0078] • Synchronization to enforce policies such as "no more than one ongoing publication to the swarm at a time".

[0079] Detect changes to group configuration (configuration) and artifacts, and trigger release builds upon such changes.

[0080] In some examples, a source code version control management service (SCVMS) 104 can be configured to store authoritative group configurations, and an artifact notification service (ANS) 106 can be subscribed to by the CIOS center 102 so that the CIOS center 102 can be notified of new artifact builds. The CIOS center 102 can then map incoming changes to the affected groups and initiate a release plan where desired. In addition, in some examples, an artifact push service (APS) can be called by the CIOS center 102 before publishing to a target to ensure that any artifacts required for a successful release are present in the target's region before publishing.

[0081] In some examples, a customer (e.g., engineer) 108 can call CIOS hub 102 to CRUD groups and / or releases, and view the status of ongoing CIOS activities. Group management service 110 can include one or more APIs to manipulate groups, review / plan / approval service 112 can include CRUD APIs to create and approve plans, and view a central copy of the status of all CIOS managed resources, change monitoring service 114 can monitor SCVMS 104 for changes to group configurations, and can receive notifications from ANS 106 about changes to other artifacts, and state ingestor service 116 can create a copy of the region status in CIOS hub database (DB) 118 so that review / plan / approval 112 can expose them. In some examples, CIOS hub DB 118 can be a DB for groups, plans, and status. Group information can be authoritative; and everything else can come from an outdated copy of the data of CIOS region 120. CIOS hub 102 may be configured to provide any suitable portion and / or number of user interfaces (e.g., user interfaces 500-1300) for presenting any suitable data related to groups, releases, infrastructure components, artifacts, etc. In some embodiments, CIOS hub 102 may present data related to one or more releases via any suitable interface. A release may include any suitable combination of tasks related to one or more infrastructure components and / or one or more code changes to one or more applications (e.g., artifacts). Some examples of user interfaces provided by CIOS hub 102 are described below with respect to Figure 5-Figure 13 Give a description.

[0082] In some examples, the engineer 108 can perform an API call to the group management service 110 (e.g., through the entry agent queue 122) to create a list of groups. The protocol for making such API calls can be Hypertext Transfer Protocol Secure (HTTPS), etc. The relevant access control list (ACL) for this operation can include a local area network (LAN) 124 or other dedicated connection. For example, CIOS can manage / control network connectivity as an alternative to connecting the customer's local data center or network to CIOS using the public Internet (e.g., dedicated, leased and / or private connection). In addition, authentication and authorization (e.g., of the engineer 108) can be performed by a reservation system portal that allows users to manage machine infrastructure (e.g., reservation services). In some cases, the CIOS center 102 can use Java Database Connectivity (JDBC), etc. to store group metadata, plans and states in the center DB 118. In some examples, the ANS 106 can be configured to notify the change monitoring service 114 when a new artifact has been published. The ANS 106 can use HTTPS, and both authentication and authorization can be handled by a mutual transport layer security service. In addition, in some cases, the change monitoring service 114 can poll the SCVMS 104 for group configuration changes. This polling can be performed using a secure shell (SSH) or other protocol. Authentication for the change monitoring service 114 can be handled by the CIOS system account, and authorization can be handled by the SCVMS 104.

[0083] In some examples, the engineer 108 can use the review / plan / approval service 112 to perform one or more of the following operations. The engineer 108 can plan and / or approve by calling the CIOS center 102 to generate and approve the plan. The engineer 108 can view by calling the CIOS center 102 to view the status of the CIOS activities being carried out globally. In addition, the engineer 108 can call the CIOS center 102 to view a copy of the global CIOS management resource status. These API calls (etc.) can be executed via the HTTPS protocol or similar protocols. In addition, the relevant ACL can be controlled by the LAN 124, and both authentication and authorization can be handled by the reservation service. In some examples, the review / plan / approval service 112 can request a plan and push the plan approval to all areas of the CIOS area 120 (e.g., using HTTPS, etc.). The relevant ACL can be controlled using a security list managed by a wide area network (WAN) gateway 126. Authentication can be handled by mutual transport layer security and authorization can be handled by various identity policies. Additionally, the state ingestor service 116 can watch the working state or state changes of the CIOS regions 120 so that the CIOS can provide their central view upon request (e.g., also using HTTPS, etc.) The ACLS for this can also be handled by the WAN gateway 126, and both authentication and authorization can be handled by the mutual transport layer security service.

[0084] Figure 2 An architecture 200 is depicted to illustrate techniques for implementing at least a CIOS region 202. In some examples, the CIOS region 202 is where most of the work of declarative provisioning and planning and approval of published applications can occur. In some cases, each instance of a CIOS region 202 can have a front-facing region that can handle "execution target" level operations. It can be configured to do the following:

[0085] Handles all CIOS authentication for incoming operations from CIOS Center 102.

[0086] Enforce the rule that only one "execution" (plan / import resource / apply plan) can be in progress at a time for a given execution target.

[0087] A binary artifact store that manages declarative provisioning artifacts used for input and output during a declarative infrastructure provisioning execution. Examples of inputs are declarative infrastructure provisioning configuration files and input state files. A typical output is a final state file.

[0088] Request work from the CIOS executor and poll for the results of any given execution.

[0089] In some cases, the CIOS front end may rely on a CIOS executor 206 (also referred to herein as a "scheduler") that may handle the actual execution. In some examples, the CIOS executor operates at the "execution" level, and it may:

[0090] Tracks the pool of available worker nodes

[0091] Query incoming work requests and assign them to eligible workers when available

[0092] Track worker status and perform updates to report to clients

[0093] Detect dead nodes via the lease protocol and may fail tasks assigned to the dead nodes, depending on the task status.

[0094] Provide facilities to cancel / kill / pause / resume execution, and those can be mapped onto facilities to pass cancel / kill / resume information to worker nodes.

[0095] In some cases, CIOS executors can depend on CIOS workers, which can assign tasks to be performed to workers and provide facilities for workers to update the progress of their work. The worker service operates at the granularity of "tasks". Each worker is an agent that executes the tasks assigned to it and reports the task status and output. Each worker can:

[0096] Poll the executor worker API for assigned work items and take action to make the assigned state match its local state:

[0097] οStart a container to poll for tasks that do not exist locally

[0098] ο Kill containers, for locally running containers that have no corresponding assigned tasks

[0099] Reporting on the status of work

[0100] Stage inputs and outputs for job container execution

[0101] Launch and monitor declarative infrastructure provisioning containers to do the actual work of publishing against execution targets.

[0102] The CIOS worker can depend on the CIOS executor to poll the work of the worker endpoint from the CIOS executor and report the results to it. The worker can rely on the executor for all coordination. In addition, the CIOS worker can also depend on the CIOS region 202, where the worker service reads input from one or more APIs associated with the region front-end service and writes output to one or more APIs. Examples of inputs are configuration and startup state files and import mappings. Examples of outputs are declarative provisioning processes, output declarative provisioning state files, and import result states.

[0103] In some examples, CIOS region 202 may be a regional service for managing regional instances / deployments of CIOS. CIOS region 202 is responsible for authoritatively storing and managing plans and statistics related to a particular region. Region DB 204 may be a CIOS DB for status and plans in a particular region. This is Figure 1 The authoritative copy of the regional subset of the central DB 118 of the CIOS. Scheduler 206 can be responsible for managing worker queue capacity, assigning tasks to workers, and tracking task status. In some cases, task DB 208 is another CIOS DB for task status. The data in this DB is mainly used for operational purposes. In addition, workers 210 can be a queue of Java virtual machines (JVMs) that manage declarative provisioning images. They receive instructions from scheduler 206 and transmit the results to both scheduler 206 and CIOS region 202. CIOS container 212 can run declarative provisioning operations in its own private dock 214 container. This container does not need to contain secrets. In addition, in some examples, signing agent 216 can be configured to prevent secret leakage via declarative provisioning tools to avoid placing secrets in declarative provisioning images. Instead, CIOS can perform request signing or initiate mutual transport layer security (mTLS) services in the agent. This also makes it easier to use FIPS-compliant encryption libraries.

[0104] In some examples, the CIOS center 102 can call the CIOS region 202 to create a plan, push approvals, watch job status (service principal), and extract declarative provider status (service principal). The entry agent 218 can be configured as an ACL and various identity policies can be used for both authentication and authorization. Alternatively, in some examples, the entry agent 218 can be replaced by a load balancer configured to balance incoming load requests, plans, etc. In some cases, the CIOS region 202 can run the declarative provider by asking the scheduler 206 to do so. The worker 210 can ask the scheduler 206 what it should run and can report the status to the scheduler 206 when it is completed. In some cases, mTLS can handle both authentication and authorization for the CIOS region 202 and the worker 210. In addition, when the worker 210 needs to run the declarative provider, it performs this operation in the dock container by interacting with the local dock 214. Authentication for this stage can be handled by a local unix socket. The last step can use the dock protocol; however, HTTPS can be used for the previous steps.

[0105] In some embodiments, CIOS region 202 can be configured to provide any suitable portion and / or number of user interfaces (e.g., user interfaces 500-1300) for presenting any suitable data related to groups, releases, infrastructure components, artifacts, etc. In some embodiments, CIOS region 202 can present data related to one or more releases via any suitable interface. A release can include any suitable combination of tasks related to one or more infrastructure components and / or one or more code changes to one or more applications (e.g., artifacts). Figure 5-Figure 13 Some examples of user interfaces provided by CIOS area 202 are described.

[0106] In some examples, the CIOS container 212 enables the declarative provider to interact with the signing agent 216 (via an API), while the declarative provider thinks it is calling various CIOS services. The signing agent 216 listens on a temporary port for each call instance of the declarative provider, which only the declarative provider knows. The signing agent 216 can initiate request signing or mTLS, and can pass the call of the declarative provider to other CIOS services within the service enclave. In some cases, the signing agent 216 can also communicate with one or more public CIOS services 220. For example, the signing agent 216 will use the internal endpoints of the public service as much as possible. For services without internal endpoints, it must use the export agent 222 to reach the external endpoint. This use of the signing agent 216 cannot be used for cross-region communication; for example, the export agent whitelist in each region can only apply to the public IP range of the region. In some examples, the worker 210 can then keep the status and logs from the declarative provider in the CIOS region 202 so that they can be leaked to the CIOS center 102.

[0107] Using CIOS, there are several stages in the representative customer experience: boot process, pre-release, global release and tactical release. For the pre-release stage, the following is an example of what happens between building a new artifact and publishing the artifact to release one (e.g., R1). This should replace some or most of the current change management process. As the relevant artifacts are built, CIOS can automatically generate releases using the "latest version of everything in the group". Releases are specific versions of group configurations with specific inputs (e.g., artifact versions, domains, regions, and ads). Releases contain roll-forward plans for each region and metadata describing regional ordering. Each regional plan is a collection of operations that the declarative provider will take to implement the group configuration in the region. Teams with pre-release environments can use CIOS to automatically release and test software in the environment. Teams can configure CIOS to automatically test rollback plans. Teams will be able to check and approve releases through the CIOS UI. The team can approve some, but not all, of the regional plans in the release. If the "latest version of everything" does not produce a suitable plan, the team can ask CIOS to generate a plan for a selected artifact version.

[0108] For the global release phase, here is an example of how the team can execute tomorrow's version of today's "normal CM". Once the release is approved, CIOS pushes each approved regional plan to the corresponding region. CIOS acts independently in each region to apply the approved plan. CIOS will only execute the set of actions explicitly described in the plan for that region. Instead of "thinking independently", it will fail. The CIOS UI shows the team the progress of the execution. When manual approval is required, the CIOS UI prompts the team. If the execution fails due to CIOS or downstream service outages, then CIOS can notify the team and can prompt them to perform subsequent steps (e.g., abort, retry). CIOS does perform retries, but some downstream system outages will exceed its willingness to retry. If the execution fails due to service health degradation or test failures, then CIOS will assist the team in rolling back the group to its starting state. CIOS will notify (e.g., page) the team when it initiates an automatic rollback. The team must approve the rollback plan, and then CIOS will execute it.

[0109] For the Tactical Release phase, here’s an example of how a team might execute tomorrow’s release of “Emergency CM.” When generating a plan, a team can request that CIOS target a specific resource in several ways: by topology (e.g., domain, region, AD, etc.), by resource type (e.g., “metrics configuration only” or “deployment orchestration service deployment only,” etc.), or a combination of the above (e.g., in a decoupled fashion). Teams approve tactical releases just like global releases. CIOS orchestrates them in a similar manner. If a team needs to deploy a tactical release while there is an active global release, CIOS will stop executing the global release in the targeted region and then start executing the tactical release.

[0110] In some examples, the state of a declarative provider (e.g., traditionally a file) is the authoritative record of the set of resources managed by the declarative provider. It contains a mapping between the logical identifier of each resource from the configuration file and the actual identifier of the resource. When the declarative provider creates a resource, certain kinds of failures prevent the actual identifier from being recorded in the state. When this happens, the actual identifier no longer belongs to the declarative provider. These can be referred to as "orphaned resources".

[0111] For most resources, orphans represent a waste - the declarative provisioner starts an instance that (for example) it forgot about, but will start another instance the next time it runs. For resources with unique constraints or client-supplied identifiers, orphans prevent the declarative provisioner from making progress. For example, if the declarative provisioner created the user "nglass" and a failure orphaned it, the next run of the declarative provisioner will try to create "nglass" and fail because a user with that username already exists. In some cases, orphans are only a problem when adding new resources to the state. In some cases, the refresh behavior of the declarative provisioner can naturally recover from failures to record updates and deletions.

[0112] CIOS needs to be robust in the face of outages in downstream services or outages in the CIOS itself. Because CIOS can make full use of declarative provisioners to apply changes, this means that running declarative provisioners and maintaining declarative provisioner state should be robust. Declarative provisioners perform "small-scale" retries - enough to avoid outages that last a few minutes. For example, a cloud provider will retry for up to 30 minutes. An outage in downstream systems that lasts more than 30 minutes will cause the declarative provisioner to fail. When a declarative provisioner fails, it records all changes it successfully made in the state and then exits. In order to retry, the CIOS must re-execute the declarative provisioners. Re-executing declarative provisioners also allows the CIOS to retry if the CIOS itself fails. In some cases, the CIOS can run the following operations in a loop:

[0113] • Refresh - The declarative provider calls the GET API to retrieve a new snapshot of each resource described in its state.

[0114] • Plans - Declarative providers generate plans (concrete sets of API calls) that will achieve the desired state given the most recently refreshed current state.

[0115] • Apply - A declarative provider executes a collection of steps in a plan.

[0116] CIOS can always run all three steps when executing a declarative provisioner. The refresh operation helps to recover from any updates or deletions that were not recorded. CIOS checks the results of the planned operations and compares them to the approved release plan. If the newly generated plan contains operations that are not in the approved release plan, then CIOS may fail and the service team can be notified.

[0117] Figure 3A directed acyclic graph (DAG) 300 is depicted for illustrating an example cluster 302. For a single cluster configuration in CIOS, the progress of code / configuration from check-in to production can be described all the way from the first test deployment to the last product deployment. Internally, CIOS refers to each element in the progress as an execution target (ET). CIOS executes ETs based on the DAG 200 defined in the cluster configuration. Each ET (e.g., ET-1, ET-2, ET-3, ET-4, ET-5, ET-6, and ET-7) is roughly a copy of the service described by the cluster configuration.

[0118] Figure 4 DAG 400 is depicted for illustrating an example cluster 402. In a cluster configuration, CIOS is very opinionated about how teams express this schedule - they must model it using cloud infrastructure tenancies and regions. Teams should not use domains to model schedules. CIOS allows teams to use multiple tenancies within a domain and multiple regions within a tenancy. DAG 400 illustrates Figure 3 , expressed in terms of leases and regions. This example is for an overlay service where pre-prodET is in the prod region. The service enclave service will have unstable and stable leases in release one. In DAG 400, IAD is the regional airport code for Dulles Airport in Washington, DC, YYZ is the regional airport code for Toronto, Ontario, PHX, LHR, and FRA are the regional airport codes for Phoenix, London, and Frankfurt, respectively, and LUF and LFI are for two different air force bases.

[0119] In one embodiment, the CIOS and / or other techniques described herein are improvements to each of Terraform (a declarative provisioning tool), Tanden (a code generation tool), and Oracle Deployment Orchestrator (ODO). In addition, in some examples, the CIOS and / or other techniques described herein can be implemented using at least a portion of Terraform, Tanden, and ODO tools.

[0120] Figure 5 5. A schematic diagram of an example user interface (UI) 500 is depicted in accordance with at least one embodiment. UI 500 may include any suitable combination of infrastructure area 502, application area 504, and task area 506. UI 500 may include, for example, Figure 5 500 , or these areas may be arranged differently within UI 500 .

[0121] Infrastructure area 502 may be located at any suitable location in UI 500. Figure 5As shown in , infrastructure region 502 is positioned in the upper left corner of UI 500. Infrastructure region 502 may include infrastructure release data corresponding to any suitable number of infrastructure releases (e.g., release names, the number of execution targets to which released infrastructure components will be provisioned, one or more indicators of progress associated with executing releases, an indicator of the latest infrastructure release, etc.). As depicted, infrastructure region 502 presents infrastructure release data corresponding to six releases, which are titled "Lovable", "Excited", "Elegant", "Nuclear", "Strange", and "Aqueous". Entry 508 presents infrastructure release data corresponding to release "Lovable" and includes a percentage (e.g., 75%) and progress bar 510, each indicating that the release has been executed for 75% of the group. It should be appreciated that the percentage and progress bar 510 are example user interface elements for depicting release progress, but any suitable user interface element may be used to represent such progress (e.g., visually, textually, etc.). For example, the progress of the corresponding infrastructure release may additionally or alternatively be represented by a number, a chart, or any other suitable user interface element for displaying progress. In some embodiments, a label 512 or another suitable user interface element including an icon, a check mark, etc. may be used to identify a particular infrastructure release as the latest release. Figure 5 As depicted in , entry 508 includes a target count indicating the number of execution targets (e.g., 15) for which infrastructure components corresponding to the Lovable release are provisioned. It is contemplated that the infrastructure release data provided in each entry of infrastructure region 502 may be arranged differently and may include information corresponding to the Lovable release. Figure 5 The number of attributes depicted in the example is greater or less than the number of attributes of the infrastructure release data corresponding to each release.

[0122] In some embodiments, UI 500 may include application area 504. Application area 504 may be located in any suitable location of UI 500. Figure 5In the example depicted in , application area 504 is positioned in the upper right corner of UI 500. Application area 504 may include application release data corresponding to any suitable number of application releases (e.g., application release names, the number of execution targets to which the released software artifacts will be deployed, one or more indicators of progress associated with executing the release (e.g., deploying software artifacts), an indicator of the latest application release, etc.). As depicted, application area 504 presents application release data corresponding to six application releases, which are titled "Chuck," "Bob," "Felipe," "Asa," "Strange," and "Errol." Entry 514 presents application release data corresponding to application release "Chuck" and includes a percentage (e.g., 60%) and a progress bar 516 indicating that the release has been executed on 60% of the group. It should be appreciated that the percentage and progress bar 516 are example user interface elements for depicting application release progress, but any suitable user interface element may be used to represent such progress (e.g., visually, textually, etc.). For example, the progress of the corresponding application release may additionally or alternatively be represented by a number, a chart, or any other suitable user interface element for displaying progress. In some embodiments, a label 518 or another suitable user interface element including an icon, a check mark, etc. may be used to identify a particular infrastructure release as the latest release. Figure 5 , entry 514 includes a target count indicating the number of execution targets (e.g., 12) to which the artifacts (e.g., application code) corresponding to the Chuck release are supplied. It is contemplated that the application release data provided in each entry of the application area 504 may be arranged differently and may include more or fewer attributes of the application release data corresponding to each release.

[0123] In some embodiments, UI 500 may include a task area 506. Task area 506 may be located in any suitable location in UI 500. Figure 5, positioned toward the lower half of UI 500. Task area 506 may include target release information corresponding to each execution target of the group. Each execution target of the examples provided herein may correspond to a region. A region in the examples herein may include at least one physical location. Target release information may include an identifier of an infrastructure release, a state corresponding to the progress of infrastructure components released to the execution target provisioning infrastructure (e.g., a visual representation of the state), an identifier of an application release, a state indicating the progress of deploying artifacts (e.g., application code) corresponding to the application release (e.g., a visual representation of the state). Task area 506 may include any suitable number and combination of columns, such as an execution target column 520, an infrastructure change column 522, and / or an application change column 524. Execution target column 520 may be organized in stages, where the stages may indicate the order in which a release (e.g., a set of provisioning infrastructure components and / or a set of deployed software artifacts) is executed across execution targets. In UI 500, four stages are depicted: stage I, stage II, stage III, and stage IV. In some embodiments, stage I must be completed before the deployment enters stage II, stage II is completed before stage III, and so on. As depicted, Phase I and Phase II each include one execution target, Phase III includes 4 execution targets, and Phase IV includes 12 execution targets. Execution targets may be applied in parallel.

[0124] Each row of task area 506 can correspond to a stage and / or an execution target. For example, entry 526 can correspond to a stage (e.g., stage I) and a single execution target of the stage. Entry 528 can correspond to stage III. Entry 530 can correspond to stage IV. By default, entries corresponding to the execution targets of the stages can be hidden. Selecting an entry corresponding to a stage can cause a row corresponding to the corresponding execution target of the stage to appear. For example, entry 532 can be initially hidden and only entry 530 can be displayed. In some embodiments, once entry 530 is selected, entry 532 can be presented. Entry 532 depicts specific execution targets / areas of stage IV corresponding to infrastructure releases (e.g., "Lovable") and application releases (e.g., "Chuck").

[0125] The infrastructure change column 522 may include the name of the infrastructure release and the status of the infrastructure release for each stage or execution target. In some embodiments, a stage including more than one execution target may correspond to one or more infrastructure and / or application releases. Therefore, in some embodiments, the infrastructure change column 522 may include data indicating the number of different infrastructure releases used by the execution targets of the stage. For example, an indicator 534 may be presented to indicate that there are three different infrastructure releases to be released to the execution targets of stage IV. A status indicator 536 may also be presented in the infrastructure change column to indicate the status of each infrastructure release to each execution target of the stage. The status indicator 536 may separately indicate that the release of one or more execution targets has encountered an error, is in progress, or has been completed. Similarly, the application change column 524 may include an indicator 538 to indicate that an application release will be used for each execution target of stage IV, and includes a status indicator 540 to indicate the status of each application release for each execution target of stage IV. For an entry corresponding to a single execution target (e.g., entry 532), the infrastructure change column 522 may present the name of the infrastructure release and the status. In some embodiments, the status (e.g., "completed," "failed," "in progress," "pending review," etc.) can be displayed as Figure 5 , or the status may be presented differently. For entries corresponding to a single execution target, application change column 524 may similarly include the name of the application release (e.g., "Chuck") and the status of the application release (e.g., "Complete", "Failed", "In Progress", "Pending Review", etc.). The status displayed for the application release may be the same as or different from the status provided for the infrastructure release. In some embodiments, selecting an entry (e.g., selecting entry 542) may cause the entry to be visually modified (e.g., the background of the entry may be modified) to indicate the selection. Figure 5 An example modification corresponding to selection of item 542 is depicted in FIG. Selecting link 544 may navigate the user to Figure 6 UI 600, but other navigation actions may provide similar results.

[0126] In some embodiments, if the release fails in at least one aspect, the status of this failure can be indicated at UI 500. For example, a failure in infrastructure component provisioning is indicated at 546 and a failure in software artifact deployment is indicated at 548. In some embodiments, user input (e.g., selection of the word "failure") can be received at 546 and / or 548. In response to this user input, one or more options can be provided to the user to perform remedial actions (e.g., retrying the provisioning and / or deployment tasks corresponding to the execution target, canceling the provisioning and / or deployment tasks corresponding to the execution target, modifying the provisioning and / or deployment tasks corresponding to the execution target, etc.).

[0127] Figure 6 A schematic diagram illustrating an example UI 600 for providing information related to a selected publication in accordance with at least one embodiment is depicted. UI 600 may depict a user interface from which details of a publication may be viewed. A publication name portion 602 is displayed at the top of UI 600, but publication name portion 602 may be located at any suitable location on UI 600. As shown, publication name portion 602 may present publication data associated with a particular publication. As an example, publication data associated with publication "Excited" is depicted as including publication name 604, status 606, publication identifier 608, but more or fewer attributes of publication data may be presented. As shown, publication name 604 is "Excited", but publication name 604 may include any suitable alphanumeric identifier corresponding to the name of any suitable publication in a desired group. Status 606 may indicate a status associated with a particular publication (e.g., "Not Started", "Needs Approval", "Applying", "Failure", "Complete", etc.). Publication identifier 608 is depicted as "09879iuhku7w", but publication identifier 608 may be any suitable ID that may be unique to the relevant publication.

[0128] UI 600 may also include a status bar 610, which may include information about the status of the relevant release, such as a graph 612, a timestamp 614, and a status code 616. Similarly, a status bar 618 may include a graph 620, a timestamp 622, and a status code 624. Graphs 612 and 618 may present a series of ordered task lists. For example, each node of graphs 612 and 618 may represent a set of tasks (e.g., "1" indicates a set of 1 tasks, "9" indicates a set of 9 tasks, etc.). If more than one task is indicated in a node, the node may be intended to refer to a set of tasks to be executed in parallel. Each task may correspond to a release corresponding to a specific target. The order of the nodes (e.g., from left to right) may indicate the order in which each set of (one or more) tasks is executed. For example, a task associated with node 626 may be required to be completed before a task associated with node 628 is started. Similarly, a task associated with node 628 may be required to be completed before a task associated with node 630 is started. Each task associated with node 630 can be executed in parallel. Timestamp 614 can present a start date. In addition, timestamp 614 can present a start time corresponding to the status code "started", and an end time corresponding to the status code "completed". Status code 624 can indicate that the associated task is approved, while timestamp 622 can indicate that the start time corresponding to the task associated with node 632 can be marked as "in progress" to indicate that the task is currently being executed. It should be appreciated that status codes 616 and 624 can be any suitable status code (e.g., "approved", "in progress", "failure", "need approval", etc.) for tracking the status of the associated release.

[0129] In some embodiments, the status bar can be used to depict the order of stages. For example, the status bar 610 can correspond to a specific stage (such as stage 1), while the status bar 618 can correspond to a different stage (such as stage 2). As described above, the stage can be used to describe the order in which the stages are to be completed. As depicted, the 11 stage 1 tasks shown in the status bar 610 can be required to be completed before the 12 stage 2 tasks associated with the status bar 618 begin. It should be appreciated that additional stages other than just two stages can be used. When the information corresponding to one or more stages is presented in the case of a given current window size is too wide to be displayed, it should be appreciated that the status bar 610 can be horizontally scrollable so that the user can scroll through the various stages to view their corresponding states. In some embodiments, the status bar 610 utilizes "smart scrolling" so that if the user is utilizing an input device (e.g., a mouse) that only has vertical scrolling capabilities, the user can still scroll horizontally. For example, the user can physically scroll down using the input device and the status bar 610 will scroll to the right. If the user physically scrolls up using the input device, the status bar 610 can scroll to the left. Filters enable users to focus on impactful changes so that users are less likely to be distracted by operational noise and miss impactful changes or errors.

[0130] A phase plan section 634 may also be included in the UI 600, and as shown, the phase plan section 634 is located at the bottom of the UI 600, but it may be placed differently in the UI 600. The phase plan section 634 may include information related to the desired phase (e.g., phase 2 corresponding to the status bar 618). As shown in the UI 600, the phase plan section 634 indicates a phase title 636, a phase status 638, a number of execution targets 640, an operation summary 642, a lease column 644, a deployment progress column 646, a create, read, update, delete (CRUD) operation column 648, and a target review status column 650. The phase title 636 may include the name of the selected phase of the release depicted in the UI 600. The name may include any suitable alphanumeric identifier of any suitable length. In some embodiments, the phase status 622 may be the state of the selected release phase. As shown in the UI 600, the phase title 636 is "Phase II", and the phase status 638 is depicted as "Needs Approval". Phase status 638 may be any suitable status for the selected release phase (e.g., "Needs Approval," "In Progress," "Failed," "Completed," etc.). The number of execution targets 640, depicted as "12" in UI 600, may indicate an arbitrary number of execution targets to which the release may be deployed. Operation summary 642 may indicate the number of create, revise, update, and delete operations planned for the phase. As shown in UI 600, operation summary 642 includes four different operations (listed from left to right): create, update, delete, and read (e.g., do not change). Figure 6 , there are 20 create operations, 20 update operations, 100 delete operations, and one no-change operation. UI 600 may include any suitable number of operations or combinations of operations in operation summary 642. Operation summary 642 may include four buttons corresponding to create, revise, update, and delete. These buttons may each be used as a toggle to filter the corresponding set of operations from stage plan portion 634. For example, if the "Create" button is selected, all create operations may be filtered from stage plan portion 634. If the Create button is selected again, the create operation may not be filtered and reappear in stage plan portion 634. By default, the toggle button may be unchecked (e.g., deselected) so that no operations are filtered, but any suitable default behavior may be used.

[0131] It should be recognized that although Figure 6 Changes that fall under a particular execution goal are depicted, but in some embodiments, similar changes may be grouped together and the execution goals associated with each change may be displayed. Figure 6The corresponding phase plan can be adjusted in two ways: from execution target to change (as depicted) or from change to execution target.

[0132] Lease column 644 can be located at any suitable location on UI 600, and lease column 644 can include a list of execution target tasks, including entries corresponding to a particular set of tasks of node 632 corresponding to phase II (e.g., entry 652), and a list of applications 654 scheduled to be created, modified, or deleted during the execution of these tasks. To display the list of applications 654, the user can select option 655 to expand the list to indicate the applications (e.g., SMS agent) included in the release. As shown in UI 600, the only application currently presented is "SMS agent" 658. UI 600 can depict the modification to be made to the configuration file of the SMS agent at 659. In some embodiments, the computing system providing UI 600 can identify a previous configuration of a software artifact (e.g., SMS agent), identify a new configuration of the software artifact to be deployed, and provide an indication of the change from the previous configuration of the software artifact to the new configuration (e.g., as depicted at 659). As depicted, the modification can include deleting row 5 (indicated by 5-) and adding a new row 5 (indicated by 5+). In some embodiments, "modify" (also referred to as update) may include both delete and create. Updated create / delete may be indicated as an update operation rather than a create / delete within the CRUD operation column 648. Application list 654 may also include any other suitable applications for the selected publication.

[0133] A deployment progress column 646 may display the status of a release at the associated execution target. As shown in UI 600, the status of the execution target for the depicted release is "Applied", but any suitable status may be displayed (e.g., "Applied", "Needs Approval", "Not Started", "Completed", "Failed", etc.). A CRUD operation column 648 may include information about the operations to be performed for the associated target. The operations may include create commands, update commands, delete commands, or unchanged commands, and the operations may be applied to each execution target, each application, or any suitable software and / or hardware component. A target review status column 650 may include information about whether the operations on each entity have been reviewed. As shown in UI 600, the target review status is shown as "Reviewed", but the target review status may be any status suitable for tracking operations in the associated release.

[0134] Phase plan section 634 may also include a collection of selection options (e.g., selection option 660), which may include options for "Plan," "Status," "Log," "Approve," etc. UI 600 and corresponding data are intended to be provided when the "Plan" option is selected.

[0135] A release history section 662 may also be located on the UI 600. As shown in the UI 600, the release history section 662 is located on the left portion of the UI 600, but the release history section 662 may be located at any suitable location on the UI 600. The release history section 662 may include information about various releases within the relevant group. As depicted in the UI 600, three releases are presented: "Lovable", "Excited", and "Elegant", but any suitable number of releases may be displayed in the release history section 662. Selecting any one release from the release history section 662 may present corresponding data associated with that release for each of the UI elements 602-660 discussed above. In some embodiments, the release history section 662 may also include a change type indicator 664 (e.g., "Infrastructure", "Application", etc.), a target number indicator 666, a release timestamp 668, a roll forward option 670, and a create new release option 672. The target number 666 may indicate how many execution targets a particular release is intended to be served to. Target quantity 666 may be indicated for each particular release and may include any suitable quantity of targets for the associated release. Release timestamp 668 may include the time when the selected release was created or provisioning was completed and a status indicator (e.g., "created," "completed," etc.). Release timestamp 668 may be located at any suitable location on the associated release, or release timestamp 668 may not be present in any particular release. Roll forward option 672 enables a user to redeploy a previously rolled back configuration. Create new release option 656 may enable a user to create a new release for the selected group.

[0136] In some embodiments, the user can right-click his mouse to cause option 656 to appear. Option 656 may appear near the user's mouse cursor. Selecting option 656 may navigate the user to the Figure 8 UI 800.

[0137] It should be appreciated that the user may be provided with the ability to scroll up or down within the phase plan portion 634 to view various portions of data associated with a particular selected phase. In some embodiments, the status bar (e.g., status bar 620) of the selected phase may be highlighted and / or enlarged, indicating that its corresponding phase is selected and that the information in the phase plan portion 634 corresponds to the selected phase.

[0138] Figure 7 is a diagram illustrating an example user interface (eg, UI 700 ) for viewing the status of a posting in accordance with at least one embodiment.

[0139] Publishing status section 704 may be located at any suitable location on UI 700. As shown in UI 700, publishing status section 704 is located at the top of UI 700. Publishing status section 704 may include any suitable information related to a publication, including the status of the publication (e.g., "applied," "paused," "completed," "failed," etc.), and may include related publications (e.g., Figure 7 The publication status portion 704 may include any other suitable information for tracking the status of the relevant publication.

[0140] In at least one embodiment, UI 700 may include a phase plan portion 706. In some embodiments, the Figure 6 Selection of "status" option 702 of selection option 660 presents UI 700 including phase plan portion 706. Selection of "status" option 702 may display information regarding the status of the associated release or any other suitable information related to the status of the associated release.

[0141] In some embodiments, the phase plan section 706 may list the phases (e.g., as described above in conjunction with Figure 6 The set of execution goals corresponding to the phase II) discussed. Figure 6 as depicted in, and similarly in Figure 7 , a stage can be associated with a diagram 620 including nodes 632, 710, and 712. Each node can correspond to a set of tasks for that stage. For example, execution target task sets 714, 716, and 718 can be listed. Execution target task set 714 can correspond to node 632, execution target task set 716 can correspond to node 710, and execution target task set 718 can correspond to node 712. As shown in UI 700, execution target task set 718 has been selected, which includes ten execution targets (e.g., as indicated at both node 712 and execution target task set 718). After selecting execution target task set 718, the corresponding ten execution tasks can be presented as separate rows under execution target task set 718. As shown in FIG. Figure 7 As depicted in , each task can correspond to a specific execution target to which the release will be provisioned.

[0142] In some embodiments, a publishing options menu 720 may be provided. Upon selecting the publishing options menu 720, a number of menu options may be provided (e.g., Pause publishing (not depicted), Publishing details, Resume, Cancel publishing, etc.). In some embodiments, publishing may be paused by selecting the publishing options menu 720, and then selecting the option to pause publishing. The view of UI 700 is intended to depict the state of UI 700 after publishing has been paused. In some embodiments, a paused state may be depicted at field 722. If a user hovers over field 722, status information regarding the paused state may be displayed, as depicted at 724. The information provided at 724 may include any suitable information regarding the state of a particular stage corresponding to a particular publication.

[0143] After pausing a release, the user may again select release options menu 710 to display release details option 728, resume option 730, and cancel release option 732. Release details option 728, when selected, may display any suitable information about the associated release (e.g., release number). Resume option 712, when selected, may start the associated release deployment from the point where it was paused. Cancel release option 714, when selected, may cancel the associated release and remove the canceled release from the group.

[0144] It should be appreciated that the user may be provided with the ability to scroll up or down within the phase plan section 634 to view various portions of data related to a particular phase selected.

[0145] Figure 8 800 is a diagram illustrating an example user interface (e.g., UI 800) for viewing a log associated with a release according to at least one embodiment. In some embodiments, UI 800 including phase plan portion 634 may be responsive to a request to Figure 6 The “log” option 802 of the selection option 660 is presented. Selecting the “log” option 802 may display information about the log and / or source code of the execution target that has been selected, or provide a user interface option to access information about the log and / or source code of any suitable execution target corresponding to the selected phase (or a subsequently selected phase).

[0146] The UI 800 may include Figure 6 The stage plan section 634 of the embodiment. The execution task set 804 can be selected to display one or more tasks of the execution task set 804. The execution task set 804 can be combined with the above Figure 6 Describe and Figure 8802. In some embodiments, upon selecting to perform task set 804 (or at any suitable time), tasks 806 corresponding to providing a release at a particular execution target (e.g., London, England) may be displayed. In some embodiments, a user may expand task 806 (e.g., by selecting option 808) to view one or more logs corresponding to the execution target.

[0147] Fig. 9 An example UI 900 is depicted that depicts a selected execution target (e.g., associated with a Figure 8 The execution target resource corresponding to the execution target task 806 of the execution target task 806 can be accessed by clicking Figure 8 The UI 900 may be displayed by the name of the execution target task 806 depicted in the figure or by any other suitable method, and the UI 900 may be updated with information about the execution target corresponding to the execution target task 806 by periodic or forced refresh of the UI 900. The UI 900 may include the name 902 of the execution target and the version 904 of the group. The name 902 and the version 904 may be located at any suitable location on the UI 900, but as shown in FIG. Fig. 9 As shown in , it is located at the top of UI 900.

[0148] UI 900 may also include a resources section 906. In some embodiments, resources section 906 may indicate any suitable number of infrastructure and / or software application components associated with a particular execution target. For example, resources section 906 may include various resources, such as infrastructure components "Bob," "Carl," "DNS," indicated at 908, and software artifacts (e.g., application code) such as "Application 1," "Application 2," and "Test" indicated at 910. Each resource may indicate whether the resource is an infrastructure component (as depicted at 910) or an application (as depicted at 912). As depicted at 912 and also at 914, each resource may have accompanying information such as a resource type (e.g., "Infrastructure," "Application," etc.) and a resource count, which may be any number suitable for describing how much of each resource exists in the selected execution target. When selected, a resource may display a configuration associated with the selected resource (e.g., DNS) in box 916, as well as any other suitable information associated with the selected resource. It should be appreciated that, as depicted, UI 900 may be presented as a user interface that may be overlaid on any suitable interface (e.g., Figure 5-Figure 8 A dialog box or another suitable pop-up window on the UI 500-800).

[0149] Fig.10is a diagram illustrating an example user interface (e.g., UI 1000) for presenting information about a selected stage of a selected release in accordance with at least one embodiment. UI 1000 may include a progress bar 1002 that may include all stages or any suitable subset of stages of a selected release 1004. Although shown at the top of UI 1000, progress bar 1002 may be located at any suitable location on UI 1000. Progress bar 1002 may also include various information about each stage of the selected release 1004, including, but not limited to, stage name, number of execution targets, timestamp, approval status, stage status, and any other suitable information related to each stage of the selected release 1004. The selected stage 1006 shown in the UI is "Stable (13)", but any stage in progress bar 1002 may be selected to show relevant information about the corresponding stage. The selected stage 1006 may also include a circular progress bar 1007 that may visually track the progress of the collective task(s) of the selected stage 1006. In other words, the circular progress bar 1007 can present a visual representation of the progress corresponding to the stage. In some embodiments, the circular progress bar 1007 can pulse to indicate that the tasks of the selected stage 1002 are currently in progress. In some embodiments, the circular progress bar 1007 can include one or more green portions (e.g., indicators) and / or one or more red portions (e.g., indicators) and / or one or more white portions (e.g., indicators), each portion corresponding to a task in a set of tasks associated with the stage. In some embodiments, the green portion of the circular progress bar 1007 (e.g., a green indicator) can represent completed tasks of the selected stage 1006, and the red portion of the progress bar 1007 (e.g., a red indicator) can represent failed tasks of the selected stage 1006. The white portion of the progress bar 1007 (e.g., a white indicator) can represent tasks of the selected stage 1006 that have not yet failed or completed. The UI 1000 can also include a release history portion 1108 (e.g., Figure 6 , and the selected release 1004 can be located in the release history section 1008 of the UI 1000.

[0150] Each execution task of the stage (e.g., corresponding to the execution target of the deployment release) can be presented in the status area 1010. In some embodiments, the tasks can be displayed in the order in which they will be executed and / or in any suitable position on the UI 1000. As shown, the list of execution tasks is located at the bottom of the UI 1000. The list of tasks presented in the area 1010 can include a progress column 1012, an operation column 1014, and any other suitable information related to the listed tasks. The progress column 1012 can display the progress status (e.g., "success", "failure", "application", etc.) of each execution target in the list 1008 of execution targets. The operation column 1014 can include information about which operations can be performed for each task of the selected stage 1006 (e.g., each task corresponding to the execution target of the selected stage 1006).

[0151] Fig.11 1 is a diagram illustrating an example user interface 1100 according to at least one embodiment, the example user interface 1100 depicting an execution chart for illustrating the execution order of a set of execution tasks. Fig.10 1006). The portion corresponding to the selected stage 1102 may include a chart 1106. The chart 1106 may depict the order in which the execution tasks corresponding to the execution targets may be executed. As shown in UI 1100, the chart 1106 may include nodes 1108, 1110, and 1112. Node 1108 may be associated with an execution task corresponding to an execution target. Node 1110 may be associated with an execution task corresponding to an execution target. Node 1112 may be associated with seven execution tasks corresponding to seven execution targets. Chart 1106 depicts the execution order between each group of tasks corresponding to nodes 1108, 1110, and 1112. For example, the task associated with node 1108 may be required to be completed before the task associated with node 1110 is started. Similarly, the task associated with node 1110 may be required to be completed before the task associated with node 1112 can be executed. If a node includes more than one task, the tasks may be executed at least partially in parallel (e.g., substantially in parallel). UI 1100 may also include any suitable combination of execution tasks corresponding to any suitable number of execution targets to be executed serially or in parallel. UI 1100 may display a list of each task in the order in which the tasks are to be executed in region 1114. In some embodiments, the tasks that may be executed in parallel may be displayed in region 1114 in any suitable order.

[0152] Fig.121 is a diagram illustrating an example user interface (eg, UI 1200) depicting execution status associated with one or more stages of a selected release according to at least one embodiment. Stage 1202 can be located at a progress bar 1204 (eg, Fig.10 1200) or any other suitable location on UI 1200. Stage 1002 may include a diagram 1206 indicating a particular order in which tasks corresponding to nodes 1208 and 1210 are to be performed. As depicted in UI 1200, tasks corresponding to node 1208 may be performed before tasks corresponding to node 1210. Circular progress bar 1212 (e.g., Fig.10 The example of the circular progress bar 1007 of ) can be used for each node to indicate the status of (one or more) execution tasks of each node. As depicted by the circular progress bar 1212, the task corresponding to the node 1208 can be completed, while the task corresponding to the node 1210 can still be in progress.

[0153] UI 1200 may also include a task list 1214. When stage 1002 is selected, the execution target(s) corresponding to each task may be presented in task list 1214. As shown in UI 1200, the execution task corresponding to node 1208 may be presented in 1216.

[0154] The execution tasks corresponding to node 1210 may be presented at 1218. Thus, in some embodiments, the execution tasks may be presented in an order corresponding to the execution order of the execution tasks. States 1220 and 1222 may be presented in task list 1214. State 1220 may correspond to a textual display corresponding to the state of node 1208 and state 1222 may correspond to a textual display corresponding to the state of node 1210.

[0155] Fig.13 1 is a diagram illustrating an example user interface (eg, UI 1300) showing an example security plan according to at least one embodiment. UI 1300 may include an execution task list 1302 (eg, Fig.101300 ), which can be located at any suitable location on UI 1300, and as shown, execution task list 1302 is at the top of user interface 1300. Execution task 1302 can correspond to modifying software resources associated with the execution target from a first state to a second state. In some embodiments, as part of modifying the software resources from the first state to the second state, UI 1300 can be used to present a collection of changes to be made to the software resources. As depicted, execution task list 1302 includes execution tasks 1304 corresponding to the target (e.g., marked as "unstable"), which, when selected, can display module 1306, which, when in turn, is selected, can display module 1308 (marked as "app_deployment", as depicted), which, when selected, can display module 1310. Execution target 1304 can display any suitable number of modules and / or application deployments corresponding to execution task 1304. In an embodiment with more than one module 1306, the modules 1306 can be listed in descending order of the number of create, update, delete or unchanged operations. For example, the modules 1306-1310 can be displayed so that the modules with the most creation times can be listed at the top of the list, and the remaining task commands can be displayed in descending order according to the number of creation operations corresponding to each task. In some embodiments, the modules 1306-1310 can be organized differently (e.g., in ascending order, or in any other suitable method for organizing the modules 1306-1310). In some embodiments, when the module 1310 is selected, the UI 1300 can present a security plan log 1312, as well as any other suitable information corresponding to the task 1304.

[0156] The security plan log 1312 can be presented in any suitable location on the UI 1300, but as shown in the UI 1300, the security plan log 1310 is located in the lower right corner of the UI 1300. The security plan log can present information about changes made to the application code corresponding to the module 1310. For example, the line 1314 can depict the added code line, and the line 1316 can depict the deleted code line replaced by the line 1314. In some embodiments, the line 1312 (and / or any part of the code to be added) can be displayed with a green background or any other color background suitable for identifying one or more code lines to be added. The line 1314 (e.g., or any part of the code to be deleted) can be displayed with a red background or any other color background suitable for identifying one or more code lines to be deleted.

[0157] Using UI 1300, a user may be enabled to view each planned code change for each part of a task.

[0158] Fig.14 An example flow chart of a process 1400 illustrating techniques for implementing CIOS according to certain embodiments of the present disclosure is illustrated. This process is illustrated as a logical flow chart, each operation of which can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation can represent a computer executable instruction stored on one or more computer-readable storage media, which, when executed by one or more processors, performs the described operation. In general, computer executable instructions include routines, programs, objects, components, data structures, etc. that perform specific functions or implement specific data types. The order in which the operations are described is not intended to be interpreted as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0159] In addition, the process can be executed under the control of one or more computing devices or computer systems configured with executable instructions, and can be implemented as a code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors by hardware or a combination thereof. As described above, the code can be stored on a computer-readable storage medium, for example, in the form of a computer program including multiple instructions that can be executed by one or more processors. In some embodiments, process 1400 can be executed in parallel by multiple processors. The computer-readable storage medium can be non-transitory.

[0160] Process 1400 may begin at block 1402, where a computing system executes a declarative infrastructure provisioner (e.g., Figure 2 CIOS area 202). As described above Figure 2 As discussed, a declarative infrastructure provider such as CIOS region 202 can provision resources using declarative files that describe components and how they interact. The configuration file can describe the resources and related fields required to create an element, and then can describe other elements that reference previously described elements. In some examples, the provisioning tool can then generate workflows for creating and managing the elements described in the configuration file. In some embodiments, the declarative infrastructure provider can utilize declarative statements formatted according to Terraform, which is a tool for building, changing, and versioning infrastructure components.

[0161] Process 1400 may continue to block 1404 where the computing system provisions a first set of infrastructure components.The first set of infrastructure components may be based at least in part on the computing system providing a first set of declarative instructions to a declarative infrastructure provisioner.

[0162] Process 1400 may continue to block 1406 where the computing system deploys a second set of software artifacts. The second set of software artifacts may be based at least in part on the computing system providing a second set of declarative instructions to the declarative infrastructure provider.

[0163] Process 1400 may continue to block 1408, where the computing system provides a set of presentation user interface elements (eg, Figure 5 The user interface element may at least identify a first state associated with provisioning a first set of infrastructure components (e.g., progress bar 510) and a second state associated with deploying a second set of software artifacts (e.g., progress bar 516).

[0164] It should be appreciated that the computing system may be configured to provide any suitable interface, such as the Figure 5-Figure 13 User interface 500-1300.

[0165] Descriptive System

[0166] Figure 15-17 Illustrated are aspects of an example environment for implementing aspects of the disclosure in accordance with various embodiments. Fig.15 A simplified diagram of a distributed system 1500 for implementing an embodiment of the present disclosure is depicted. In the illustrated embodiment, the distributed system 1500 includes one or more client computing devices 1502, 1504, 1506, and 1508 that are configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), etc., over a network(s) 1510. A server 1512 may be communicatively coupled to the remote client computing devices 1502, 1504, 1506, and 1508 via the network 1510.

[0167] In various embodiments, server 1512 may be adapted to run one or more services or software applications, such as services and applications that provide identity management services. In certain embodiments, server 1512 may also provide other services, or software applications may include non-virtual and virtual environments. In some embodiments, these services may be provided to users of client computing devices 1502, 1504, 1506, and / or 1508 as web-based services or cloud services or under a software as a service (SaaS) model. Users operating client computing devices 1502, 1504, 1506, and / or 1508 may then interact with server 1512 using one or more client applications to utilize the services provided by these components.

[0168] exist Fig.15In the depicted configuration, software components 1518, 1520, and 1522 of system 1500 are shown as being implemented on server 1512. In other embodiments, one or more components of system 1500 and / or the services provided by these components may also be implemented by one or more of client computing devices 1502, 1504, 1506, and / or 1508. Users operating the client computing devices may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that a variety of different system configurations are possible, which may differ from distributed system 1500. Thus, Fig.15 The embodiment shown in is one example of a distributed system for implementing an embodiment system and is not intended to be limiting.

[0169] Client computing devices 1502, 1504, 1506, and / or 1508 may include various types of computing systems. For example, a client computing device may include a portable handheld device (e.g., Cellular phone, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head mounted display) that runs a computer such as Microsoft Windows The client computing device may also include a general-purpose personal computer, including, for example, a computer running various versions of Microsoft Apple The client computing device can be a personal computer and / or laptop computer running any of a variety of commercially available or a workstation computer running a UNIX-like operating system (including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS). Client computing devices may also include electronic devices capable of communicating over network(s) 1510 (such as thin client computers, Internet-enabled gaming systems (e.g., with or without Gesture Input Devices Microsoft gaming console) and / or personal messaging device).

[0170] Although Fig.15The distributed system 1500 in FIG. 1 is shown with four client computing devices, but any number of client computing devices may be supported. Other devices (such as devices with sensors, etc.) may interact with the server 1512 .

[0171] The network(s) 1510 in the distributed system 1500 may be any type of network(s) familiar to those skilled in the art that may support data communications using any of a variety of available protocols, including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internetwork Packet Exchange), AppleTalk, etc. Merely by way of example, the network(s) 1510 may be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network, the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., in any of the Institute of Electrical and Electronics Engineers (IEEE) 1002.11 protocol suites, and / or any other wireless protocol operating under the network) and / or any combination of these and / or other networks.

[0172] Server 1512 may include one or more general-purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, Server 1512 may include one or more virtual machines running virtual operating systems, or other computing architectures involving virtualization. One or more flexible logical storage device pools may be virtualized to maintain virtual storage devices for servers. Virtual networks may be controlled by server 1512 using software-defined networking. In various embodiments, server 1512 may be suitable for running one or more services or software applications described in the foregoing disclosure. For example, server 1512 may correspond to a server for performing processing as described above according to an embodiment of the present disclosure.

[0173] Server 1512 may run an operating system including any of the operating systems discussed above, as well as any commercially available server operating system. Server 1512 may also run any of a variety of additional server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Servers, database servers, etc. Exemplary database servers include, but are not limited to, database servers commercially available from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0174] In some implementations, server 1512 may include one or more applications to analyze and integrate data feeds and / or event updates received from users of client computing devices 1502, 1504, 1506, and 1508. By way of example, data feeds and / or event updates may include, but are not limited to, data received from one or more third-party information sources and continuous data streams. feed, Updates or real-time updates, which may include real-time events related to sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc. Server 1512 may also include one or more applications that display data feeds and / or real-time events via one or more display devices of client computing devices 1502, 1504, 1506, and 1508.

[0175] Distributed system 1500 may also include one or more databases 1514 and 1516. These databases may provide a mechanism for storing information (such as user identity information and other information used by embodiments of the present disclosure). Databases 1514 and 1516 may reside in various locations. For example, one or more of databases 1514 and 1516 may reside on a non-transient storage medium local to server 1512 (and / or residing in server 1512). Alternatively, databases 1514 and 1516 may be remote from server 1512 and communicate with server 1512 via a network-based or dedicated connection. In one set of embodiments, databases 1514 and 1516 may reside in a storage area network (SAN). Similarly, any necessary files for performing functions attributed to server 1512 may be appropriately stored locally on server 1512 and / or remotely stored. In one set of embodiments, databases 1514 and 1516 may include a relational database suitable for storing, updating, and retrieving data in response to SQL formatted commands, such as a database provided by Oracle.

[0176] Fig.16 An example computer system 1600 that can be used to implement embodiments of the present disclosure is illustrated. In some embodiments, computer system 1600 can be used to implement any of the various servers and computer systems described above. Fig.16As shown in FIG. 1 , computer system 1600 includes various subsystems, including a processing subsystem 1604 that communicates with a plurality of peripheral subsystems via a bus subsystem 1602. These peripheral subsystems may include a processing acceleration unit 1606, an I / O subsystem 1608, a storage subsystem 1618, and a communication subsystem 1624. The storage subsystem 1618 may include a tangible computer-readable storage medium 1622 and a system memory 1610.

[0177] The bus subsystem 1602 provides a mechanism for allowing the various components and subsystems of the computer system 1600 to communicate with each other as expected. Although the bus subsystem 1602 is schematically shown as a single bus, alternative embodiments of the bus subsystem can utilize multiple buses. The bus subsystem 1602 can be any type of bus structure in several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any bus architecture in a variety of bus architectures. For example, such architectures can include an industry standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standard association (VESA) local bus, and a peripheral component interconnect (PCI) bus, which can be implemented as a mezzanine bus manufactured according to the IEEE P1386.1 standard, etc.

[0178] The processing subsystem 1604 controls the operation of the computer system 1600 and may include one or more processing units 1632, 1634, etc. The processing unit may include one or more processors, including a single-core or multi-core processor, one or more cores of a processor, or a combination thereof. In some embodiments, the processing subsystem 1604 may include one or more special-purpose coprocessors, such as a graphics processor, a digital signal processor (DSP), etc. In some embodiments, some or all of the processing units of the processing subsystem 1604 may be implemented using custom circuits, such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA).

[0179] In some embodiments, the processing unit in the processing subsystem 1604 can execute instructions stored in the system memory 1610 or on the computer-readable storage medium 1622. In various embodiments, the processing unit can execute various program or code instructions and can maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed may reside in the system memory 1610 and / or on the computer-readable storage medium 1610, including potentially on one or more storage devices. Through appropriate programming, the processing subsystem 1604 can provide the various functions described above for dynamically modifying documents (e.g., web pages) in response to usage patterns.

[0180] In certain embodiments, a processing acceleration unit 1606 may be provided for performing custom processing or for offloading some of the processing performed by the processing subsystem 1604 in order to speed up the overall processing performed by the computer system 1600 .

[0181] I / O subsystem 1608 may include devices and mechanisms for inputting information into computer system 1600 and / or for outputting information from or via computer system 1600. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into computer system 1600. User interface input devices may include, for example, a keyboard, a pointing device such as a mouse or trackball, a touch pad or touch screen incorporated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices, such as Microsoft Windows, which enable a user to control and interact with input devices. Motion Sensor, Microsoft Game controllers, devices that provide an interface for receiving input using gestures and voice commands. User interface input devices may also include eye gesture recognition devices, such as detecting a user's eye activity (e.g., "blinking" when taking a picture and / or making a menu selection) and translating eye gestures into input devices (e.g., Google ) In addition, the user interface input device may include a user interface that enables the user to communicate with the voice recognition system (e.g., Navigator) for interacting with a voice recognition sensing device.

[0182] Other examples of user interface input devices include, but are not limited to, three-dimensional (3D) mouse, joystick or pointing rod, game controller and graphics tablet, and audio / video equipment, such as loudspeaker, digital camera, digital camcorder, portable media player, webcam, image scanner, fingerprint scanner, bar code reader 3D scanner, 3D printer, laser rangefinder and eye tracking device. In addition, user interface input devices can include, for example, medical imaging input devices, such as computer tomography, magnetic resonance imaging, position emission tomography, medical ultrasound examination equipment. User interface input devices can also include, for example, audio input devices, such as MIDI keyboard, digital musical instrument etc.

[0183] The user interface output device may include a display subsystem, indicator lights, or non-visual displays (such as audio output devices), etc. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1600 to a user or other computers. For example, the user interface output device may include, but is not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0184] Storage subsystem 1618 provides a repository or data repository for storing information used by computer system 1600. Storage subsystem 1618 provides a tangible, non-transitory computer-readable storage medium for storing basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provide the above functionality when executed by processing subsystem 1604 can be stored in storage subsystem 1618. The software can be executed by one or more processing units of processing subsystem 1604. Storage subsystem 1618 can also provide a repository for storing data used in accordance with the present disclosure.

[0185] The storage subsystem 1618 may include one or more non-transitory memory devices, including volatile and non-volatile memory devices. Fig.16 As shown in , the storage subsystem 1618 includes a system memory 1610 and a computer-readable storage medium 1622. The system memory 1610 may include multiple memories, including a volatile main random access memory (RAM) for storing instructions and data during program execution and a non-volatile read-only memory (ROM) or flash memory in which fixed instructions are stored. In some embodiments, a basic input / output system (BIOS) containing basic routines that help transfer information between elements within the computer system 1600 (such as during startup) can be stored in ROM. The RAM can contain data and / or program modules currently operated and executed by the processing subsystem 1604. In some embodiments, the system memory 1610 may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0186] By way of example and not limitation, Fig.16As depicted in FIG. 1 , system memory 1610 may store application programs 1612, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 1614, and operating system 1616. For example, operating system 1616 may include various versions of Microsoft Apple and / or Linux operating systems, various commercially available or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or mobile operating systems (such as iOS, Phone, OS, OS and OS operating system).

[0187] Computer-readable storage media 1622 may store programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by processing subsystem 1604, provide the above-described functionality may be stored in storage subsystem 1618. By way of example, computer-readable storage media 1622 may include non-volatile memory, such as a hard drive, a magnetic disk drive, an optical disk drive (such as a CD ROM, DVD, disk or other optical media). Computer readable storage media 1622 may include, but is not limited to, The computer readable storage medium 1622 may include a solid-state drive (SSD) based on non-volatile memory (such as a flash-based SSD, an enterprise-class flash drive, a solid-state ROM, etc.), an SSD based on volatile memory (such as solid-state RAM, dynamic RAM, static RAM), a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using a flash-based and DRAM-based SSD. The computer readable medium 1622 may provide storage for computer readable instructions, data structures, program modules, and other data for the computer system 1600.

[0188] In certain embodiments, storage subsystem 1600 may also include a computer-readable storage media reader 1620 that may be further connected to computer-readable storage media 1622. Together with and optionally in conjunction with system memory 1610, computer-readable storage media 1622 may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for storing computer-readable information.

[0189] In certain embodiments, computer system 1600 can provide support for executing one or more virtual machines. Computer system 1600 can execute programs such as hypervisors to facilitate the configuration and management of virtual machines. Each virtual machine can be allocated memory, computers (e.g., processors, cores), I / O and networking resources. Each virtual machine can run its own operating system, which can be the same or different from the operating system executed by other virtual machines executed by computer system 1600. Thus, computer system 1600 can potentially run multiple operating systems simultaneously. Each virtual machine generally runs independently of other virtual machines.

[0190] The communication subsystem 1624 provides an interface to other computer systems and networks. The communication subsystem 1624 serves as an interface for receiving data from other systems and transmitting data from the computer system 1600 to other systems. For example, the communication subsystem 1624 can enable the computer system 1600 to establish a communication channel to one or more client devices via the Internet for receiving information from the client devices and sending information to the client devices. In addition, the communication subsystem 1624 can be used to transmit a notification of a successful login or a notification of a password re-entry from the privileged account manager to the requesting user.

[0191] The communication subsystem 1624 can support both wired and / or wireless communication protocols. For example, in some embodiments, the communication subsystem 1624 may include a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular telephone technology, advanced data network technology (such as 3G, 4G or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 family of standards, or other mobile communication technologies, or any combination thereof)), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communication subsystem 1624 can provide a wired network connection (e.g., Ethernet) as a supplement or alternative to a wireless interface.

[0192] The communication subsystem 1624 may receive and transmit data in various forms. For example, in some embodiments, the communication subsystem 1624 may receive input communications in the form of structured and / or unstructured data feeds 1626, event streams 1628, event updates 1630, etc. For example, the communication subsystem 1624 may be configured to receive (or send) in real time from social media networks and / or other communication services (such as feed, A data feed 1626 of updates, a user of a web feed (such as a Rich Site Summary (RSS) feed), and / or real-time updates from one or more third-party information sources.

[0193] In some embodiments, the communication subsystem 1624 can be configured to receive data in the form of a continuous data stream, which can include an event stream 1628 of real-time events and / or event updates 1630, which can be continuous or unbounded in nature without a clear end. Examples of applications that generate continuous data can include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0194] The communication subsystem 1624 may also be configured to output structured and / or unstructured data feeds 1626 , event streams 1628 , event updates 1630 , etc. to one or more databases that may be in computer communication with one or more streaming data source computers coupled to the computer system 1600 .

[0195] Computer system 1600 may be one of various types, including a handheld portable device (e.g., Cellular phone, computing tablets, PDAs), wearable devices (e.g., Google head mounted display), personal computer, workstation, mainframe, kiosk, server rack, or any other data processing system.

[0196] Due to the ever-changing nature of computers and networks, Fig.16 The description of computer system 1600 depicted in FIG. 1 is intended only as a specific example. Fig.16 Many other configurations are possible with more or fewer components than the system depicted in FIG. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will recognize other ways and / or methods to implement the various embodiments.

[0197] The systems depicted in some of the figures may be provided in various configurations. In some embodiments, the system may be configured as a distributed system, where one or more components of the system are distributed across one or more networks in one or more cloud infrastructure systems.

[0198] A cloud infrastructure system is a collection of one or more server computing devices, network devices, and / or storage devices. These resources can be divided by a cloud service provider and allocated to its customers in some way. For example, a cloud service provider (such as Oracle Corporation of Redwood Shores, California) can provide various types of cloud services, including but not limited to one or more services provided under the category of Software as a Service (SaaS), services provided under the category of Platform as a Service (PaaS), services provided under the category of Infrastructure as a Service (IaaS), or services of other categories including hybrid services. Examples of SaaS services include but are not limited to the ability to build and deliver a set of on-demand applications (such as Oracle Fusion applications). SaaS services enable customers to utilize applications executed on cloud infrastructure systems without requiring customers to purchase software for applications. Examples of PaaS services include but are not limited to services that enable organizations (such as Oracle) to integrate existing applications on a shared public architecture, and the ability to build new applications that fully utilize shared services provided by the platform (such as Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.). IaaS services can help manage and control underlying computing resources, such as storage, network, and other basic computing resources, for allowing customers to utilize services provided by SaaS platforms and PaaS platforms.

[0199] Fig.17 1700 is a simplified block diagram of one or more components of a system environment 1700 according to an embodiment of the present disclosure, through which services provided by one or more components of the embodiment system can be provided as cloud services. In the illustrated embodiment, the system environment 1700 includes one or more client computing devices 1704, 1706, and 1708, which can be used by users to interact with a cloud infrastructure system 1702 that provides cloud services. The client computing devices can be configured to operate client applications, such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application, that can be used by users of the client computing devices to interact with the cloud infrastructure system 1702 to use the services provided by the cloud infrastructure system 1702.

[0200] It should be appreciated that the cloud infrastructure system 1702 depicted in the figure may have other components in addition to those depicted. In addition, the embodiment shown in the figure is only one example of a cloud infrastructure system that can be combined with embodiments of the present disclosure. In some other embodiments, the cloud infrastructure system 1702 may have more or fewer components than shown in the figure, may combine two or more components, or may have a different configuration or arrangement of components.

[0201] Client computing devices 1704 , 1706 , and 1708 may be devices similar to those described above for client computing devices 1502 , 1504 , 1506 , and 1508 .

[0202] Although an example system environment 1700 with three client computing devices is shown, any number of client computing devices can be supported. Other devices such as devices with sensors and the like can interact with the cloud infrastructure system 1702 .

[0203] Network(s) 1710 can facilitate data communications and exchanges between clients 1704, 1706, and 1708 and cloud infrastructure system 1702. Each network can be any type of network(s) familiar to those skilled in the art that can support data communications using any of a variety of commercially available protocols, including those described above for network(s) 1510.

[0204] Cloud infrastructure system 1702 may include one or more computers and / or servers, which may include those described above with respect to server 1512 .

[0205] In some embodiments, the services provided by the cloud infrastructure system may include a large number of services available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. The services provided by the cloud infrastructure system can be dynamically expanded to meet the needs of its users. The specific instantiation of the services provided by the cloud infrastructure system is referred to as a "service instance" in this article. In general, any service that is made available to users from a cloud service provider's system via a communication network (such as the Internet) is referred to as a "cloud service." In a public cloud environment, the servers and systems that make up the cloud service provider's system are different from the consumer's own local servers and systems. For example, a cloud service provider's system can host applications, and users can order and use applications on demand via a communication network such as the Internet.

[0206] In some examples, services in a computer network cloud infrastructure may include protected computer network access to storage devices, hosted databases, hosted web servers, software applications, or other services provided by a cloud provider to users, or as otherwise known in the art. For example, a service may include password-protected access to remote storage on the cloud over the Internet. As another example, a service may include a hosted relational database and scripting language middleware engine based on a web service for private use by networked developers. As another example, a service may include access to an email software application hosted on a cloud provider's website.

[0207] In some embodiments, the cloud infrastructure system 1702 may include a suite of database service products, middleware, and applications delivered to consumers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle Public Cloud provided by the present assignee.

[0208] In various embodiments, the cloud infrastructure system 1702 may be adapted to automatically provision, manage, and track consumer subscriptions to services provided by the cloud infrastructure system 1702. The cloud infrastructure system 1702 may provide cloud services via different deployment models. For example, services may be provided under a public cloud model, where the cloud infrastructure system 1702 is owned by an organization that sells cloud services (e.g., owned by Oracle) and makes the services available to the general public or to different industrial enterprises. As another example, services may be provided under a private cloud model, where the cloud infrastructure system 1702 operates only for a single organization and may provide services to one or more entities within the organization. Cloud services may also be provided under a community cloud model, where the cloud infrastructure system 1702 and the services provided by the cloud infrastructure system 1702 are shared by several organizations in a related community. Cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0209] In some embodiments, the services provided by cloud infrastructure system 1702 may include one or more services provided under a software as a service (SaaS) category, a platform as a service (PaaS) category, an infrastructure as a service (IaaS) category, or other service categories including hybrid services. A consumer may subscribe to one or more services provided by cloud infrastructure system 1702 via a subscription order. Cloud infrastructure system 1702 then performs processing to provide the services in the consumer's subscription order.

[0210] In some embodiments, the services provided by the cloud infrastructure system 1702 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services belonging to the SaaS category. For example, a SaaS platform may provide the ability to build and deliver on-demand application suites on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure used to provide SaaS services. By utilizing the services provided by the SaaS platform, consumers may utilize applications executed on the cloud infrastructure system. Consumers may obtain application services without the need for consumers to purchase licenses and support separately. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business flexibility to large organizations.

[0211] In some embodiments, platform services can be provided by a cloud infrastructure system via a PaaS platform. A PaaS platform can be configured to provide cloud services belonging to the PaaS category. Examples of platform services may include, but are not limited to, services that enable organizations (such as Oracle) to integrate existing applications on a shared common architecture, and the ability to build new applications using shared services provided by the platform. A PaaS platform can manage and control the underlying software and infrastructure used to provide PaaS services. Consumers can obtain PaaS services provided by a cloud infrastructure system without the need for consumers to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.

[0212] By utilizing the services provided by the PaaS platform, consumers can adopt programming languages ​​and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware Services) and Java cloud services. In one embodiment, the database cloud service may support a shared service deployment model that enables organizations to pool database resources and provide database as a service to consumers in the form of a database cloud. The middleware cloud service can provide consumers with a platform for developing and deploying various business applications, and the Java cloud service can provide consumers with a platform for deploying Java applications in the cloud infrastructure system.

[0213] A variety of different infrastructure services can be provided by IaaS platforms in cloud infrastructure systems. Infrastructure services facilitate the management and control of underlying computing resources (such as storage, networks, and other basic computing resources) so that consumers can utilize the services provided by SaaS platforms and PaaS platforms.

[0214] In some embodiments, cloud infrastructure system 1702 may also include infrastructure resources 1730 for providing resources used to provide various services to consumers of the cloud infrastructure system. In one embodiment, infrastructure resources 1730 may include a pre-integrated and optimized combination of hardware (such as servers, storage devices, and networking resources) that execute services provided by PaaS platforms and SaaS platforms.

[0215] In some embodiments, resources in cloud infrastructure system 1702 can be shared by multiple users and dynamically reallocated as needed. In addition, resources can be allocated to users in different time zones. For example, cloud infrastructure system 1730 can enable a first set of users in a first time zone to utilize resources of the cloud infrastructure system for a specified number of hours, and then enable the same resources to be reallocated to another set of users in a different time zone, thereby maximizing utilization of the resources.

[0216] In certain embodiments, a plurality of internal shared services 1732 may be provided that are shared by different components or modules of the cloud infrastructure system 1702 and services provided by the cloud infrastructure system 1702. These internal shared services may include, but are not limited to: security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services for enabling cloud support, email services, notification services, file transfer services, and the like.

[0217] In some embodiments, cloud infrastructure system 1702 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functions may include the ability to provision, manage, and track subscriptions of consumers received by cloud infrastructure system 1702 or the like.

[0218] In one embodiment, as depicted in the figure, cloud management functionality may be provided by one or more modules such as order management module 1720, order orchestration module 1722, order provisioning module 1724, order management and monitoring module 1726, and identity management module 1728. These modules may include or may be provided using one or more computers and / or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0219] In example operation 1734, a customer using a client device (such as client devices 1704, 1706, or 1708) may interact with cloud infrastructure system 1702 by requesting one or more services provided by cloud infrastructure system 1702 and placing an order for a subscription to one or more services provided by cloud infrastructure system 1702. In certain embodiments, the customer may access a cloud user interface (UI) (cloud UI 1712, cloud UI 1714, and / or cloud UI 1716) and place a subscription order via these UIs. Order information received by cloud infrastructure system 1702 in response to a customer placing an order may include information identifying the customer and the one or more services provided by cloud infrastructure system 1702 to which the customer intends to subscribe.

[0220] After a customer has placed an order, order information is received via the cloud UI, 1712 , 1714 , and / or 1716 .

[0221] At operation 1736, the order is stored in order database 1718. Order database 1718 may be one of several databases operated by cloud infrastructure system 1718 and in conjunction with other system elements.

[0222] At operation 1738, the order information is forwarded to order management module 1720. In some examples, order management module 1720 may be configured to perform billing and accounting functions related to the order, such as validating the order and, upon validation, booking the order.

[0223] At operation 1740, information about the order is transmitted to order orchestration module 1722. Order orchestration module 1722 can use the order information to coordinate the provisioning of services and resources for the customer's order. In some examples, order orchestration module 1722 can use the services of order provisioning module 1724 to coordinate the provisioning of resources to support the subscribed services.

[0224] In certain embodiments, order orchestration module 1722 enables management of business processes associated with each order and applies business logic to determine whether an order should proceed to provisioning. At operation 1742, upon receiving an order for a new subscription, order orchestration module 1722 sends a request to order provisioning module 1724 to allocate resources and configure those resources required to complete the order for the subscription. Order provisioning module 1724 enables allocation of resources for the services subscribed by the customer. Order provisioning module 1724 provides a level of abstraction between the cloud services provided by cloud infrastructure system 1700 and the physical implementation layer for provisioning resources for providing the requested services. Thus, order orchestration module 1722 can be independent of implementation details, such as whether services and resources are actually provisioned in real time or pre-provisioned and allocated / assigned only upon request.

[0225] At operation 1744, once the services and resources are provisioned, notifications of the services provided may be sent to the customer on the client devices 1704, 1706, and / or 1708 via the order provisioning module 1724 of the cloud infrastructure system 1702. At operation 1746, the customer's subscription order may be managed and tracked by the order management and monitoring module 1726. In some cases, the order management and monitoring module 1726 may be configured to collect usage statistics for the services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, system uptime, and system downtime.

[0226] In certain embodiments, cloud infrastructure system 1700 may include identity management module 1728. Identity management module 1728 may be configured to provide identity services, such as access management and authorization services, in cloud infrastructure system 1700. In some embodiments, identity management module 1728 may control information about consumers who wish to utilize services provided by cloud infrastructure system 1702. Such information may include information authenticating the identities of these consumers and information describing the actions these consumers are authorized to perform with respect to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). Identity management module 1728 may also include descriptive information about each consumer and management of how and by whom the descriptive information may be accessed and modified.

[0227] Although specific embodiments of the present disclosure have been described, various modifications, changes, alternative constructions and equivalents are also included in the scope of the present disclosure. The embodiments of the present disclosure are not limited to operations within certain specific data processing environments, but can be freely operated within multiple data processing environments. In addition, although the embodiments of the present disclosure have been described using a specific series of transactions and steps, it should be apparent to those skilled in the art that the scope of the present disclosure is not limited to the described series of transactions and steps. The various features and aspects of the above-described embodiments may be used alone or in combination.

[0228] In addition, although the embodiments of the present disclosure have been described using a specific combination of hardware and software, it should be appreciated that other combinations of hardware and software are also within the scope of the present disclosure. The embodiments of the present disclosure can be implemented using only hardware, or only software, or a combination thereof. The various processes described herein can be implemented on the same processor or on different processors in any combination. Accordingly, where a component or module is described as being configured to perform certain operations, this configuration can be implemented, for example, by designing an electronic circuit to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes can communicate using various techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes can use different techniques, or the same pair of processes can use different techniques at different times.

[0229] Thus, the description and drawings should be considered in an illustrative rather than a restrictive sense. However, it will be apparent that additions, subtractions, deletions and other modifications and changes may be made thereto without departing from the broader spirit and scope set forth in the claims. Therefore, although specific disclosed embodiments have been described, these embodiments are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims. Modifications include any relevant combination of the disclosed features.

Claims

1. A computer-implemented method comprising: executing, by a computing system, a declarative infrastructure provisioner configured to manage provisioning infrastructure resources and deploying artifacts of a cloud computing environment in accordance with a configuration file, the configuration file comprising declarative statements describing one or more infrastructure resources to be provisioned and one or more software artifacts to be deployed to the cloud computing environment; provisioning, by a computing system, a first set of infrastructure components based at least in part on a first set of declarative statements of the configuration file; deploying, by the computing system, a second set of software artifacts based at least in part on a second set of declarative statements of the configuration file; as well as A computing system is provided to present a user interface that presents: i) a first area presenting first status information corresponding to a first plurality of releases, a first release in the first plurality of releases corresponding to a provisioning operation of a first set of infrastructure components, and ii) a second area presenting second status information corresponding to a second plurality of releases, a second release in the second plurality of releases corresponding to deploying a second set of software artifacts to respective infrastructure components, the first area being adjacent to the second area at the user interface, the first status information and the second status information being simultaneously visible; Wherein first state information associated with a first set of provisioning infrastructure components and second state information associated with a second set of deployment software artifacts independently correspond to one or more execution targets, each of the one or more execution targets corresponding to a predefined region including at least one physical location.

2. The computer-implemented method of claim 1 , further comprising presenting, by the computing system, a visual representation of progress corresponding to a stage in a plurality of stages, each stage in the plurality of stages being associated with provisioning a corresponding subset of a first set of infrastructure components and deploying a corresponding subset of a second set of software artifacts to a set of execution targets, each execution target in the set of execution targets corresponding to a predefined region including at least one physical location, the plurality of stages being associated with a predefined execution order.

3. The computer-implemented method of claim 2, wherein presenting a visual representation of progress corresponding to the phase comprises presenting, within the visual representation of progress corresponding to the phase, respective indicators of states corresponding to the set of execution goals.

4. The computer-implemented method of any one of claims 1 to 3, further comprising: identifying, by the computing system, a previous configuration of software artifacts in the second set of software artifacts; identifying, by the computing system, a new configuration of software artifacts based at least in part on the second set of deployment software artifacts; as well as An indication of a change from a previous configuration to a new configuration of a software artifact is provided by the computing system via a user interface.

5. The computer-implemented method of any one of claims 1 to 3, further comprising: detecting, by the computing system, a failure in provisioning of at least one infrastructure component of the first set of infrastructure components; presenting, by the computing system via a user interface, an indication of the fault; receiving user input by the computing system; as well as At least one remedial action is performed by the computing system in response to the user input.

6. The computer-implemented method of any one of claims 1 to 3, further comprising: detecting, by the computing system, a failure in the deployment of at least one software artifact in the second set of software artifacts; presenting, by the computing system via a user interface, an indication of the fault; receiving user input by the computing system; as well as At least one remedial action is performed by the computing system in response to the user input.

7. A computer-implemented method as described in any of claims 1-3, wherein deploying the second set of software artifacts includes modifying software resources associated with the execution target from a first state to a second state, and the computer-implemented method also includes presenting, by the computing system, a set of changes to be made to the software resources as part of modifying the software resources from the first state to the second state.

8. The computer-implemented method of any one of claims 1-3, further comprising generating a user interface to include a plurality of user interface elements that at least identify first state information associated with a first set of provisioning infrastructure components and second state information associated with a second set of deployment software artifacts.

9. A system for providing a user interface, comprising: one or more processors; as well as One or more memories storing computer executable instructions that, when executed by one or more processors, cause the system to: executing a declarative infrastructure provisioner configured to manage provisioning infrastructure resources and deploying artifacts of a cloud computing environment according to a configuration file, the configuration file comprising declarative statements describing one or more infrastructure resources to be provisioned and one or more software artifacts to be deployed to the cloud computing environment; provisioning a first set of infrastructure components based at least in part on a first set of declarative statements of the configuration file; deploying a second set of software artifacts based at least in part on a second set of declarative statements of the configuration file; as well as providing a user interface presenting: i) a first area presenting first status information corresponding to a first plurality of releases, a first release in the first plurality of releases corresponding to a provisioning operation of a first set of infrastructure components, and ii) a second area presenting second status information corresponding to a second plurality of releases, a second release in the second plurality of releases corresponding to deploying a second set of software artifacts to respective infrastructure components, the first area being adjacent to the second area at the user interface, the first status information and the second status information being simultaneously visible; Wherein first state information associated with a first set of provisioning infrastructure components and second state information associated with a second set of deployment software artifacts independently correspond to one or more execution targets, each of the one or more execution targets corresponding to a predefined region including at least one physical location.

10. The system of claim 9, wherein the execution instructions further cause the system to present a visual representation of progress corresponding to a stage in a plurality of stages, each stage in the plurality of stages being associated with provisioning a corresponding subset of a first set of infrastructure components and deploying a corresponding subset of a second set of software artifacts to a set of execution targets, each execution target in the set of execution targets corresponding to a predefined region including at least one physical location, the plurality of stages being associated with a predefined execution order.

11. The system of claim 9 or 10, wherein executing the instructions further causes the system to: identifying a previous configuration of software artifacts in the second set of software artifacts; identifying a new configuration of software artifacts based at least in part on the second set of deployment artifacts; and An indication of a change from a previous configuration to a new configuration of the software artifact is provided via the user interface.

12. The system of claim 9 or 10, wherein executing the instructions further causes the system to: detecting a failure of provisioning at least one infrastructure component of a first set of infrastructure components or at least one software artifact of a second set of deployment software artifacts; presenting an indication of the fault via a user interface; Receive user input; as well as At least one remedial action is performed in response to the user input.

13. A non-transitory computer-readable storage medium comprising one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause a computing device to: executing a declarative infrastructure provisioner configured to manage provisioning infrastructure resources and deploying artifacts of a cloud computing environment according to a configuration file, the configuration file comprising declarative statements describing one or more infrastructure resources to be provisioned and one or more software artifacts to be deployed to the cloud computing environment; provisioning a first set of infrastructure components based at least in part on a first set of declarative statements of the configuration file; deploying a second set of software artifacts based at least in part on a second set of declarative statements of the configuration file; as well as providing a user interface presenting: i) a first area presenting first status information corresponding to a first plurality of releases, a first release in the first plurality of releases corresponding to a provisioning operation of a first set of infrastructure components, and ii) a second area presenting second status information corresponding to a second plurality of releases, a second release in the second plurality of releases corresponding to deploying a second set of software artifacts to respective infrastructure components, the first area being adjacent to the second area at the user interface, the first status information and the second status information being simultaneously visible; Wherein first state information associated with a first set of provisioning infrastructure components and second state information associated with a second set of deployment software artifacts independently correspond to one or more execution targets, each of the one or more execution targets corresponding to a predefined region including at least one physical location.

14. The non-transitory computer-readable storage medium of claim 13, wherein executing the instructions further causes the computing device to present a visual representation of progress corresponding to a stage in a plurality of stages, each stage in the plurality of stages being associated with provisioning a corresponding subset of a first set of infrastructure components and deploying a corresponding subset of a second set of software artifacts to a set of execution targets, each execution target in the set of execution targets corresponding to a predefined region including at least one physical location, the plurality of stages being associated with a predefined execution order.

15. The non-transitory computer readable storage medium of claim 13 or 14, wherein executing the instructions further causes the computing device to: identifying a previous configuration of software artifacts in the second set of software artifacts; identifying a new configuration of software artifacts based at least in part on the second set of deployment artifacts; and An indication of a change from a previous configuration to a new configuration of the software artifact is provided via the user interface.

16. The non-transitory computer readable storage medium of claim 13 or 14, wherein executing the instructions further causes the computing device to: detecting a failure of provisioning at least one infrastructure component of a first set of infrastructure components or at least one software artifact of a second set of deployment software artifacts; presenting an indication of the fault via a user interface; Receive user input; as well as At least one remedial action is performed in response to the user input.

17. A non-transitory computer-readable storage medium as described in claim 13 or 14, wherein deploying the second set of software artifacts includes modifying software resources associated with the execution target from a first state to a second state, wherein executing the instructions also causes the computing device to present a set of changes to be made to the software resources as part of modifying the software resources from the first state to the second state.

18. A computer-implemented method comprising: The computing system provides a user interface that presents the following: a first region presenting a first state associated with provisioning a first set of infrastructure components based at least in part on executing a first plurality of releases, a first release in the first plurality of releases corresponding to a provisioning operation of the first set of infrastructure components, the first set of infrastructure components being provisioned based at least in part on a computing system providing a first set of declarative instructions to a declarative infrastructure provisioner; and a second region presenting a second state associated with deploying a second set of software artifacts based on a second plurality of releases, a second release in the second plurality of releases corresponding to deploying a second set of software artifacts to respective infrastructure components, the second set of software artifacts being provisioned based at least in part on the computing system providing a second set of declarative instructions to the declarative infrastructure provisioner; Wherein the first area is adjacent to the second area at the user interface, wherein the first state and the second state are simultaneously visible, and wherein the first state and the second state correspond to one or more execution targets, and the one or more execution targets independently correspond to a predefined area including at least one physical location.

19. A system for providing a user interface, comprising: one or more processors; as well as one or more memories storing computer executable instructions that, when executed by the one or more processors, cause the system to: Provided in the user interface: a first region presenting a first state associated with provisioning a first set of infrastructure components based at least in part on executing a first plurality of releases, a first release in the first plurality of releases corresponding to a provisioning operation of the first set of infrastructure components, the first set of infrastructure components being provisioned based at least in part on a computing system providing a first set of declarative instructions to a declarative infrastructure provisioner; and a second region presenting a second state associated with deploying a second set of software artifacts based on a second plurality of releases, a second release in the second plurality of releases corresponding to deploying a second set of software artifacts to respective infrastructure components, the second set of software artifacts being provisioned based at least in part on the computing system providing a second set of declarative instructions to the declarative infrastructure provisioner; Wherein the first area is adjacent to the second area at the user interface, wherein the first state and the second state are simultaneously visible, and wherein the first state and the second state correspond to one or more execution targets, and the one or more execution targets independently correspond to a predefined area including at least one physical location.

20. A non-transitory computer-readable storage medium comprising one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause a computing device to: Provided in the user interface: a first region presenting a first state associated with provisioning a first set of infrastructure components based at least in part on executing a first plurality of releases, a first release in the first plurality of releases corresponding to a provisioning operation of the first set of infrastructure components, the first set of infrastructure components being provisioned based at least in part on a computing system providing a first set of declarative instructions to a declarative infrastructure provisioner; and a second region presenting a second state associated with deploying a second set of software artifacts based on a second plurality of releases, a second release in the second plurality of releases corresponding to deploying a second set of software artifacts to respective infrastructure components, the second set of software artifacts being provisioned based at least in part on the computing system providing a second set of declarative instructions to the declarative infrastructure provisioner; Wherein the first area is adjacent to the second area at the user interface, wherein the first state and the second state are simultaneously visible, and wherein the first state and the second state correspond to one or more execution targets, and the one or more execution targets independently correspond to a predefined area including at least one physical location.

21. An apparatus comprising means for performing the steps of the method according to any one of claims 1-8 and 18.

Images