User interface techniques for infrastructure orchestration service

Abstract

To provide more efficient and reliable methods, systems and non-transitory computer-readable storage media for implementing a virtual cloud environment.SOLUTION: A method comprises: executing a declarative infrastructure provisioner; provisioning a first set of infrastructure components based on providing a first set of declarative instructions to the declarative infrastructure provisioner; deploying a second set of software artifacts based on providing a second set of declarative instructions to the declarative infrastructure provisioner; and providing a user interface presenting a plurality of user interface elements, the plurality of user interface elements identifying 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.SELECTED DRAWING: Figure 14

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a utility application of, and claims the benefit of and priority under 35 U.S.C. § 119(e) of, the following U.S. provisional and utility applications, the entire contents of which are incorporated by reference for all purposes: U.S. Provisional Application No. 62 / 963,456, filed January 20, 2020, entitled "USER INTERFACE TECHNIQUES FOR AN INFRASTRUCTURE ORCHESTRATION SERVICE," U.S. Provisional Application No. 62 / 964,596, filed January 22, 2020, entitled "USER INTERFACE TECHNIQUES FOR AN INFRASTRUCTURE ORCHESTRATION SERVICE" The patent application is U.S. Ser. No. 17 / 001,626, filed August 24, 2020, entitled "Compounds for a Novel Composition of a Novel Fluorescent Device." [Background technology]

[0002] background Today, cloud infrastructure services utilize many individual services to provision and deploy code and configuration (respectively) across many areas of the cloud infrastructure service. These tools require significant manual effort to use, especially given that provisioning is generally declarative and deploying code is essential. Furthermore, as the number of service teams and areas increases, the cloud infrastructure service must continue to grow. Some cloud infrastructure service strategies to deploy to more and smaller areas include a per-area fee, but these do not scale well. Summary of the Invention [Means for solving the problem]

[0003] Quick Overview Techniques for providing one or more user interfaces are disclosed herein. In some embodiments, a method is disclosed. The method may comprise: a computing system executing a declarative infrastructure provisioner; the computing system provisioning a first set of infrastructure components based at least in part on providing a first set of declarative instructions to the declarative infrastructure provisioner; the computing system deploying a second set of software artifacts based at least in part on providing a second set of declarative instructions to the declarative infrastructure provisioner; the computing system providing a user interface displaying a plurality of user interface elements, the plurality of user interface elements identifying 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.

[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 based at least in part 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 based at least in part on providing a second set of declarative instructions to the declarative infrastructure provisioner. The operations may further include providing a user interface displaying a plurality of user interface elements, the plurality of user interface elements identifying 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 computer-executable instructions that, 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 based at least in part 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 based at least in part on providing a second set of declarative instructions to the declarative infrastructure provisioner. The operations may further include providing a user interface displaying a plurality of user interface elements, the plurality of user interface elements identifying 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 computer-implemented method is disclosed that may include 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 components being provisioned at least in part based on a declarative infrastructure provisioner, and the second set of software artifacts being provisioned at least in part based on the declarative infrastructure provisioner.

[0007] In some embodiments, a system is disclosed that may include one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause the system to perform operations, such as providing a user interface that displays a plurality of user interface elements. The plurality of user interface elements may 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 being provisioned based at least in part on a declarative infrastructure provisioner, and the second set of software artifacts being 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 include one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause a computing device to perform operations. The operations may include providing a user interface 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.

[0009] In some embodiments, an apparatus is disclosed, which may comprise means for performing the steps of any of the method embodiments of the present disclosure.

[0010] To facilitate identifying the description of any particular element or act, the most significant digit(s) in a reference number refers to the figure number in which that element is first introduced. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service, according to at least one embodiment. [Figure 2]FIG. 1 is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service, according to at least one embodiment. [Figure 3] FIG. 1 is a flow diagram illustrating an exemplary flocculation according to at least one embodiment. [Figure 4] FIG. 1 is a flow diagram illustrating an exemplary flocculation according to at least one embodiment. [Figure 5] FIG. 1 is a schematic diagram illustrating an exemplary user interface according to at least one embodiment. [Figure 6] FIG. 1 is a schematic diagram illustrating an exemplary user interface for providing information related to a selected release, according to at least one embodiment. [Figure 7] FIG. 10 is a schematic diagram illustrating an exemplary user interface for viewing the status of a release, according to at least one embodiment. [Figure 8] FIG. 10 is a schematic diagram illustrating an exemplary user interface for viewing the status of a release, according to at least one embodiment. [Figure 9] FIG. 1 is a schematic diagram illustrating an exemplary user interface displaying execution target resources for a selected execution target, according to at least one embodiment. [Figure 10] FIG. 1 is a schematic diagram illustrating an exemplary user interface for displaying information about a selected phase of a selected release, according to at least one embodiment. [Figure 11] FIG. 1 is a schematic diagram illustrating an exemplary user interface displaying an execution graph to illustrate the execution order of a set of execution tasks, according to at least one embodiment. [Figure 12] FIG. 12 is a schematic diagram illustrating an example user interface showing an example UI 1200 displaying execution status associated with one or more phases of a selected release, according to at least one embodiment. [Figure 13]FIG. 1 is a schematic diagram illustrating an example user interface displaying an example safety plan, according to at least one embodiment. [Figure 14] FIG. 1 is a flow diagram illustrating an example process for generating a user interface for infrastructure provisioning, according to at least one embodiment. [Figure 15] FIG. 1 is a block diagram of a distributed system according to at least one embodiment. [Figure 16] A block diagram of one or more components of a system environment in which services provided by one or more components of an embodiment system may be provided as cloud services, according to at least one embodiment. [Figure 17] FIG. 1 is a block diagram of an exemplary computer system in which various embodiments of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE INVENTION

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

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

[0014] In some cases, IaaS providers may also provide various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) to accompany their infrastructure components. Thus, because these services may be policy-driven, IaaS users could implement policies to drive load balancing and maintain application availability and performance.

[0015] In some examples, IaaS customers can access resources and services over a wide area network (WAN) (e.g., the Internet) and use the cloud provider's services to install the remaining elements of their application stack. For example, a user may log into an IaaS platform, create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware (e.g., databases), and manage workloads and backups. They can even create storage buckets for VMs and install enterprise software on them. The customer can then use the provider's services to perform a variety of functions, including network traffic balancing, troubleshooting application problems, performance monitoring, and disaster recovery management.

[0016] In most cases, the cloud computing model requires the participation of a cloud provider. A cloud provider may, but need not, be a third-party service that specializes in providing (e.g., selling) IaaS. An entity may also choose to deploy a private cloud in which it becomes its own infrastructure service provider.

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

[0018] In some instances, IaaS provisioning may even mean obtaining computers or virtual hosts for use and installing required libraries or services on them. In most cases, deployment does not include provisioning, which may need to be performed first.

