User Interface Technology for Infrastructure Orchestration Service

Abstract

Techniques for providing several user interfaces are disclosed. A computing system may execute a declarative infrastructure provisioner. The computing system may provide declarative instructions to direct the declarative infrastructure provisioner to deploy multiple infrastructure resources and multiple artifacts. One exemplary user interface may provide a global view of multiple infrastructure components and artifacts. Another exemplary user interface may provide corresponding state and change activity of the multiple infrastructure components and artifacts. Yet another user interface may be provided that displays similarities and / or differences between a locally generated safety plan illustrating a first change in the computing environment and a remotely generated safety plan illustrating a second change in the computing environment.

Description

Technical Field

[0001] Cross - Reference to Related Applications This application is a regular application of the following U.S. provisional applications and regular applications, claims the benefits and priorities under 35 U.S.C. § 119(e) of the following U.S. provisional applications and regular applications, and the entire contents of which are incorporated by reference for all purposes. The following U.S. provisional applications and regular applications are: U.S. Provisional Application No. 62 / 963,456, filed on January 20, 2020, entitled "USER INTERFACE TECHNIQUES FOR AN INFRASTRUCTURE ORCHESTRATION SERVICE"; U.S. Provisional Application No. 62 / 964,596, filed on January 22, 2020, entitled "USER INTERFACE TECHNIQUES FOR AN INFRASTRUCTURE ORCHESTRATION SERVICE"; and U.S. Regular Application No. 17 / 001,626, filed on August 24, 2020, entitled "USER INTERFACE TECHNIQUES FOR AN INFRASTRUCTURE ORCHESTRATION SERVICE".

Background Art

[0002] Background Today, cloud infrastructure services are provisioning and deploying code and configurations (respectively) across many areas of cloud infrastructure services using many individual services. Considering that provisioning is generally declarative and it is absolutely necessary to deploy code, these tools require a significant amount of manual labor to use. Further, as the number of service teams and areas increases, cloud infrastructure services also need to continue to grow. Among the strategies of cloud infrastructure services to deploy to even more and smaller areas, some include the cost per area, but these cannot scale well. Summary of the Invention Means for Solving the Problems

[0003] Brief Summary Techniques for providing one or more user interfaces are disclosed herein. In some embodiments, a method is disclosed. The method may comprise the computing system executing a declarative infrastructure provisioner. The method may further comprise the computing system provisioning a first set of infrastructure components, at least in part based on providing a first set of declarative instructions to the declarative infrastructure provisioner. The method may further comprise the computing system deploying a second set of software artifacts, at least in part based on providing a second set of declarative instructions to the declarative infrastructure provisioner. The method may further comprise the computing system providing a user interface that displays a plurality of user interface elements, wherein the plurality of user interface elements identify at least a first status associated with the step of provisioning the first set of infrastructure components and a second status associated with the step of deploying the second set of software artifacts.

[0004] In some embodiments, a system is disclosed. The system includes 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 provisioner. The operations may further include provisioning a first set of infrastructure components, at least in part based on providing a first set of declarative instructions to the declarative infrastructure provisioner. The operations may further include deploying a second set of software artifacts, at least in part based on providing a second set of declarative instructions to the declarative infrastructure provisioner. The operations may further include providing a user interface that displays a plurality of user interface elements, where the plurality of user interface elements identify at least a first status associated with provisioning the first set of infrastructure components and a second status associated with deploying the second set of software artifacts.

[0005] 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 instructions executable by a computer, and the instructions executable by the computer, when executed by the one or more processors, cause a computing device to perform operations. The operations may include executing a declarative infrastructure provisioner. The operations may further include provisioning a first set of infrastructure components, at least in part based on providing a first set of declarative instructions to the declarative infrastructure provisioner. The operations may further include deploying a second set of software artifacts, at least in part based on providing a second set of declarative instructions to the declarative infrastructure provisioner. The operations may further include providing a user interface that displays a plurality of user interface elements, where the plurality of user interface elements identify at least a first status associated with provisioning the first set of infrastructure components and a second status associated with deploying the second set of software artifacts.

[0006] In some embodiments, a method executed by a computer is disclosed. The method may comprise the step of a computing system providing a user interface that displays a plurality of user interface elements, the plurality of user interface elements identifying at least a first status associated with provisioning a first set of infrastructure components and a second status associated with deploying a second set of software artifacts. The first set of infrastructure is provisioned based at least in part on a declarative infrastructure provisioner, and the second set of software artifacts is provisioned based at least in part on the declarative infrastructure provisioner.

[0007] In some embodiments, a system is disclosed. The system may comprise one or more processors and one or more memories storing instructions executable by a computer, the instructions executable by the one or more processors to cause the system to perform operations. The operations may comprise providing a user interface that displays a plurality of user interface elements, the plurality of user interface elements identifying at least a first status associated with provisioning a first set of infrastructure components and a second status associated with deploying a second set of software artifacts. The first set of infrastructure is provisioned based at least in part on a declarative infrastructure provisioner, and the second set of software artifacts is provisioned based at least in part on the declarative infrastructure provisioner.

[0008] In some embodiments, a non-transitory computer-readable storage medium is disclosed. The non-transitory computer-readable storage medium may comprise one or more processors and one or more memories storing computer-executable instructions, and the computer-executable instructions, when executed by the one or more processors, cause a computing device to perform operations. The operations may comprise providing a user interface that displays a plurality of user interface elements, and the plurality of user interface elements identify at least a first status associated with provisioning a first set of infrastructure components and a second status 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.

[0009] In some embodiments, an apparatus is disclosed. The apparatus may comprise means for performing steps of any of the methods according to embodiments of the present disclosure.

[0010] To facilitate identification of any particular element or act, the leading digit in a reference number refers to the drawing number in which that element is first introduced.

Brief Description of the Drawings

[0011]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

DETAILED DESCRIPTION OF THE INVENTION

[0012] Detailed Description In some examples, Infrastructure as a Service (IaaS) is a particular 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 three main categories (or sub-categories) of cloud computing services. Most people consider the other main categories to be Software as a Service (SaaS) and Platform as a Service (PaaS), and sometimes SaaS is considered to be a broader category that encompasses both PaaS and IaaS, and there are even those who consider IaaS to be a sub-category of PaaS.

[0013] In the IaaS model, a cloud computing provider can operate and manage infrastructure components (such as servers, storage devices, network nodes (such as hardware), deployment software, platform virtualization (such as the hypervisor layer), etc.).

[0014] In some cases, the IaaS provider may also supply various services (such as billing, monitoring, logging, security, load balancing, and clustering, etc.) that are associated with those infrastructure components. Therefore, since these services can be policy-driven, IaaS users will be able to enforce policies to drive load balancing to maintain application availability and performance.

[0015] In some examples, IaaS customers can access resources and services via 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, create a virtual machine (VM), install an operating system (OS) on each VM, deploy middleware (such as a database), create storage buckets for workloads and backups, and even install enterprise software on that VM. Then, the customer can use the provider's services to perform various functions (including network traffic balancing, troubleshooting application problems, performance monitoring, disaster recovery management, etc.).

[0016] In most cases, cloud computing models require the participation of a cloud provider. The cloud provider can be a third-party service that specializes in providing (e.g., selling) IaaS, but it doesn't have to be. An entity can also choose to deploy a private cloud that becomes its own infrastructure service provider.

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

[0018] In some examples, IaaS provisioning can even mean obtaining computers or virtual hosts for use and installing the necessary libraries or services on them. In most cases, deployment does not include provisioning, and it may be necessary to perform provisioning first.

[0019] IaaS provisioning can sometimes have two different problems. First, there is the initial challenge of provisioning the infrastructure before anything is running. Second, there is the challenge of scaling the existing infrastructure once everything has been provisioned (e.g., adding a new service, changing a service, removing a service, etc.). In some cases, these two challenges can be addressed by enabling the infrastructure configuration to be defined declaratively. In other words, the infrastructure (e.g., which components are needed 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 and how they cooperate) can be described declaratively. In some examples, once the topology is defined, a workflow can be generated to create and / or manage the various components described in the configuration file.

[0020] In some examples, the infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a pool of configurable and / or shared computing resources, sometimes on-demand), which are also known as the core network. In some examples, there may also be one or more security group rules provisioned to define how network security is set up, and one or more virtual machines (VMs). Other infrastructure elements (load balancers, databases, etc.) may also be provisioned. As more and more infrastructure elements are required and / or added, the infrastructure can be incrementally scaled.

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