[0019] IaaS provisioning can present two distinct problems. First, there is the initial challenge of provisioning an initial set of infrastructure before anything is running. Second, there is the challenge of deploying the existing infrastructure once everything is provisioned (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure 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 entire topology of the infrastructure (e.g., which resources depend on which and how each of them works together) can be described declaratively. In some instances, once the topology is defined, workflows can be generated to create and / or manage the various components described in the configuration files.

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

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

[0022] In some examples, a provisioning tool workflow may be configured to execute various commands. One function that may be executed is view adjustment, in which the provisioning tool may compare its current view of the infrastructure (e.g., the expected state of the infrastructure) with how the infrastructure is actually operating. In some examples, executing the view adjustment function may include querying various resource providers or infrastructure resources to identify which resources are actually operating. Another function that the provisioning tool may execute is plan generation, in which the provisioning tool may compare the infrastructure components that are actually operating with how the provisioning tool wants their state to appear (e.g., the desired configuration). In other words, the plan generation function may determine what changes need to be made to bring the resources up to the latest expectations. In some examples, a third function is execution (e.g., apply) function, in which the provisioning tool may execute the plan generated by the plan generation function.

[0023] In general, a provisioning tool can be configured to take 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 perform the boots in that order without user intervention and / or without that information necessarily being included in the configuration file.

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

[0025] As mentioned above, there are generally two different tools used to handle the provisioning of infrastructure resources and the deployment of code to control the infrastructure resources, and the orchestration between these two tools is done manually. However, at scale, manual execution always leads to mismatches. Therefore, an automated tool that can both provision and deploy virtual infrastructure is a more efficient and reliable technique for realizing a virtual cloud environment. makes the technique possible.

[0026] In some instances, when two tools are used, problems can arise when a user manually makes changes to code between the provisioning and deployment phases. 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 a small change to the way a user codes something can cause major problems in the deployment phase. In some instances, the first time an operator performs an action in a new area (e.g., a typo in the code), the object coded with the typo may remain permanently. Even if an application is deployed with the typo and the application is unaffected by the typo (e.g., the application still functions), it may happen that further code changes are eventually affected by the typo and cause the entire system to crash. Thus, the techniques provided herein can eliminate the gap between provisioning and deployment, which can often cause problems.

[0027] Typically, deployment modeling is declarative, allowing infrastructure resources to be declared using configuration files. For example, deployment files are typically generated using generic representable state transfer (REST) ​​concepts (e.g., REST application programming interfaces (APIs)) using create-read-update-delete (CRUD) instructions. However, the deployment itself typically does not follow this concept. Furthermore, while infrastructure provisioning tools are often very powerful and / or expressive, tools for deployment are often much more restrictive in terms of the actions they can perform (e.g., they are imperative as opposed to declarative). Therefore, there has been a long-standing 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 implementing a cloud infrastructure orchestration service (CIOS) are described herein. Such techniques may be configured to manage both the provisioning and deployment of infrastructure assets within a cloud environment, as briefly described above. In some examples, a CIOS may include two classes of services: a central component and a regional component (e.g., a central CIOS and a regional CIOS). The following terminology is used throughout:

[0029] Infrastructure components: Long-lived pieces of infrastructure that support running code Examples: deployment applications, load balancers, Domain Name System (DNS) entries, object storage buckets, etc. Artifact: Code deployed to a deployment application or Kubernetes engine cluster, or configuration information (hereafter "config") applied to an infrastructure component. These can be read-only resources.

[0030] Deployment Tasks: Short-lived tasks that are often associated with deploying or testing code. Furthermore, deployment tasks are modeled as resources that do not live as long as the releases that create them.

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

[0032] CIOS maintains the state of its cloud infrastructure service declarative provisioners so that CIOS can control the lifecycle of these short-lived resources as it relates to releases.

[0033] Resource: A CRUD-enabled resource CIOS models each of the above constructs as a resource, and the next section explains this modeling in more detail.

[0034] Flock: A model of CIOS that encapsulates the control plane and all its components. It exists primarily to model ownership of infrastructure components and represent them. Flock config: describes the set of all infrastructure components, artifacts, and deployment tasks associated with a single service. Each flock has exactly one flock config, which is checked into source control.

[0035] Flock configs are declarative: they expect CIOS to provide the realm, domain, ad and artifact version as input.

[0036] A floc is granular. A floc consists of a single service and supporting infrastructure.

[0037] State: A snapshot of the state of every resource in a flock at a specific point in time. Release: A tuple of a specific version of a Flock config and the specific versions of any artifacts it references. Think of releases as describing a state that may not yet exist. Release Plan: The set of steps that CIOS will need to take to transition all areas 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. Apply: This is a noun. It is a single attempt to execute a release plan. An execution changes the current state of the flock.

[0038] CIOS can be described as an orchestration layer that applies configuration to downstream systems (e.g., globally). It is designed to enable infrastructure provisioning and code deployments globally without manual effort from service teams (e.g., potentially beyond initial approval). High-level responsibilities of CIOS include, but are not limited to:

[0039] Providing teams with a view into the current state of resources managed by the CIOS, including any ongoing change activity Helping the team plan and release new changes Coordinating activities across various downstream systems within a domain to execute approved release plans without human intervention Coordinate activities across regions / realms to execute approved release plans globally In some examples, CIOS handles onboarding by allowing teams to provide configuration information to CIOS with checked-in code. Furthermore, this is a more burdensome task than in previous implementations, as CIOS can automate many more things. In some examples, CIOS handles pre-deployment by providing teams with the ability to automatically deploy and test code. In some examples, CIOS can handle writing change management (CM) policies by allowing teams to automatically generate plans for deploying new artifacts (e.g., globally) as they build them. It can do this by examining the current state of each area and the current CIOS config (which can itself be an artifact). Furthermore, teams can examine these plans and iterate them by changing the CIOS config and asking CIOS to replan. Once the team is satisfied with the plan, they 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 simply pointers to the CIOS plan. Therefore, the team does not spend as much time reasoning about the plan. Plans are more accurate because they are machine generated, and although they are often too detailed for humans, they can be displayed with sophisticated user interfaces (UIs).

[0040] In some examples, the CIOS can handle CM execution by automatically executing deployment plans. Once a release plan is created and approved, engineers have no involvement in CM unless the CIOS initiates the rollback. In some cases, this may require teams to automate tasks that are currently manual. In some examples, the CIOS can handle change management (CM) rollback by automatically generating a plan to return a flock to its original (e.g., pre-release) state when the CIOS detects a degradation in service health during execution. In some examples, the CIOS can handle deploying sudden / tactical changes by receiving a release plan that applies to a subset of areas and / or resources managed by the CIOS and then executing that plan.

[0041] Additionally, CIOS may support the primitives necessary to define fully automated, worldwide deployments. For example, CIOS can measure service health by monitoring alarms and running integration tests. CIOS can help teams quickly define rollback behavior in the event of service degradation, which can then be executed automatically. CIOS can automatically generate and display release plans and track approvals. In some examples, the language teams use to describe desired deployment behavior may be declarative. CIOS can combine the functionality of code deployment and infrastructure configuration (e.g., provisioning) in one system. CIOS also supports flexible ordering across domains and across components within a domain. Teams can express ordering through checked-in configurations. Teams can invoke CIOS planning and release APIs programmatically.

[0042] 1 illustrates an architecture 100 for describing a technique for implementing at least a central CIOS 102. In some examples, the central CIOS 102 may be a service that handles operations at the level of a "flock." The central CIOS 102 has several responsibilities, including but not limited to:

[0043] Acting as an authentication gateway for flock metadata changes and release operations CIOS repository for Flock and storing a formal mapping of Flock metadata to deployment artifacts Coordinating global releases across phases and targets Synchronization to enforce policies such as "only one in-progress release to a flock at a time" Detecting changes to flock configurations and artifacts and triggering release generation upon such changes In some examples, a Source Code Version Control Management Service (SCVMS) 104 may be configured to store the official flock configuration, and an Artifact Notification Service (ANS) 106 may be contracted by the central CIOS 102 to notify the central CIOS 102 of new artifact constructions. The central CIOS 102 may then map incoming changes to affected flocks and initiate release planning if desired. Additionally, in some examples, an Artifact Push Service (APS) may be invoked by the central CIOS 102 prior to a release to a target to ensure that any artifacts required for a successful release are present in the target's domain prior to the release.

[0044] In some examples, customers (e.g., engineers) 108 can call the central CIOS 102 to CRUD flocks and / or releases to see the status of ongoing CIOS activity. The flock management service 110 can include one or more APIs for manipulating flocks, the view / plan / approval service 112 can include CRUD APIs for creating and approving plans and viewing a central copy of the state of all CIOS-managed resources, the change monitoring service 114 can watch the SCVMS 104 for changes to flock configurations and receive notifications from the ANS 106 about changes to other artifacts, and the state ingestor service 116 can create copies of regional states in the central CIOS database (DB) 118 so that the view / plan / approval 112 can publish them. In some examples, the central CIOS DB 118 can be a DB of flocks, plans, and states. Flock information can be authoritative, while everything else can be an outdated copy of data from the regional CIOS 120. 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 blocks, releases, infrastructure components, artifacts, etc. In some embodiments, 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 user interfaces provided by central CIOS 102 are described below with respect to FIGS. 5-13.

[0045] In some examples, the engineer 108 makes an API call to the flock management service 110 (e.g., via the ingress proxy fleet 122) to A list of locks can be created. The protocol for making such API calls can be Hypertext Transport Protocol Secure (HTTPS), etc. The associated access control list (ACL) for this operation can include a local area network (LAN) 124 or other private connection. For example, the CIOS can manage / control network connections (e.g., dedicated, leased, and / or private connections) that replace the use of the public Internet to connect a customer's on-premises data center or network with the CIOS. Additionally, authentication and authorization (e.g., of engineers 108) can be performed by a reservation system portal that allows users to manage machine interfaces (e.g., reservation services). In some examples, the central CIOS 102 can store flock metadata, plans, and states in the central DB 118 using Java Database Connectivity (JDBC), etc. In some examples, the ANS 106 can be configured to notify the change monitoring service 114 when new artifacts are published. The ANS 106 can use HTTPS, and both authentication and authorization can be handled by mutual transport layer security services. Additionally, in some examples, the change monitoring service 114 may poll the SCVMS 104 for block configuration changes. This polling may be performed using Secure Shell (SSH) or other protocols. Authentication of the change monitoring service 114 may be handled by a CIOS system account, and authorization may be handled by the SCVMS 104.

[0046] In some examples, engineers 108 can use the view / plan / approval service 112 to perform one or more of the following actions: Engineers 108 can plan and / or approve by calling the central CIOS 102 to generate and approve a plan; Engineers 108 can view by calling the central CIOS 102 to see the status of ongoing CIOS activity worldwide; Engineers 108 can also use the central CIOS 102 to view a replica of the state of resources managed by the global CIOS. These API calls (or the like) can be made via HTTPS or a similar protocol. Additionally, associated ACLs can be controlled by the LAN 124, and authentication and authorization can be handled by the reservation service. In some examples, the view / plan / approval service 112 can request a plan (e.g., using HTTPS) and push plan approvals to all regions of the regional CIOS 120. Associated ACLs can be controlled using security lists managed by the wide area network (WAN) gateway 126. Authentication may be handled by mutual transport layer security, and authorization may be handled by various identity policies. Additionally, the state ingestor service 116 may monitor the regional CIOS 120 for job status or state changes so that the CIOS can provide a central view of those statuses or state changes upon request (e.g., again using HTTPS, etc.). ACLS for this may also be handled by the WAN gateway 126, and both authentication and authorization may be handled by mutual transport layer security services.

[0047] 2 is a diagram illustrating an architecture 200 for describing techniques for executing at least a regional CIOS 202. In some examples, the regional CIOS 202 is where much of the declarative provisioning and planning work, as well as approved release applications, can occur. In some examples, each instance of the regional CIOS 202 can have a regional front-end that can handle operations at the level of an "execution target." It can be configured to perform the following:

[0048] Handles all CIOS authentication for incoming actions from the central CIOS 102 Enforcing the rule that only one "execution" (plan / resource import / apply plan) can be in progress for a given execution target at a time. Managing binary artifact storage for declarative provisioning artifacts used as inputs and outputs during declarative infrastructure provisioning runs. Example inputs are declarative infrastructure provisioning configuration files and input state files. A typical output is a final state file.

[0049] Requesting work from the CIOS executor and polling for results from the CIOS executor for any given execution In some examples, the CIOS front end may rely on the CIOS executor 206 (also referred to herein as the "scheduler"), which can handle the actual execution. In some examples, the CIOS executor operates at the level of "execution," which can perform the following:

[0050] Keeping track of the pool of available worker nodes · Matching incoming job requests and assigning them to available and qualified workers Tracking worker status and execution updates for reporting to clients Dead nodes can be detected by the leasing protocol and tasks assigned to the dead nodes can be disabled depending on the task status. Provide functionality to cancel / kill / pause / resume execution and map it to functionality to pass the cancel / kill / resume information to worker nodes. In some examples, the CIOS executor may rely on CIOS workers, which can assign tasks to workers for execution and provide functionality for workers to update job progress. The worker service operates at the granularity of a "task". Each worker is an agent that executes the tasks assigned to it and reports task status and output. Each worker can do the following:

[0051] Polling the Execute Worker API for assigned worker items and taking steps to reconcile the assigned state with its local state Starting a container to poll for task items that do not exist locally Killing a container for locally running containers that do not have a corresponding assigned task item Reporting job status Staging input and output for job container execution Launching and monitoring declarative infrastructure provisioning containers to do the actual work of releasing execution targets A CIOS worker may depend on the CIOS executor to poll for work from the CIOS executor and report results to the CIOS executor's worker endpoint. The worker may rely on the executor for all coordination. Additionally, a CIOS worker may depend on regional CIOS 202, where the worker service reads input from and writes output to one or more APIs associated with the regional front-end service. Examples of input are configuration and starting state files, and import of mappings. Examples of output are the import of a declarative provisioning process, the output of a declarative provisioning state file, and the resulting state.

[0052] In some examples, regional CIOS 202 may be a regional service for managing regional instances / deployments of CIOS. Regional DB 204 covers the responsibility of authoritatively storing and managing plans and states associated with a particular region. Regional DB 204 can be a CIOS DB for the state and plans in that particular region. It is an authoritative copy of a subset of the regions in central DB 118 of FIG. 1. Scheduler 206 can be responsible for managing worker fleet capacity, assigning tasks to workers, and keeping track of task state. In some examples, task DB 208 is another CIOS DB for task state. The data in this DB is mostly for operational purposes. Additionally, workers 210 can be a fleet of Java Virtual Machines (JVMs) that manage declarative provisioning images. They receive instructions from scheduler 206 and communicate results to both scheduler 206 and regional CIOS 202. CIOS container 212 can execute declarative provisioning actions in its own private Docker 214 container. This container may not contain sensitive content. Additionally, in some examples, the signing proxy 216 can be configured to prevent secrets from being exfiltrated by declarative provisioning tools to avoid including secrets in the declarative provisioning image. Instead, the CIOS can perform signing requests or initiate mutual Transport Layer Security (mTLS) services at the proxy, again facilitating the use of FIPS-compliant cryptographic libraries.

[0053] In some examples, the central CIOS 102 can call the regional CIOS 202 to create plans, push approvals, watch job status (service principals), and extract declarative provisioner state (service principals). The ingress proxy 218 can be configured as an ACL, and various identity policies can be used for authentication and authorization. Alternatively, in some examples, the ingress proxy 218 may be replaced with a load balancer configured to load balance 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 is supposed to be running and can report 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. Additionally, if the worker 210 needs to run the declarative provisioner, it runs it in a Docker container by interacting with local Docker 214. Authentication at this stage may be handled by a local Unix socket. This final step may use the Docker protocol, while the previous steps may utilize HTTPS.

[0054] In some embodiments, regional CIOS 202 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 blocks, releases, infrastructure components, artifacts, etc. In some embodiments, 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 regional CIOS 202 are described below with respect to FIGS. 5-13.

[0055] In some examples, the CIOS container 212 allows a declarative provisioner to interact (via an API) with the signing proxy 216, which the declarative provisioner thinks it is invoking various CIOS services. The signing proxy 216 listens on one ephemeral port per declarative provisioner instance invocation, known only to the declarative provisioner. The signing proxy 216 can initiate signing or mTLS requests and pass declarative provisioner 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 endpoints of public services when possible. For services that do not have internal endpoints, it must use the egress proxy 222 to reach external endpoints. This use of the signing proxy 216 would not be for cross-domain communication. For example, the egress proxy whitelist in each domain could be only for that domain's public IP ranges. In some examples, the worker 210 could then maintain state and logs from the declarative provisioners in the regional CIOS 202 so that they can be spilled to the central CIOS 102.

[0056] Using CIOS, a typical customer experience has several phases: onboarding, pre-release, global release, and tactical release. In the pre-release phase, below is an example of what happens between a new artifact being built and releasing the artifact to Release 1 (e.g., R1). This should replace some or most of the current change management process. Once the related artifacts are built, CIOS can automatically generate releases using the "latest version of everything in the flock." A release is a specific version of a flock configuration with specific inputs (e.g., artifact version, realm, region, and ad). A release contains one rollforward plan per region and metadata describing the region ordering. Each region plan is a set of actions that the declarative provisioner will take to realize the flock configuration in that region. Teams with pre-release environments can use CIOS to automatically release and test software in the above environments. Teams can configure CIOS to automatically test rollback plans. Teams could review and approve releases via the CIOS UI. Teams can approve some (but not all) of the local plans within a release. If "latest version of everything" does not result in a suitable plan, the team can ask CIOS to generate plans for cherry-picked artifact versions.

[0057] During the worldwide release phase, the following is an example of how a team might execute tomorrow's version of today's "normal CM." Once a release is approved, the CIOS pushes each approved regional plan to its respective region. The CIOS works independently within each region to apply the approved plan. The CIOS only executes the set of actions explicitly described in that region's plan. Without "thinking independently," it would fail. 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 an outage in the CIOS or a downstream service, the CIOS can notify the team and prompt them for next steps (e.g., abort, retry). The CIOS performs retries, but some outages in downstream systems may exceed its willingness to retry. If the execution fails due to a degradation in service health or a test failure, the CIOS assists the team by rolling back the flock to its starting state. The CIOS notifies the team (e.g., paging) when it initiates an automatic rollback. The team must approve the rollback plan, which the CIOS then executes.

[0058] During the tactical release phase, below is an example of how a team could execute tomorrow's version of "Sudden CM." When generating a plan, the team may ask CIOS to target the plan to specific resources in several ways: topologically (e.g., by realm, region, AD, etc.), by resource type (e.g., "metrics config only" or "deployment orchestration service deployments only"), or a combination of the above (e.g., in a disjunctive manner). The team approves tactical releases similarly to global releases. CIOS orchestrates them similarly. If the team needs to deploy a tactical release while there is an active global release, CIOS will stop the global release execution in the target region and then start the tactical release execution.

[0059] In some examples, the declarative provisioner's state (e.g., traditionally a file) is the authoritative record of the set of resources managed by the declarative provisioner. It contains a mapping between each resource's logical identifier from the configuration file and the resource's actual identifier. When the declarative provisioner is creating a resource, certain kinds of failures can prevent the actual identifier from being recorded in the 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 represent waste. The declarative provisioner might (for example) launch an instance and forget about it, but the next time it runs, it will launch another instance instead. For resources with uniqueness constraints or client-supplied identifiers, orphans prevent the declarative provisioner from moving forward. For example, if the declarative provisioner creates a user "nglass" and a failure causes it to abandon, the next run of the declarative provisioner will attempt to create "nglass" and fail because a user with that username already exists. In some cases, orphans are only a problem when adding new resources to the state. In some instances, the declarative provisioner's refresh behavior may naturally recover from the failure and log updates and deletions.

[0061] CIOS needs to be robust in the face of outages of downstream services or outages of the CIOS itself. Since CIOS can leverage declarative provisioners to apply changes, this means it should be robust in running the declarative provisioners and maintaining the declarative provisioner state. The declarative provisioner provider performs "minor" retries sufficient to avoid outages lasting several minutes. For example, a cloud provider may perform retries for up to 30 minutes. A downstream system outage lasting longer than 30 minutes will cause the declarative provisioner to fail. When the declarative provisioner fails, it records all changes that were successfully made to its state and then exits. To perform a retry, the CIOS must re-run the declarative provisioner. Re-running the declarative provisioner allows the CIOS to perform retries even in the face of failures of the CIOS itself. In some examples, the CIOS can perform the following actions in a loop:

[0062] Refresh: The declarative provisioner calls the "Get API" to retrieve a new snapshot of any resources listed in its state. Plan: The declarative provisioner generates a plan (a specific set of API calls) that achieves the desired state, given the current, recently refreshed state. Apply: The declarative provisioner executes a set of steps in the plan. CIOS may always perform all three of these steps when running a declarative provisioner. A refresh operation removes any updates or deletions that were not recorded. It also aids recovery. The CIOS examines the results of the plan actions and compares them to the approved release plan. If the newly generated plan contains actions that were not in the approved release plan, the CIOS can fail and notify the service team.

[0063] Figure 3 illustrates a directed acyclic graph (DAG) 300 for illustrating an example flock 302. The progression of code / configuration for a single flock configuration in CIOS from check-in to production can be described, all the way from the initial test deployment to the final prod deployment. Internally, CIOS refers to each element in the progression as an execution target (ET). CIOS executes the ETs based on the DAG 200 defined in the flock configuration. 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 configuration.

[0064] Figure 4 illustrates a DAG 400 to illustrate an example flock 402. In a flock configuration, CIOS is very opinionated about how teams express this progression. Teams must model it using cloud infrastructure tenancies and regions. Teams should not model progression using realms. CIOS allows teams to use many tenancies within a realm and many regions within a tenancy. DAG 400 shows a version of DAG 300 from Figure 3 expressed with tenancies and regions. This example is for an overlay service where the pre-prod ET is in the prod region. The service enclave service will have an unstable tenancy and a stable tenancy in Release 1. In DAG 400, IAD is the regional airport code for Dulles Airport in Washington, DC; YYZ is the regional airport code for Toronto, Ontario; PHX, LHR, and FRA are the regional airport codes for Phoenix, London, and Frankfurt, respectively; and LUF and LFI are for two different Air Force bases.

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

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

[0067] 5, infrastructure area 502 is positioned in the upper left corner of UI 500. Infrastructure area 502 may include infrastructure release data corresponding to any suitable number of infrastructure releases (e.g., release name, number of execution targets to which infrastructure components of the release are provisioned, one or more indicators of progress associated with the execution of the release, an indicator of the latest infrastructure release, etc.). As shown, infrastructure area 502 includes six infrastructure releases entitled "Lovable," "Excited," "Elegant," "Nuclear," "Strange," and "Aquaeus." Item 508 displays infrastructure release data corresponding to a release. Item 508 displays infrastructure release data corresponding to 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 block. While the percentage and progress bar 510 are exemplary user interface elements for indicating release progress, it should be understood that any suitable user interface element may be utilized to display such progress (e.g., visually, textually, etc.). By way of example, the progress of the corresponding infrastructure release may additionally or alternatively be displayed numerically, in a table, or by other suitable user interface element for displaying progress. In some embodiments, a particular infrastructure release may be identified as the latest release using label 512 or another suitable user interface element including 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) to which infrastructure components corresponding to release "Lovable" will be provisioned. It is contemplated that the infrastructure release data provided in each item of infrastructure area 502 may be arranged differently and may include more or fewer attributes of infrastructure release data corresponding to each release than the number of attributes shown in FIG. 5.

[0068] In some embodiments, UI 500 may include an applications area 504. The applications area 504 may be located in any suitable location on UI 500. In the example shown in FIG. 5, the applications area 504 is positioned in the upper right corner of UI 500. The applications area 504 may include application release data corresponding to any suitable number of application releases (e.g., the application release name, the number of execution targets to which 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 the software artifacts), an indicator of the most recent application release, etc.). As shown, the applications area 504 displays application release data corresponding to six application releases entitled “Chuck,” “Bob,” “Felipe,” “Asa,” “Strange,” and “Erol.” Item 514 displays application release data corresponding to application release “Chuck” and includes a percentage (e.g., 60%) and a progress bar 516 indicating that the release has executed for 60% of the time. While the percentage and progress bar 516 are exemplary user interface elements for indicating application release progress, it should be understood that any suitable user interface element may be utilized to display such progress (e.g., visually, textually, etc.). By way of example, the progress of a corresponding application release may additionally or alternatively be displayed numerically, in a table, or by other suitable user interface element for displaying progress. In some embodiments, a particular infrastructure release may be identified as the most recent release using a label 518 or another suitable user interface element including an icon, a check mark, etc. As shown in FIG. 5 , item 514 includes a target number indicating the number (e.g., 12) of execution targets to which artifacts (e.g., application code) corresponding to release “chuck” will be provisioned.It is contemplated that the application release data provided in each item in application area 504 may be arranged differently and may include more or fewer attributes of the application release data corresponding to each release.