[0022] In some examples, the workflow of a provisioning tool can be configured to execute various commands. One function that can be executed 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 examples, executing the view reconciliation function can involve querying various resource providers or infrastructure resources to identify which resources are actually operating. Another function that a provisioning tool can execute is plan generation, in which the provisioning tool can compare the infrastructure components that are actually operating with how the provisioning tool wants them to appear (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 date with the latest expectations. In some examples, a third function is the execution (e.g., application) function, in which the provisioning tool can execute the plan generated by the plan generation function.

[0023] Generally, a provisioning tool can be configured to obtain a configuration file, parse the declarative information contained therein, and programmatically / automatically determine the order in which resources need to be provisioned to execute a plan. For example, if a VPC needs to be booted before security group rules and VMs are booted, the provisioning tool can make that determination and execute the boot in that order without user intervention and / or without that information necessarily being contained in the configuration file.

[0024] In some examples, continuous deployment techniques can be utilized to enable the deployment of infrastructure code across various virtual computing environments. Further, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is desired to be deployed to one or more (but often many) different production environments (e.g., sometimes across various different geographical locations spanning the globe). However, in some examples, the infrastructure to which the code will be deployed must first be set up. In some examples, provisioning can be done manually, resources can be provisioned using a provisioning tool, and / or code can be deployed using a deployment tool once the infrastructure is provisioned.

[0025] As described above, generally, there are two different tools used to handle each of the provisioning of infrastructure resources and the deployment of code to control infrastructure resources, and the orchestration between these two tools is done manually. However, at scale, manual execution always results in deviations. Therefore, an automated tool that can perform both the provisioning and deployment of virtual infrastructure enables more efficient and reliable techniques for realizing virtual cloud environments.

[0026] In some instances, when two tools are used, problems can occur when a user manually makes code changes between the provisioning phase and the deployment phase. As described herein, techniques that use a single tool for both provisioning and deployment can mitigate this by automating the process so that there is no opportunity for manual code changes. It is possible that even a minor change to how a user codes something could result in a major problem in the deployment phase. In some instances, when an operator first executes an action (e.g., a typo in the code) in a new area, the object coded with that typo could remain permanently as is. Even if the application is deployed with that typo and the application is not affected by the typo (e.g., the application still functions), it is possible that eventually further code changes will be affected by the typo and crash the entire system. Thus, the techniques provided herein can eliminate the gap between provisioning and deployment that can often cause problems.

[0027] Generally, the modeling of a deployment is declarative such that infrastructure resources can be declared using configuration files. For example, generally, create, read, update, delete (CRUD) instructions are used to generate deployment files using the Representational State Transfer (REST) concept (e.g., a REST Application Programming Interface (API)). However, the deployment itself generally does not conform to this concept. Further, infrastructure provisioning tools are, by nature, very powerful and / or expressive, but tools for deployment are, by nature, much more restrictive with respect to the operations they can perform (e.g., they are imperative as opposed to declarative). Thus, there has been a long-felt need for tools that can address both functional requirements (e.g., provisioning and deployment of infrastructure elements) within a cloud environment.

[0028] In some examples, techniques for executing a Cloud Infrastructure Orchestration Service (CIOS) are described herein. Such techniques can be configured to manage both the provisioning and deployment of infrastructure assets within a cloud environment, as briefly described above. In some examples, the CIOS can include two classes of services, namely a central component and a regional component (e.g., a central CIOS and a regional CIOS). The following terms are used throughout.

[0029] · Infrastructure component: A long-lived part of the infrastructure that supports running code Examples: Deployment applications, load balancers, Domain Name System (DNS) entries, object storage buckets, etc. · Artifact: The code is deployed to a deployment application or a Kubernetes engine cluster, or the configuration information (hereinafter referred to as "config") is applied to infrastructure components. These can be read-only resources.

[0030] · Deployment Task: A short-lived task often associated with deploying or testing code. Additionally, deployment tasks are modeled as resources that do not survive as long as the release that creates them.

[0031] Example: "Please deploy $artifact to $environment", "Please watch $alarm for 10 minutes", "Please execute $testSuite" or "Please wait for $manualApproval" For example, CIOS can model the deployment of a deployment orchestrator as the creation of a resource that transitions to an available state when it is completed.

[0032] Since CIOS maintains the state of its cloud infrastructure service declarative provisioner, CIOS can control the lifecycle of these short-lived resources when they are related to a release.

[0033] · Resource: A CRUD-able resource CIOS models each of the above configurations as a resource. The following section will explain this modeling in detail.

[0034] · Flock: A model of CIOS that encapsulates the control plane and all of its components. Exists mainly to model the ownership of infrastructure components to indicate infrastructure components · Flock Configuration: Describes a set of all infrastructure components, artifacts, and deployment tasks associated with a single service Each flock has exactly one flock configuration. The flock configuration is checked into source control.

[0035] Flock configurations are declarative. They are expected to take the realm, region, ad, and artifact version as inputs provided by CIOS.

[0036] Flocks are granular. A flock is composed of a single service and the supporting infrastructure.

[0037] · State: A snapshot at a specific point in time of the state of all resources within a flock · Release: A tuple of a specific version of a flock configuration and the specific versions of any artifacts it references Consider a release to describe a state that may not yet exist · Release Plan: A set of steps that CIOS would need to transition all regions from their current state to the state described by the release A release plan has a finite number of steps and clearly defined start and end times · Application: This is a noun. It is a single attempt to execute a release plan. Execution changes the current state of the flock.

[0038] CIOS can be said to be an orchestration layer that applies configurations to downstream systems (e.g., globally). It is designed to enable global infrastructure provisioning and code deployment without manual effort from the service team (e.g., beyond initial approval in some cases). CIOS's top-level responsibilities include, but are not limited to, the following.

[0039] Provide the team with a view of the current state of resources managed by CIOS, including any in - process change activities Help the team plan and release new changes Coordinate activities across various downstream systems in the area to execute an approved release plan without human intervention Coordinate activities across areas / realms to execute an approved release plan globally In some examples, the CIOS processes onboarding by enabling the team to provide configuration information to the CIOS with the checked-in code. Further, since the CIOS can automate more, this is a more burdensome task than previous implementations. In some examples, the CIOS processes pre-deployment by providing the team with a function that can automatically deploy and test the code. In some examples, the CIOS can process the writing of change management (CM) policies by enabling the team to automatically generate a plan for deploying them (e.g., globally) when the team builds new artifacts. It can do this by examining the current state of each area and the current CIOS configuration (which can itself be an artifact). Further, the team can examine these plans and iterate them by asking the CIOS to change the CIOS configuration and replan. When the team is satisfied with a plan, it can create a "release" that references the plan. This plan can then be marked as approved or rejected. The team can still write CMs, but they are just pointers to the CIOS plan. Thus, the team does not spend as much time reasoning about this plan. The plan is more accurate because it is generated by a machine. The plan can be displayed by a sophisticated user interface (UI), although it may be too detailed for humans.

[0040] In some examples, the CIOS can handle the execution of CM by automatically executing the deployment plan. Once the release plan is created and approved, engineers do not participate in CM unless the CIOS starts a rollback. In some cases, this can require the team to automate tasks that are currently manual. In some examples, the CIOS can handle the rollback of change management (CM) by automatically generating a plan to return the flock to its original (e.g., pre-release) state when the CIOS detects a degradation of service health during execution. In some examples, the CIOS can receive a release plan applied to a subset of the areas and / or a subset of the resources managed by the CIOS and then process the deployment of ad-hoc / tactical changes by executing that plan.

[0041] Furthermore, the CIOS can support the primitives necessary to define a fully automated worldwide deployment. For example, the CIOS can measure service health by monitoring alarms and running integration tests. The CIOS can help the team quickly define rollback behavior in case of a service degradation and then automatically execute it. The CIOS can automatically generate and display a release plan and track approvals. In some examples, the language used by the team to describe the desired deployment behavior can be declarative. The CIOS can combine the functionality of code deployment and infrastructure configuration (e.g., provisioning) within one system. Also, the CIOS supports flexible ordering across areas and across components within an area. The team can express the ordering by the checked-in config. The team can call the CIOS's planning to programmatically release an API.

[0042] Figure 1 is a diagram showing an architecture 100 for explaining techniques for executing at least a central CIOS 102. In some examples, the central CIOS 102 can be a service that processes operations at the "flock" level. The central CIOS 102 has several responsibilities, which include but are not limited to the following.

[0043] · Serve as an authentication gateway for flock metadata changes and release operations · Store the formal mapping of flock metadata to the CIOS repository and deployment artifacts for the flock · Coordinate global releases across phases and targets · Synchronization for enforcing policies such as "in-progress release to a flock only once" · Detect changes to flock configurations (configs) and artifacts and trigger release generation upon such changes In some examples, a source code version control management service (SCVMS) 104 can be configured to store the formal flock configuration, and an artifact notification service (ANS) 106 can be contracted by the central CIOS 102 to be able to notify the central CIOS 102 of the construction of new artifacts. The central CIOS 102 can then map incoming changes to the affected flocks and, if desired, initiate release planning. Further, in some examples, an artifact push service (APS) is called by the central CIOS 102 prior to releasing to a target to ensure that any artifacts necessary for the success of the release exist within the target area prior to the release.

[0044] In some examples, a customer (e.g., an engineer) 108 can call the central CIOS 102 to CRUD a flock and / or a release and view the status of ongoing CIOS activities. The flock management service 110 may include one or more APIs for manipulating flocks, and the view / plan / approval service 112 may include CRUD APIs for creating and approving plans and viewing a central copy of the state of resources managed by all CIOSs. The change monitoring service 114 may watch the SCVMS 104 for changes to the flock configuration and may receive notifications from the ANS 106 about changes to other artifacts. The status ingestor service 116 may create a copy of the regional state in the central CIOS database (DB) 118 so that the view / plan / approval 112 can expose them. In some examples, the central CIOS DB 118 can be a database for flocks, plans, and status. The flock information may be official, while the rest may all be old copies of data from the regional CIOSs 120. The central CIOS 102 may be configured to provide any suitable portion of a user interface (e.g., user interfaces 500 - 1300) and / or any suitable number of user interfaces for displaying any suitable data related to flocks, releases, infrastructure components, artifacts, etc. In some embodiments, the central CIOS 102 may display 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 tasks related to one or more code changes to one or more applications (e.g., artifacts). Some examples of the user interfaces provided by the central CIOS 102 will be described below with respect to FIGS. 5 - 13.

[0045] In some examples, engineer 108 can execute an API call to the flock management service 110 (e.g., via the ingress proxy fleet 122) to create a list of flocks. The protocol for making such an API call can be, for example, the Hypertext Transfer Protocol Secure (HTTPS). The associated access control list (ACL) for this operation can include the local area network (LAN) 124 or other private connections. For example, the CIOS can manage / control a network connection (e.g., a dedicated connection, a leased connection, and / or a private connection) that replaces the use of the public Internet to connect the customer's on-premises data center or network to the CIOS. Further, authentication and authorization (e.g., of engineer 108) can be performed by a reservation system portal that enables a user to manage a machine interface (e.g., a reservation service). In some examples, the central CIOS 102 can store flock metadata, plans, and states in the central DB 118 using, for example, Java (registered trademark) Database Connectivity (JDBC). In some examples, the ANS 106 can be configured to notify the change monitoring service 114 when a new artifact is published. The ANS 106 can use HTTPS, and authentication and authorization can be processed by a mutual transport layer security service. Further, in some examples, the change monitoring service 114 can poll the SCVMS 104 for flock configuration changes. This polling can be performed using Secure Shell (SSH) or other protocols. Authentication of the change monitoring service 114 can be processed by the CIOS system account, and authorization can be processed by the SCVMS 104.

[0046] In some examples, engineer 108 can perform one or more of the following operations using the view / plan / approval service 112. Engineer 108 can perform a plan and / or approval by calling the central CIOS 102 to generate and approve a plan. Engineer 108 can perform a view by calling the central CIOS 102 to view the status of ongoing CIOS activities on a global scale. Further, engineer 108 can view a replica of the state of resources managed by the central CIOS 102 by a global CIOS. These API calls (or something like that) can be executed by the HTTPS protocol or a similar protocol. Further, the associated ACL can be controlled by the LAN 124, and authentication and authorization can be processed by a reservation service. In some examples, the view / plan / approval service 112 can push a plan approval to all regions of the regional CIOS 120 by requesting planning (e.g., using HTTPS, etc.). The associated ACL can be controlled using a security list managed by the wide area network (WAN) gateway 126. Authentication can be processed by mutual transport layer security, and authorization can be processed by various identity policies. Further, the state ingestor service 116 can monitor the regional CIOS 120 for those job statuses or state changes so that the CIOS can provide a central view of the job status or state change on demand (e.g., also using HTTPS, etc.). The ACLs for this can also be processed by the WAN gateway 126, and authentication and authorization can be processed by the mutual transport layer security service.

[0047] Figure 2 is a diagram showing an architecture 200 for explaining the technology for at least executing the regional CIOS 202. In some examples, the regional CIOS 202 is where many parts of the declarative provisioning and planning work, as well as where approved release applications can occur. In some examples, each instance of the regional CIOS 202 may have a regional front-end that can process operations at the "execution target" level. It can be configured to perform the following.

[0048] · Process all CIOS authentications for incoming operations from the central CIOS 102 · Enforce the rule that only one "execution" (plan / resource import / apply plan) can be in progress for a given execution target at a time · Manage binary artifact storage for declarative provisioning artifacts used for input and output during the execution of declarative infrastructure provisioning. Examples of input are declarative infrastructure provisioning configuration files and input state files. A typical output is the final state file.

[0049] · For any given execution, request polling for work from the CIOS executor and results from the CIOS executor In some examples, the CIOS front-end may depend on a CIOS executor 206 (also referred to herein as a "scheduler") that can process actual executions. In some examples, the CIOS executor operates at the "execution" level and can perform the following.

[0050] · Track the pool of available worker nodes · Query incoming job requests and assign them to eligible workers that are available · Track worker status and execution update information for reporting to the client · Detect dead nodes by the lease protocol and, depending on the task status, disable the tasks assigned to the dead nodes. · Provide functions for canceling / force-terminating / suspending / resuming execution and map them to functions for passing cancel / force-termination / resume information to the worker nodes. In some examples, the CIOS executor may depend on the CIOS worker, which can assign tasks for execution to the worker and provide a function for the worker to update job progress. The worker service operates at the granularity of "tasks". Each worker is an agent that executes the tasks assigned to that worker and reports the task status and output. Each worker can perform the following.

[0051] · Poll the executor-worker API for the assigned worker items and take measures to match the assignment state with its local state. Start a container for polling task items that do not exist locally. Force-terminate the container for locally executing a container that does not have the corresponding assigned task item. · Report the status of the job. · Stage the input and output for job container execution. · Start and monitor a declarative infrastructure provisioning container for performing the actual work of releasing the execution target. The CIOS worker may depend on the CIOS executor to poll work from the CIOS executor and report the results to the worker endpoint of the CIOS executor. The worker may rely on the executor for all coordination. Further, the CIOS worker may also depend on the regional CIOS202, where the worker service reads input from one or more APIs associated with the regional front-end service and writes output to one or more of these APIs. Examples of input are configuration and start state files, and the import of mappings. Examples of output are the declarative provisioning process, the output of the declarative provisioning state file, and the import of the resulting state.

[0052] In some examples, the regional CIOS 202 can be a regional service for managing regional instances / deployments of the CIOS. The regional CIOS 202 covers the responsibility of formally storing and managing plans and states related to a specific area. The regional DB 204 can be a CIOS DB for the states and plans in that specific area. This is an official copy of a subset of the areas of the central DB 118 in FIG. 1. The scheduler 206 can be responsible for managing the worker fleet capacity, assigning tasks to workers, and tracking the progress of task states. In some examples, the task DB 208 is another CIOS DB for task states. Most of the data in this DB is for operational purposes. Further, the workers 210 can be a fleet of Java virtual machines (JVMs) that manage declarative provisioning images. These receive instructions from the scheduler 206 and communicate the results to both the scheduler 206 and the regional CIOS 202. The CIOS container 212 can execute declarative provisioning actions in its own private Docker 214 container. This container may not contain confidential matters. Further, in some examples, the signing proxy 216 can be configured to prevent the leakage of confidential matters by the declarative provisioning tool to avoid putting confidential matters in the declarative provisioning image. Instead, the CIOS can perform signing requests or initiate mutual transport layer security (mTLS) services in the proxy. This also makes it easier to use FIPS-compliant cryptographic libraries.

[0053] In some examples, the central CIOS 102 can call the regional CIOS 202 to create a plan, push an approval, monitor the job status (service principal), and extract the declarative provisioner state (service principal). The ingress proxy 218 can be configured as an ACL, and various identity policies can be used for both authentication and authorization. Alternatively, in some examples, the ingress proxy 218 may be replaced with a load balancer configured to distribute the load of incoming requests, plans, etc. In some examples, the regional CIOS 202 can execute the declarative provisioner by asking the scheduler 206 to do so. The worker 210 can ask the scheduler 206 what it should be executing and can report the status to the scheduler 206 upon completion. In some cases, mTLS may handle both authentication and authorization for the regional CIOS 202 and the worker 210. Further, the worker 210 executes the declarative provisioner in the docker container by interacting with the local docker 214 when it needs to execute the declarative provisioner. Authentication at this stage can be handled by the local unix (registered trademark) socket. Although the docker protocol may be used in this last step, HTTPS may be utilized in the previous steps.

[0054] In some embodiments, the regional CIOS 202 may be configured to provide any suitable portion of a user interface (e.g., user interfaces 500-1300) for displaying any suitable data related to flocks, releases, infrastructure components, artifacts, etc., and / or any suitable number of user interfaces. In some embodiments, the regional CIOS 202 may display 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 tasks related to one or more code changes to one or more applications (e.g., artifacts). Some examples of user interfaces provided by the regional CIOS 202 are described below with respect to FIGS. 5-13.

[0055] In some examples, the CIOS container 212 enables a declarative provisioner to interact (via an API) with the signing proxy 216, which the declarative provisioner believes it is invoking various CIOS services. The signing proxy 216 listens on one ephemeral port per invocation of the declarative provisioner instance, which only the declarative provisioner knows. The signing proxy 216 can initiate signing or mTLS requests and pass the declarative provisioner's invocations to other CIOS services within the service enclave. In some examples, the signing proxy 216 can also communicate with one or more public CIOS services 220. For example, the signing proxy 216 uses the internal endpoint of the public service if available. For services without an internal endpoint, it must use an egress proxy 222 to reach the external endpoint. This use of the signing proxy 216 is not for cross-region communication. For example, the egress proxy whitelist in each region can be for that region's public IP range only. In some examples, the worker 210 can then maintain their state and logs such that the state and logs from the declarative provisioner in the regional CIOS 202 can flow out to the central CIOS 102.

[0056] Using CIOS, a typical customer experience has several phases, namely onboarding, pre-release, worldwide release, and tactical release. In the pre-release phase, the following is an example of what happens between the construction of new artifacts and releasing the artifacts to Release 1 (e.g., R1). This should replace some or most of the current change management process. When the relevant artifacts are built, CIOS can automatically generate a release using "the latest version of everything in the flock". A release is a specific version of the flock configuration with specific inputs (e.g., artifact version, realm, region, and ad). A release includes one roll-forward plan per region and metadata describing the region ordering. Each regional plan is a set of actions that the declarative provisioner would perform to realize the flock configuration in that region. A team with a pre-release environment can use CIOS to automatically release and test software in the above environment. The team can configure CIOS to automatically test the rollback plan. The team will be able to examine and approve the release via the CIOS UI. The team can approve some (but not all) of the regional plans within the release. If "the latest version of everything" does not result in a suitable plan, the team can ask CIOS to generate a plan for the cherry-picked artifact version.

[0057] In the world-scale release phase, the following is an example of how the team executes the next version of today's "usual CM". Once the release is approved, the CIOS pushes each approved regional plan to its respective region. The CIOS operates independently within each region to apply the approved plan. The CIOS only executes the set of actions explicitly described in that region's plan. It won't work if it "thinks independently". The CIOS UI shows the team the progress of the execution. The CIOS UI prompts the team when manual approval is required. If the execution fails due to a stop in the CIOS or downstream services, the CIOS can notify the team and prompt the team for the next steps (e.g., abort, retry). The CIOS performs the retry, but there are cases within the downstream system's stop that go beyond the intention to retry. If the execution fails due to a decrease in service health or test failure, the CIOS helps the team by rolling back the flock to its starting state. The CIOS notifies the team (e.g., paging) when it starts the automatic rollback. The team must approve the rollback plan, and then the CIOS executes it.

[0058] In the tactical release phase, the following is an example of how the team can execute the tomorrow's version of "ad hoc CM". When generating the plan, the team can ask the CIOS to target the plan to specific resources in several ways, namely topologically (e.g., realm, region, AD, etc.), by resource type (e.g., "metrics config only" or "deployment of deployment orchestration service only", etc.), or in a combination of the above (e.g., in a disjunctive manner). The team approves the tactical release as well as the worldwide release. The CIOS orchestrates them in the same way. If the team needs to deploy a tactical release while there is an active worldwide release, the CIOS stops the execution of the worldwide release in the target region and then starts the execution of the tactical release.

[0059] In some cases, the state of a declarative provisioner (e.g., a file, conventionally) is the official record of a set of resources managed by the declarative provisioner. It includes the mapping between the logical identifier of each resource from the configuration file and the actual identifier of the resource. When the declarative provisioner is creating a resource, a particular kind of failure can prevent the actual identifier from being recorded in that state. When this happens, the actual identifier is no longer that of the declarative provisioner. These can be called "orphan resources".

[0060] For most resources, orphans are considered waste. A declarative provisioner may have launched an instance, forgotten about it, and then when it runs again it will launch a different instance instead. For resources with uniqueness constraints or identifiers supplied by the client, orphans prevent the declarative provisioner from proceeding. For example, if a declarative provisioner creates user "nglass" and failure discards it, the declarative provisioner's next run will fail when it tries to create "nglass" because a user with that username already exists. In some cases, orphans only become a problem when adding a new resource to the state. In some examples, the declarative provisioner's refresh behavior may naturally recover from failure and record updates and deletions.

[0061] CIOS needs to be resilient in the face of a downstream service outage or an outage of CIOS itself. Since CIOS can utilize a declarative provisioner to apply changes, this means that it should be resilient with respect to running the declarative provisioner and maintaining the declarative provisioner state. The declarative provisioner provider performs "small scale" retries sufficient to avoid outages that last for several minutes. For example, a cloud provider performs retries for up to 30 minutes. A downstream system outage that lasts longer than 30 minutes fails the declarative provisioner. When the declarative provisioner fails, it records all changes that were successfully applied in that state and then exits. To perform a retry, CIOS must re-run the declarative provisioner. By re-running the declarative provisioner, CIOS can perform retries even if CIOS itself fails. In some examples, CIOS can perform the following actions in a loop.

[0062] · Refresh: The declarative provisioner calls "Get API" to retrieve a new snapshot of any resources described in that state · Plan: The declarative provisioner generates a plan (a specific set of API calls) to achieve the desired state considering the recently refreshed current state. · Apply: The declarative provisioner executes a set of steps in the plan. CIOS can always execute all three of these steps when running the declarative provisioner. The refresh operation helps recover from any updates or deletions that were not recorded. CIOS examines the results of the plan operation and compares it with the approved release plan. If the newly generated plan contains operations that were not in the approved release plan, CIOS can fail and notify the service team.

[0063] Figure 3 is a diagram showing a directed acyclic graph (DAG) 300 for explaining an exemplary flock 302. The code / config progress from check-in to generation for a single flock config in CIOS can be described all the way from the first test deployment to the last prod deployment. Internally, CIOS refers to each element in the progress as an execution target (ET). CIOS executes the ETs based on the DAG 200 defined in the flock config. Each ET (e.g., ET-1, ET-2, ET-3, ET-4, ET-5, ET-6, and ET-7) is roughly one copy of the service described by the flock config.

[0064] FIG. 4 is a diagram showing a DAG 400 for explaining an exemplary flock 402. In the flock configuration, the CIOS is very arbitrary about how the team represents this progress. The team must model it using cloud infrastructure tenancy and regions. The team should not model progress using realms. The CIOS enables the team to use many tenancies within a realm and many regions within a tenancy. DAG 400 shows a version of DAG 300 from FIG. 3, represented with tenancies and regions. This example is for an overlay service where the pre-prod ET is within the prod region. The service enclave service will have unstable tenancies and stable tenancies within Release 1. In DAG 400, IAD is the local airport code for Dallas Airport in Washington, D.C., YYZ is the local airport code for Toronto, Ontario, PHX, LHR, and FRA are the local airport codes for Phoenix, London, and Frankfurt, respectively, and LUF and LFI are for two different air force bases.

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

[0066] FIG. 5 is a schematic diagram of an exemplary user interface (UI) 500 according to at least one embodiment. UI 500 may include any suitable combination of an infrastructure area 502, an application area 504, and a task area 506. UI 500 may include the infrastructure area 502, the application area 504, and the task area 506 as arranged and shown in FIG. 5, or these areas may be arranged differently within UI 500.

[0067] The infrastructure area 502 can be located at any suitable position of the UI500. As shown in FIG. 5, the infrastructure area 502 is positioned at the upper left corner of the UI500. The infrastructure area 502 can include infrastructure release data corresponding to any suitable number of infrastructure releases (e.g., release name, number of execution targets on which the infrastructure components of the release are provisioned, one or more indicators of progress associated with the execution of the release, indicator of the latest infrastructure release, etc.). As shown, the infrastructure area 502 displays infrastructure release data corresponding to six releases titled "lovable", "excited", "elegant", "nuclear", "strange", and "aqueous". Item 508 displays infrastructure release data corresponding to the release "lovable" and includes a percentage (e.g., 75%) and a progress bar 510, each indicating that the release has been executed for 75% of the flock. The percentage and the progress bar 510 are exemplary user interface elements for indicating release progress, but it should be understood that any suitable user interface element may be used to display such progress (e.g., visually, in text, etc.). As an example, the progress of the corresponding infrastructure release may also or alternatively be displayed by a number, a table, or other suitable user interface elements for displaying progress. In some embodiments, a particular infrastructure release can be identified as the latest release using another suitable user interface element, including a label 512 or an icon, a check mark, etc. As shown in FIG. 5, item 508 includes a target number indicating the number of execution targets (e.g., 15) on which the infrastructure components corresponding to the release "lovable" are provisioned.In each item of the infrastructure area 502, the infrastructure release data provided may be arranged differently and may contain more or fewer attributes of the infrastructure release data corresponding to each release than the number of attributes shown in FIG. 5.

[0068] In some embodiments, the UI 500 may include an application area 504. The application area 504 may be located at any suitable position of the UI 500. In the example shown in FIG. 5, the application area 504 is positioned at the upper right corner of the UI 500. The application area 504 may include application release data corresponding to any suitable number of application releases (e.g., application release name, number of execution targets where the software artifacts of the release are deployed, one or more indicators of progress associated with the execution of the release (e.g., deployment of software artifacts), indicator of the latest application release, etc.). As shown, the application area 504 displays application release data corresponding to six application releases titled "Chuck", "Bob", "Felipe", "Asa", "Strange" and "Errol". Item 514 displays application release data corresponding to the application release "Chuck", and includes a percentage (e.g., 60%) and a progress bar 516 indicating that the release has been executed for 60% of the flock. The percentage and the progress bar 516 are exemplary user interface elements for indicating application release progress, but it should be understood that any suitable user interface element may be used to display such progress (e.g., visually, in text, etc.). As an example, the progress of the corresponding application release may also or alternatively be displayed by a number, a table, or other suitable user interface elements for displaying progress. In some embodiments, a particular infrastructure release may be identified as the latest release using another suitable user interface element including a label 518 or an icon, a checkmark, etc. As shown in FIG. 5, item 514 includes a target number indicating the number of execution targets (e.g., 12) where the artifacts (e.g., application code) corresponding to the release "Chuck" are provisioned.The application release data provided in each item of the application area 504 may be arranged differently and may contain more or fewer attributes of the application release data corresponding to each release.

[0069] In some embodiments, the UI 500 may include a task area 506. The task area 506 may be located at any suitable position of the UI 500. In the example shown in FIG. 5, it is positioned towards the lower half of the UI 500. The task area 506 may include target release information corresponding to each execution target of the flock. Each execution target in the examples provided herein may correspond to a region. The regions in the examples herein may comprise at least one physical location. The target release information may include an identifier for infrastructure release, a status (e.g., a visual indication of the status) corresponding to the progress of provisioning of infrastructure components for infrastructure release to the execution target, an identifier for application release, and a status (e.g., a visual indication of the status) indicating the progress of deployment of an artifact (e.g., application code) corresponding to that application release. The task area 506 may include any suitable number of columns and combinations of columns, such as an execution target column 520, an infrastructure change column 522, and / or an application change column 524. The execution target column 520 can be organized by phases, where the phases may indicate the order in which a release (e.g., including provisioning a set of infrastructure components and / or deploying a set of software artifacts) is executed across the execution targets. Four phases, Phase I, Phase II, Phase III, and Phase IV, are shown for the UI 500. In some embodiments, Phase I must be completed before the deployment enters Phase II, Phase II must be completed before Phase III, and so on. As shown, Phase I and II each include one execution target, Phase III includes four execution targets, and Phase IV includes twelve execution targets. These execution targets are applicable in parallel.

[0070] Each row of the task area 506 may correspond to a phase and / or an execution target. As an example, item 526 may correspond to a phase (e.g., Phase I) and a single execution target of that phase. Item 528 may correspond to Phase III. Item 530 may correspond to Phase IV. By default, items corresponding to the execution targets of a phase may be hidden. The selection of an item corresponding to a phase can cause the rows corresponding to the corresponding execution targets of that phase to appear. As an example, item 532 may initially be hidden and only item 530 may be displayed. In some embodiments, when item 530 is selected, item 532 may be displayed. Item 532 indicates a specific execution target / area of Phase IV to which infrastructure release (e.g., "rabbable") and application release (e.g., "chuck") correspond.

[0071] Infrastructure change column 522 may include the name of the infrastructure release for each phase or execution target and the status of the infrastructure release. In some embodiments, a phase that includes two or more execution targets may correspond to one or more infrastructure and / or application releases. Thus, in some embodiments, infrastructure change column 522 may include data indicating several different infrastructure releases utilized by the execution targets of the phase. As an example, indicator 534 may be displayed to indicate that there are three different infrastructure releases released to the execution target of Phase IV. Status indicator 536 may also be displayed within the infrastructure change column to indicate the status of each infrastructure release to each execution target of the phase. Status indicator 536 may individually indicate that the release to one or more execution targets has encountered an error, is in progress, or is complete. Similarly, application change column 524 may include an indicator 538 for indicating that one application release is utilized for each execution target of Phase IV, and a status indicator 540 for indicating the status of each application release for each execution target of Phase IV. For an item corresponding to a single execution target (e.g., item 532), infrastructure change column 522 may display the name and status of the infrastructure release. In some embodiments, the status (e.g., "completed", "failed", "in progress", "pending review", etc.) may be displayed in text as shown in FIG. 5, or the status may be displayed differently. For an item 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 that application release (e.g., "completed", "failed", "in progress", "pending review", etc.).The status displayed for an application release may be the same as or different from the status provided for an infrastructure release. In some embodiments, by selecting an item (e.g., selecting item 542), the item may be visually changed to display this selection (e.g., the background of the item may be changed). One exemplary change corresponding to the selection of item 542 is shown in FIG. 5. By selecting link 544, the user may be navigated to UI600 of FIG. 6, although other navigation actions may provide a similar result.

[0072] In some embodiments, if a release fails in at least one aspect, the status of this failure may be displayed in UI500. As an example, a failure in infrastructure component provisioning is displayed at 546, and a failure in software artifact deployment is displayed at 548. In some embodiments, user input may be received at 546 and / or 548 (e.g., selection of the word "failure"). In response to this user input, the user may be provided with one or more options to perform improvement measures (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, changing the provisioning and / or deployment tasks corresponding to the execution target, etc.).

[0073] FIG. 6 is a schematic diagram showing an exemplary UI 600 for providing information related to a selected release, according to at least one embodiment. The UI 600 may display a user interface where details of the release can be viewed. The release name section 602 is shown at the top of the UI 600, but the release name section 602 may be located at any suitable position on the UI 600. As shown, the release name section 602 may display release data associated with a particular release. As an example, the release data associated with the release "Excited" is shown as including a release name 604, a status 606, and a release identifier 608, but more or fewer attributes of the release data may be displayed. As shown, the release name 604 is "Excited", but the release name 604 may include any suitable alphanumeric identifier corresponding to the name of any suitable release in the desired flock. The status 606 may display the status associated with a particular release (e.g., "not started", "approval required", "applied", "failed", "completed", etc.). The release identifier 608 is shown as "09879iuhku7w", but the release identifier 608 may be any suitable ID that may be unique to the associated release.

[0074] The UI 600 may also include a status bar 610, which may contain information about the status of a related release (such as graph 612, timestamp 614, and status code 616). Similarly, status bar 618 may include graph 620, timestamp 622, and status code 624. Graphs 612 and 618 may display a numbered list of tasks. As an example, each node of graphs 612 and 618 may represent a set of tasks (e.g., "1" represents a set of 1 task, "9" represents a set of 9 tasks, etc.). If two or more tasks are shown in a node, this node may be intended to refer to a set of tasks that are executed in parallel. Each task may correspond to a release that corresponds to a specific target. The order of the nodes (e.g., from left to right) may indicate the sequence in which each set of tasks is executed. For example, the task associated with node 626 may be required to complete before the task associated with node 628 starts. Similarly, the task associated with node 628 may be required to complete before the task associated with node 630 starts. Each of the tasks associated with node 630 may be executed in parallel. Timestamp 614 may display the start date. Further, timestamp 614 may display the start time corresponding to the status code "start" and the end time corresponding to the status code "complete". Status code 624 may indicate that the associated task has been approved, timestamp 622 may indicate the start time corresponding to the task associated with node 632, and node 632 may be labeled "in progress" to indicate that the task is currently being executed. It should be understood that status codes 616 and 624 may be any suitable status codes for tracking the status of a related release (e.g., "approved", "in progress", "failed", "approval required", etc.).

[0075] In some embodiments, the status bar may be utilized to display the phase order. As an example, status bar 610 may correspond to a particular phase such as phase 1, and status bar 618 may correspond to a different phase such as phase 2. As described above, phases may be used to describe the order in which the phases are completed. As shown, the 11 phase 1 tasks shown in status bar 610 may be required to be completed before the 12 phase 2 tasks associated with status bar 618 are started. It should be understood that additional phases other than the two phases may be utilized. Considering the current window size, if the display of information corresponding to a phase or multiple phases is too wide to be displayed, the status bar 610 may be horizontally scrollable so that the user can scroll through the various phases to view their corresponding statuses. In some embodiments, status bar 610 utilizes "smart scrolling" so that the user can still scroll horizontally when using an input device (e.g., a mouse) with only a vertical scrolling function. As an example, the user may physically scroll downward using the input device, and status bar 610 will scroll to the right. When the user physically scrolls upward using the input device, status bar 610 may scroll to the left. Filters enable the user to focus on significant changes so that the user is less likely to be distracted by operational noise and miss significant changes or errors.

[0076] The phase plan section 634 can also be included in the UI 600 and, as shown, although the phase plan section 634 is below the UI 600, it may be arranged differently within the UI 600. The phase plan section 634 can contain information related to a desired phase (e.g., phase 2 corresponding to the status bar 618). As shown in the UI 600, the phase plan section 634 displays a phase title 636, a phase status 638, the number of execution targets 640, an overview of operations 642, a tenancy 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 can include the name of the selected phase of the release shown in the UI 600. This name can include any suitable alphanumeric identifier of any suitable length. In some embodiments, the phase status 622 can be the status of the selected phase of the release. As shown in the UI 600, the phase title 636 is "Phase II" and the phase status 638 is shown as "Approval required". The phase status 638 can be any suitable status for the selected phase of the release (e.g., "Approval required", "In progress", "Failed", "Completed", etc.). The number of execution targets 640 shown as "12" in the UI 600 can indicate any number of execution targets to which the release can be deployed. The overview of operations 642 can indicate the number of create operations, revision operations, update operations, and delete operations planned for that phase. As shown in the UI 600, the overview of operations 642 includes four different operations (listed left to right): create, update, delete, and read (e.g., no change). As shown in FIG. 6, there are 20 create operations, 20 update operations, 100 delete operations, and 1 no-change operation. The UI 600 can include any suitable number of operations or combinations of operations in the overview of operations 642. The overview of operations 642 can include four buttons corresponding to create, revise, update, and delete. Each of these buttons can be used as a toggle for filtering a corresponding set of operations from the phase plan section 634.For example, when the "Create" button is selected, all create operations can be filtered from the phase plan section 634. When the Create button is selected again, these create operations can be unfiltered and reappear within the phase plan section 634. By default, these buttons may be turned off (e.g., deselected) so that no operations are filtered, although any suitable default behavior may be utilized.

[0077] FIG. 6 shows changes under the influence of a particular execution target, but it should be understood that in some embodiments, similar changes may be grouped and the execution targets associated with each change may be displayed. Accordingly, the phase plan corresponding to FIG. 6 may be changed in two ways: to the execution target for the change (as shown) or to the change for the execution target.

[0078] The tenancy list 644 can be located at any suitable position on the UI 600, and the tenancy list 644 includes a list of execution target tasks including items corresponding to a specific set of tasks (e.g., item 652) corresponding to the nodes 632 of Phase II, and a list 654 of applications that are expected to be created, modified, or deleted during the execution of those tasks. To display the list 654 of applications, the user can select an option 655 to expand the list to display the applications included in the release (e.g., the SMS agent). As shown in the UI 600, the only currently displayed application is the "SMS agent" 658. The UI 600 can indicate the changes made to the configuration file of the SMS agent at 659. In some embodiments, the computing system providing the UI 600 can identify the previous configuration of a software artifact (e.g., the SMS agent), identify the new configuration of the deployed software artifact, and provide a display of the changes from the previous configuration to the new configuration of the software artifact (e.g., shown at 659). As shown, this change can include deleting line 5 (indicated by 5-) and adding a new line 5 (indicated by 5+). In some embodiments, a "change" (also referred to as an update) can include deletions as well as creations. The creation / deletion of an update can be displayed as an update operation rather than a creation / deletion within the CRUD operation column 648. The list 654 of applications can also include other suitable applications for the selected release.

[0079] The deployment progress column 646 can display the status of the release in the associated execution target. As shown in UI600, the status of the execution target for the shown release is "Applied", although any suitable status (e.g., "Applied", "Needs Approval", "Not Started", "Completed", "Failed", etc.) may be displayed. The CRUD operation column 648 can contain information about the operations to be performed on the associated target. These operations can include create commands, update commands, delete commands, or no-change commands, and these operations are applicable to each execution target, each application, or any suitable software and / or hardware components. The target review status column 650 can contain information about whether these operations have been reviewed on each entity. As shown in UI600, the target review status is shown as "Reviewed", although the target review status can be any status suitable for tracking the operations in the associated release.

[0080] The phase plan section 634 can also include a set of selection options (e.g., selection option 660), and this set of selection options can include options for "Plan", "Status", "Log", "Approval", etc. UI600 and the corresponding data are intended to be provided when the "Plan" option is selected.

[0081] The release history section 662 may also be located on the UI 600. As shown in the UI 600, although the release history section 662 is located in the left portion of the UI 600, the release history section 662 may be located at any suitable position on the UI 600. The release history section 662 may include information regarding various releases within the associated flock. As shown in the UI 600, three releases, namely "lovable", "excited", and "elegant", are displayed, but any suitable number of releases may be displayed in the release history section 662. By selecting any one of the releases from the release history section 662, corresponding data associated with that release for each of the above UI elements 602 - 660 may be displayed. 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 new release creation option 672. The target number 666 may indicate how many execution targets a particular release is intended to be provisioned for. The target number 666 is displayed for each particular release and may include any suitable number of targets for the associated release. The release timestamp 668 may include the time when the selected release was created or when the provisioning was completed, along with a status indicator (e.g., "created", "completed", etc.). The release timestamp 668 may be located at any suitable position on the associated release, or the release timestamp 668 may be absent for any particular release. The roll forward option 672 enables the user to redeploy a previously rolled-back configuration. The new release creation option 656 may enable the user to create a new release for the selected flock.

[0082] In some embodiments, the user may right - click the mouse to cause option 656 to appear. Option 656 may appear generally near the user's mouse cursor. By selecting option 656, the user may be navigated to UI800 of FIG. 8, which is further described below.

[0083] It should be understood that the user may be provided with a function to scroll up or down within the phase plan section 634 to view various portions of the data related to the selected particular phase. In some embodiments, a status bar (e.g., status bar 620) of the selected phase indicating that the corresponding phase has been selected and that the information in the phase plan section 634 corresponds to the selected phase may be highlighted and / or enlarged.

[0084] FIG. 7 is a schematic diagram showing an exemplary user interface (e.g., UI700) for viewing the release status according to at least one embodiment.

[0085] The release status section 704 may be located at any suitable position on the UI700. As shown in UI700, the release status section 704 is at the top of the UI700. The release status section 704 may be any suitable information related to the release, and this information may include the status of the release (e.g., "applied", "paused", "completed", "failed", etc.) and a timestamp including the time when the related release (e.g., the release corresponding to the related information shown in FIG. 7) started, completed, was paused, etc. The release status section 704 may include other suitable information for tracking the status of the related release.

[0086] In at least one embodiment, UI700 may include a phase plan section 706. In some embodiments, UI700 including the phase plan section 706 may be displayed in response to a selection of the "Status" option 702 of the selection option 660 of FIG. 6. By selecting the "Status" option 702, information about the status of the relevant release or other suitable information related to the status of the relevant release can be displayed.

[0087] In some embodiments, the phase plan section 706 can describe multiple sets of execution targets corresponding to a phase (e.g., phase II described above in relation to FIG. 6). As shown in FIG. 6 and similarly in FIG. 7, the phase can be associated with a graph 620 including nodes 632, 710, and 712. Each node can correspond to a set of tasks for that phase. As an example, execution target task sets 714, 716, and 718 can be described. 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 UI700, execution target task set 718 including 10 execution targets (e.g., shown in both node 712 and execution target task set 718) is selected. When execution target task set 718 is selected, the corresponding 10 execution tasks can be displayed as individual lines under execution target task set 718. As shown in FIG. 7, each task can correspond to a specific execution target for which the release is provisioned.

[0088] In some embodiments, a release option menu 720 may be provided. Selecting the release option menu 720 may provide several menu options (e.g., pause the release (not shown), release details, resume, cancel the release, etc.). In some embodiments, the release may be paused by selecting the release option menu 720 and subsequently selecting an option to pause the release. The view of the UI 700 is intended to display the state of the UI 700 after the release has been paused. In some embodiments, the paused state may be displayed in field 722. When the user hovers over field 722, status information regarding the paused state may be displayed as shown at 724. The information provided at 724 may include any suitable information about the state of a particular phase corresponding to a particular release.

[0089] After pausing the release, the user may select the release option menu 720 again to display the release details option 728, the resume option 730, and the release cancel option 732. The release details option 728, when selected, can display any suitable information about the associated release (e.g., release number). The resume option 712, when selected, can start the deployment of the associated release from where it was paused. The release cancel option 714, when selected, can cancel the associated release and remove the canceled release from the flock.

[0090] It should be understood that the user may be provided with the ability to scroll up or down within the phase plan section 634 to view different portions of the data associated with a selected particular phase.

[0091] FIG. 8 is a schematic diagram showing an exemplary user interface (e.g., UI800) for viewing logs associated with a release, according to at least one embodiment. In some embodiments, the UI800 including the phase plan section 634 may be displayed in response to the selection of the "Log" option 802 of the selection option 660 in FIG. 6. By selecting the "Log" option 802, information about the log and / or source code of the already selected execution target can be displayed, or a user interface option for accessing information about the log and / or source code of any suitable execution target corresponding to the selected phase (or a subsequently selected phase) can be provided.

[0092] The UI800 may include the phase plan section 634 of FIG. 6. The execution task set 804 may be selected to display one or more tasks of the execution task set 804. The execution task set 804 may correspond to the node 632 described above in relation to FIG. 6 and shown again in FIG. 8. In some embodiments, when the execution task set 804 is selected (or at any suitable time), a task 806 (e.g., UK-London) corresponding to providing a release at a specific execution target may be displayed. In some embodiments, the user may expand the task 806 (e.g., by selecting the option 808) to view one or more logs corresponding to that execution target.

[0093] FIG. 9 is a diagram showing an exemplary UI 900 that displays execution target resources for a selected execution target (e.g., the execution target corresponding to execution target task 806 from FIG. 8) according to at least one embodiment. The UI 900 can be displayed by clicking on the name of the execution target task 806 shown in FIG. 8 or by other suitable means, and the UI 900 can be updated with information about the execution target corresponding to the execution target task 806 by a periodic or forced refresh of the UI 900. The UI 900 can include the name 902 of the execution target and the version 904 of the flock. The name 902 and the version 904 can be located at any suitable position on the UI 900, but as shown in FIG. 9, they are located at the top of the UI 900.

[0094] UI900 may also include a resource section 906. In some embodiments, the resource section 906 can display any suitable number of infrastructure and / or software application components associated with a particular execution target. As an example, the resource section 906 can include various resources as shown at 908 (infrastructure components such as "Bob", "Carl", "DNS", etc.) and software artifacts such as application code (e.g., "Application 1", "Application 2", and "Test", etc.) as shown at 910. Each resource can indicate whether the resource is an infrastructure component (as shown at 910) or an application (as shown at 912). As shown at 912 and similarly at 914, each resource can have associated information such as a resource type (e.g., "Infra", "Application", etc.) and a resource count, where the resource count can be any number suitable for describing how many of each resource exist within the selected execution target. When selected, the resource can display a configuration (e.g., DNS) associated with the selected resource as seen in box 916, and other suitable information associated with the selected resource. As shown, it should be understood that UI900 can be displayed as a dialog box or another suitable pop-up window that can be overlaid on top of any suitable interface (e.g., UIs 500 - 800 of FIGS. 5 - 8).

[0095] FIG. 10 is a schematic diagram showing an exemplary user interface (e.g., UI1000) for displaying information about a selected phase of a selected release according to at least one embodiment. UI1000 may include a progress bar 1002, and the progress bar 1002 may include all phases of the selected release 1004 or any suitable subset of those phases. The progress bar 1002 is shown at the top of UI1000, but may be located at any suitable position on UI1000. The progress bar 1002 may also include various information about each phase of the selected release 1004, and this information includes, but is not limited to, phase name, number of execution targets, timestamp, approval status, phase status, and other suitable information related to each phase of the selected release 1004. The selected phase 1006 shown in the UI is "stable(13)", but any phase in the progress bar 1002 may be selected to display the relevant information about each phase. The selected phase 1006 may also include a circular progress bar 1007 that can visually track the progress of the collective tasks of the selected phase 1006. In other words, the circular progress bar 1007 may display (present) a visual representation of the progress corresponding to the phase. In some embodiments, the circular progress bar 1007 may pulsate to indicate that the tasks of the selected phase 1002 are currently in progress. In some embodiments, the circular progress bar 1007 may 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), and each portion corresponds to a certain task among a set of tasks associated with the phase. In some embodiments, the green portion (e.g., green indicator) of the circular progress bar 1007 may represent the completed tasks of the selected phase 1006, and the red portion (e.g., red indicator) of the progress bar 1007 may represent the failed tasks of the selected phase 1006.The white portion of the progress bar 1007 (e.g., the white indicator) may represent the tasks of the selected phase 1006 that have neither failed nor been completed. The UI 1000 may also include a release history section 1108 (e.g., the release history section 646 of FIG. 6), and the selected phase 1004 may be located within the release history section 1008 of the UI 1000.