[0069] In some embodiments, UI 500 may include a task area 506. Task area 506 may be located in any suitable location on UI 500. In the example shown in FIG. Located toward the bottom half of UI 500. Task area 506 may include target release information corresponding to each execution target of the block. Each execution target in the examples provided herein may correspond to a region. A region in the examples herein may comprise at least one physical location. The target release information may include an identifier for the infrastructure release and a status (e.g., a visual indication of the status) corresponding to the progress of provisioning infrastructure components of the infrastructure release to the execution target, and an identifier for the application release and a status (e.g., a visual indication of the status) indicating the progress of deployment of artifacts (e.g., application code) corresponding to the application release. Task area 506 may include any suitable number and combination of columns, such as an execution target column 520, an infrastructure changes column 522, and / or an application changes column 524. Execution target column 520 may be organized by phase, and the phase 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. UI 500 shows four phases: Phase I, Phase II, Phase III, and Phase IV. 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, Phases I and II each include one execution target, Phase III includes four execution targets, and Phase IV includes twelve execution targets. These execution targets can be applied in parallel.

[0070] Each row in 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 for that phase. Item 528 may correspond to Phase III. Item 530 may correspond to Phase IV. By default, items corresponding to execution targets for a phase may be hidden. Selection of an item corresponding to a phase can cause rows corresponding to the corresponding execution targets for 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 particular execution target / area for Phase IV to which an infrastructure release (e.g., "Lovable") and an application release (e.g., "Chuck") correspond.

[0071] Infrastructure changes column 522 may include the name of the infrastructure release and the status of the infrastructure release for each phase or execution target. 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 changes 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 targets in Phase IV. Status indicators 536 may also be displayed within the infrastructure changes column to indicate the status of each infrastructure release for each execution target of the phase. Status indicators 536 may individually indicate whether a release for one or more execution targets encountered an error, is in progress, or is complete. Similarly, application changes column 524 may include indicator 538 to indicate that one application release is utilized for each execution target in Phase IV, and indicator 539 to indicate the status of each application release for each execution target in Phase IV. and a status indicator 540 to indicate the status of the release. In an item corresponding to a single execution target (e.g., item 532), infrastructure changes column 522 may display the name and status of the infrastructure release. In some embodiments, the status (e.g., "Done," "Failed," "In Progress," "Awaiting Review," etc.) may be displayed textually as shown in FIG. 5, or the status may be displayed differently. In an item corresponding to a single execution target, application changes column 524 may similarly include the name of the application release (e.g., "Check") and the status of the application release (e.g., "Done," "Failed," "In Progress," "Awaiting Review," etc.). The status displayed for the application release may be the same as or different from the status provided for the infrastructure release. In some embodiments, selecting an item (e.g., selecting item 542) may visually change the item (e.g., the background of the item may change) to reflect this selection. One exemplary change responsive to selecting item 542 is shown in FIG. 5. By selecting link 544, the user may be navigated to UI 600 of FIG. 6, although other navigation actions may provide similar results.

[0072] In some embodiments, if a release fails in at least one aspect, the status of the failure may be displayed in UI 500. As an example, a failure of infrastructure component provisioning may be displayed at 546, and a failure of software artifact deployment may be displayed at 548. In some embodiments, user input may be received at 546 and / or 548 (e.g., selecting the word "failed"). In response to this user input, the user may be provided with one or more options for performing a remedial action (e.g., retrying the provisioning and / or deployment tasks corresponding to the execution target, canceling the provisioning and / or deployment tasks corresponding to the execution target, modifying the provisioning and / or deployment tasks corresponding to the execution target, etc.).

[0073] FIG. 6 is a schematic diagram illustrating 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 from which details of the release can be viewed. A release name section 602 is shown at the top of the UI 600, but the release name section 602 may be located in any suitable location 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, although 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 block. The status 606 may display a status (e.g., “Not Started,” “Approval Required,” “Applied,” “Failed,” “Completed,” etc.) associated with a particular release. Although release identifier 608 is shown as "09879iuhku7w," release identifier 608 may be any suitable ID that may be unique to the associated release.

[0074] UI 600 may also include a status bar 610, which may include information about the status of an associated release, such as a graph 612, a timestamp 614, and a status code 616. Similarly, status bar 618 may include a graph 620, a timestamp 622, and a status code 624. Graphs 612 and 618 may display a numbered list of tasks. As an example, graphs 612 and 618 Each node in the table may represent a set of tasks (e.g., "1" represents a set of one task, "9" represents a set of nine tasks, etc.). When more than one task is represented in a node, the node may be intended to refer to a set of tasks that are executed in parallel. Each task may correspond to a release corresponding to a particular 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 can begin. Similarly, the task associated with node 628 may be required to complete before the task associated with node 630 can begin. Each of the tasks associated with node 630 may be executed in parallel. The timestamp 614 may indicate a start date. Additionally, the timestamp 614 may indicate a start time corresponding to a status code "start" and an end time corresponding to a status code "complete." Status code 624 may indicate that the associated task has been approved, timestamp 622 may indicate a 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 running. It should be appreciated that status codes 616 and 624 may be any suitable status codes for tracking the status of the associated release (e.g., "approved," "in progress," "failed," "approval required," etc.).

[0075] In some embodiments, a status bar may be utilized to display 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 noted above, phases may be used to describe the order in which phases are completed. As shown, the eleven phase 1 tasks depicted in status bar 610 may be required to be completed before the twelve phase 2 tasks associated with status bar 618 begin. It should be understood that additional phases other than two may be utilized. It should be understood that if the display of information corresponding to a phase or multiple phases is too wide to display given the current window size, status bar 610 may be horizontally scrollable so that the user can scroll through the various phases and view their corresponding status. In some embodiments, status bar 610 utilizes “smart scrolling” so that if a user is utilizing an input device (e.g., a mouse) with only vertical scrolling capabilities, the user can still scroll horizontally. As an example, a user may physically scroll down using an input device, causing status bar 610 to scroll to the right. If a user physically scrolls up using an input device, status bar 610 may scroll to the left. The filter allows the user to focus on significant changes without being distracted by operational noise and therefore less likely to miss significant changes or errors.

[0076] A phase plan section 634 may also be included in the UI 600; as shown, the phase plan section 634 is at the bottom of the UI 600, but may be positioned differently within the UI 600. The phase plan section 634 may include information related to the desired phase (e.g., phase 2, corresponding to the status bar 618). As shown in the UI 600, the phase plan section 634 displays a phase title 636, a phase status 638, a number of execution targets 640, an operation summary 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 may include the name of the selected phase of the release shown in the UI 600. This name may include any suitable alphanumeric identifier of any suitable length. In some embodiments, the phase status 622 is the status of the selected phase of the release. As shown in UI 600, the phase title 636 is "Phase II" and the phase status 638 is shown as "Approval Required." The phase status 638 may be any suitable status for the selected phase of the release (e.g., "Approval Required," "In Progress," "Failed," "Complete," etc.). The number of execution targets 640, shown in UI 600 as "12," may indicate any number of execution targets to which the release can be deployed. The operations summary 642 may indicate the number of create, revise, update, and delete operations planned for the phase. As shown in UI 600, the operations summary 642 includes four different operations (listed from 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 one no change operation. The UI 600 may include any suitable number or combination of operations in the operations summary 642. The operations summary 642 may include four buttons corresponding to create, revise, update, and delete. Each of these buttons may be utilized as a toggle to filter a corresponding set of actions from the phase plan section 634. For example, when the "Create" button is selected, all create actions may be filtered from the phase plan section 634. When the Create button is selected again, these create actions may be unfiltered and reappear in the phase plan section 634. By default, these buttons may be turned off (e.g., deselected) so that no actions are filtered, although any suitable default behavior may be utilized.

[0077] 6 shows changes that are subject to a particular execution target, it should be understood that in some embodiments, similar changes may be grouped together and the execution target to which each change is associated may be displayed. Thus, the phase plan corresponding to FIG. 6 may be transformed in two ways: execution target for changes (as shown) or changes to execution targets.

[0078] Tenancy column 644 may be located in any suitable location on UI 600, and may include a list of execution target tasks, including items corresponding to a particular set of tasks (e.g., item 652) corresponding to node 632 of Phase II, and a list 654 of applications scheduled to be created, modified, or deleted during the execution of those tasks. To display list 654 of applications, a user may select option 655 to expand the list to display applications included in the release (e.g., SMS Agent). As shown in UI 600, the only application currently displayed is "SMS Agent" 658. UI 600 may show changes to be made to the SMS Agent's configuration file at 659. In some embodiments, the computing system providing UI 600 may identify the previous configuration of the software artifact (e.g., SMS Agent), identify the new configuration of the software artifact to be deployed, and provide an indication of the changes from the previous configuration to the new configuration of the software artifact (e.g., displayed at 659). As shown, this change may include deleting row 5 (indicated by 5-) and adding a new row 5 (indicated by 5+). In some embodiments, a "change" (also referred to as an update) may include both a delete and a create. A create / delete update may be displayed as an update operation rather than a create / delete in the CRUD operations column 648. The list of applications 654 may also include other suitable applications for the selected release.

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

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

[0081] A release history section 662 may also be located on the UI 600. As shown in the UI 600, the release history section 662 is located on the left portion of the UI 600, although the release history section 662 may be located in any suitable location on the UI 600. The release history section 662 may include information about various releases within the associated flock. As shown in the UI 600, three releases are displayed: “Lovable,” “Exciting,” and “Elegant,” but any suitable number of releases may be displayed in the release history section 662. Selecting any one of the releases from the release history section 662 may display corresponding data associated with that release for each of the above UI elements 602-660. In some embodiments, the release history section 662 may also include a change type indicator 664 (e.g., “Infrastructure,” “Application,” etc.), a target count indicator 666, a release timestamp 668, a roll forward option 670, and a create new release option 672. The target count 666 may indicate how many execution targets a particular release is intended to provision. A target count 666 is displayed for each specific release and may include any suitable number of targets for the associated release. A release timestamp 668 may include the time the selected release was created or the time provisioning was completed, along with a status indicator (e.g., "created," "completed," etc.). The release timestamp 668 may be located in any suitable location on the associated release, or the release timestamp 668 may be absent for any particular release. A rollforward option 672 allows a user to redeploy a previously rolled back configuration. A create new release option 656 may allow a user to create a new release for the selected block.

[0082] In some embodiments, a user may right-click their mouse to cause option 656 to appear, which may appear approximately near the user's mouse cursor. By selecting option 656, the user may navigate to UI 800 of FIG. 8, which is described further below.

[0083] It should be appreciated that a 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 particular selected phase. In some embodiments, a status bar (e.g., status bar 620) of a selected phase may be highlighted and / or enlarged to indicate that the corresponding phase has been selected and that the information in the phase plan section 634 corresponds to the selected phase.

[0084] FIG. 7 is a diagram illustrating an exemplary user interface (eg, UI 700) for viewing the status of a release, according to at least one embodiment.

[0085] Release status section 704 may be located in any suitable location on UI 700. As shown in UI 700, release status section 704 is located at the top of UI 700. Release status section 704 may include any suitable information related to a release, including the status of the release (e.g., "applied," "paused," "done," "failed," etc.) and a timestamp, which may include the time the associated release (e.g., the release corresponding to the associated information shown in FIG. 7) started, completed, paused, etc. Release status section 704 may include other suitable information for tracking the status of the associated release.

[0086] In at least one embodiment, UI 700 may include a phase plan section 706. In some embodiments, UI 700 including phase plan section 706 may be displayed in response to selection of a "Status" option 702 of selection options 660 of Figure 6. Selecting "Status" option 702 may display information about the status of the associated release or other suitable information related to the status of the associated release.

[0087] In some embodiments, the phase plan section 706 may list multiple sets of execution targets corresponding to a phase (e.g., Phase II described above in connection with FIG. 6 ). As shown in FIG. 6 and similarly in FIG. 7 , a phase may be associated with a graph 620 including nodes 632, 710, and 712. Each node may correspond to a set of tasks for that phase. As an example, execution target task sets 714, 716, and 718 may be listed. Execution target task set 714 may correspond to node 632, execution target task set 716 may correspond to node 710, and execution target task set 718 may correspond to node 712. As shown in the UI 700, an execution target task set 718 including 10 execution targets (e.g., shown in both node 712 and execution target task set 718) has been selected. Selecting the execution target task set 718 may display the corresponding 10 execution tasks as individual rows below the execution target task set 718. As shown in FIG. 7 , each task may correspond to a particular execution target for which a release is provisioned.

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

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

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

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

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

[0093] 9 is a diagram illustrating an example UI 900 displaying execution target resources for a selected execution target (e.g., the execution target corresponding to the 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 any other suitable method, and the UI 900 can be updated with information about the execution target corresponding to the execution target task 806 by periodic or forced refresh of the UI 900. The UI 900 can include a name 902 of the execution target and a block version 904. The name 902 and version 904 can be located in any suitable location on the UI 900, but as shown in FIG. 9 , are located at the top of the UI 900.

[0094] The UI 900 may also include a resources section 906. In some embodiments, the resources section 906 may display any suitable number of infrastructure and / or software application components associated with a particular execution target. As an example, the resources section 906 may include various resources (e.g., infrastructure components “Bob,” “Carl,” “DNS,” etc.) as shown at 908 and software artifacts (e.g., application code) (e.g., “Application 1,” “Application 2,” and “Test”) as shown at 910. Each resource may indicate whether the resource is an infrastructure component (e.g., as shown at 910) or an application (e.g., as shown at 912). As shown at 912 and similarly at 914, each resource may indicate a resource type (e.g., “Infrastructure,” “Application,” etc.) and The UI 900 may have accompanying information such as a resource count, which may be any number suitable for describing how many of each resource are present in the selected execution target. Once a resource is selected, the UI 900 may display 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 the UI 900 may be displayed as a dialog box or another suitable pop-up window that may be overlaid on any suitable interface (e.g., UIs 500-800 of FIGS. 5-8).

[0095] FIG. 10 is a schematic diagram illustrating an exemplary user interface (e.g., UI 1000) for displaying information about a selected phase of a selected release, according to at least one embodiment. UI 1000 may include a progress bar 1002, which may include all phases of a selected release 1004 or any suitable subset of those phases. While progress bar 1002 is shown at the top of UI 1000, it may be located in any suitable location on UI 1000. Progress bar 1002 may also include various information about each phase of the selected release 1004, including, but not limited to, the phase name, the number of execution targets, a timestamp, approval status, phase status, and other suitable information associated with each phase of the selected release 1004. The selected phase 1006 shown in the UI is “stable (13),” although any phase in progress bar 1002 may be selected to display relevant information about the respective phase. The selected phase 1006 may also include a circular progress bar 1007 that allows visual tracking of the progress of the collective tasks of the selected phase 1006. Stated another way, the circular progress bar 1007 may display (present) a visual indication of the progress corresponding to the phase. In some embodiments, the circular progress bar 1007 may pulse 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), each portion corresponding to a task in the set of tasks associated with the phase. In some embodiments, a green portion of the circular progress bar 1007 (e.g., a green indicator) may represent a completed task for the selected phase 1006, and a red portion of the progress bar 1007 (e.g., a red indicator) may represent a failed task for the selected phase 1006.The white portion (e.g., a white indicator) of the progress bar 1007 may represent tasks in the selected phase 1006 that have not yet failed or 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 a phase (e.g., corresponding to an execution target to which a release will be deployed) may be displayed in status area 1010. In some embodiments, the tasks may be displayed in the order in which they are to be executed and / or in any suitable location on UI 1000. As shown, the list of execution tasks is located at the bottom of UI 1000. The list of tasks displayed in area 1010 may include a progress column 1012, an action column 1014, and other suitable information related to the listed task. The progress column 1012 may display the progress status (e.g., “succeeded,” “failed,” “applied,” etc.) of each execution target in list of execution targets 1008. The action column 1014 may include information about which action may be performed for each task of the selected phase 1006 (e.g., each task corresponding to an execution target of the selected phase 1006).

[0097] FIG. 11 is a schematic diagram illustrating an exemplary user interface 1100 displaying an execution graph for illustrating the execution order of a set of execution tasks, according to at least one embodiment. A selected phase 1102 may be selected from a progress bar 1104 (e.g., an example of the progress bar 1006 of FIG. 10 ). The section corresponding to the selected phase 1102 may include a graph 1106. The graph 1106 may indicate the order in which execution tasks corresponding to execution targets may be executed. As shown in the UI 1100, the graph 1106 may include nodes 1108, 1110, and 1112. The node 1108 may be associated with one execution task corresponding to one execution target. The node 1110 may be associated with one execution task corresponding to one execution target. The node 1112 may be associated with seven execution tasks corresponding to seven execution targets. The graph 1106 indicates the sequence of execution among each group of tasks corresponding to the nodes 1108, 1110, and 1112. For example, a task associated with node 1108 may be required to complete before a task associated with node 1110 can begin. Similarly, a task associated with node 1110 may be required to complete before a task associated with node 1112 can be executed. If a node includes two or more tasks, the tasks may be executed at least partially in parallel (e.g., substantially in parallel). UI 1100 may also include any suitable combination of execution tasks corresponding to any suitable number of execution targets executed serially or in parallel. UI 1100 may display a list of each task in area 1114 in the order in which the tasks will be executed. In some embodiments, tasks that may be executed in parallel may be displayed in area 1114 in any suitable order.

[0098] FIG. 12 is a schematic diagram illustrating an exemplary user interface (e.g., UI 1200) displaying execution status associated with one or more phases of a selected release, according to at least one embodiment. Phase 1202 may be located in a progress bar 1204 (e.g., an example of progress bar 1002 of FIG. 10 ) or other suitable location on UI 1200. Phase 1002 may include a graph 1206 illustrating a particular sequence of task execution corresponding to node 1208 and node 1210. As shown in UI 1200, 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 circular progress bar 1007 of FIG. 10 ) may be utilized for each node to indicate the status of each node's execution task. As indicated by circular progress bar 1212, the task corresponding to node 1208 may be completed, while the task corresponding to node 1210 may still be in progress.