[0096] Each execution task of the phase (e.g., corresponding to the execution target where the release is deployed) may be displayed in the status area 1010. In some embodiments, the tasks may be displayed in the order in which they are executed and / or at 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 displayed in the area 1010 may include a progress column 1012, an action column 1014, and other suitable information related to the tasks described. The progress column 1012 may display the progress status (e.g., "success", "failure", "applied", etc.) of each execution target in the list 1008 of execution targets. The action column 1014 may include information about what actions can be performed for each task of the selected phase 1006 (e.g., each task corresponding to the execution target of the selected phase 1006).

[0097] FIG. 11 is a schematic diagram showing an exemplary user interface 1100 that displays an execution graph for explaining the execution order of a set of execution tasks according to at least one embodiment. The selected phase 1102 can be selected from a progress bar 1104 (e.g., an example of the progress bar 1006 in FIG. 10). The section corresponding to the selected phase 1102 may include a graph 1106. The graph 1106 may show the order in which the execution tasks corresponding to the execution targets can be executed. As shown in UI 1100, the graph 1106 may include nodes 1108, 1110, and 1112. Node 1108 may be associated with one execution task corresponding to one execution target. Node 1110 may be associated with one execution task corresponding to one execution target. Node 1112 may be associated with seven execution tasks corresponding to seven execution targets. The graph 1106 shows the sequence of execution between each group of tasks corresponding to nodes 1108, 1110, and 1112. For example, the task associated with node 1108 may be required to complete before the task associated with node 1110 can start. Similarly, the task associated with node 1110 may be required to complete before the task associated with node 1112 can be executed. If a node includes two or more tasks, those 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 that are executed serially or in parallel. UI 1100 may display a list of each task in area 1114 in the order in which the tasks are executed. In some embodiments, tasks that can be executed in parallel may be displayed in area 1114 in any suitable order.