[0099] UI 1200 may also include a task list 1214. When phase 1002 is selected, the execution targets corresponding to each task may be displayed in task list 1214. As shown in UI 1200, the execution task corresponding to node 1208 may be displayed in 1216, and the execution task corresponding to node 1210 may be displayed in 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 task list 1214. Status 1220 may correspond to a textual representation of the status corresponding to node 1208, and status 1222 may correspond to a textual representation of the status corresponding to node 1210.

[0100] 13 is a schematic diagram illustrating an example user interface (e.g., UI 1300) displaying an example safety plan, according to at least one embodiment. The UI 1300 may include an action task list 1302 (e.g., action task list 1008 of FIG. 10), which may be located in any suitable location on the UI 1300, and as shown, this action task A script list 1302 is located at the top of the UI 1300. 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, the UI 1300 may be utilized to display a set of changes made to the software resources as part of changing the software resources from the first state to the second state. As shown, the execution task list 1302 includes an execution task 1304 (e.g., labeled “unstable”) corresponding to the target, which, when selected, can display a module 1306, which, when selected, can then display a module 1308 (labeled “app_deployment,” as shown), which, when selected, can display a module 1310. The execution target 1304 may display any suitable number of modules and / or application deployments corresponding to the execution task 1304. In embodiments having more than one module 1306, the modules 1306 may be listed in descending order of frequency of create, update, delete, or no-change operations. As an example, the modules 1306-1310 may be displayed such that the most frequently created modules may be listed at the top of the list, and the remaining tasks may be displayed in descending order according to the corresponding number of created operations for each task. In some embodiments, the modules 1306-1310 may be organized differently (e.g., ascending order, or any other suitable method for organizing the modules 1306-1310). In some embodiments, when a module 1310 is selected, the UI 1300 may display a safety plan log 1312 and other suitable information corresponding to the task 1304.

[0101] Although the safety plan log 1312 may be displayed in any suitable location on the UI 1300, 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 may display information about changes to be made to the application code corresponding to the module 1310. For example, line 1314 may indicate an added line of code, and line 1316 may indicate a deleted line of code that replaces line 1314. In some embodiments, line 1312 (and / or any portion of the code being added) may be displayed with a green background or other color suitable to identify the one or more lines of code being added. Line 1314 (e.g., or any portion of the code being deleted) may be displayed with a red background or other color suitable to identify the one or more lines of code being deleted.

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

[0103] FIG. 14 is an exemplary flow diagram illustrating a process 1400 for implementing CIOS techniques in accordance with certain embodiments of the present disclosure. This process is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or 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 perform the described operations when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the 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) collectively executed on one or more processors, may be implemented by hardware, or may be implemented by a combination thereof. As noted above, the code may be stored on a computer-readable storage medium, for example, in the form of a computer program including multiple instructions executable by one or more processors. In some embodiments, process 1400 may be executed in parallel by multiple processors. The computer-readable storage medium may be non-transitory.

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

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

[0107] Process 1400 may proceed to block 1406, where the computing system deploys a second set of software artifacts. The second set of software artifacts may be based at least in part on the computing system providing a second set of declarative instructions to the declarative infrastructure 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 applications area 504 of FIG. 5 ). These user interface elements may identify at least a first status associated with provisioning a first set of infrastructure components (e.g., progress bar 510) and a second status associated with deploying a second set of software artifacts (e.g., progress bar 516).

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

[0110] Exemplary System 15-17 illustrate aspects of an exemplary environment for implementing aspects of the present disclosure, according to various embodiments. FIG. 15 is a simplified diagram of a distributed system 1500 for implementing one 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 execute and operate client applications (such as a web browser, a proprietary client (e.g., Oracle Forms), etc.) over one or more networks 1510. A server 1512 may be communicatively coupled to the remote client computing devices 1502, 1504, 1506, and 1508 over the network 1510.

[0111] In various embodiments, server 1512 may be adapted to run one or more services or software applications, such as services and applications that provide identity management services. In particular embodiments, server 1512 may also provide other services or software applications, which may include non-virtualized and virtualized environments. In some embodiments, these services may be provided to users of client computing devices 1502, 1504, 1506, and / or 1508 as web-based or cloud services or under a software-as-a-service (SaaS) model. Users operating client computing devices 1502, 1504, 1506, and / or 1508 may then utilize one or more client applications to interact with server 1512 to 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 executing 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. Users operating these client computing devices may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that a variety of different system configurations are possible and 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, client computing devices may include portable handheld devices (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display) running software (e.g., Microsoft Windows Mobile®) and / or various mobile operating systems (e.g., iOS, Windows Phone, Android®, BlackBerry 10, Palm OS, etc.). These devices may support various applications (e.g., various internet-related apps, email, short message service (SMS) applications, etc.) and may use various other communication protocols. Client computing devices may be general-purpose personal computers. The client computing devices may also include general-purpose personal computers, including, by way of example, personal and / or laptop computers running various versions of the Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may be workstation computers running any of a variety of commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems (e.g., Google Chrome OS). The client computing devices may also include electronic devices capable of communicating over the network 1510, such as thin client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox gaming consoles with or without Kinect gesture input devices), and / or personal messaging devices.

[0114] 15 is shown with four client computing devices, any number of client computing devices may be supported. Other devices (such as devices with sensors) may interact with server 1512.

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

[0116] The servers 1512 may be comprised of one or more general-purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or other suitable configurations and / or combinations. The servers 1512 may include one or more virtual machines running a virtual operating system or other computing architectures involving virtualization. One or more flexible pools of logical storage devices may be virtualized to maintain virtual storage devices for the servers. A virtual network may be controlled by the servers 1512 using software-defined networking. In various embodiments, the servers 1512 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, the servers 1512 may correspond to a server for performing the above-described processing according to one embodiment of the present disclosure.

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

[0118] In some implementations, server 1512 may include one or more applications for parsing and consolidating data feeds and / or event updates received from users of client computing devices 1502, 1504, 1506, and 1508. By way of example, the data feeds and / or event updates may include, but are not limited to, Twitter feeds, Facebook updates, or real-time updates received from one or more third-party sources and continuous data streams, including real-time events related to sensor data applications, financial stock tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc. Server 1512 may also include one or more applications for displaying the data feeds and / or real-time events via one or more display devices of client computing devices 1502, 1504, 1506, and 1508.

[0119] 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 a variety of locations. As one example, one or more of databases 1514 and 1516 may reside 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 one set of embodiments, databases 1514 and 1516 may reside within a storage area network (SAN). Similarly, any necessary files to perform functions attributed to server 1512 may be stored locally and / or remotely on server 1512, as appropriate. In one set of embodiments, databases 1514 and 1516 may include relational databases (such as those provided by Oracle Corporation) adapted to store, update, and retrieve data in response to commands formatted in SQL.

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

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

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

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

[0124] In particular embodiments, processing acceleration unit 1606 may be provided to perform customized processing to accelerate the overall processing performed by computer system 1600 or to offload portions of the processing performed by processing subsystem 1604.