[0098] FIG. 12 is a schematic diagram showing an exemplary user interface (e.g., UI1200) that displays an execution status related to one or more phases of a selected release according to at least one embodiment. Phase 1202 may be located at a progress bar 1204 (e.g., an example of the progress bar 1002 in FIG. 10) or other suitable location on the UI1200. Phase 1002 may include a graph 1206 showing a specific sequence of task executions corresponding to nodes 1208 and 1210. As shown in UI1200, the task corresponding to node 1208 may be executed before the task corresponding to node 1210. A circular progress bar 1212 (e.g., an example of the circular progress bar 1007 in FIG. 10) may be utilized for each node to indicate the status of the execution task of each node. As shown by the circular progress bar 1212, the task corresponding to node 1208 is complete, while the task corresponding to node 1210 may still be in progress.

[0099] UI1200 may also include a task list 1214. When phase 1002 is selected, the execution targets corresponding to each task may be displayed in the task list 1214. As shown in UI1200, the execution task corresponding to node 1208 may be displayed at 1216, and the execution task corresponding to node 1210 may be displayed at 1218. Thus, in some embodiments, these execution tasks may be displayed in an order corresponding to the execution order. Statuses 1220 and 1222 may be displayed in the task list 1214. Status 1220 may correspond to a text display of the status corresponding to node 1208, and status 1222 may correspond to a text display of the status corresponding to node 1210.