[0125] I / O subsystem 1608 may include devices and mechanisms for inputting information into computer system 1600 and / or outputting information from or through computer system 1600. In general, use of the term input device is intended to include all possible types of devices and mechanisms for inputting information into computer system 1600. User interface input devices may include, for example, keyboards, pointing devices (such as a mouse or trackball), touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include motion-sensing and / or gesture-activated controls that allow a user to control and interact with the input device. Gesture recognition devices (such as a Microsoft Kinect® motion sensor), a Microsoft Xbox® 360 game controller, and devices that provide an interface for receiving input via gestures and verbal commands may also be included. User interface input devices may also include eye gesture recognition devices (such as a Google Glass® blink detector) that detect eye movements from a user (e.g., "blinks" while taking a photo and / or making a menu selection) and translate the eye gestures as input to an input device (e.g., Google Glass®). Additionally, user interface input devices may include voice recognition sensing devices that allow a user to interact with a voice recognition system (e.g., Siri® 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, gamepads and graphic tablets, as well as audio / visual devices (such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode reader 3D scanners, 3D printers, laser range finders, and eye-tracking devices). Additionally, user interface input devices may include, for example, medical imaging input devices (such as computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound devices, etc.). User interface input devices 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 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 computer system 1600 to a user or to another computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / visual information (such as monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems).

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

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

[0130] 16, system memory 1610 may store, but is not limited to, application programs 1612 (which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc.), program data 1614, and operating system 1616. By way of example, operating system 1616 may include various versions of the Microsoft Windows, Apple Macintosh, and / or Linux operating systems, various commercially available UNIX or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome OS, etc.), and / or mobile operating systems (such as iOS, Windows Phone, Android OS, BlackBerry 10 OS, and Palm 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, cause 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 (such as a hard disk drive, a magnetic disk drive, an optical disk drive (such as a CD-ROM, DVD, or Blu-ray disc), or other optical media). The computer-readable storage medium 1622 may include, but is not limited to, a Zip drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disc, a 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 ROM), volatile memory-based SSDs (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 for the computer system 1600.

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

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

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

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

[0136] The communications subsystem 1624 can send and receive data in various formats. For example, in some embodiments, the communications subsystem 1624 can receive incoming communications in the form of structured and / or unstructured data feeds 1626, event streams 1628, event updates 1630, etc. For example, the communications subsystem 1624 can be configured to receive (or send) data feeds 1626 in real time from users of social media networks and / or other communications services (such as Twitter feeds, Facebook updates, web feeds (such as Rich Site Summary (RSS) feeds), and / or real-time updates from one or more third-party sources).

[0137] In particular embodiments, communications 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 updates 1630, which may be continuous or infinite in nature without a clear end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial stock tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

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

[0139] The computer system 1600 may be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a personal computer, a workstation, a mainframe, a kiosk, a server rack, or other data processing system.

[0140] Due to the ever-changing nature of computers and networks, the description of computer system 1600 shown in Figure 16 is intended as an example only. Many other configurations are possible, having more or fewer components than the system shown in Figure 16. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other aspects and / or methods for implementing the various embodiments.

[0141] The systems shown in the various figures may be provided in a variety of configurations, and in some embodiments, the systems may be configured as distributed systems in which one or more components of the systems are distributed across one or more networks in one or more cloud infrastructure systems.

[0142] A cloud infrastructure system is a collection of one or more server computing devices, network devices, and / or storage devices. These resources may be divided by a cloud service provider and allocated in some manner to its customers. For example, a cloud service provider (such as Oracle Corporation of Redwood Shores, California) may offer various types of cloud services, including, but not limited to, one or more services offered under the Software-as-a-Service (SaaS) category, services offered under the Platform-as-a-Service (PaaS) category, services offered 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 deliver a suite of on-demand applications (such as Oracle Fusion applications). SaaS services allow customers to use applications running on the cloud infrastructure system without having to purchase the software for those applications. Examples of PaaS services include, but are not limited to, services that allow an organization (such as Oracle) to consolidate existing applications onto a shared common architecture, the ability to build new applications that leverage shared services provided by the platform (such as Oracle Java Cloud Services (JCS), Oracle Database Cloud Services (DBCS)), etc. IaaS services may facilitate the management and control of basic computing resources (such as storage, network, and other basic computing resources) for customers who use services provided by SaaS and PaaS platforms.

[0143] 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 an embodiment system may be provided as cloud services, according to one embodiment of the present disclosure. In the embodiment shown, the system environment 1700 includes one or more client computing devices 1704, 1706, and 1708 that may be used by users to interact with a cloud infrastructure system 1702 that provides cloud services. These client computing devices may be configured to run client applications (such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application) that may be used by users of the client computing devices to interact with the cloud infrastructure system 1702 and use the services provided by the cloud infrastructure system 1702.

[0144] It should be understood that the cloud infrastructure system 1702 depicted in the figure may have components other than those shown. Furthermore, the depicted embodiment is only one example of a cloud infrastructure system that may incorporate an embodiment of the present disclosure. In some other embodiments, cloud infrastructure system 1702 may have more or fewer components than depicted in the figure, may combine two or more components, or may have a different configuration or arrangement 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] Although the exemplary system environment 1700 is shown with three client computing devices, any number of client computing devices may be supported. Other devices (such as devices with sensors) may interact with the cloud infrastructure system 1702.

[0147] Network 1710 may facilitate communication and exchange of data between clients 1704, 1706, and 1708 and cloud infrastructure system 1702. Each network may be any type of network familiar to those skilled in the art that is capable of supporting data communication using any of a variety of commercially available protocols, including those described above for network 1510.

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

[0149] In particular embodiments, the services provided by a cloud infrastructure system may include numerous services (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.) that are made available on demand to users of the cloud infrastructure system. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of its users. One specific instantiation of the services provided by a cloud infrastructure system is referred to herein as a " A service instance is referred to as a "service instance." Generally, any service made available to users from a cloud service provider's system over a communications network such as the Internet is referred to as a "cloud service." In a public cloud environment, the servers and systems that make up the cloud service provider's system are distinct from the customer's own on-premise servers and systems. For example, the cloud service provider's system may host and manage applications, and users may order and use the applications on demand over a communications network such as the Internet.

[0150] In some examples, services in a computer network cloud infrastructure may 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 as otherwise known in the art. For example, a service may include password-protected access over the Internet to remote storage on the cloud. As another example, a service may include a web-services-based hosted relational database and scripting language middleware engine for personal use by a networked developer. As another example, a service may include access to an email software application hosted on a cloud vendor's website.

[0151] In particular embodiments, cloud infrastructure system 1702 may include a suite of application, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. One example of such a cloud infrastructure system is the Oracle Public Cloud (Oracle Public Cloud) offered by the present assignee. Public Cloud).

[0152] In various embodiments, cloud infrastructure system 1702 may be adapted to automatically provision, manage, and track customer subscriptions to services provided by cloud infrastructure system 1702. Cloud infrastructure system 1702 may provide cloud services through a variety of deployment models. For example, services may be provided under a public cloud model, in which cloud infrastructure system 1702 is owned by an organization that sells cloud services (e.g., owned by Oracle Corporation) and the services are made available to the general public or to companies in different industries. As another example, services may be provided under a private cloud model, in which cloud infrastructure system 1702 is operated solely for a single organization and may provide services to one or more entities within that organization. Cloud services may also be provided under a community cloud model, in which cloud infrastructure system 1702 and the services provided by cloud infrastructure system 1702 are shared by several organizations in an associated community. Cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0153] In some embodiments, the services provided by cloud infrastructure system 1702 may include one or more services offered under the Software as a Service (SaaS) category, Platform as a Service (PaaS) category, Infrastructure as a Service (IaaS) category, or other service categories, including hybrid services. A customer may purchase services from cloud infrastructure system 1702 via a subscription order. The cloud infrastructure system 1702 then performs processing to provide the services in the customer's subscription order.

[0154] In some embodiments, services provided by cloud infrastructure system 1702 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall into the SaaS category. For example, the SaaS platform may provide the ability to build and deliver a suite of on-demand applications on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure for delivering the SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications that run on the cloud infrastructure system. Customers can obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be offered. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business flexibility for large organizations.

[0155] In some embodiments, platform services may be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform may be configured to provide cloud services that fall under the PaaS category. Examples of platform services may include, but are not limited to, services that enable organizations (e.g., Oracle) to consolidate existing applications on a shared, common architecture and the ability to build new applications that leverage shared services provided by the platform. The PaaS platform may manage and control the underlying software and infrastructure to provide the PaaS services. Customers may 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 Services (JCS), Oracle Database Cloud Services (DBCS), etc.

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

[0157] A variety of different infrastructure services may be provided in a cloud infrastructure system by an IaaS platform that facilitates 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 and PaaS platforms.

[0158] In particular embodiments, 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, infrastructure resources 1730 may include a pre-integrated and optimized combination of hardware (such as servers, storage, and networking resources) for running the services provided by the PaaS and SaaS platforms.

[0159] In some embodiments, resources in cloud infrastructure system 1702 may be shared by multiple users and dynamically reallocated per request. Furthermore, resources may be allocated to users in various time zones. For example, cloud infrastructure system 1702 may allow a first set of users in a first time zone to utilize resources of the cloud infrastructure system for a particular time, and then allow reallocation of the same resources to another set of users located in a different time zone, thereby maximizing resource utilization.

[0160] In particular embodiments, several internal shared services 1732 may be provided that are shared by various components or modules of cloud infrastructure system 1702 and services provided by cloud infrastructure system 1702. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services to enable cloud support, email services, notification services, file transfer services, etc.

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

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

[0163] In example operation 1734, a customer requests one or more services provided by cloud infrastructure system 1702 and receives a request from the cloud infrastructure system. A customer may interact with cloud infrastructure system 1702 using a client device (such as client device 1704, 1706, or 1708) by placing an order for a subscription to one or more services offered by cloud infrastructure system 1702. In particular embodiments, a customer may access a cloud user interface (UI), i.e., cloud UI 1712, cloud UI 1714, and / or cloud UI 1716, and place a subscription order through these UIs. Order information received by cloud infrastructure system 1702 in response to a customer placing an order may include information identifying the customer and the one or more services offered by cloud infrastructure system 1702 for which the customer intends to subscribe.

[0164] After an order is placed by a customer, the order information is received via the cloud UI 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 in coordination with other system elements.

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

[0167] At operation 1740, information regarding the order is communicated to order orchestration module 1722. The order orchestration module 1722 may utilize 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 may orchestrate the provisioning of resources to support the subscribed service using the services of the order provisioning module 1724.

[0168] In particular embodiments, the order orchestration module 1722 enables management of business processes associated with each order and applies business logic to determine whether the order should proceed to provisioning. At 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 needed to fulfill the subscription order. The order provisioning module 1724 enables allocation of resources for services ordered by a customer. The order provisioning module 1724 provides a level of abstraction between the cloud services provided by the cloud infrastructure system 1702 and the physical implementation layer used to provision resources to provide the requested services. This allows the order orchestration module 1722 to be decoupled from implementation details (such as whether services and resources are actually provisioned on the fly or whether services and resources are pre-provisioned and only allocated / assigned upon request).

[0169] In operation 1744, once the services and resources are provisioned, notification of the provided services is sent to the order process of the cloud infrastructure system 1702. The subscription order may be sent by the visioning module 1724 to the customer on the client device 1704, 1706, and / or 1708. At operation 1746, the customer's subscription order may be managed and tracked by the order management and monitoring module 1726. In some examples, the order management and monitoring module 1726 may be configured to collect usage statistics of the services in the subscription order (such as the amount of storage used, the amount of data transferred, the number of users, and the amount of system up time and system down time).

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

[0171] While specific embodiments of the present disclosure have been described, various modifications, variations, alternative configurations, and equivalents are encompassed within the scope of the present disclosure. The embodiments of the present disclosure are not limited to operation in a particular data processing environment, but can freely operate in multiple data processing environments. Furthermore, while embodiments of the present disclosure have been described using a particular sequence 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 sequence of transactions and steps described. Various features and aspects of the above-described embodiments may be used individually or together.

[0172] Furthermore, while embodiments of the present disclosure have been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments of the present disclosure may be implemented solely in hardware, solely in software, or using a combination thereof. The various processes described herein may be implemented on the same processor or on any combination of different processors. Thus, while components or modules are described as being configured to perform particular operations, such configuration may be achieved, for example, by designing electronic circuitry to perform the operations, by programming a programmable electronic circuit (such as a microprocessor) to perform the operations, or any combination thereof. Processes may communicate using a variety of techniques (including, but not limited to, conventional techniques for inter-process communication), with different process pairs using different techniques and the same process pair using different techniques at different times.

[0173] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions and other modifications and alterations may be made therein without departing from the broader spirit and scope of the appended claims. Accordingly, while specific embodiments of the present disclosure have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims. These variations include any relevant combination of the features disclosed, within the scope of the following claims.

Claims

1. 1. A computer-implemented method comprising: a computing system executing a declarative infrastructure provisioner; provisioning, by the computing system, a first set of infrastructure components based at least in part on providing a first set of declarative instructions to the declarative infrastructure provisioner; deploying, by the computing system, a second set of software artifacts based at least in part on providing a second set of declarative instructions to the declarative infrastructure provisioner; and wherein the computing system provides a user interface displaying a plurality of user interface elements, the plurality of user interface elements identifying 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.

2. 2. The computer-implemented method of claim 1, wherein the first status associated with provisioning the first set of infrastructure components and the second status associated with deploying the second set of software artifacts correspond individually to one or more execution targets, each execution target of the one or more execution targets corresponding to a predefined region comprising at least one physical location.

3. 3. The computer-implemented method of claim 1, further comprising the computing system displaying a visual indication of progress corresponding to a phase of a plurality of phases, each phase of the plurality of phases being associated with provisioning a respective set of infrastructure components or deploying a respective set of software artifacts to a set of execution targets, each execution target of the set of execution targets corresponding to a predefined region comprising at least one physical location, and the plurality of phases being associated with a predefined execution order.

4. 4. The computer-implemented method of claim 3, wherein displaying the visual indication of progress corresponding to the phase comprises displaying, within the visual indication of progress corresponding to the phase, an indicator of each of the statuses corresponding to the set of execution targets.

5. the computing system identifying a previous configuration of a software artifact of the second set of software artifacts; identifying, by the computing system, a new configuration of the software artifacts based at least in part on deploying the second set of software artifacts; and the computing system providing, via the user interface, an indication of the changes from the previous configuration to the new configuration of the software artifact.

6. The computing system includes the first set of infrastructure components. detecting a failure in provisioning of at least one infrastructure component of the infrastructure components; the computing system displaying, via the user interface, an indication of the failure; receiving user input from the computing system; 10. The computer implemented method of claim 1, further comprising the step of: the computing system performing at least one remedial action in response to the user input.

7. detecting, by the computing system, a failure in the deployment of at least one software artifact of the second set of software artifacts; the computing system displaying, via the user interface, an indication of the failure; receiving user input from the computing system; 10. The computer implemented method of claim 1, further comprising the step of: the computing system performing at least one remedial action in response to the user input.

8. 10. The computer-implemented method of claim 1, wherein deploying the second set of software artifacts comprises changing software resources associated with an execution target from a first state to a second state, the computer-implemented method further comprising the computing system displaying a set of changes to be made to the software resources as part of changing the software resources from the first state to the second state.

9. 10. The computer-implemented method of claim 1, further comprising generating the user interface to comprise the plurality of user interface elements that identify at least the first status associated with provisioning the first set of infrastructure components and the second status associated with deploying the second set of software artifacts.

10. 1. 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: Run the declarative infrastructure provisioner, causing a first set of infrastructure components to be provisioned based at least in part on providing a first set of declarative instructions to the declarative infrastructure provisioner; deploying a second set of software artifacts based at least in part on providing a second set of declarative instructions to the declarative infrastructure provisioner; providing a user interface displaying a plurality of user interface elements, the plurality of user interface elements including at least a first status associated with causing the first set of infrastructure components to be provisioned and a second status associated with causing the second set of software artifacts to be deployed; and a second status that is assigned to the system.

11. 11. The system of claim 10, wherein the first status associated with causing the first set of infrastructure components to be provisioned and the second status associated with causing the second set of software artifacts to be deployed correspond individually to one or more execution targets, each execution target of the one or more execution targets corresponding to a predefined region comprising at least one physical location.

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

13. Execution of the instructions further causes the system to: identifying a previous configuration of a software artifact of the second set of software artifacts; identifying a new configuration of the software artifacts based at least in part on deploying the second set of software artifacts; The system of any one of claims 10 to 12, further comprising providing, via the user interface, an indication of changes from the previous configuration to the new configuration of the software artefact.

14. Execution of the instructions further causes the system to: detecting a failure in the provisioning of at least one infrastructure component of the first set of infrastructure components or the deployment of at least one software artifact of the second set of software artifacts; displaying an indication of the failure via the user interface; Receive user input, The system of any one of claims 10 to 13, wherein at least one remedial action is performed in response to said user input.

15. 1. A non-transitory computer-readable storage medium comprising one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause a computing device to: Run the declarative infrastructure provisioner, causing a first set of infrastructure components to be provisioned based at least in part on providing a first set of declarative instructions to the declarative infrastructure provisioner; deploying a second set of software artifacts based at least in part on providing a second set of declarative instructions to the declarative infrastructure provisioner; providing a user interface displaying a plurality of user interface elements, the plurality of user interface elements being associated with at least the first set of infrastructure elements; a first status associated with causing the infrastructure component to be provisioned and a second status associated with causing the second set of software artifacts to be deployed.

16. 16. The non-transitory computer-readable storage medium of claim 15, wherein the first status associated with causing the first set of infrastructure components to be provisioned and the second status associated with causing the second set of software artifacts to be deployed correspond to one or more execution targets, respectively, each execution target of the one or more execution targets corresponding to a predefined region comprising at least one physical location.

17. 17. The non-transitory computer-readable storage medium of claim 15 or 16, wherein execution of the instructions further causes the computing device to display a visual indication of progress corresponding to a phase of a plurality of phases, each phase of the plurality of phases being associated with provisioning a respective set of infrastructure components or deploying a respective set of software artifacts to a set of execution targets, each execution target of the set of execution targets corresponding to a predefined region comprising at least one physical location, and the plurality of phases being associated with a predefined order of execution.

18. Execution of the instructions further causes the computing device to: identifying a previous configuration of a software artifact of the second set of software artifacts; identifying a new configuration of the software artifacts based at least in part on deploying the second set of software artifacts; 18. The non-transitory computer-readable storage medium of claim 15, further comprising: a user interface configured to provide an indication of changes from the previous configuration to the new configuration of the software artifact.

19. Execution of the instructions further causes the computing device to: detecting a failure in the provisioning of at least one infrastructure component of the first set of infrastructure components or the deployment of at least one software artifact of the second set of software artifacts; displaying an indication of the failure via the user interface; Receive user input, The non-transitory computer-readable storage medium of any one of claims 15 to 18, configured to cause at least one remedial action to be taken in response to the user input.

20. 20. The non-transitory computer-readable storage medium of claim 15, wherein causing the second set of software artifacts to be deployed comprises modifying a software resource associated with an execution target from a first state to a second state, and execution of the instructions further causes the computing device to display a set of changes to be made to the software resource as part of modifying the software resource from the first state to the second state.

21. 1. A computer-implemented method comprising: The computing system provides a user interface displaying a plurality of user interface elements, the plurality of user interface elements displaying at least a first set of infrastructure components. and identifying a first status associated with deploying a second set of software artifacts and a second status associated with deploying a second set of infrastructure, wherein 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.

22. 1. 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:

1. A system for providing a user interface displaying 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 being provisioned based at least in part on a declarative infrastructure provisioner, and the second set of software artifacts being provisioned based at least in part on the declarative infrastructure provisioner.

23. 1. A non-transitory computer-readable storage medium comprising one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause a computing device to:

1. A non-transitory computer-readable storage medium for causing a user interface to be provided 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 being provisioned based at least in part on a declarative infrastructure provisioner, and the second set of software artifacts being provisioned based at least in part on the declarative infrastructure provisioner.

24. Apparatus comprising means for carrying out the steps of any one of claims 1 to 9 and 21.

Images