[0100] FIG. 13 is a schematic diagram showing an exemplary user interface (e.g., UI1300) that displays an exemplary security plan according to at least one embodiment. UI1300 may include an execution task list 1302 (e.g., the execution task list 1008 of FIG. 10) that may be located at any suitable position on UI1300, and as shown, this execution task list 1302 is at the top of UI1300. The execution task list 1302 may correspond to changing software resources associated with an execution target from a first state to a second state. In some embodiments, UI1300 may be utilized to display a set of changes applied to those software resources as part of changing the software resources from a first state to a second state. As shown, the execution task list 1302 includes an execution task 1304 corresponding to the target (e.g., labeled "unstable"), and the execution task 1304 can display module 1306 when selected, and module 1306 can then display module 1308 (labeled "app_deployment" as shown) when selected, and module 1308 can display module 1310 when selected. The execution target 1304 may display any suitable number of modules and / or application deployments corresponding to the execution task 1304. In embodiments having two or more modules 1306, the modules 1306 may be listed in descending order of the number of create, update, delete, or no-change operations. As an example, modules 1306 - 1310 may be displayed such that the module with the most create operations is listed at the top of the list, and the remaining tasks are displayed in descending order according to the corresponding number of create operations for each task. In some embodiments, modules 1306 - 1310 may be arranged differently (e.g., in ascending order, or in any other suitable way for arranging modules 1306 - 1310). In some embodiments, when module 1310 is selected, UI1300 may display a security plan log 1312, and other suitable information corresponding to task 1304.

[0101] The safety plan log 1312 can be displayed at any suitable position on the UI 1300. However, as shown in the UI 1300, the safety plan log 1310 is located in the lower right corner of the UI 1300. The safety plan log can display information about changes made to the application code corresponding to the module 1310. For example, line 1314 can indicate an added line of code, and line 1316 can indicate a deleted line of code that has been replaced by line 1314. In some embodiments, line 1312 (and / or any portion of the added code) can be displayed with a green background or other colored background suitable for identifying one or more lines of the added code. Line 1314 (e.g., or any portion of the deleted code) can be displayed with a red background or other colored background suitable for identifying one or more lines of the deleted code.

[0102] Using the UI 1300, the user can be enabled to view each planned code change for each part of the task.

[0103] FIG. 14 is an exemplary flow diagram showing a process 1400 for implementing the CIOS technology according to a particular embodiment of the present disclosure. This process is shown as a logical flow diagram, and each of its operations may be implemented in hardware, in computer instructions, or in a combination thereof. In the context of computer instructions, these operations may represent computer-executable instructions stored on one or more computer-readable storage media that execute the operations described as being performed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be construed as limiting, and any number of the described operations can be combined in any order and / or in parallel to implement this process.

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

[0105] Process 1400 may start at block 1402, where the computing system executes a declarative infrastructure provisioner (e.g., regional CIOS 202 of FIG. 2). As described above in connection with FIG. 2, a declarative infrastructure provisioner (such as regional CIOS 202) may provision resources using a declarative file that describes components and how they interact. Since the configuration file can describe resources and the associated fields required to create elements, other elements that reference previously described elements can also be described. In some examples, the provisioning tool can then generate a workflow for creating and managing the elements described in the configuration file. In some embodiments, the declarative infrastructure provisioner may utilize declarative statements formatted according to Terraform, a tool for building, changing, and versioning infrastructure components.

[0106] Process 1400 may proceed to block 1404, where the computing system provisions a first set of infrastructure components. This 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.

[0107] Process 1400 may proceed to block 1406, where the computing system deploys a second set of software artifacts. This second set of software artifacts may be based at least in part on the computing system providing a second set of declarative instructions to a declarative infrastructure provisioner.

[0108] Process 1400 may proceed to block 1408, where the computing system provides a user interface system that displays a set of user interface elements (e.g., infrastructure area 502 and application area 504 of FIG. 5). These user interface elements may identify at least a first status (e.g., progress bar 510) associated with provisioning the first set of infrastructure components and a second status (e.g., progress bar 516) associated with deploying the second set of software artifacts.

[0109] It should be understood that the computing system may be configured to provide any suitable interface, such as user interfaces 500-1300 of FIGS. 5-13 above.

[0110] Exemplary system Figures 15 to 17 are diagrams showing aspects of an exemplary environment for realizing aspects of the present disclosure according to various embodiments. FIG. 15 is a simplified diagram of a distributed system 1500 for realizing an embodiment of the present disclosure. In the illustrated embodiment, the distributed system 1500 includes one or more client computing devices 1502, 1504, 1506, and 1508, which are configured to operate by executing client applications (such as web browsers, proprietary clients (e.g., Oracle Forms), etc.) via one or more networks 1510. The server 1512 can be communicatively coupled to the remote client computing devices 1502, 1504, 1506, and 1508 via the network 1510.

[0111] In various embodiments, the server 1512 can be adapted to execute one or more services or software applications (such as services and applications that provide identity management services). In certain embodiments, the server 1512 can also provide other services or software applications that can include non-virtual environments and virtual environments. In some embodiments, these services can be provided to the users of the 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. And the users operating the client computing devices 1502, 1504, 1506, and / or 1508 can utilize one or more client applications to interact with the server 1512 and utilize the services provided by these components.

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

[0113] Client computing devices 1502, 1504, 1506 and / or 1508 may include various types of computing systems. For example, a client computing device may be a portable handheld device (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)) or a wearable device (e.g., Google Glass® head-mounted display) that runs software (such as Microsoft Windows Mobile™) and / or various mobile operating systems (iOS, Windows Phone, Android™, BlackBerry 10, Palm OS, etc.). These devices may support various applications (such as various Internet-related applications, email, short message service (SMS) applications, etc.) and may use various other communication protocols. A client computing device may also include general-purpose personal computers, which, by way of example, include personal computers and / or laptop computers that run various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. A client computing device may be a workstation computer that runs any of the various UNIX® or UNIX-like operating systems available in the market, and these UNIX® or UNIX-like operating systems include, but are not limited to, various GNU / Linux operating systems (such as Google Chrome OS, etc.).Also, the client computing device may also include an electronic device that can communicate via network 1510 (such as a sink client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect (registered trademark) gesture input device) and / or a personal messaging device, etc.).

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

[0115] The network 1510 in the distributed system 1500 can be any type of network with which those skilled in the art are familiar that can support data communication using any of a variety of available protocols, and these protocols include, but are not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internetwork Packet Exchange), AppleTalk, etc. By way of example only, the network 1510 can be a local area network (LAN), an Ethernet (registered trademark)-based network, token ring, wide area network, Internet, virtual network, virtual private network (VPN), intranet, extranet, public switched telephone network (PSTN), infrared network, wireless network (e.g., a network operating under any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol suite, Bluetooth (registered trademark) and / or other wireless protocols), and / or any combination of these and / or other networks.

[0116] Server 1512 may be composed of one or more general-purpose computers, dedicated server computers (including, for example, PC (Personal Computer) servers, UNIX (registered trademark) servers, midrange servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or other appropriate configurations and / or combinations. Server 1512 may include one or more virtual machines that execute a virtual operating system, or other computing architectures that include virtualization. One or more flexible pools of logical storage devices may be virtualized to maintain virtual storage devices for the server. A virtual network may be controlled by Server 1512 using software-defined networking. In various embodiments, Server 1512 may be adapted to execute one or more of the services or software applications described in the foregoing disclosure. For example, Server 1512 may correspond to a server for executing the above processing according to an embodiment of the present disclosure.

[0117] Server 1512 may execute an operating system that includes any of the above, and any server operating system available on the market. Server 1512 may also execute any of various other server applications and / or middleware applications, and these applications include HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, JAVA (registered trademark) servers, database servers, etc. Exemplary database servers include, but are not limited to, those available on the market from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0118] In some implementations, server 1512 may include one or more applications for analyzing and consolidating data feeds and / or event update information received from users of client computing devices 1502, 1504, 1506, and 1508. As an example, the data feeds and / or event update information may include, but is not limited to, Twitter® feeds, Facebook® update information, or real-time update information received from one or more third-party information sources and continuous data streams, which may include real-time events related to sensor data applications, financial stock market dashboards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, etc. Server 1512 may also include one or more applications for displaying data feeds and / or real-time events via one or more display devices of client computing devices 1502, 1504, 1506, and 1508.

[0119] The distributed system 1500 may also include one or more databases 1514 and 1516. These databases may provide a mechanism for storing information such as identity information and other information used by embodiments of the present disclosure. Databases 1514 and 1516 may be in various locations. As an example, one or more of databases 1514 and 1516 may be on a non-transitory storage medium local to (and / or within) 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 a set of embodiments, databases 1514 and 1516 may be within a storage area network (SAN). Similarly, any necessary files for performing functions by server 1512 may be stored locally on and / or remotely from server 1512 as appropriate. In a set of embodiments, databases 1514 and 1516 may include relational databases (such as databases provided by Oracle Corporation) adapted to store, update, and retrieve data in response to commands formatted by SQL.

[0120] FIG. 16 is a diagram showing an exemplary computer system 1600 that may be used to implement an embodiment of the present disclosure. In some embodiments, computer system 1600 may be used to implement any of the various servers and computer systems described above. As shown in FIG. 16, computer system 1600 includes various subsystems including a processing subsystem 1604 that communicates with several 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. Storage subsystem 1618 may include a tangible computer-readable storage medium 1622 and a system memory 1610.

[0121] The bus subsystem 1602 provides a mechanism for the various components and subsystems of the computer system 1600 to communicate with each other as intended. Although the bus subsystem 1602 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1602 can be any of several types of bus structures, which include a memory bus or memory controller, a peripheral bus, and a local bus using any of various bus architectures. For example, such architectures can include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus that can be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard, among others.

[0122] The processing subsystem 1604 controls the operation of the computer system 1600 and may include one or more processing units such as 1632, 1634 etc. The processing unit can 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 can be implemented using customized circuitry (such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA), etc.).

[0123] In some embodiments, the processing unit within the processing subsystem 1604 can execute instructions stored within the system memory 1610 or on the computer-readable storage medium 1622. In various embodiments, the processing unit can execute various programs or code instructions and can maintain multiple simultaneously executing programs or processes. At any given time, some or all of the program code to be executed can be within the system memory 1610 and / or on the computer-readable storage medium 1622 (optionally including on one or more storage devices). Through suitable programming, the processing subsystem 1604 can provide the various functions described above for dynamically changing a document (e.g., a web page) in response to usage patterns.

[0124] In certain embodiments, the processing acceleration unit 1606 can be provided to execute customized processing or to offload a portion of the processing executed by the processing subsystem 1604 in order to accelerate the overall processing performed by the computer system 1600.

[0125] The I / O subsystem 1608 may include devices and mechanisms for inputting information into the computer system 1600 and / or outputting information from or via the computer system 1600. In general, the use of the term input device is intended to include all possible types of devices and mechanisms for inputting information into the computer system 1600. User interface input devices may include, for example, a keyboard, a pointing device (such as a mouse or trackball), a touchpad or touch screen incorporated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, an audio input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may also include a motion sensing and / or gesture recognition device (such as a Microsoft Kinect (registered trademark) motion sensor) that enables a user to control the input device and interact with it, a Microsoft Xbox (registered trademark) 360 game controller, and a device that provides an interface for receiving input using gestures and spoken commands. User interface input devices may further include an eye gesture recognition device (such as a Google Glass (registered trademark) blink detector) that detects a user's eye movement (such as a "blink" while taking a photo and / or making a menu selection) and converts it into an input to the input device (such as Google Glass (registered trademark)). Additionally, user interface input devices may include a voice recognition sensing device that enables a user to interact with a voice recognition system (such as a Siri (registered trademark) navigator) via voice commands.

[0126] Other examples of user interface input devices include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, and audio / visual devices (such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices). Further, the user interface input device may include, for example, medical imaging input devices (such as computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound examination devices, etc.). The user interface input device may also include, for example, audio input devices (such as MIDI keyboards, digital musical instruments, etc.).

[0127] User interface output devices may include a display subsystem, indicator lights, or non-visual displays (such as audio output devices). The display subsystem may be a cathode ray tube (CRT), a flat panel device (such as one using a liquid crystal display (LCD) or a 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 the user or another computer. For example, user interface output devices may include, but are not limited to, various display devices (such as monitors, printers, speakers, headphones, automotive navigation systems, plotters, voice output devices, and modems) that visually convey text, graphics, and audio / video information.

[0128] Storage subsystem 1618 provides a repository or data store 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 structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provides the above functionality when executed by processing subsystem 1604 may be stored in storage subsystem 1618. This software may be executed by one or more processing units of processing subsystem 1604. Storage subsystem 1618 may also provide a repository for storing data used in accordance with the present disclosure.

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

[0130] As an example, as shown in FIG. 16, the system memory 1610 may store, but is not limited to, an application program 1612 (which may include a client application, a web browser, a middle-tier application, a relational database management system (RDBMS), etc.), program data 1614, and an operating system 1616. As an example, the operating system 1616 may be various versions of Microsoft Windows (registered trademark), Apple Macintosh (registered trademark), and / or Linux operating systems, UNIX (registered trademark) or UNIX-based operating systems available in various markets (including, but not limited to, various GNU / Linux operating systems, Google Chrome (registered trademark) OS, etc.), and / or mobile operating systems (iOS, Windows (registered trademark) Phone, Android (registered trademark) OS, BlackBerry (registered trademark) 10 OS, and Palm (registered trademark) OS operating systems).

[0131] The computer-readable storage medium 1622 may store programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processing subsystem 1604, causes the processor to provide the above-described functionality may be stored in the storage subsystem 1618. By way of example, the computer-readable storage medium 1622 may include non-volatile memory (hard disk drive, magnetic disk drive, optical disk drive (such as CD ROM, DVD, Blu-ray (registered trademark) disk, or other optical media), or other optical media). The computer-readable storage medium 1622 may include, but is not limited to, Zip (registered trademark) drive, flash memory card, Universal Serial Bus (USB) flash drive, Secure Digital (SD) card, DVD disk, digital video tape, etc. The computer-readable storage medium 1622 may also include solid state drives (SSDs) based on non-volatile memory (such as flash memory-based SSDs, enterprise flash drives, solid state ROMs), SSDs based on volatile memory (such as solid state RAM, dynamic RAM, static RAM), DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM-based SSDs and flash memory-based SSDs. The computer-readable medium 1622 may provide storage of computer-readable instructions, data structures, program modules, and other data to the computer system 1600.

[0132] In certain embodiments, the storage subsystem 1600 may also include a computer-readable storage medium reader 1620 that is further connectable to the computer-readable storage medium 1622. Together with and optionally in combination with the system memory 1610, the computer-readable storage medium 1622 may comprehensively represent a combination of remote, local, fixed, and / or removable storage devices and storage media for storing computer-readable information.

[0133] In certain embodiments, computer system 1600 may provide support for running one or more virtual machines. Computer system 1600 may execute a program (such as a hypervisor) to facilitate the configuration and management of virtual machines. Each virtual machine may be allocated memory, computers (e.g., processors, cores), I / O, and networking resources. Each virtual machine may execute its own operating system, which may be the same as or different from the operating systems executed by other virtual machines executed by computer system 1600. Thus, in some cases, multiple operating systems may be executed simultaneously by computer system 1600. Each virtual machine generally operates independently of other virtual machines.

[0134] Communication subsystem 1624 provides an interface to other computer systems and networks. Communication subsystem 1624 serves as an interface for sending and receiving data between other systems and computer system 1600. For example, communication subsystem 1624 may enable computer system 1600 to establish a communication channel with one or more client devices via the Internet for sending and receiving information with the client devices. Additionally, communication subsystem 1624 may be used to convey a notification of a successful login or a notification to the requesting user to re-enter a password from a privileged account manager.

[0135] Communication subsystem 1624 may support both wired and / or wireless communication protocols. For example, in certain embodiments, communication subsystem 1624 may include radio frequency (RF) transceiver components, global positioning system (GPS) receiver components, and / or other components for accessing wireless voice and / or data networks (e.g., using cellular phone technology, advanced data network technology (such as 3G, 4G or EDGE (Enhanced Data rates for GSM Evolution)), WiFi (IEEE802.11 family of standards), or other mobile communication technologies, or any combination thereof), and may provide a wired network connection (e.g., Ethernet) in addition to, or instead of, the wireless interface.

[0136] Communication subsystem 1624 can transmit and receive data in various formats. For example, in some embodiments, communication subsystem 1624 may receive input communication in the form of structured and / or unstructured data feeds 1626, event streams 1628, event update information 1630, etc. For example, communication subsystem 1624 may be configured to receive (or transmit) data feeds 1626 and / or other communication services (e.g., Twitter (registered trademark) feeds, Facebook (registered trademark) update information, web feeds (such as Rich Site Summary (RSS) feeds), and / or real-time update information from one or more third-party information sources) in real time from users of social media networks.

[0137] In certain embodiments, the communication subsystem 1624 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1628 of real-time events and / or event update information 1630 that is substantially continuous or infinite and has no clear end. Examples of applications that generate continuous data include, for example, sensor data applications, financial stock market dashboards, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0138] Also, the communication subsystem 1624 may be configured to output structured and / or unstructured data feeds 1626, event streams 1628, event update information 1630, etc. to one or more databases that may communicate with one or more streaming data source computers coupled to the computer system 1600.

[0139] The computer system 1600 can be one of various types, including handheld portable devices (e.g., iPhone (registered trademark) mobile phone, iPad (registered trademark) computing tablet, PDA), wearable devices (e.g., Google Glass (registered trademark) head-mounted display), personal computers, workstations, mainframes, kiosks, server racks, or other data processing systems.

[0140] Due to the constantly changing nature of computers and networks, the description of the computer system 1600 shown in FIG. 16 is intended as a specific example only. Many other configurations with more or fewer components than the system shown in FIG. 16 are possible. Based on the disclosure and teachings provided herein, those skilled in the art will understand other aspects and / or methods for implementing various embodiments.

[0141] The systems shown in some of the drawings may be provided in various configurations. In some embodiments, these systems may be configured as distributed systems in which one or more components of the system are distributed across one or more networks within one or more cloud infrastructure systems.

[0142] A cloud infrastructure system is an aggregation of one or more server computing devices, network devices, and / or storage devices. These resources can be partitioned by a cloud service provider and allocated to its customers in some way. For example, a cloud service provider (such as Oracle in Redwood Shores, California) can provide various types of cloud services (including, but not limited to, one or more services provided under the Software-as-a-Service (SaaS) category, services provided under the Platform-as-a-Service (PaaS) category, services provided under the Infrastructure-as-a-Service (IaaS) category, or other categories of services including hybrid services). Examples of SaaS services include, but are not limited to, the ability to build and provide a set of on-demand applications (such as Oracle Fusion applications). SaaS services enable customers to utilize these applications without the need for the customers to purchase software for the applications to be run on the cloud infrastructure system. Examples of PaaS services include, but are not limited to, services that enable an organization (such as Oracle) to rationalize and integrate existing applications on a common shared architecture, the ability to build new applications that utilize shared services provided by the platform (such as Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.). IaaS services can facilitate the management and control of basic computing resources (such as storage, network, and other basic computing resources) for customers who utilize the services provided by SaaS platforms and PaaS platforms.

[0143] FIG. 17 is a simplified block diagram of one or more components of a system environment 1700 in which services provided by one or more components of the system according to an embodiment of the present disclosure 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, and the one or more client computing devices 1704, 1706, and 1708 can be used by a user to interact with a cloud infrastructure system 1702 that provides cloud services. These client computing devices can be configured to operate a client application (such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application), and this client application can interact with the cloud infrastructure system 1702 and be used by the user of the client computing device to use the services provided by the cloud infrastructure system 1702.

[0144] It should be understood that the cloud infrastructure system 1702 shown in the figure may have components other than those shown. Further, the illustrated embodiment is merely an example of a cloud infrastructure system that can incorporate an embodiment of the present disclosure. In some other embodiments, the cloud infrastructure system 1702 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different configurations or arrangements of components.

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

[0146] Exemplary system environment 1700 is shown with three client computing devices, but any number of client computing devices may be supported. Other devices (such as devices equipped with sensors) may interact with cloud infrastructure system 1702.

[0147] Network 1710 may facilitate data communication and exchange between clients 1704, 1706, and 1708 and cloud infrastructure system 1702. Each network can be any type of network with which those skilled in the art are familiar and which can support data communication using any of a variety of protocols available in the market, including those described above for network 1510.

[0148] Cloud infrastructure system 1702 may comprise one or more computers and / or servers that may include those described above for server 1512.

[0149] In certain embodiments, the services provided by a cloud infrastructure system can include a number of services made 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 a cloud infrastructure system can scale dynamically to meet the needs of its users. A particular instantiation of a service provided by a cloud infrastructure system is referred to herein as a "service instance". Generally, any service made available to a user 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 a cloud service provider's system are different from a customer's own on-premises servers and systems. For example, a cloud service provider's system can operate and manage applications, and a user can order and use an application on demand via a communication network such as the Internet.

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

[0151] In certain embodiments, the cloud infrastructure system 1702 can include a series of application, middleware, and database service offerings that are provided to customers 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 assignee.

[0152] In various embodiments, the cloud infrastructure system 1702 can be adapted to automatically provision, manage, and track customer subscriptions to services provided by the cloud infrastructure system 1702. The cloud infrastructure system 1702 can provide cloud services via various deployment models. For example, the services may be owned by an organization that sells cloud services (such as owned by Oracle) provided by the cloud infrastructure system 1702 and provided under a public cloud model where the services are made available to the general public or different industry enterprises. As another example, the services may be provided under a private cloud model where the cloud infrastructure system 1702 operates exclusively for a single organization and can provide services to one or more entities within that organization. Also, the cloud services may 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 the relevant community. Additionally, the cloud services may be provided under a hybrid cloud model that is a combination of two or more different models.

[0153] In some embodiments, the services provided by the cloud infrastructure system 1702 can 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 customer can order one or more services provided by the cloud infrastructure system 1702 via a subscription order. The cloud infrastructure system 1702 then executes processing to provide the services in the customer's subscription order.

[0154] 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, the application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services corresponding to the SaaS category. For example, the SaaS platform may provide a function of building and providing a series of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the basic software and infrastructure for providing the SaaS services. By using the services provided by the SaaS platform, customers can utilize the applications running in the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. Various different SaaS services may be provided. Examples thereof include, but are not limited to, services that provide sales performance management, enterprise integration, and solutions for business flexibility to large organizations.

[0155] In some embodiments, the platform service can be provided via a PaaS platform by a cloud infrastructure system. The PaaS platform can be configured to provide cloud services corresponding to the PaaS category. Examples of platform services include, but are not limited to, services that enable an organization (such as Oracle) to organize and integrate existing applications on a common architecture for sharing, and the ability to build new applications that utilize shared services provided by the platform. The PaaS platform can manage and control the basic software and infrastructure for providing PaaS services. Customers can obtain the PaaS services provided by the cloud infrastructure system without having 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), and the like.

[0156] By using the services provided by the PaaS platform, customers can use the programming languages and tools supported by the cloud infrastructure system and can 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 customers in the form of a database cloud. The middleware cloud service may provide a platform in the cloud infrastructure system for customers to develop and deploy various business applications, and the Java cloud service may provide a platform in the cloud infrastructure system for customers to deploy Java applications.

[0157] Various different infrastructure services can be provided in the cloud infrastructure system by the IaaS platform. The infrastructure services facilitate the management and control of basic computing resources (such as storage, network, and other basic computing resources) for customers who use the services provided by the SaaS platform and the PaaS platform.

[0158] In certain embodiments, the cloud infrastructure system 1702 may also include infrastructure resources 1730 for providing resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, the infrastructure resources 1730 may include a pre-integrated and optimized combination of hardware (such as servers, storage, and networking resources) for running services provided by the PaaS platform and the SaaS platform.

[0159] In some embodiments, the resources in the cloud infrastructure system 1702 are shared by multiple users and can be dynamically reallocated per request. Further, the resources can be allocated to users in different time zones. For example, the cloud infrastructure system 1702 enables a first group of users in a first time zone to utilize the resources of the cloud infrastructure system for a certain period of time, and then enables reallocation of the same resources to another group of users located in a different time zone, thereby maximizing resource utilization.

[0160] In certain embodiments, some internal shared services 1732 may be provided that are shared by various components or modules of the cloud infrastructure system 1702 and by the services provided by the cloud infrastructure system 1702. These internal shared services can 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 to enable cloud support, email services, notification services, file transfer services, and the like.

[0161] In certain embodiments, the cloud infrastructure system 1702 may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in a cloud infrastructure system. In one embodiment, cloud management functions may include functions such as provisioning, managing, and tracking customer subscriptions received by the cloud infrastructure system 1702.

[0162] In one embodiment, as shown in the figure, the cloud management functions may be provided by one or more modules (such as an order management module 1720, an order orchestration module 1722, an order provisioning module 1724, an order management and monitoring module 1726, and an identity management module 1728). These modules may include or be provided using one or more computers and / or servers, which may be general-purpose computers, dedicated server computers, server farms, server clusters, or other suitable configurations and / or combinations.

[0163] In exemplary operation 1734, a customer may interact with cloud infrastructure system 1702 using a client device (such as client devices 1704, 1706, or 1708) 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), namely 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 the customer placing an order may include information identifying the customer and the one or more services provided by cloud infrastructure system 1702 that the customer intends to contract for.

[0164] After the order is placed by the customer, the order information is received via cloud UIs 1712, 1714, and / or 1716.

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

[0166] In operation 1738, the order information is transferred to order management module 1720. In some examples, order management module 1720 may be configured to perform billing and charging functions related to the order (such as verifying the order and reserving the order upon verification).

[0167] In operation 1740, information regarding the order is communicated to the order orchestration module 1722. The order orchestration module 1722 can use the order information to orchestrate the provisioning of services and resources for the order placed by the customer. In some examples, the order orchestration module 1722 can use the services of the order provisioning module 1724 to orchestrate the provisioning of resources to support the subscribed services.

[0168] In certain embodiments, the order orchestration module 1722 enables the management of the business process associated with each order, applies business logic, and determines whether the order should proceed to provisioning. In operation 1742, upon receiving an order for a new subscription, the order orchestration module 1722 sends a request to the order provisioning module 1724 to allocate resources and configure those resources required to fulfill the subscription order. The order provisioning module 1724 enables the allocation of resources for the services ordered by the customer. The order provisioning module 1724 provides an abstraction level between the cloud services provided by the cloud infrastructure system 1702 and the physical implementation layer used to provision the resources for providing the requested services. This separates the order orchestration module 1722 from the implementation details (such as whether the services and resources are actually provisioned on-the-fly or whether the services and resources are pre-provisioned and only allocated / assigned upon request, etc.).

[0169] In operation 1744, when services and resources are provisioned, a notification of the provided services can be sent by the order provisioning module 1724 of the cloud infrastructure system 1702 to the customers on the client devices 1704, 1706, and / or 1708. In operation 1746, the customer's subscription orders can be managed and tracked by the order management and monitoring module 1726. In some examples, the order management and monitoring module 1726 can be configured to collect usage statistics of the services in the subscription orders (such as the amount of storage used, the amount of data transferred, the number of users, and the amount of system uptime and system downtime).

[0170] In certain embodiments, the cloud infrastructure system 1700 can include an identity management module 1728. The identity management module 1728 can be configured to provide identity services (such as access management and authorization services in the cloud infrastructure system 1700). In some embodiments, the identity management module 1728 can control information about customers who desire to utilize the services provided by the cloud infrastructure system 1702. Such information can include information for authenticating the identities of such customers and information describing what actions they are authorized to perform on various system resources (such as files, directories, applications, communication ports, memory segments, etc.). The identity management module 1728 can also include management of the descriptive information for each customer and information about how and by whom that descriptive information can be accessed and modified.

[0171] While specific embodiments of the present disclosure have been described, various variations, modifications, alternative configurations, and equivalents are also included within the scope of the present disclosure. Embodiments of the present disclosure are not limited to operating within a specific, concrete data processing environment, but can operate freely within multiple data processing environments. Further, while embodiments of the present disclosure have been described using a specific set 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 recited set of transactions and steps. The various features and aspects of the above embodiments may be used individually or in combination.

[0172] Furthermore, while embodiments of the present disclosure have been described using a specific combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments of the present disclosure may be implemented using only hardware, only software, or a combination thereof. The various processes described herein may be implemented on the same processor or on any combination of different processors. Thus, components or modules are described as being configured to perform certain operations, but such configurations can be achieved, 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 by any combination thereof. Processes can communicate using various techniques (including, but not limited to, conventional techniques for inter-process communication), different process pairs may use different techniques, and the same process pair may use different techniques at different times.

[0173] Accordingly, the specification and drawings are to be considered in an illustrative, rather than a limiting sense. However, it will be apparent that additions, subtractions, deletions, and other modifications and variations may be made without departing from the broader spirit and scope as set forth in the claims. Accordingly, while specific embodiments of the disclosure have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims. These modifications include any relevant combination of the disclosed features.

Claims

1. A method executed by a computer, comprising: a computing system executing a declarative infrastructure provisioner; the computing system executing an infrastructure release based on provisioning a first set of infrastructure components across a first plurality of execution targets, at least in part based on providing a first set of declarative instructions to the declarative infrastructure provisioner; the computing system executing an application release based on deploying a second set of software artifacts across a second plurality of execution targets, at least in part based on providing a second set of declarative instructions to the declarative infrastructure provisioner; the computing system providing a user interface comprising a plurality of user interface elements, the plurality of user interface elements comprising: (i) a first region displaying a first release status corresponding to each execution of a plurality of the infrastructure releases; (ii) a second region displaying a second release status corresponding to each execution of a plurality of the application releases; (iii) a third region displaying a first status of execution of an infrastructure release at a particular execution target and a second status of execution of an application release at the particular execution target; wherein the first region, the second region, and the third region are adjacent to each other and visually displayed simultaneously. A method executed by a computer.

2. The method executed by a computer according to claim 1, wherein the execution target corresponds to a predefined area comprising at least one physical location.

3. The method executed by a computer according to claim 1 or 2, further comprising the step of displaying a visual representation of progress corresponding to a certain phase among a plurality of phases, wherein each phase of the plurality of phases is associated with the step of provisioning each set of infrastructure components or the step of deploying each set of software artifacts to a set of execution targets, each execution target of the set of execution targets corresponds to a predefined area having at least one physical location, and the plurality of phases are associated with a predefined execution order.

4. The method executed by a computer according to claim 3, wherein the step of displaying the visual representation of progress corresponding to the phase comprises the step of displaying each indicator of status corresponding to the set of execution targets within the visual representation of progress corresponding to the phase.

5. The computing system identifying a previous configuration of a certain software artifact among the second set of software artifacts; The computing system identifying a new configuration of the software artifact at least partially based on the step of deploying the second set of software artifacts; The method executed by a computer according to any one of claims 1 to 4, further comprising the step of the computing system providing, via the user interface, a display of the change from the previous configuration to the new configuration of the software artifact.

6. The computing system detecting a failure in provisioning at least one infrastructure component among the first set of infrastructure components; The computing system displaying the indication of the failure via the user interface; The computing system receiving user input; The method executed by a computer according to any one of claims 1 to 5, further comprising the step of the computing system executing at least one improvement measure in response to the user input.

7. The step of the computing system detecting a failure in the deployment of at least one software artifact among the second set of software artifacts; The step of the computing system displaying the indication of the failure via the user interface; The step of the computing system receiving user input; The method executed by a computer according to any one of claims 1 to 6, further comprising the step of the computing system executing at least one improvement measure in response to the user input.

8. The step of deploying the second set of software artifacts comprises the step of changing software resources associated with an execution target from a first state to a second state, and the method executed by the computer further comprises the step of the computing system displaying a set of changes applied to the software resources as part of the step of changing the software resources from the first state to the second state. The method executed by a computer according to any one of claims 1 to 7.

9. In the first region, further, the number of targets of the first plurality of execution targets is displayed, The method executed by a computer according to any one of claims 1 to 8, wherein in the second region, further, the number of targets of the second plurality of execution targets is displayed.

10. A system, One or more processors; One or more memories storing computer-executable instructions, which, when executed by the one or more processors, cause the system to, Execute a declarative infrastructure provisioner, Execute an infrastructure release based on provisioning a first set of infrastructure components across a first plurality of execution targets, at least in part based on providing a first set of declarative instructions to the declarative infrastructure provisioner. Execute an application release based on deploying a second set of software artifacts across a second plurality of execution targets, at least in part based on providing a second set of declarative instructions to the declarative infrastructure provisioner. Provide a user interface comprising a plurality of user interface elements, the plurality of user interface elements comprising: (i) a first region that displays a first release status corresponding to each execution of a plurality of the infrastructure releases; (ii) a second region that displays a second release status corresponding to each execution of a plurality of the application releases; (iii) a third region that displays a first status of execution of an infrastructure release at a particular execution target and a second status of execution of an application release at the particular execution target, wherein the first region, the second region, and the third region are adjacent to each other and are visually displayed simultaneously.

11. The system according to claim 10, wherein the execution target corresponds to a predefined area comprising at least one physical location.

12. Further, the execution of the instructions causes the system to display a visual representation of progress corresponding to a particular phase among a plurality of phases, each phase of the plurality of phases being associated with provisioning each set of infrastructure components or deploying each set of software artifacts to a set of execution targets, each execution target of the set of execution targets corresponding to a predefined area comprising at least one physical location, and the plurality of phases being associated with a predefined execution order. The system according to claim 10 or 11.

13. Further, the execution of the instructions causes the system to: identify a previous configuration of a particular software artifact among the second set of software artifacts. Identifying a new configuration of the software artifacts, at least in part based on deploying the second set of software artifacts; The system according to any one of claims 10 to 12, wherein the change from the previous configuration of the software artifacts to the new configuration is displayed via the user interface. **Claim 14** The execution of the instructions further causes the system to Detect a failure in provisioning at least one infrastructure component of the first set of infrastructure components or deploying at least one software artifact of the second set of software artifacts; Display the indication of the failure via the user interface; Receive user input; The system according to any one of claims 10 to 13, wherein at least one improvement measure is executed in response to the user input. **Claim 15** A method executed by a computer, the method comprising: A computing system providing a user interface that displays a plurality of user interface elements, the plurality of user interface elements including: (i) a first area that displays a first status associated with performing an infrastructure release based on provisioning a first set of infrastructure components across a first plurality of execution targets; (ii) a second area that displays a second status associated with performing an application release based on deploying a second set of software artifacts across a second plurality of execution targets; and (iii) a third area that displays the first status of performing the infrastructure release and the second status of performing the application release at a particular execution target, wherein the first area, the second area, and the third area are adjacent to each other and visually displayed simultaneously; The first area, the second area, and the third area are adjacent to each other and are visually displayed simultaneously. The method, executed by a computer, wherein 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 deployed at least in part based on the declarative infrastructure provisioner.

16. A system comprising: 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 provide a user interface that displays a plurality of user interface elements, the plurality of user interface elements including: (i) a first region that displays a first status associated with performing an infrastructure release based on provisioning a first set of infrastructure components across a first plurality of execution targets; (ii) a second region that displays a second status associated with performing an application release based on deploying a second set of software artifacts across a second plurality of execution targets; and (iii) a third region that displays the first status of performing an infrastructure release at a particular execution target and the second status of performing an application release at the particular execution target; wherein the first region, the second region, and the third region are adjacent to each other and visually displayed simultaneously; wherein 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 deployed at least in part based on the declarative infrastructure provisioner.

17. An apparatus comprising means for performing the steps of any one of claims 1 to 9 and 15.

18. A program for causing a computing device to execute the method of any one of claims 1 to 9 and 15.

Images