Technique for utilizing directed acyclic graph for deployment instruction

Abstract

To provide a method of, a system for, and a storage medium for utilizing a directed acyclic graph for deployment instructions.SOLUTION: A method realized by a computer includes various operations. A computing device executes instructions for executing a plurality of times of analysis of setting data relating to deployment to generate a first DAG (directed acyclic graph). The first DAG is used for deploying a first resource based on the analysis. The computing device generates a second DAG for use in deployment of an execution target based on the analysis. The second DAG designates a dependency relation among the execution targets for deployment. The computing device further generates a connection list data structure based on the analysis and traverses the connection list data structure to thereby deploy the computing system.SELECTED DRAWING: Figure 15

Description

[Technical Field]

[0001] This application is a utility application and claims the benefit of and priority under 35 U.S.C. §119(e) to U.S. Provisional Application No. 62 / 963,477, filed January 20, 2020, and entitled "TECHNIQUES FOR UTILIZING DIRECTED ACYCLIC GRAPHS FOR DEPLOYMENT INSTRUCTIONS," and U.S. Utility Application No. 16 / 953,262, filed November 19, 2020, and entitled "TECHNIQUES FOR UTILIZING DIRECTED ACYCLIC GRAPHS FOR DEPLOYMENT INSTRUCTIONS," the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002] background Today, cloud infrastructure services utilize many individual services for provisioning and deploying 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 largely declarative and code deployment is imperative. On top of this, cloud infrastructure services must continue to grow as the number of service teams and regions increases. The strategy of some cloud infrastructure services to deploy to more and smaller regions, while splitting spending by region, does not scale well. Summary of the Invention [Means for solving the problem]

[0003] overview Techniques for utilizing a directed acyclic graph for deployment instructions are disclosed. In some embodiments, a computer-implemented method may include various operations. Instructions may be executed by a computing device to perform an analysis of configuration data related to deployment. The computing device may generate a first directed acyclic graph (DAG), where the first DAG is utilized to deploy a first resource (e.g., a software service) based on the analysis. A second DAG may be generated for deploying execution targets based on phases, where the second DAG specifies dependencies between execution targets of the deployment. The computing device may generate a linked list data structure based on the analysis and may deploy the computing system by traversing the linked list data structure.

[0004] In another embodiment, a system for utilizing a DAG for deployment instructions is disclosed. The system may include one or more processors and one or more memories having computer-executable instructions stored therein that, when executed by the one or more processors, configure the one or more processors to perform various operations. A computing device may execute instructions to perform one or more analyses of configuration data associated with deploying a computing system. The computing device may generate a first DAG, the first DAG being utilized to deploy a first resource based at least in part on performing the one or more analyses. The computing device may generate a plurality of execution targets based at least in part on performing the one or more analyses. The computing device may generate a second DAG for deploying the target, the second DAG specifying dependencies between execution targets of the deployment. The computing device may generate a linked list data structure based at least in part on performing the one or more analyses, the linked list data structure specifying dependencies between the multiple deployment phases. The computing device may then deploy the computing system based at least in part on traversing the linked list data structure, the second DAG, and the first DAG.

[0005] In another embodiment, a computer-readable storage medium for utilizing a DAG for deployment instructions is disclosed, the computer-executable instructions may store thereon. The computer-executable instructions, when executed by one or more processors, cause the one or more processors to perform various operations. A computing device may execute instructions to perform one or more analyses of configuration data associated with deploying a computing system. The computing device may generate a first DAG, the first DAG being utilized to deploy a first resource based at least in part on performing the one or more analyses. The computing device may generate a second DAG for deploying multiple execution targets based at least in part on performing the one or more analyses, the second DAG specifying dependencies between the execution targets of the deployment. The computing device may generate a linked list data structure based at least in part on performing the one or more analyses, the linked list data structure specifying dependencies between multiple deployment phases. The computing device may then deploy the computing system based at least in part on traversing the linked list data structure, the second DAG, and the first DAG.

[0006] In other embodiments, an apparatus is disclosed, which may comprise means for performing the steps of the methods disclosed herein.

[0007] In another embodiment, a computer program product is disclosed, which may include computer instructions that, when executed by a processor, perform the steps of the methods disclosed herein.

[0008] To facilitate easy comprehension of the description of a particular element or operation, the leading digit or digits in a reference numeral refer to the number of the figure in which that element is first introduced. [Brief explanation of the drawings]

[0009] [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 Flock in accordance with at least one embodiment. [Figure 4] FIG. 1 is a flow diagram illustrating an exemplary Flock in accordance with at least one embodiment. [Figure 5] 1 is a user interface presenting information about a release that includes multiple phases and multiple execution targets, according to at least one embodiment. [Figure 6] 10 is an exemplary code segment for defining a list and order of phases according to at least one embodiment. [Figure 7] 1 is an exemplary data structure that may be generated by a Cloud Infrastructure Orchestration Service (CIOS) to hold lists and orders associated with one or more phases, according to at least one embodiment. [Figure 8]10 is an exemplary code segment for defining a list and order of execution targets according to at least one embodiment. [Figure 9] 1 is an exemplary data structure that may be generated by a Cloud Infrastructure Orchestration Service (CIOS) to hold a list and order associated with one or more execution targets associated with a phase, according to at least one embodiment. [Figure 10] 1 is an exemplary code segment for establishing explicit and implicit dependencies between resources of an execution target, according to at least one embodiment. [Figure 11] 1 is an exemplary code segment for establishing explicit and implicit dependencies between resources of an execution target, according to at least one embodiment. [Figure 12] 1 is an exemplary directed acyclic graph corresponding to resources of a cloud computing system, in accordance with at least one embodiment. [Figure 13] FIG. 1 is a flow diagram illustrating an example process for orchestrating the execution of a task that includes a dependency on at least one capability, according to at least one embodiment. [Figure 14] 1 is an exemplary process flow for a computer infrastructure orchestration service traversing a linked list, a directed acyclic graph of execution targets, and a directed acyclic graph of capabilities, according to at least one embodiment. [Figure 15] 1 is a flowchart of a process for deploying a computing system using a directed acyclic graph in a computer infrastructure orchestration service, according to at least one embodiment. [Figure 16] FIG. 1 is a block diagram of a distributed system according to at least one embodiment. [Figure 17]A block diagram of one or more components of a system environment according to at least one embodiment, whereby services provided by one or more components of an embodiment of the system can be provided as cloud services. [Figure 18] 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

[0010] 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 classifications (or subcategories) of cloud computing services. Many consider the other major classifications to be software as a service (SaaS) and platform as a service (PaaS), with SaaS sometimes considered a broader classification that includes both PaaS and IaaS, and some considering IaaS a subclassification of PaaS.

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

[0012] In some cases, IaaS providers may supply various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) that accompany these infrastructure components. The ability to be service driven will enable IaaS users to implement policies that drive load balancing to maintain application availability and performance.

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

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

[0015] In some examples, IaaS deployment is the process of putting a new application or a new version onto a prepared application server, etc. It may also include the process of provisioning the server (e.g., installing libraries, daemons, etc.). This 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 (the OS), middleware, and / or application deployment (e.g., on self-service virtual machines (e.g., that can be spun up on demand) or the like).

[0016] In some instances, IaaS provisioning may refer to obtaining computers or virtual hosts for use and then installing the necessary libraries or services on them. In most cases, deployment does not include provisioning, which will need to be done first.

[0017] In some cases, IaaS provisioning presents two distinct problems. First, there is the initial challenge of provisioning an initial set of infrastructure before anything can be done. Second, once everything is provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges will be addressed by allowing the configuration of the infrastructure to be defined declaratively: that is, one or more configuration files define the infrastructure (e.g., which components are needed and how they interact). The overall topology of the infrastructure can then be declaratively described (e.g., which resources depend on which resources and how they interact with each other). In some cases, once the topology is defined, workflows can be generated to create and / or manage the different components described in the configuration files.

[0018] In some embodiments, IaaS provisioning may include generating a directed acyclic graph (DAG). A DAG may include any suitable number of nodes and edges. The DAG may be a finite, directed graph containing a set of edges. Each edge points from one node to another. The nodes and edges may be arranged to avoid a directed cycle. That is, the DAG is defined so that, starting from any node, a consistently directed set of edges does not eventually circle back to that same node. IaaS provisioning may include parsing configuration files corresponding to one or more resources (e.g., services, software resources, etc.) of the system. A separate DAG may be generated for each resource. The DAG for each resource may define the resource's dependency on the capabilities of one or more other resources (e.g., services, software resources, etc.) of the system. For example, a first DAG may be generated and utilized to deploy the first resource (e.g., a software service such as an email service configured to manage electronic messages for one or more users, also referred to as a "computing service"). The first DAG may indicate the dependency of the first resource on the capabilities provided by a second resource (e.g., another software service different from the first resource, such as an identity service configured to verify / authenticate a user's identity based on previously obtained credentials). The first resource and / or the second resource may each be one of multiple services provided by the computing system. A "capability" may refer to a portion of the functionality of a given resource (e.g., the second resource's ability to verify / authenticate a user's identity). A process may be instantiated to traverse the DAG. If the process reaches a node in the DAG that corresponds to a capability that is currently unavailable, the process may publish an indication to the scheduling service that the process has reached a dependency on that capability and is waiting for that particular capability to become available before proceeding. As various resources of the system are deployed and / or launched, they may publish an indication to the scheduling service that various capabilities are available as they become available.As used herein, the terms “launch,” “launching,” and “launched” refer to the process of performing a startup sequence consisting of operations corresponding to a particular resource (e.g., software / computing service, computing device, etc.). Deploying a resource (e.g., a software service) may include starting and / or making available at least some functionality (e.g., one or more capabilities) of the functionality provided by the resource. When the scheduling service determines that a particular capability has become available, it may resume the process from where it last left off (e.g., immediately after announcing that the capability is needed). This process may regenerate the DAG and resume traversal (e.g., from the last accessed node). By utilizing a DAG for each resource, the system may manage dependencies between the capabilities of different resources, eliminating the need for a human operator to manually start up complex systems.

[0019] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as a core network (which may be, for example, an on-demand pool of configurable and / or shared computing resources). 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 may also be provisioned, such as load balancers, databases, etc. The infrastructure will evolve incrementally as more infrastructure elements are desired and / or added.

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

[0021] In some cases, a provisioning tool's workflow may be configured to execute various commands. One function that may be performed is view reconciliation. In view reconciliation, the provisioning tool may compare its view of the current infrastructure (e.g., the expected infrastructure state) with the actual operation of the infrastructure. In some cases, performing the view reconciliation function may include querying various resource providers or infrastructure resources to identify which resources are actually running. Another function that a provisioning tool may perform is plan generation. In plan generation, the provisioning tool may compare the infrastructure components that are actually running with the provisioning tool's desired view of the state (e.g., the desired configuration). That is, the plan generation function may determine what changes need to be made to bring the resources to their latest expected state. In some cases, a third function is an execution (e.g., apply) function. In the execution function, the provisioning tool may execute the plan generated by the plan generation function.

[0022] In general, a provisioning tool may be configured to take a configuration file, parse the declarative information contained within the configuration file, and programmatically / automatically determine the order in which resources must be provisioned to execute a plan. For example, if a VPC needs to be launched before security group rules and VMs are launched, the provisioning tool can make this determination and enforce the determined order of launch without user intervention and / or without having to include that information in a configuration file.

[0023] In some cases, continuous deployment techniques may be employed to enable the deployment of infrastructure code across various virtual computing environments. In addition, the described techniques may enable infrastructure management within these environments. In some examples, a service team may write code that they want to deploy to one or more production environments, often many different production environments (e.g., across various different geographic locations, and possibly across the globe). However, in some examples, the infrastructure onto which the code will be deployed must first be set up. In some cases, provisioning may be done manually, provisioning tools may be utilized to provision the resources, and / or deployment tools may be utilized to deploy the code once the infrastructure is provisioned.

[0024] As mentioned above, there are generally two different tools utilized to address the provisioning of infrastructure resources and the deployment of code to control the infrastructure resources, with manual orchestration between the tools. However, when implemented at scale, manual implementations invariably result in misalignment. Therefore, automated tools that can both provision and deploy virtual infrastructure enable a more efficient and reliable technique for implementing virtual cloud environments.

[0025] In some instances, when two tools are used, problems can arise if a user manually makes changes to the code between the provisioning and deployment phases. Techniques using one tool for both provisioning and deployment, as described herein, can mitigate these problems by automating the process and eliminating the opportunity for manual code changes. A small change in one user's coding could potentially cause major problems during the deployment phase. In some instances, when an operator first operates in a new region (e.g., with a typo in the code), the object coded with the typo may remain. If the application is deployed with the typo and the application is not affected by the typo (e.g., it works), future additional code changes may be affected by the typo and crash the entire system. Thus, the techniques provided herein can eliminate the gap between provisioning and deployment, which can often lead to problems.

[0026] Typically, modeling deployments is declarative, allowing for the use of configuration files to declare infrastructure resources. For example, CRUD (Create, Read, Update, and Delete) instructions are commonly used to generate deployment files using common REST (Representational State Transfer) concepts (e.g., REST APIs (Application Programming Interfaces)). However, the deployment itself does not typically follow the same concepts. In addition to this, while infrastructure provisioning tools tend to be very powerful and / or expressive, deployment tools tend to be much more limited in terms of the operations they can perform (e.g., deployment tools are imperative as opposed to declarative). Thus, there has long been a need for a single tool that can address both functional requirements (e.g., provisioning and deployment of infrastructure elements) within a cloud environment.

[0027] In some examples, techniques for implementing a Cloud Infrastructure Orchestration Service (CIOS) are described. These techniques can be configured to manage both the provisioning and deployment of infrastructure resources within a cloud environment, as briefly described above. In some cases, a CIOS may include two classes of services: a central component and a regional component (e.g., CIOS Central and CIOS Regional). The following terms are used throughout the specification:

[0028] ● Infrastructure Components - Long-term pieces of infrastructure that support working code.

[0029] Examples: deployment applications, load balancers, DNS (Domain Name System) entries, object storage buckets, etc.

[0030] Artifact - deployment application or Kubernetes The code deployed to the Engine cluster or the configuration information applied to infrastructure components (hereafter "config"). These may be read-only resources.

[0031] Deployment Tasks - Short-lived tasks often related to deploying or testing code. Additionally, deployment tasks are modeled as resources that do not outlive the release that creates them.

[0032] For example: "deploy $artifact to $environment", "watch $alarm for 10 minutes", "execute $testSuite", or "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 complete.

[0033] Because CIOS maintains the state of its cloud infrastructure service declarative provisioners, CIOS can control the lifecycle of these short-lived resources as it relates to release.

[0034] ● Resources − CRUDable resources. CIOS models each of the constructs listed above as a resource. The next section provides more details about this modeling.

[0035] Flock - A model of CIOS that encapsulates the control area and all components. It exists primarily to model ownership of and point to infrastructure components.

[0036] Flock configuration - describes the set of all infrastructure components, artifacts, and deployment tasks related to a service.

[0037] Each Flock has exactly one Flock configuration, which is checked in to gain control provenance.

[0038] Flock configuration is declarative, requiring the realm, region, advertisement, and artifact version to be provided as input by CIOS.

[0039] Flock is fine-grained - Flock consists of a single service and supporting infrastructure.

[0040] ● State - A current snapshot of the state of all resources in the Flock. ● Release - A tuple consisting of a concrete version of a Flock configuration, and the concrete versions of all artifacts it references.

[0041] ○We believe that the release describes a state that may not yet exist. Release Plan - A set of steps that CIOS will take to transition all regions from their current state to the state described by the release.

[0042] o A release plan has a finite number of steps and definite start and end times.

[0043] Apply - This is a noun. An attempt to execute a release plan. The execution changes the current state of the Flock.

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

[0045] ●Provide the team with a view of the current state of CIOS-managed resources, including in-flight change behavior.

[0046] ● Assist the team in planning and releasing new changes. Coordinates actions between various downstream systems within a region to execute approved release plans without human intervention.

[0047] Coordinate actions across regions / realms to execute approved release plans globally.

[0048] In some instances, CIOS addresses onboarding by allowing teams to provide CIOS with configuration information via checked-in code. Additionally, CIOS is a more important aspect of operations than it was in previous implementations because it can automate other things. In some cases, CIOS addresses pre-deployment by providing teams with the ability to automatically deploy and test code. In some cases, CIOS can address writing CM (change management) policies by allowing teams to automatically generate plans for rolling out new artifacts (e.g., worldwide) when they build them. This can be done by inspecting the current state of each region and the current CIOS configuration (which can itself be an artifact). Additionally, teams can inspect these plans and iterate on them by changing the CIOS configuration and requesting CIOS to recreate the plan. Once satisfied with the plan, the team can create a "release" that references the plan. The plan can then be scored for approval or rejection. Teams can still write CMs, but these are merely pointers to the CIOS plan. This reduces the time teams spend thinking about the plan. The accuracy improves as the plans are machine generated, and although the plans are too detailed for humans to understand, they can be displayed via an advanced UI (user interface).

[0049] In some examples, CIOS can handle CM execution by automatically executing deployment plans. Once a release plan is created and approved, engineers have no further participation in CM unless CIOS initiates a rollback. This may require teams to automate currently manual tasks in some cases. In some examples, CIOS can handle CM (change management) rollback by automatically generating a plan to return a Flock to its original (e.g., pre-release) state upon detecting a degradation in service health during operation. In some examples, CIOS can handle deploying sudden / strategic changes by receiving a release plan that is limited in scope to a subset of regions and / or a subset of resources managed by CIOS, and then executing the plan.

[0050] In addition to this, CIOS may support the primitives needed 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 when a service degrades, and then have it executed automatically. CIOS can automatically generate and display release plans and track approvals. In some cases, the language used by teams to describe desired deployment behavior may be declarative. CIOS can combine the functionality of code deployment with infrastructure configuration (e.g., provisioning) into a single system. CIOS can also support regional deployments. Supports flexible ordering between regions and between components within a region. Teams can indicate ordering via checked-in configuration. Teams can programmatically call CIOS planning and release APIs.

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

[0052] Responsible for serving as the authentication gateway for Flock metadata changes and release operations.

[0053] Store a trusted mapping of Flock metadata in deployment artifacts and Flock's CIOS repository.

[0054] • Coordinate the global release across phases and targets. ● Synchronization to enforce policies like "only one in-progress release to Flock at a time."

[0055] Detects changes to Flock configuration and artifacts and triggers the generation of releases accordingly.

[0056] In some examples, a Source Code Version Control and Management Service (SCVMS) 104 can be configured to store trusted Flock configurations, and CIOS Central 102 can subscribe to an Artifact Notification Service (ANS) 106 so that CIOS Central 102 is notified about new artifact builds. CIOS Central 102 can then map the incoming changes to the affected Flocks and initiate release planning, if necessary. In addition to this, in some examples, an Artifact Push Service (APS) can be invoked by CIOS Central 102 prior to a release to the target, ensuring that all of the artifacts required for a successful release are present in the target region prior to the release.

[0057] In some examples, customers (e.g., engineers) 108 can call CIOS Central 102 for CRUD Flock and / or Release to see the status of ongoing CIOS activities. A Flock Management Service 110 can include one or more APIs for manipulating Flocks; a View / Plan / Approval Service 112 can include CRUD APIs for creating and approving plans and for viewing a central copy of the state of all resources managed by CIOS; a Change Monitoring Service 114 can watch the SCVMS 104 for changes made to Flock configurations and can receive notifications about changes made to other artifacts from ANS 106; and a State Ingester Service 116 can create copies of regional state in a CIOS Central DB (database) 118 for View / Plan / Approval 112 to expose. In some examples, the CIOS Central DB 118 can be a DB for Flocks, Plans, and States. Flock information can be authoritative, while other information can be an outdated copy of data from CIOS Regional 120. CIOS Central 102 may provide any suitable portion of and / or any number of user interfaces (e.g., user interfaces 500-1300) for presenting any suitable data regarding Flocks, releases, infrastructure components, artifacts, etc. In some embodiments, CIOS Central 102 may be configured to present data about one or more releases via any suitable interface. A release may include any suitable combination of tasks related to one or more infrastructure components and / or one or more code changes to one or more applications (e.g., artifacts). Some example user interfaces provided by CIOS Central 102 are described below in FIGS. 5-13.

[0058] In some examples, engineers 108 can perform API calls to the Flock Management Service 110 (e.g., through the Ingress Proxy Fleet 122) to create a list of Flocks. The protocol for making such API calls may be, for example, HTTPS (Hypertext Transport Protocol Secure). The relevant ACLs (Access Control Lists) for this operation may include a LAN (Local Area Network) 124 or other private connection. For example, the CIOS may manage / control network connectivity instead of using the public Internet (e.g., dedicated, leased, and / or private connections) to connect a customer's on-premises data center or network with the CIOS. Additionally, authentication and authorization (e.g., of engineers 108) may be performed by a reservation system portal that allows users to manage machine infrastructure (e.g., reservation services). In some cases, the CIOS Central 102 can store Flock metadata, plans, and states in a central DB 118, for example, using JDBC (Java Database Connectivity). In some examples, the ANS 106 can be configured to notify the Change Monitoring Service 114 when new artifacts are published. The ANS 106 may utilize HTTPS, and both authentication and authorization may be handled by Mutual Transport Layer Security Services. Additionally, in some cases, the Integrity Monitoring Service 114 may poll the SCVMS 104 for changes to Flock configuration. This polling may be done using SSH (Secure Shell) or other protocols. Authentication of the Integrity Monitoring Service 114 may be handled by a CIOS system account, and authorization may be handled by the SCVMS 104.

[0059] In some examples, an engineer 108 can use the view / plan / approval service 112 to perform one or more of the following operations: The engineer 108 can create plans and / or approvals by calling the CIOS central 102 to generate and approve plans. The engineer 108 can view the status of ongoing global CIOS operations by calling the CIOS central 102. Additionally, the engineer 108 can view a copy of the state of global resources managed by the CIOS by calling the CIOS central 102. These API calls (or the like) can be made via HTTPS or a similar protocol. Additionally, the relevant ACLs can be controlled by the LAN 124, and both authentication and authorization can be handled by the reservation service. In some examples, the view / plan / approval service 112 can request a plan and drive approval of the plan to all regions of the CIOS regionals 120 (e.g., using HTTPS). The relevant ACLs can be controlled using security lists managed by the wide area network (WAN) gateway 126. Authentication can be handled by mutual transport layer security, and authorization can be handled by various identity policies. Additionally, the State Ingester service 116 can watch the CIOS regional 120 for job status or state changes, and the CIOS can provide a central view of these on request (e.g., also using HTTPS). ACLS for this can also be handled by the WAN gateway 126, and both authentication and authorization can be handled by mutual transport layer security services.

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

[0061] Handles all CIOS authentication for operations received from CIOS Central 102.

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

[0063] Manages binary artifact storage for declarative provisioning artifacts used as inputs and outputs during declarative infrastructure provisioning runs. Examples of inputs include declarative infrastructure provisioning configuration files and input state files. The output is typically a final state file.

[0064] Requests work from the CIOS executor for a given execution and polls the results from the CIOS executor.

[0065] In some cases, the CIOS front-end may rely on a CIOS executor 206 (also referred to herein as a "scheduler") that can handle the actual execution. The CIOS executor, in some instances, operates at the "execution" level and can perform the following operations:

[0066] ● Keep track of the pool of available worker nodes. Querying incoming job requests and assigning these requests to eligible workers as they become available.

[0067] Tracking worker status and execution updates for reporting to clients.

[0068] Dead nodes can be detected through the leasing protocol and tasks assigned to the dead node can be stopped from functioning depending on the status of the tasks.

[0069] It provides facilities to cancel / kill / pause / resume execution, and can map these to facilities to pass cancel / kill / resume information to worker nodes.

[0070] In some cases, a CIOS executor may rely on CIOS workers, which can assign tasks to workers to execute, and can provide facilities to allow workers to be updated on the progress of their jobs. The worker service operates at the granularity of a "task". Each worker is an agent that executes the tasks assigned to it and reports the task's status and output. Each worker can:

[0071] Polls the ExecutorWorker API for assigned work items and takes action to match the assigned state with its local state.

[0072] Start a container to poll for task items that do not exist locally. o Kill containers for locally running containers that do not have a corresponding task item assigned to them.

[0073] ● Report the status of the job. ● Stage inputs and outputs for job container execution.

[0074] Launching and monitoring declarative infrastructure provisioning containers to do the actual work of the release for the execution target.

[0075] CIOS workers may rely on CIOS executors to poll for work from the CIOS executor's worker endpoint and report results back to the CIOS executor's worker endpoint. Workers may rely on the executors for all coordination. In addition, CIOS workers may rely on CIOS regionals 202, where worker services read input from and write output to one or more APIs associated with regional front-end services. Examples of inputs include configuration and start state files and import mappings. Examples of outputs include the declarative provisioning process, the output of declarative provisioning state files, and the import of result states.

[0076] In some examples, CIOS regional 202 may be a regional service for managing regional instances / deployments of CIOS. CIOS regional 202 covers the responsibility of authoritatively storing and managing plans and state associated with a particular region. Regional DB 204 may be a CIOS DB for state and plans in a particular region. This is an authoritative copy of the regional subset of central DB 118 of FIG. 1. Scheduler 206 may be responsible for managing the fleet capacity of workers, assigning tasks to workers, and tracking the state of tasks. In some cases, task DB 208 is another CIOS DB for task state. The data in this DB is mostly operational data. Additionally, workers 210 may be a fleet of JVMs (Java Virtual Machines) that manage declarative provisioning images. They receive instructions from scheduler 206 and communicate results to both scheduler 206 and CIOS regional 202. The CIOS container 212 can perform declarative provisioning operations in its own private Docker 214 container, which does not need to contain secrets. Additionally, in some examples, to avoid secrets being included in the declarative provisioning image, the signing proxy 216 can be configured to prevent secrets from being exfiltrated via the declarative provisioning tool. Instead, the CIOS can perform request signing or initiate mTLS (mutual transport layer security) services at the proxy. This also facilitates the use of FIPS-compliant cryptographic libraries.

[0077] In some examples, CIOS Central 102 can call CIOS Regional 202 to create plans, drive approvals, watch job status (service principals), and extract declarative provisioner state (service principals). Ingress Proxy 218 can be configured as an ACL, and various identity policies can be used for authentication and authorization. Alternatively, in some examples, Ingress Proxy 218 can be configured to load balance incoming requests, plans, etc. A configured load balancer may be substituted. In some cases, CIOS regional 202 may ask scheduler 206 to execute the declarative provisioner. Worker 210 may check with scheduler 206 about what should be running and report the status back to scheduler 206 upon completion. In some cases, mTLS may handle both authentication and authorization for CIOS regional 202 and worker 210. Additionally, if a declarative provisioner needs to be executed, worker 210 does so within a Docker container by interacting with local Docker 214. Authentication for this step may be handled by a local Unix socket. This final step may use the Docker protocol, but the previous steps may utilize HTTPS.

[0078] In some embodiments, CIOS regional 202 may be configured to provide any suitable portion of and / or any number of user interfaces (e.g., user interfaces 500-1300) for presenting any suitable data related to flocks, releases, infrastructure components, artifacts, etc. In some embodiments, CIOS regional 202 may present data related to one or more releases via any suitable interface. A release may include any suitable combination of tasks related to one or more infrastructure components and / or one or more code changes to one or more applications (e.g., artifacts). Some example user interfaces provided by CIOS regional 202 are described below in FIGS. 5-13.

[0079] In some examples, the CIOS container 212 allows the declarative provisioner to interact with the signing proxy 216 (via an API) while the declarative provisioner believes the signing proxy 216 is invoking various CIOS services. The signing proxy 216 listens on one ephemeral port per invocation instance of the declarative provisioner, known only to the declarative provisioner. The signing proxy 216 can initiate signature or mTLS requests and pass the declarative provisioner's invocation to other CIOS services within the service enclave. In some cases, the signing proxy 216 can also communicate with one or more public CIOS services 220. For example, the signing proxy 216 utilizes the internal endpoints of public services when available. Services without internal endpoints must utilize the egress proxy 222 to reach their external endpoints. This use of signing proxy 216 need not be for inter-region communication; for example, the egress proxy whitelist in each region may whitelist only for that region's public IP range. In some examples, worker 210 may then maintain state and logs from the declarative provisioner in CIOS regional 202 so that they can be flushed to CIOS central 102.

[0080] With CIOS, there are four phases of a typical customer experience: onboarding, pre-release, worldwide release, and strategic release. For the pre-release phase, examples of events that can occur between the new artifact being built and the artifact being released to Release 1 (e.g., R1) include: This will replace some or most of the current change management process. Once the relevant artifacts are built, CIOS can automatically generate a release with "the latest version of everything in Flock." A release is a concrete version of a Flock configuration with concrete inputs (e.g., artifact version, realm, region, and advertisement). A release contains one rollforward plan per region and metadata describing the region ordering. Each regional plan is a set of actions the declarative provisioner can take to realize the Flock configuration in that region. Teams with pre-release environments can use CIOS to automatically release and test software in those environments. Teams can configure CIOS to automatically test rollback plans. Teams will be able to inspect and approve releases through the CIOS UI. Teams can approve some, but not all, of the regional plans in a release. If "all latest versions" does not result in a suitable plan, teams can request CIOS to generate plans for select artifact versions.

[0081] For the Worldwide Release phase, here is an example of how the team executes tomorrow's version of today's "Normal CM": Once the release is approved, CIOS pushes the approved regional plan to each region. CIOS operates independently within each region to enforce the approved plan. CIOS only takes the set of actions explicitly described in that region's plan. It does not "think on its own" - it fails. The CIOS UI displays execution progress to the team. If manual approval is required, the CIOS UI prompts the team. If the execution fails due to an outage in the CIOS or downstream services, CIOS can notify the team and prompt them about next steps (e.g., abort, retry). CIOS retries, but outages in downstream systems outweigh the willingness to retry. If the execution fails due to degraded service health or test failures, CIOS helps the team roll back the Flock to its starting state. CIOS notifies (e.g., calls) the team when to initiate the automatic rollback. The team must approve this rollback plan, which is then executed by CIOS.

[0082] For the strategic release phase, here's an example of how the team executes the "new CM" for tomorrow's version: When generating the plan, the team may ask CIOS to target the plan on specific resources in several ways: topologically (e.g., realm, region, advertisement, etc.), by resource type (e.g., "metric configuration only" or "deployment orchestration service deployment only"), or a combination of the above (e.g., in isolation). The team approves the strategic release in the same way as a global release. CIOS orchestrates the strategic release in the same way. If the team needs to deploy a strategic release even though there is an active global release, CIOS will stop the execution of the global release in the target region and then start the execution of the strategic release.

[0083] In some instances, the declarative provisioner's state (e.g., typically a file) is an authoritative record of the set of resources that the declarative provisioner manages. It contains a mapping between each resource's logical identifier from the configuration file and the resource's actual identifier. When the declarative provisioner creates resources, certain types of failures can cause the actual identifier to no longer be recorded in the state. This occurs when the actual identifier is no longer in the declarative provisioner's possession. These can be called "orphaned resources".

[0084] For most resources, orphans represent garbage: the declarative provisioner will launch an instance that it forgot about (for example), but instead of it running the next time, the declarative provisioner will launch another instance. For resources with uniqueness constraints or client-provided identifiers, orphans will cause the declarative provisioner to It will be unable to proceed. For example, if the declarative provisioner creates a user "nglass" and the failure causes it to become orphaned, the next run of the declarative provisioner will attempt to create "nglass," but the creation will fail because a user with that username already exists. In some cases, orphaning is only an issue when adding new resources to the state. In some cases, the declarative provisioner's update operations may naturally recover from failures to record updates and deletions.

[0085] CIOS must be robust in the event of outages of downstream services or the CIOS itself. CIOS can utilize the declarative provisioner to apply changes, so it can be said to be robust in running the declarative provisioner and preserving the declarative provisioner state. The declarative provisioner provider performs "minor" retries that are sufficient to avoid outages that last a few minutes. For example, a cloud provider may perform retries for a maximum of 30 minutes. If the downstream system outage lasts longer than 30 minutes, the declarative provisioner will fail. When the declarative provisioner fails, it records all changes it made during normal operation in its state and then exits. To retry, the CIOS must rerun the declarative provisioner. Rerunning the declarative provisioner also allows the CIOS to retry in the event of a failure of the CIOS itself. In some cases, the CIOS can perform the following actions in a loop:

[0086] Update - The declarative provisioner invokes the GET API to retrieve a recent snapshot of all resources described in the state.

[0087] ● Plan - Given the current state, including any recent updates, the declarative provisioner generates a plan (a sequence of concrete API calls) that will achieve the desired state.

[0088] ● Apply - The declarative provisioner executes the set of steps contained in the plan. CIOS may always perform all three of these steps when running a declarative provisioner. The update operation helps recover from updates or deletions that were not recorded. CIOS inspects the results of executing the plan and compares it to the approved release plan. If the newly generated plan contains actions that were not included in the approved release plan, CIOS may fail and notify the service team.

[0089] FIG. 3 shows a DAG (Directed Acyclic Graph) 300 to illustrate an example Flock 302. The progression of code / configuration from check-in to production for one Flock configuration in CIOS can be described, from initial test deployment to final production deployment. Internally, CIOS calls each element in the progression of ETs (Execution Targets), which exist throughout the internal API but do not leak to the Flock configuration. CIOS executes 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 generally one copy of the service described by the Flock configuration.

[0090] Figure 4 is 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 progression using tenancies and regions of the cloud infrastructure. Teams should not model progression using realms. CIOS allows teams to use many tenancies within a realm and many regions within a tenancy. However, CIOS prohibits teams from using the same region twice within a tenancy (but each in a different region). (The same region may be used twice within a realm in different tenancies.) DAG 400 shows a variation of DAG 300 in Figure 3 expressed using tenancies and regions. This example is for an overlay service where the pre-production ET is in the production region. Service Enclave Service Release 1 has an unstable tenancy and a stable tenancy. In DAG 400, IAD is the regional airport code for Dulles Airport in Washington, DC; YYZ is the regional airport code for Toronto in Ontario; PHX, LHR, and FRA are the regional airport codes for Phoenix, London, and Frankfurt, respectively; and LUF and LFI are the airport codes for two different air force bases.

[0091] In one embodiment, CIOS and / or other technologies described herein are modifications of each of Terraform (a declarative provisioning tool), Tanden (a code generation tool), and ODO (Oracle Deployment Orchestrator). Additionally, 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.

[0092] FIG. 5 illustrates a user interface (UI) 500 presenting information about a release that includes multiple phases and multiple execution targets, according to at least one embodiment. The UI 500 may include a phase area 502 and an execution target area 504. The phase area 502 may show an ordered list of phases, such as phase 506 (e.g., “R_n”), phase 507 (e.g., “R_s”), phase 508 (e.g., “R_e”), and phase 509 (e.g., “R_w”). In some embodiments, the order of phases may be displayed from left to right, where the leftmost phase completes before the phase to its right, which in turn completes before the phase to its right, and so on. In some embodiments, the ordered list of phases may be stored in any suitable data structure, such as a linked list. An exemplary linked list is described in further detail below in FIG. 7.

[0093] Each phase may correspond to multiple tasks (e.g., multiple tasks involving deploying one or more infrastructure resources for one or more execution targets). While the list of phases shown in UI 500 includes four phases, phase area 502 may include any suitable number of phases for deploying infrastructure resources for one or more execution targets. In some embodiments, the ordered list of phases presented in phase area 502 may be horizontally scrollable. Phase area 502 may indicate a phase number 510, a status 511, a number of completed execution targets and / or number of execution targets 513, and a Flock configuration identifier 514. Phase number 510 may indicate the number of phases included in the linked list, and status 511 may indicate the status of the release. As shown in FIG. 5, status 511 may indicate “applying,” but status 511 may also be any suitable status indicator (e.g., “not yet started,” “completed,” “failed,” etc.). 5, the number of completed execution targets and / or number of execution targets 513 indicates that deployments to 24 of the total 57 execution targets have been completed for the execution targets. The number of completed execution targets and / or number of execution targets 512 may be presented on UI 500 in any suitable manner. Although Flock configuration identifier 514 is presented on UI 500 as "13380fb2832," Flock configuration 514 may be presented on UI 500 in any suitable manner for conveying a unique identifier for the Flock configuration file corresponding to the release shown in FIG. 5.

[0094] Each subarea corresponding to a phase is identified by a phase identifier (e.g., phase identifier 51 6), a total execution target number indicator (e.g., total execution target number indicator 518), timestamp information (e.g., timestamp information 520), an execution target tracker area (e.g., execution target tracker area 522), and other suitable information regarding the phase. For example, identifier 516 (e.g., "R_s") may be any suitable alphanumeric string for uniquely identifying the phase. In some embodiments, total execution target number indicator 518 may be presented adjacent to identifier 516. Total execution target number indicator 518 indicates the total number of execution targets (e.g., 14) associated with a given phase.

[0095] The timestamp information 520 may include a start time and / or an end time, respectively, associated with when a phase began and / or completed. In some embodiments, the timestamp information 520 may include any suitable indicator for indicating the status of the corresponding phase (e.g., "not started," "failed," "completed," etc.). In some embodiments, any suitable information regarding the phase may be presented in the phase area 502. Information regarding each phase may be presented similarly, or the presentation of the phase information may be in a different format and / or may include more or less information than that shown in FIG. 5 .

[0096] An execution target tracker area (e.g., execution target tracker area 522 for phase 506) may be presented within each phase. The execution target tracker area for each phase may include one or more execution target indicators (e.g., execution target indicators 524, 526, and 528). Each execution target indicator may include a number indicating the number of tasks (e.g., deployments to the corresponding execution target) to be executed simultaneously. As an example, execution target indicator 524 indicates that a deployment to a specific execution target may be executed. Execution target indicator 526 and its placement to the right of execution target indicator 524 indicate that after completion of a first task corresponding to execution target indicator 524, another deployment to a different execution target will be executed. Execution target indicator 528 and its placement to the right of execution target indicator 526 indicate that after completion of a second task corresponding to execution target indicator 524, 12 separate deployments to 12 different execution targets will be executed. The combination of execution target indicators 524, 526, and 528 collectively represent a collapsed version of a directed acyclic graph (eg, DAG 900, described below in FIG. 9).

[0097] In some embodiments, execution target indicators 524-528 may correspond to a data structure configured to maintain a list of execution targets associated with a phase and the order in which tasks (e.g., deployments to each execution target) are to be executed. Details of an exemplary data structure for maintaining this list and order are described below in conjunction with FIG. 9. Each execution target indicator may include a ring (e.g., ring 530). The ring may be divided into any suitable number of portions corresponding to the number of execution targets associated with the execution target indicator. In the illustrated example, ring 530 may be divided into 12 equal portions. Each portion of ring 530 may correspond to a particular execution target and may be colored with a color corresponding to the status of the tasks corresponding to that particular execution target. As an example, ring 530 may indicate that nine deployments to execution targets have been completed (e.g., by nine green portions). The remaining three portions of ring 530 (e.g., colored white) may indicate that three tasks corresponding to three execution targets have not yet started. As another example, the remaining three portions of ring 530 may be colored a different color (e.g., yellow) to indicate the status of the tasks corresponding to the execution targets. The execution target indicators 528 indicate that the corresponding tasks have started but are not yet completed. Thus, by viewing the ring 530, a user can quickly visually identify the current status of the tasks associated with the execution target indicators 528. By viewing the execution target indicators in the execution target tracker area 522, a user can see that deployments to eleven execution targets have been completed and three are in progress. In some embodiments, each execution target indicator may correspond to a node in a directed acyclic graph (DAG) (e.g., DAG 900 of FIG. 9) associated with a given phase (e.g., "R_s").

[0098] Execution target area 504 may include an execution target column 532, a progress column 534, and an operation column 536. Execution target column 532 may include a list of targets (e.g., execution targets) corresponding to tasks (e.g., deployments) executed in association with a given phase (e.g., phase 506 as shown). In some embodiments, execution target column 532 may be stored chronologically or in any other suitable manner for storing task executions. Progress column 534 may include a list of progress indicators indicating a status (e.g., "successful," "not started," "in progress," etc.) corresponding to each execution target. Operation column 536 may include a list of operations to be performed on the execution targets identified in execution target column 532. For example, the list of operations included in operation column 536 may include CRUD (create, read, update, and delete) operations, etc.

[0099] FIG. 6 is an example code segment 600 for defining a list and order of phases, according to at least one embodiment. As shown in FIG. 6, code segment 600 defines four phases. Each phase is defined as a resource of type “phase” and assigned an identifier (e.g., “R_n,” “R_s,” “R_e,” and “R_n”). As shown in code segment 600, resources 602, 604, 606, and 608 correspond to respective phases. Each phase may include one or more variables, one of which may include an indicator to indicate the order of execution of each phase. In some embodiments, the indicator may indicate a dependency and / or lack of a dependency on one or more other phases. As an example, indicator 618 (e.g., predecessors=[] on line 5) may indicate a lack of relationship with other phases. This may be interpreted by the system as defining that the first phase is to be executed. Indicator 620 (e.g., predecessors=[phase.R_n.variable1]) may be utilized to indicate a dependency on another phase (e.g., phase “R_n”) by including a corresponding value assignment for a variable associated with the other phase (e.g., phase “R_n”). Similarly, indicator 622 may indicate a dependency on another phase (e.g., “R_s”) (e.g., by including a corresponding value assignment for a variable associated with “R_s”), and indicator 624 may indicate a dependency on yet another phase (phase “R_e”) (e.g., by including a corresponding value assignment for a variable associated with “R_e”).

[0100] In some embodiments, a configuration file corresponding to a release may include code segment 600. As part of the execution of a pre-processing procedure, the configuration file may be parsed / traversed one or more times. One of these traversals may analyze code segment 600 to generate a data structure in which the identity and order of execution corresponding to one or more phases may be maintained. Figure 7 shows an example of a data structure (e.g., a linked list) that may be utilized to maintain this information.

[0101] Use indicators 618-624 to establish the specific order in which the phases will be executed. For example, as shown in FIG. 6, phase "R_n" is executed first, followed by phase "R_s," phase "R_e," and phase "R_w." It will be appreciated that dependencies may indicate one or more other phases that must complete before the tasks associated with a given phase can begin. While four phases are defined in FIG. 6, it will be appreciated that any suitable number of phases may similarly be defined.

[0102] FIG. 7 illustrates an exemplary data structure (e.g., linked list 700) generated by a cloud infrastructure orchestration service (CIOS) to maintain lists and orders associated with one or more phases. Linked list 700 may be generated to identify the phases and execution order defined in code segment 600 of FIG. 6. As shown in FIG. 7, linked list 700 includes four nodes 702, 704, 706, and 708. Nodes 702, 704, 706, and 708 may each correspond to one of the four phases defined in code segment 600. Each node of the linked list may correspond to a data object configured to store any suitable information corresponding to a given phase. By way of example, a given node may store any suitable number of variables, identifiers, data structures, pointers, references, etc. corresponding to a particular phase. As a non-limiting example, node 702 corresponding to phase “R_n” may store three variables defined in code segment 600 as corresponding to phase “R_n.” Each linked list 700 node may include any suitable number of variables corresponding to a given phase.

[0103] Each node in the linked list may contain a pointer / reference to another node in the linked list (if there are multiple phases). As an example, node 702 may contain a reference to node 704. Node 704 may contain a reference to node 706. Node 706 may contain a reference to node 708. Node 708 may indicate (e.g., by a null pointer) that it is the end node of linked list 700. In some embodiments, these pointers / references may be identified based on indicators 618-624 in code segment 600.

[0104] In some embodiments, at runtime, the CIOS may identify the order in which particular phases are to be executed based at least in part on traversing linked list 700 starting from node 702 (e.g., the start node). Any suitable combination of data stored in each corresponding node may be used to execute these phases. Upon completing the operations corresponding to a given phase, the CIOS may traverse to the next phase, repeating this process any suitable number of times until the operations corresponding to the end node (e.g., node 708) of linked list 700 are completed. In some embodiments, if the operation of a given node is unsuccessful (e.g., an error occurs), the CIOS may not traverse to the next node, but may instead abort the deployment and return a notification alerting the user to inform them of this situation.

[0105] Each linked list 700 node may correspond to a data structure configured to identify and maintain an execution order corresponding to one or more execution targets. The definition and use of such data structures is described in more detail in Figures 8 and 9. It will be appreciated that linked list 700 may provide information utilized by UI 500 of Figure 5 to present any suitable information related to a phase (e.g., identifier 516, timestamp information 520, execution target 518, etc.).

[0106] FIG. 8 is an example code segment 800 for defining a list and order of execution targets (e.g., execution targets corresponding to a particular phase) according to at least one embodiment. As shown in FIG. 8, four execution targets are defined in the code segment 800. Each execution target is a resource of type "execution target." Each execution target is defined as a resource and assigned an identifier (e.g., "us-la," "us-sj," "us-sf," and "us-sd"). As shown in code segment 800, resources 802-808 each correspond to a unique execution target. Each execution target may be associated with one or more variables, one of which may include an indicator to indicate the execution order of each phase. In some embodiments, the indicator may indicate one or more dependencies and / or no dependencies on one or more other execution targets. As an example, indicator 818 (e.g., predecessors=[] on line 5) may indicate no relationship with other phases, which may be interpreted by the system as defining that the first execution target is to be executed. Indicator 620 (e.g., predecessors=[execution_target.us-la.variable1]) may be utilized to indicate a dependency on another execution target (e.g., phase "us-la") by including a value assignment corresponding to a variable associated with another execution target (e.g., execution target "us-la"). Similarly, indicator 822 may indicate a dependency on another phase (e.g., execution target “us-sj” by including a corresponding value assignment for a variable associated with execution target “us-sj”), and indicator 624 may indicate a dependency on yet another phase (e.g., execution target “us-sf” by including a corresponding value assignment for a variable associated with execution target “us-sf”).

[0107] In some embodiments, code segment 800 may be included in a configuration file corresponding to the release (e.g., the same or a different configuration file that includes code segment 800). As part of the execution of a preprocessing procedure, the configuration file may be parsed / traversed one or more times. One of these traversals may analyze code segment 800 to generate a data structure in which the identities and order of execution targets corresponding to a given phase may be maintained. Figure 9 shows an example of a data structure (e.g., a DAG (Directed Acyclic Graph)) that may be utilized to maintain this information.

[0108] Indicators 818-824 may be used to establish a specific order in which execution targets are executed. For example, as shown in FIG. 8 , tasks associated with execution target “us-la” are executed first, followed by tasks associated with execution target “us-sj,” tasks associated with execution target “us-sf,” and tasks associated with execution target “us-sd.” It will be appreciated that dependencies may indicate one or more other execution targets whose corresponding tasks must complete before tasks associated with a given execution target can begin. While four execution targets are defined in FIG. 8 , it will be appreciated that any suitable number of phases may be similarly defined. In some embodiments, execution targets may share common dependencies (e.g., the same predecessor definitions). Common dependencies may be used to indicate that tasks associated with execution targets sharing the common dependency may be executed concurrently.

[0109] FIG. 9 illustrates an exemplary data structure (e.g., a directed acyclic graph (DAG) 900) that a cloud infrastructure orchestration service (CIOS) may generate to maintain a list and order associated with one or more execution targets associated with a phase, according to at least one embodiment. DAG 900 may be one of multiple DAGs generated in response to one or more parsing of a configuration file associated with a release by CIOS. Each node in DAG 900 may correspond to an execution target. As shown in FIG. 9, DAG 900 includes six nodes (e.g., nodes 902, 904, 906, 908, 910, and 912). Each of these nodes may correspond to one of six execution targets defined in a manner similar to that described for code segment 800 in FIG. 8. Each node in DAG 900 may represent an arbitrary execution target corresponding to a given execution target. A given node may correspond to a data object configured to store any suitable information. By way of example, a given node may store any suitable number of variables, identifiers, data structures, pointers, references, etc. that correspond to a particular execution target.

[0110] Each node in DAG 900 may include pointers / references to one or more nodes in DAG 900. As an example, node 902 may include a reference to node 904. Node 904 may include references to nodes 906-910. Nodes 906-910 may each include a reference to node 912. Node 912 may indicate (e.g., by a null pointer) that it is an end node of DAG 900. In some embodiments, these pointers / references may be identified based on indicators similar to indicators 818-824 described above with respect to FIG. 8. In some embodiments, nodes 906, 908, and 910 may include a common dependency on node 904, such that tasks associated with nodes 906-910 may be executed at least in part concurrently. In some embodiments, node 912 may represent an execution target that depends on nodes 906-910. Therefore, the task associated with the execution target corresponding to node 912 can be executed only after the tasks associated with all of the execution targets corresponding to nodes 906-910 have been completed.

[0111] In some embodiments, a DAG 900 may correspond to a node of one of the linked lists 700 described above with respect to Figure 7. That is, one or more execution targets (e.g., identified and represented by a node of the DAG 900) may correspond to a particular phase (e.g., a node) of the linked list 700. In some embodiments, a node of the linked list 700 may include a reference to the DAG 900, or one or more nodes of the DAG 900 may include a reference to a node of the linked list 700.

[0112] In some embodiments, the CIOS may traverse a configuration file (e.g., including code segment 800 of FIG. 8 ) and generate a DAG 900 from this traversal. The generation of the DAG 900 may be completed as part of a pre-processing procedure performed before or at runtime. Upon completing operations corresponding to a given execution target, the CIOS may traverse to the next execution target(s), repeating this process any suitable number of times until operations corresponding to one or more end nodes (e.g., node 912) of the DAG 900 are completed. In some embodiments, if the operation corresponding to a given node is unsuccessful (e.g., an error occurs), the CIOS may not traverse the next node and may instead return a notification alerting the user to inform them of this situation.

[0113] Each node of DAG 900 may correspond to a data structure configured to identify and maintain an execution order corresponding to one or more resources (e.g., services, software modules, etc.). FIGS. 10-12 describe in more detail the definition and use of such a data structure (e.g., a DAG of capabilities). As an example, each node of DAG 900 may correspond to another DAG (e.g., DAG 1200 of FIG. 12 , which lists and orders resources and / or capabilities and identifies the order of task execution). It will be appreciated that DAG 900 may provide information utilized by UI 500 of FIG. 5 to present any suitable information related to execution target indicators 524-528. Thus, the information shown in execution target tracking area 522 may represent a simplified version of DAG 900 (e.g., the DAG corresponding to a given phase, such as phase “R_s”). In a simplified version of the DAG, the concurrently executable nodes of the DAG 900 may be condensed to one node (see, e.g., execution target indicator 528, which indicates that 12 nodes of the DAG have been condensed to one node). In some embodiments, the CIOS allocates infrastructure resources and / or release software based at least in part on traversing the DAG 900. The software artifacts may be deployed. Specific tasks and a specific order of tasks are identified as described with respect to FIGS. 10-12.

[0114] FIG. 10 is an example code segment 1000 for establishing explicit and implicit dependencies between resources of an execution target, according to at least one embodiment. Code segment 1000 includes two modules 1002 and 1004 and a resource 1006, as shown in FIG. 10. Modules 1002 and 1004 each include names 1008 and 1010, denoted “apps_example1” and “apps_example2,” respectively. The modules may include names of any suitable length containing any suitable alphanumeric character(s). Modules 1002 and 1004 may define the application / service a user wants to launch or provision. Modules 1002 and 1004 may be used to deploy applications to AvailableDomain1 and AvailableDomain2, respectively. Resource 1006 may include a multi-parameter list including a resource type 1012, denoted “type” in FIG. 10, and a resource name 1014, denoted “executor” in FIG. 10. The resource type 1012 may be any type suitable for deployment, and the resource name 1014 may be any name.

[0115] Resource 1006 may be a capability and may include implicit dependencies, explicit dependencies, or both. As shown in code segment 1000, resource 1006 attempts to assign variable “variable1” to a value equal to “module.apps_example1.variable1” and to a value accessible through a module named apps_example1 (e.g., module 1002). This is intended to indicate an implicit dependency formed between resource 1006 and module 1002. The implicit dependency formed may prevent resource 1006 from operating before module 1002 completes deployment. A process responsible for launching resource 1006 may receive notification that module 1002 has completed deployment. This notification may be sent by a scheduler (e.g., scheduler 206 in FIG. 2 ) and may be received by the process responsible for launching resource 1006. Because the resource 1006 shown in FIG. 10 does not directly establish a dependency relationship between the module 1002 and the resource 1006, the implicit dependency relationship formed is considered implicit.

[0116] In contrast, resource 1006 includes an explicit dependency at line 29 of FIG. 10 that explicitly defines a dependency relationship between resource 1006 and the app_example2 module. As shown at line 29 of code segment 1000, resource 1006 includes "depends_on=apps_example2.variable2." Based on the code at line 29, an explicit dependency may be formed that may prevent resource 1006 from being deployed until apps_example2 is successfully deployed. Once apps_example2 is successfully deployed, a notification may be sent by the scheduler, and the notification may be received by a process responsible for deploying resource 1006. Note that while code segment 1000 of FIG. 10 includes one resource 1006 with one implicit dependency and one explicit dependency, one skilled in the art will recognize that any combination of resource 1006, implicit dependencies, and explicit dependencies may be used to achieve a CIOS user's goal.

[0117] CIOS (or a declarative infrastructure provisioner, such as the CIOS declarative provisioning tool described above) may be utilized to parse the configuration file containing code segment 1000. Through this parsing, CIOS (or a declarative provisioning The deployment provisioner may generate a directed acyclic graph (DAG) for each resource, module, and / or capability that compiles and defines an ordered list of dependencies on other resources, modules, and / or capabilities. While attempting to deploy a resource, CIOS may traverse the DAG to identify when a resource depends on another resource, module, and / or capability. The DAG for each resource may specify implicit dependencies, explicit dependencies, or a combination thereof, and may be used to start or deploy the corresponding resource with CIOS.

[0118] Figure 11 is an example code segment 1100 for establishing explicit and implicit dependencies between resources of an execution target, according to at least one embodiment. The code segment 1100 shown in Figure 11 includes four resources 1102, 1104, 1106, and 1108. Each of resources 1102, 1104, 1106, and 1108 may represent a capability and may include implicit dependencies, explicit dependencies, or a combination thereof.

[0119] Resource 1102 shown in FIG. 11 includes a name 1110 denoted "object_storage," a type 1112 denoted "type1" (e.g., indicating that the resource is a capability), and multiple variables (e.g., variables 1-3; however, more or fewer variables may be used). Resource 1104 shown in FIG. 11 includes a name 1116 denoted "worker" and an explicit dependency 1118 denoted "depends_on=type1.object_storage." The parameter list for resource 1102 includes an identifier 1115. Identifier 1115 may be used to reference that resource (alternatively, name 1110 may be used as well). Statement 1118 forms an explicit dependency on resource 1102 by reference to type1.object_storage. This explicit dependency allows resource 1104 to not be deployed until resource 1102 completes deployment. Resource 1106 shown in FIG. 11 includes an identifier 1120, denoted "peacock," a type (e.g., "type1," indicating a capability), and multiple variables (e.g., variable1 and variable2). Resource 1108 shown in FIG. 11 includes a type (e.g., "type4"), a name 1124, denoted "LB," and a statement 1126 ("count=type1.peacock.exists."). An implicit dependency on resource 1106 may be formed by using statement 1126. Although resource 1108 does not use an explicit dependency construct (e.g., "depends_on"), an implicit dependency exists because it attempts to assign a value to variable "count" equal to whether the capability "peacock" exists (as determined by the statement type1.peacock.exists). Therefore, because of the assignment attempted on line 18, resource 1108 may not be deployed until resource 1106 "peacock" is deployed.Although code segment 1100 of FIG. 11 includes four resources 1102, 1104, 1106, and 1108, each with one implicit dependency and one explicit dependency, those skilled in the art will recognize that any combination of resources, implicit dependencies, and explicit dependencies may be used to achieve the goals of a CIOS user.

[0120] CIOS (or a declarative infrastructure provisioner, such as the CIOS declarative provisioning tool described above) may be utilized to parse the configuration file containing code segment 1100. Through this parsing, CIOS (or a declarative infrastructure provisioner) may generate a DAG (Directed Acyclic Graph) for each resource, module, and / or capability. That resource, module, and / or capability compiles and defines an ordered list of dependencies on other resources, modules, and / or capabilities. During a resource deployment attempt, CIOS traverses the DAG to determine the dependencies of the resource, module, and / or capability. A DAG for each resource may identify when a resource depends on another resource, module, and / or capability of another resource. The DAG for each resource may specify implicit dependencies, explicit dependencies, or a combination thereof, and may be used to start or deploy the corresponding resource with CIOS.

[0121] FIG. 12 is an exemplary DAG (Directed Acyclic Graph) 1200 corresponding to a resource (e.g., resource A) of a cloud computing system, according to at least one embodiment. As shown, DAG 1200 may be a finite, directed graph including any suitable number of nodes (e.g., six nodes shown in FIG. 12) and edges (e.g., seven edges shown in FIG. 12). Each edge is directed from one node to another, as shown in FIG. 12. The nodes and edges may be arranged to avoid a directed cycle. That is, DAG 1200 is defined such that, after starting from any node, a consistently directed series of edges does not eventually cycle back to that same node. The last node (e.g., node “6”) may point to a null value or may indicate the end of the DAG.

[0122] Although DAG 1200 shows six nodes and seven edges, a DAG may include any suitable number of nodes and directed edges. In some embodiments, each node corresponds to a set of operations (e.g., operations for performing tasks such as deploying and / or starting a resource, such as resource A) or a set of capabilities, comprised of multiple operations, on which the next node depends. The directed edges of each DAG define the order in which these operations are performed and / or the dependency between the subset of operations associated with a node and the subset of capabilities associated with the node immediately preceding it.

[0123] As a simple example, nodes 1, 2, 5, and 6 in DAG 1200 represent nodes corresponding to four separate series of operations. Based on the edges shown in diagram 1200, the operations at each node are executed in an order corresponding to the order of nodes 1, 2, 5, and 6. Nodes 3 and 4 represent multiple nodes that individually correspond to one or more dependencies. As an example, node 3 may represent a dependency of the operation corresponding to node 5 on a capability related to a different resource (e.g., resource B). Similarly, node 4 may represent a dependency of the operation corresponding to node 5 on a capability related to a different resource (e.g., resource C). In some embodiments, different capability nodes (e.g., nodes identifying dependencies on a capability / capabilities of a particular resource) may be used for different resources, and a single node may be utilized to specify all dependencies, regardless of how many resources the dependencies reference. Thus, in some embodiments, a dependency corresponding to resource B (e.g., identified in node 3) and a dependency corresponding to resource C (e.g., identified in node 4) may be combined into a single node.

[0124] DAG 1200 may be traversed in a manner described in more detail with respect to Figures 10-12 to orchestrate the execution of operations to launch and / or deploy resources in a cloud computing environment in conjunction with one or more dependencies on the capabilities of other resources (or the other resources themselves).

[0125] 13 is a flow diagram illustrating an example process 1300 for orchestrating the execution of a task (e.g., deploying resources) that includes at least one capability dependency (e.g., the capability of a different resource) according to at least one embodiment. As shown in FIG. 13, the process flow 1300 includes a scheduler 1302 (e.g., scheduler 206 of FIG. 2), a worker 1304 (e.g., worker 210 of FIG. 2), and an IP process 1306 (e.g., CIOS container 212 of FIG. 2).

[0126] At 1308, scheduler 1302 may receive a task to deploy infrastructure resources in a region, and scheduler 1302 may send data related to the task to worker 1304. In some embodiments, scheduler 1302 may instantiate worker 1304 to handle the deployment of resources (e.g., services).

[0127] At 1310, worker 1304 may instantiate IP process 1306. IP process 1306 may be configured to run an instance of a declarative infrastructure provisioner (e.g., the declarative provisioning tool, Terraform, mentioned above).

[0128] At 1312, IP process 1306 may parse a configuration file associated with the deployment (e.g., a configuration file including code segments 1000 and / or 1100 of FIGS. 10 and 11) to generate a directed acyclic graph (DAG) of the particular resource. Through analysis of the configuration, IP process 1306 (the declarative infrastructure provisioner) may identify any suitable number of implicit and / or explicit dependencies on the capabilities of other resources. Once identified, IP process 1306 constructs a DAG (e.g., according to the implicit and / or explicit dependencies identified during analysis) that specifies tasks for launching and / or deploying the resource, with one or more nodes corresponding to the capabilities on which the resource depends.

[0129] At 1314, the IP process 1306 may begin traversing the DAG, and upon reaching various nodes of the DAG, perform at least a portion of the deployment and / or activation of particular resources. Any appropriate operation may be performed according to at least one node of the DAG to make available a portion of the functionality corresponding to the resource. Multiple portions of the functionality corresponding to the resource may become available. In some embodiments, the IP process 1306 may send a notification to the scheduler 1302 indicating that one or more capabilities of the resource are now available (not shown). At least one of the nodes of the DAG may correspond to the capabilities of one or more other resources. Upon reaching these types of nodes, the IP process 1306 may verify whether the capabilities are available. If so, the IP process 1306 may proceed with traversing the DAG.

[0130] At 1316, the IP process 1306 may reach a node of the DAG that corresponds to one or more capabilities of one or more other resources. In some embodiments, the IP process 1306 may determine that at least one capability associated with the node is not yet available.

[0131] At 1320, in response to determining that at least one capability associated with the node is unavailable, the IP process 1306 may transmit data to the scheduler 1302 indicating that one or more capabilities on which the resource corresponding to the IP process 1306 depends have been determined to be unavailable.

[0132] At 1322, the IP process 1306 may terminate, possibly after storing state information indicating which operations and / or which nodes of the DAG have completed and / or which particular node of the DAG was last accessed by the IP process 1306. The IP process 1306 may terminate, be killed, be paused, or cease execution.

[0133] At 1324, the scheduler 1302 determines when a particular resource is scheduled to resume activation. The device may store information indicating that it was waiting for one or more specific capabilities required for deployment purposes and / or that it was waiting for one or more specific capabilities required for deployment purposes.

[0134] At 1326, scheduler 1302 may receive one or more notifications indicating that one or more capabilities for which the resource was waiting have become available. In some embodiments, scheduler 1302 may receive various notifications from other IP processes about the various capabilities of the corresponding resources as they become available. Scheduler 1302 may maintain one or more records of these various capabilities that are available and / or one or more records of the various capabilities for which the resource is currently waiting. Scheduler 1302 may identify from these one or more records that a particular capability / capabilities for which the resource corresponding to IP process 1306 was waiting has become available. Accordingly, scheduler 1302 may proceed to 1328.

[0135] In response to determining at 1328 that the capabilities on which the resource corresponding to IP process 1306 depends have become available, scheduler 1302 may return to step 1308. In step 1308, scheduler 1302 sends data related to the original task (e.g., deploying the resource) to worker 1304. In some embodiments, scheduler 1302 may instantiate a new worker or may utilize the previous worker 1304 (as shown) to continue servicing the task associated with the resource. Worker 1304 may instantiate an IP process (not shown), which may be configured to execute and parse the configuration file to generate a DAG for the resource. The IP process may access stored state information to identify the last accessed node in the DAG (e.g., a node corresponding to one or more capabilities for which the resource was waiting). With one or more capabilities now available, the IP process may proceed to traverse the DAG in a manner similar to that described above, performing an operation at each node, performing a portion of the task, or checking capabilities on which the next portion of the task depends, until the operation at the end node of the DAG is completed.

[0136] A process similar to that described above may be performed for all resources of a task. As an example, when deploying a system having multiple resources (e.g., multiple services), process 1300 may be performed on behalf of each resource to deploy each resource of the system.

[0137] FIG. 14 illustrates an example process flow 1400 for executing a release (e.g., by a CIOS) according to at least one embodiment. At event number 1, a scheduler 1402 (e.g., scheduler 206 of FIG. 2 ) may send a task to a worker 1404 (e.g., worker 210 of FIG. 2 ). The task may include deploying a computing system or a subset thereof, such as deploying infrastructure resources to a set of execution targets. The task may require traversing a linked list (e.g., example linked list 700 of FIG. 7 ), a DAG (e.g., DAGs 900 and 1200 of FIGS. 9 and 12 , respectively), a combination thereof, or other suitable task for deploying a computing system. The worker 1404 may receive the task from the scheduler 206. The worker 1404 may be a worker node in a fleet of worker nodes. The fleet of worker nodes may include any suitable number of worker nodes for deploying a computing system. Scheduler 1402 may select a worker 1404 based at least in part on the capacity of the worker 1404. For example, if worker 1404 has the most computing power in a fleet of worker nodes, scheduler 1402 may select to send a task to worker 1404.

[0138] In event number 2, worker 1404 may parse / traverse configuration file 1406 one or more times. Configuration file 1406 may include instructions for deploying a computing system, and one or more parsing may identify resources or other capabilities that are desired to be activated or otherwise deployed for deploying the computing system. As a non-limiting example, configuration file 1406 may include code segments 600, 800, 1000, and 1100 of Figures 6, 8, 10, and 11, respectively.

[0139] At event number 3, information from configuration file 1406 may be sent to IP process 1408 (e.g., IP process 212 of FIG. 2 ). IP process 1408 may receive information from configuration file 1406 based on one or more analyses / traversals performed by worker 1404. This information may include a set of capabilities, execution targets, or other suitable resources for deploying a computing system.

[0140] At event number 4, in response to receiving this information from configuration file 1406, IP process 1408 may determine the order in which capabilities or other suitable resources for deploying a computing system are deployed. IP process 1408 may generate a linked list of phases 1410 (e.g., example linked list 700 of FIG. 7), a DAG of execution targets 1412 (e.g., example DAG 900 of FIG. 9), a DAG of capabilities 1414 (e.g., example DAG 1200 of FIG. 12), or other suitable list, graph, or data structure. Linked list of phases 1410, DAG of execution targets 1412, and DAG of capabilities 1414 (collectively referred to as "release data structures") may be generated in any suitable order.

[0141] The release data structure may be used to identify and determine an order for executing the tasks of a release. For example, each node in the linked list of phases 1410 corresponds to a separate instance of the DAG of execution targets (e.g., instance of the DAG of execution targets 1412). Here, each node in the DAG of execution targets corresponds to the DAG of capabilities (e.g., instance of the DAG of capabilities 1414). Starting from the first node in the linked list 1400, the IP process 1408 may identify the corresponding DAG of execution targets. The first node in the DAG of execution targets may be used to identify the corresponding DAG of capabilities. Tasks associated with that DAG of capabilities may be executed according to the DAG of capabilities, and upon completion, the IP process 1408 may traverse the next node in the DAG of execution targets to identify the DAG of the next corresponding capability. Each node in the DAG of execution targets may be traversed, and upon completion of the tasks corresponding to these nodes, the IP process 1408 may traverse the next node in the DAG of execution targets to identify the next DAG of capabilities. This process may be repeated any suitable number of times until all of the tasks associated with each of the execution targets associated with the final phase of the release are completed.

[0142] As an example, at event number 5, the first node in the linked list of phases 1410 is reached. The IP process 1408 identifies the DAG of execution targets corresponding to the first node.

[0143] The first node of the execution target's DAG 1412 is reached at event number 6. The capability's DAG 1414 may be identified based at least in part on its association with the first node of the execution target's DAG 1412.

[0144] At event number 7, the IP process 1408 executes tasks for a given execution target based at least in part on traversing the capabilities DAG 1414. Upon completion of these tasks, the IP process 1408 traverses the next node in the execution target DAG and executes the corresponding capabilities. The IP process 1408 may determine the capabilities DAG and execute tasks according to the traversal of the capabilities DAG. This process may continue until the task associated with the last node in the execution target DAG 1412 has been executed. The IP process 1408 may then traverse the next node in the linked list of phases 1410. The operations of events 5-7 may be repeated any appropriate number of times until all of the tasks associated with all of the execution targets associated with the last node in the linked list of phases 1410 have been executed. Upon completion of a task, execution target, and / or phase, the IP process 1408 may update or cause the UI 500 of FIG. 5 to be updated to display the current status of the task, execution target, and / or phase.

[0145] At event number 8, the IP process 1408 sends a signal to the scheduler 1402 indicating that the release traversal is complete. The scheduler 1402 may receive a signal from the IP process 1408 and may broadcast a notification that the computing system is ready for use.

[0146] 15 is a flowchart of a process 1500 for deploying a computing system using a DAG in a CIOS, according to at least one embodiment. At block 1502, the CIOS may execute instructions to perform one or more parsing of configuration data related to the deployment of the computing system. The configuration data may be included in a configuration file, and upon parsing the configuration data one or more times, the CIOS may determine a set of tasks to perform to deploy the computing system. Tasks in the set of tasks may include deploying infrastructure resources at the execution target or other suitable tasks for deploying the computing system.

[0147] At block 1504, the CIOS generates a first DAG (e.g., DAG 1200 of FIG. 12) for deploying resources based on the configuration file. The first DAG may be a DAG of capabilities, which may outline a particular order of capabilities to be activated or deployed. The first DAG may include any suitable number of tasks for deploying the capabilities and any suitable number of dependencies between the capabilities to be deployed.

[0148] In block 1506, the CIOS generates a second DAG (e.g., DAG 900 of FIG. 9 ) that defines dependencies between execution targets for deploying the execution targets based on the configuration file. The second DAG may be a DAG of execution targets that specifies the order in which the execution targets are deployed. The second DAG may include any suitable number of execution targets for deploying a computing system and any suitable number of dependencies for deploying the execution targets.

[0149] At block 1508, the CIOS generates a linked list (e.g., linked list 700 of FIG. 7 ) that specifies dependencies between phases based on the configuration file. These phases may include a first DAG, a second DAG, or a combination thereof, and the linked list may define the order in which the phases are executed. The phases of the linked list may be executed sequentially or may not include phases that are executed in parallel. The linked list may include any suitable number of phases for deploying a computing system.

[0150] At block 1510, the CIOS may deploy the computing system by traversing the first DAG, the second DAG, and the linked list. The CIOS may traverse the linked list, and the first DAG and the second DAG may be traversed simultaneously (i.e., the first DAG and the second DAG may be included in the linked list). Upon successful traversal of the linked list, the first DAG, and the second DAG, deployment of the computing system may be successful.

[0151] System example 16-18 illustrate aspects of an exemplary environment for implementing aspects of the present disclosure, according to various embodiments. FIG. 16 is a simplified diagram of a distributed system 1600 for implementing embodiments of the present disclosure. In the illustrated embodiment, the distributed system 1600 includes one or more client computing devices 1602, 1604, 1606, and 1608. The one or more client computing devices 1602, 1604, 1606, and 1608 are configured to run and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), etc., over one or more network(s) 1610. A server 1612 may be communicatively coupled to the remote client computing devices 1602, 1604, 1606, and 1608 via the network 1610.

[0152] In various embodiments, server 1612 may be configured to run one or more services or software applications, such as services and applications that provide identity management services. In particular embodiments, server 1612 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 1602, 1604, 1606, and / or 1608 as web-based or cloud services, or under a software-as-a-service (SaaS) model. Users operating client computing devices 1602, 1604, 1606, and / or 1608 may then utilize one or more client applications to interact with server 1612 and utilize the services provided by these components.

[0153] In the configuration shown in FIG. 16 , software components 1618, 1620, and 1622 of system 1600 are shown as implemented on server 1612. Also, in other embodiments, one or more of the components of system 1600 and / or one or more of the services provided by these components may be implemented by one or more of client computing devices 1602, 1604, 1606, and / or 1608. A user operating a client computing device 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 1600. Thus, the embodiment shown in FIG. 16 is an example of a distributed system for implementing the system of an embodiment and is not intended to be limiting.

[0154] Client computing devices 1602, 1604, 1606, and / or 1608 may include various types of computer systems. For example, the client computing devices may include palm-sized portable devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass® head-mounted displays) running software such as Microsoft Windows® Mobile and / or various mobile operating systems such as iOS, Windows Phone®, Android, BlackBerry 10, Palm OS, etc. The devices may support various applications, such as various Internet-related apps, email, and SMS (Short Message Service) applications, and may use various other communication protocols. Additionally, the client computing devices may include: The devices may include, by way of example, general-purpose personal computers, including personal and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. Client computing devices may also include workstation computers running various popular UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems, such as Google Chrome OS. Client computing devices may also include electronic devices capable of communicating over network(s) 1610, 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.

[0155] 16 is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as sensor-equipped devices, may also interact with server 1612.

[0156] The network(s) 1610 in the distributed system 1600 may be any type of network familiar to those skilled in the art capable of supporting data communications using a variety of available protocols, including, but not limited to, Transmission Control Protocol / Internet Protocol (TCP / IP), Systems Network Architecture (SNA), Internet packet exchange (IPX), AppleTalk, etc. By way of example only, the network(s) 1610 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 any of the IEEE (Institute Of Electrical And Electronics) 1002.16 suite of protocols, Bluetooth, and / or other wireless protocols), and / or any combination of these and / or other networks.

[0157] The server 1612 may be comprised of one or more general-purpose computers, dedicated server computers (including, by way of example, personal computer (PC) servers, UNIX servers, midrange servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable arrangement and / or combination. The server 1612 may include one or more virtual machines running a virtual operating system or other computing architecture involving virtualization. One or more flexible pools of logical storage may be virtualized to maintain virtual storage for the server. A virtual network may be controlled by the server 1612 using software-defined networking. In various embodiments, the server 1612 may be configured to execute one or more services or software applications described in the above disclosure. For example, the server 1612 may correspond to a server for executing the above-described processes according to embodiments of the present disclosure.

[0158] The server 1612 may be configured with one of the operating systems listed above and a commercially available Server 1612 may run an operating system, including any of the server operating systems. Server 1612 may also run a variety of additional server and / or mid-tier applications, including a HyperText Transport Protocol (HTTP) server, a File Transfer Protocol (FTP) server, a Common Gateway Interface (CGI) server, a Java server, a database server, etc. Exemplary database servers include, but are not limited to, database servers commercially available from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0159] In some implementations, server 1612 may include one or more applications for analyzing and consolidating data feeds and / or event updates received from users of client computing devices 1602, 1604, 1606, and 1608. 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 information sources and continuous data streams that may include real-time events related to sensor data applications, tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc. Server 1612 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 1602, 1604, 1606, and 1608.

[0160] Distributed system 1600 may also include one or more databases 1614 and 1616. These databases may provide a mechanism for storing information such as user identification information and other information used by embodiments of the present disclosure. Databases 1614 and 1616 may reside in a variety of locations. As one example, one or more of databases 1614 and 1616 may reside on non-transitory storage media local to (and / or resident in) server 1612. Alternatively, databases 1614 and 1616 may reside remotely from server 1612 and communicate with server 1612 through a network-based or dedicated connection. In one set of embodiments, databases 1614 and 1616 may reside on a storage area network (SAN). Similarly, any files necessary to perform functions attributed to server 1612 may be stored locally on server 1612 and / or remotely from server 1612, as appropriate. In one set of embodiments, databases 1614 and 1616 may include relational databases, such as those provided by Oracle, that are adapted to store, update, and retrieve data in response to SQL-formatted commands.

[0161] 17 illustrates an exemplary computer system 1700 that may be used to implement embodiments of the present disclosure. In some embodiments, the computer system 1700 may be used to implement any of the various servers and computer systems described above. As shown in FIG. 17, the computer system 1700 comprises various subsystems, including a processing subsystem 1704 that communicates with several peripheral subsystems via a bus subsystem 1702. These peripheral subsystems may comprise a processing acceleration device 1706, an I / O subsystem 1708, a storage subsystem 1718, and a communication subsystem 1724. The storage subsystem 1718 may comprise a tangible computer-readable storage medium 1722 and a system memory 1710.

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

[0163] The processing subsystem 1704 controls the operation of the computer system 1700 and may include one or more processing units 1732, 1734, 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 1704 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 1704 may be implemented using custom circuitry, such as an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA).

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

[0165] In particular embodiments, a processing acceleration unit 1706 may be provided to perform customized processing or to offload some of the processing performed by the processing subsystem 1704 so that the overall processing performed by the computer system 1700 is faster.

[0166] I / O subsystem 1708 may include devices and mechanisms for inputting information into computer system 1700 and / or devices and mechanisms for outputting information through or from computer system 1700. In general, use of the term "input device" is intended to include any type of device or mechanism for inputting information into computer system 1700. User interface input devices may include, for example, keyboards, pointing devices such as mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, voice 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 recognition devices such as a Microsoft Kinect® motion sensor that allows a user to control and interact with the input device, a Microsoft Xbox® 360 game controller, or a device that provides an interface for accepting input using gesture and voice commands. User interface input devices may also detect a user's eye movements (e.g., "blinking" while taking a photo and / or making a menu selection) and record eye behavior. The user interface input devices may include eye gesture recognition devices such as a Google Glass® blink detector that translates a user's eye gesture (e.g., a gesture) as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., Siri® navigator) via voice commands.

[0167] Other user interface input devices include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, gamepads, and graphics 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 medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, and ultrasound devices. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards and digital musical instruments.

[0168] User interface output devices may include display subsystems, indicator lights, or non-visual display devices such as audio output devices. The display subsystem may be a flat-panel display such as one using a cathode ray tube (CRT), liquid crystal display (LCD), or plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include all manner of devices and mechanisms for outputting information from computer system 1700 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 textual, graphical, and audio / visual information, such as monitors, printers, speakers, headphones, automobile navigation systems, drawing devices, audio output devices, and modems.

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

[0170] The storage subsystem 1718 may include one or more non-transitory memory elements, including volatile and non-volatile memory elements. As shown in Figure 17, the storage subsystem 1718 comprises a system memory 1710 and a computer-readable storage medium 1722. The system memory 1710 stores instructions and data during program execution. The system memory 1710 may include several types of memory, including a volatile main RAM (random access memory) for storing program code, and a nonvolatile ROM (read only memory) or flash memory in which fixed instructions are stored. In some implementations, a basic input / output system (BIOS), containing the basic routines that help transfer information between elements within the computer system 1700, such as during start-up, may be stored in ROM. RAM may contain data and / or program modules that the processing subsystem 1704 is currently operating on and executing. In some implementations, the system memory 1710 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0171] 17, system memory 1710 may include, but is not limited to, application programs 1712, such as client applications, web browsers, mid-tier applications, and relational database management systems (RDBMSs), program data 1714, and operating system 1716. By way of example, operating system 1716 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various popular 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.

[0172] The computer-readable storage medium 1722 may store programming and data structures that provide functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processing subsystem 1704, provide the processor with the functionality described above may be stored in the storage subsystem 1718. By way of example, the computer-readable storage medium 1722 may include non-volatile memory such as a hard disk drive, a magnetic disk drive, an optical disk drive such as a CD-ROM, a DVD, a Blu-Ray® disk, or other optical media. The computer-readable storage medium 1722 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 disk, a digital video tape, etc. The computer-readable storage media 1722 may 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 and flash memory-based SSDs. The computer-readable media 1722 may provide storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1700.

[0173] In particular embodiments, storage subsystem 1700 may include a computer-readable storage medium reader 1720, which may be further coupled to a computer-readable storage medium 1722. In conjunction with system memory 1710, if desired, computer-readable storage medium 1722 may be a remote, local, permanent, and / or removable storage device. The term "computer-readable information storage medium" may collectively refer to a storage medium for storing computer-readable information.

[0174] In particular embodiments, computer system 1700 may provide support for running one or more virtual machines. Computer system 1700 may execute programs such as a hypervisor to facilitate configuration and management of virtual machines. Each virtual machine may be assigned memory, computer (e.g., processors, cores), I / O, and networking resources. Each virtual machine may run its own operating system. This operating system may be the same or different from the operating systems run by other virtual machines executed by computer system 1700. Thus, multiple operating systems may potentially be run simultaneously by computer system 1700. Each virtual machine generally runs separately from other virtual machines.

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

[0176] The communications subsystem 1724 may support both wired and / or wireless communications protocols. For example, in particular embodiments, the communications subsystem 1724 may include a radio frequency (RF) transmission component for accessing a wireless voice or / and data network (e.g., using cellular technology, next-generation data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates For Global Evolution), WiFi (IEEE 802.11 family of standards), other moving object communications technologies, or any combination thereof), a global positioning system (GPS) receiving component, and / or other components. In some embodiments, the communications subsystem 1724 can provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

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

[0178] In particular embodiments, the communications subsystem 1724 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1728 of real-time events and / or event updates 1730 that is continuous or infinite, essentially without a clear end. Applications may include, for example, sensor data applications, tickers, network performance measurement tools (eg, network monitoring and traffic management applications), clickstream analysis tools, vehicle traffic monitoring, and the like.

[0179] The communications subsystem 1724 may also be configured to output structured and / or unstructured data feeds 1726, event streams 1728, event updates 1730, etc. to one or more databases that may be in communication with one or more streaming data source computers connected to the computer system 1700.

[0180] The computer system 1700 may be one of a variety of types, including a palm-sized 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.

[0181] Due to the ever-changing nature of computers and networks, the description of computer system 1700 shown in Figure 17 is illustrative only. Many other configurations are possible having more or fewer components than the system shown in Figure 17. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other ways and / or methods for implementing the various embodiments.

[0182] The systems shown in some of the figures may be provided in a variety of configurations, and in some embodiments, these 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.

[0183] A cloud infrastructure system is a collection of one or more server computing devices, network equipment, and / or storage devices. These resources may be divided by a cloud service provider and allocated to its customers in some manner. 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) classification, Platform as a Service (PaaS) classification, Infrastructure as a Service (IaaS) classification, or other classifications, including mixed services. 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 a cloud infrastructure system without having to purchase the software for the applications. PaaS services include Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), and others. These include, but are not limited to, services such as IaaS Service, which allow organizations (such as Oracle) to consolidate existing applications onto a shared common architecture, and the ability to create new applications that leverage the shared services offered by the platform. IaaS services may facilitate the management and control of underlying computing resources, such as storage, network, and other fundamental computing resources, for customers using the services offered by SaaS and PaaS platforms.

[0184] FIG. 18 is a simplified block diagram of one or more components of a system environment 1800 in which services provided by one or more components of an embodiment system may be provided as cloud services, according to an embodiment of the present disclosure. In the illustrated embodiment, the system environment 1800 includes one or more client computing devices 1804, 1806, and 1808. The one or more client computing devices 1804, 1806, and 1808 may be used by users to interact with a cloud infrastructure system 1802 that provides cloud services. The client computing devices may be configured to operate a client application, such as a web browser, a proprietary client application (e.g., Oracle Forms), or other application. The client application may be used by users of the client computing devices to interact with the cloud infrastructure system 1802 to utilize the services provided by the cloud infrastructure system 1802.

[0185] It should be understood that the cloud infrastructure system 1802 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 embodiments of the present disclosure. In other embodiments, cloud infrastructure system 1802 may have more or fewer components than those depicted in the figure, may combine two or more components, or may have a different configuration or arrangement of components.

[0186] Client computing devices 1804 , 1806 , and 1808 may be devices similar to the client computing devices described above with respect to 1602 , 1604 , 1606 , and 1608 .

[0187] Although the exemplary system environment 1800 is shown with three client computing devices, any number of client computing devices may be supported. Other devices, such as sensor-equipped devices, may also interact with the cloud infrastructure system 1802.

[0188] Network(s) 1810 may facilitate communication and exchange of data between clients 1804, 1806, and 1808 and cloud infrastructure system 1802. 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 with respect to network(s) 1810.

[0189] Cloud infrastructure system 1802 may be comprised of one or more computers and / or servers, which may include the computers and servers described above with respect to server 1812 .

[0190] In particular embodiments, the services provided by a cloud infrastructure system may include a host of services that are available upon request by users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suite document collaboration services, database processing, managed technical support services, etc. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of their users. A specific instantiation of a service provided by a cloud infrastructure system is referred to herein as a "service instance." Generally, a service instance is a service that is accessed by a user over a communications network such as the Internet. Any services provided by a cloud service provider's system that enable a customer to access the cloud are referred to as "cloud services." In a public cloud environment, the servers and systems that comprise the cloud service provider's system are distinct from the customer's on-premise servers and systems. For example, the cloud service provider's system may host applications, and users may order and use the applications on demand over a communications network such as the Internet.

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

[0192] In particular embodiments, cloud infrastructure system 1802 may include a suite of application, middleware, and database service offerings delivered to customers on a self-service, subscription basis, in an elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle Public Cloud, offered by the assignee of the present application.

[0193] In various embodiments, cloud infrastructure system 1802 may be adapted to automatically provision, manage, and track customer subscriptions to the services it provides. Cloud infrastructure system 1802 may provide cloud services through different deployment models. For example, services may be provided under a public cloud model, in which cloud infrastructure system 1802 is owned by an organization providing the cloud services (e.g., owned by Oracle) and makes the services available to the general public or to different industry enterprises. As another example, services may be provided under a private cloud model, in which cloud infrastructure system 1802 is run solely for one organization and may provide services for one or more entities within the organization. Cloud services may also be provided under a community cloud model, in which cloud infrastructure system 1802 and the services it provides are shared by several organizations within an associated community. Cloud services may also be provided under a hybrid cloud model, which is a combination of two or more different models.

[0194] In some embodiments, the services offered by cloud infrastructure system 1802 may include one or more services offered under the Software as a Service (SaaS) classification, the Platform as a Service (PaaS) classification, the Infrastructure as a Service (IaaS) classification, or other classifications, including mixed services. A customer may order one or more services offered by cloud infrastructure system 1802 by ordering a subscription. Cloud infrastructure system 1802 then processes to provide the services in your subscription order.

[0195] In some embodiments, the services provided by the cloud infrastructure system 1802 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 SaaS services. A SaaS platform may be configured to provide cloud services that fall under the SaaS classification. For example, the SaaS platform may provide functionality for building and delivering a suite of on-demand applications to an integrated development / deployment platform. The SaaS platform may manage and control the underlying software and infrastructure for providing the SaaS services. Services provided by the SaaS platform allow customers to utilize applications running 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.

[0196] 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 classification. Platform services include, but are not limited to, services that enable organizations (e.g., Oracle) to consolidate existing applications onto a shared, common architecture and the ability to create new applications that leverage the shared services provided by the platform. The PaaS platform may manage and control the underlying software and infrastructure for providing the PaaS services. Customers can obtain services provided by the PaaS cloud infrastructure system without having to purchase separate licenses and support. Platform services include, but are not limited to, JCS (Oracle Java Cloud Service), DBCS (Oracle Database Cloud Service), and others.

[0197] Services provided by a PaaS platform allow customers to adopt programming languages ​​and tools supported by the cloud infrastructure system and manage deployed services. In some embodiments, 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 services deployment model. The shared services deployment model allows organizations to pool database resources and offer databases as a service to customers in the form of a database cloud. The middleware cloud services may provide a platform for customers to develop and deploy various business applications, and the Java cloud services may provide a platform for customers to deploy Java applications in the cloud infrastructure system.

[0198] In a cloud infrastructure system, a variety of different infrastructure services can be provided by an IaaS platform. Infrastructure services are services provided by SaaS and PaaS platforms. It facilitates the management and control of underlying computing resources, such as storage, network, and other fundamental computing resources, for customers using the service.

[0199] In particular embodiments, cloud infrastructure system 1802 may include infrastructure resources 1830 for providing resources used to provide various services to customers of the cloud infrastructure system. In one embodiment, infrastructure resources 1830 may include a pre-integrated, optimized combination of hardware, such as servers, storage, and networking resources, and other resources for running the services offered by the PaaS and SaaS platforms.

[0200] In some embodiments, resources in cloud infrastructure system 1802 may be shared by multiple users and dynamically reallocated upon demand. In addition, resources may be allocated to users in different time zones. For example, cloud infrastructure system 1830 may allow a first set of users in a first time zone to utilize resources in the cloud infrastructure system for a specified number of hours, and then reallocate those same resources to another set of users located in a different time zone to maximize resource utilization.

[0201] In particular embodiments, several internal shared services 1832 may be provided that are shared by different components or modules of cloud infrastructure system 1802 and by the services provided by cloud infrastructure system 1802. These internal shared services may include, but are not limited to, services to enable security / identity services, integration services, enterprise repository services, enterprise manager services, virus scanning / whitelisting services, highly available backup / recovery services, cloud support, email services, notification services, file transfer services, etc.

[0202] In particular embodiments, cloud infrastructure system 1802 may provide comprehensive management of cloud services (e.g., SaaS services, Paa services, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functionality may include functionality for provisioning, managing, and tracking customer subscriptions received by cloud infrastructure system 1802 or the like.

[0203] In one embodiment, as shown, cloud management functionality may be provided by one or more modules, such as an order management module 1820, an order orchestration module 1822, an order provisioning module 1824, an order management / monitoring module 1826, and an identity management module 1828. These modules may include or be provided using one or more computers and / or servers. The one or more computers and / or servers may be general-purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0204] In example operation 1834, a customer using a client device, such as client device 1804, 1806, or 1808, requests one or more services offered by cloud infrastructure system 1802 and places an order for a subscription to one or more services offered by cloud infrastructure system 1802. Customers may interact with cloud infrastructure system 1802 by accessing and ordering subscriptions through cloud user interfaces (UIs), such as cloud UI 1812, cloud UI 1814, and / or cloud UI 1816. Order information received by cloud infrastructure system 1802 in response to a customer placing an order may include information identifying the customer and one or more services offered by cloud infrastructure system 1802 to which the customer intends to subscribe.

[0205] After an order is placed by a customer, the order information is accepted via the cloud UI 1812, 1814, and / or 1816.

[0206] In operation 1836, the order is stored in order database 1818. Order database 1818 may be one of several databases operated by cloud infrastructure system 1818 and in conjunction with other system elements.

[0207] In operation 1838, the order information is forwarded to the order management module 1820. In some cases, the order management module 1820 may be configured to perform billing and accounting functions for the order, such as confirming the order and registering the order after confirmation.

[0208] At operation 1840, information regarding the order is transmitted to the order orchestration module 1822. The order orchestration module 1822 may utilize this order information to orchestrate the provisioning of services and resources related to the order placed by the customer. In some cases, the order orchestration module 1822 may orchestrate the provisioning of resources to support services subscribed to using the services of the order provisioning module 1824.

[0209] In particular embodiments, order orchestration module 1822 enables management of the business flow associated with each order and applies business logic to determine whether the order should proceed to provisioning. At operation 1842, upon receiving a new subscription order, order orchestration module 1822 sends a request to order provisioning module 1824 to allocate and configure the resources needed to fulfill the subscription order. Order provisioning module 1824 enables the allocation of resources for the services subscribed to by the customer. Order provisioning module 1824 provides a level of abstraction between the cloud services provided by cloud infrastructure system 1800 and the physical implementation layer used to provision the resources to provide the requested services. This allows order orchestration module 1822 to be decoupled from implementation details, such as whether services and resources are actually provisioned on the fly or whether they are pre-provisioned and allocated only when requested.

[0210] At operation 1844, once the services and resources are provisioned, an order provisioning module 1824 of the cloud infrastructure system 1802 may send a notification to the customer on the client device 1804, 1806, and / or 1808 about the services provided. At operation 1846, an order management / monitoring module 1826 may manage and track the customer's subscription orders. In some cases, the order management / monitoring module 1826 may manage and track the subscription orders. The service may be configured to collect usage statistics regarding the service in subscription orders, such as the amount of storage used, the amount of data transferred, the number of users, and system uptime and system downtime.

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

[0212] While specific embodiments of the present disclosure have been described, various modifications, substitutions, 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 specific data processing environment, but can freely operate in multiple data processing environments. Additionally, while the 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 described sequence of transactions and steps. Various features and aspects of the above-described embodiments may be used individually or jointly.

[0213] Furthermore, while embodiments of the present disclosure have been described using particular combinations 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 exclusively in hardware or exclusively 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, where a component or module is described as being configured to perform a particular operation, such configuration may be achieved, for example, by designing electronic circuitry to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using various techniques, including, but not limited to, conventional techniques for inter-process communication; different paired processes may use different techniques, and the same pair of processes may use different techniques at different times.

[0214] The specification and drawings should appropriately be regarded as illustrative rather than strict. However, it will be apparent that additions, subtractions, deletions, and other modifications and variations may be made thereto 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.

Claims

1. 1. A computer-implemented method comprising: Executing instructions, by a computing device, to perform one or more analyses of configuration data associated with the deployment of the computing system; and causing the computing device to generate a first directed acyclic graph (DAG), the first DAG being utilized to deploy a first resource based at least in part on performing the one or more analyses, the method further comprising: The method further includes generating, by the computing device, a second DAG for deploying a plurality of execution targets based at least in part on running the one or more analyses, the second DAG specifying dependencies between execution targets of the deployment, the method further comprising: The method further comprises generating, based at least in part on the computing device performing the one or more analyses, a linked list data structure, the linked list data structure specifying dependencies between a plurality of deployment phases. The method includes the computing device deploying the computing system based at least in part on traversing the linked list data structure, the second DAG, and the first DAG.

2. The computer-implemented method of claim 1 , wherein the first DAG is generated by a declarative infrastructure provisioner.

3. 3. The computer-implemented method of claim 1, wherein the first DAG specifies a dependency of a first resource of the computing system on a capability of a second resource of the computing system.

4. 4. The computer-implemented method of claim 3, wherein each of the first resource or the second resource is one of a plurality of computing services, and the capability is part of a function of the second resource.

5. The computer-implemented method of any one of claims 1 to 4, wherein at least one node of the second DAG references a node of the first DAG.

6. The computer-implemented method of any one of claims 1 to 5, wherein a node of the linked list data structure references at least one node of the second DAG.

7. The instructions for performing one or more analyses of the configuration data include: Detecting a first dependency via an explicit statement provided in the configuration data; or 7. The computer-implemented method of claim 1, further comprising detecting a second dependency based at least in part on identifying an implicit dependency provided in the configuration data.

8. 8. The computer-implemented method of claim 1, wherein the configuration data indicates an order in which to perform infrastructure deployment operations to deploy multiple resources via one or more dependencies.

9. The computer-implemented method of any one of claims 1 to 8, wherein the one or more dependencies are defined using declarative statements.

10. 1. A system comprising: one or more processors; one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to: a computing device executing instructions to perform one or more analyses of configuration data associated with the deployment of the computing system; The computing device is configured to generate a first DAG, the first DAG being utilized to deploy a first resource based at least in part on performing the one or more analyses, and the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to further: The computing device is configured to generate, based at least in part on performing the one or more analyses, a second DAG for deploying a plurality of execution targets, the second DAG specifying dependencies between execution targets of the deployment, and the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to further: The computing device is configured to generate a linked list data structure based at least in part on performing the one or more analyses, the linked list data structure specifying dependencies between a plurality of deployment phases, and the computer-executable instructions, when executed by the one or more processors, cause the one or more processors to further: The system is configured such that the computing device deploys the computing system based at least in part on traversing the linked list data structure, the second DAG, and the first DAG.

11. 11. The system of claim 10, wherein the first DAG is generated by a declarative infrastructure provisioner, and the first DAG specifies a dependency of a first resource of the computing system on a capability of a second resource of the computing system.

12. The system of claim 11 , wherein each of the first resource or the second resource is a computing service of a plurality of computing services, and the capability is part of a function of the second resource.

13. 13. The system of claim 10, wherein at least one node of the second DAG references a node of the first DAG and a node of the linked list data structure references at least one node of the second DAG.

14. The configuration data indicates an order for performing infrastructure deployment operations to deploy a plurality of resources via one or more dependencies, the one or more dependencies being defined using declarative statements, and the instructions for performing one or more analyses of the configuration data include: Detecting the first dependency via an explicit statement provided in the configuration data; or The system of any one of claims 10 to 13, further comprising detecting a second dependency based at least in part on identifying an implicit dependency provided in the configuration data.

15. 1. A computer-readable storage medium storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations, including: Executing instructions, by a computing device, to perform one or more analyses of configuration data associated with the deployment of the computing system; and causing the computing device to generate a first DAG, the first DAG being utilized to deploy a first resource based at least in part on performing the one or more analyses, the operations further comprising: The method includes generating, by the computing device, a second DAG for deploying a plurality of execution targets based at least in part on the execution of the one or more analyses, the second DAG specifying dependencies between the execution targets of the deployment, the operations further comprising: The method includes generating, by the computing device, a linked list data structure based at least in part on performing the one or more analyses, the linked list data structure specifying dependencies between a plurality of deployment phases, the operations further comprising:

22. A computer-readable storage medium, comprising: the computing device deploying the computing system based at least in part on traversing the linked list data structure, the second DAG, and the first DAG.

16. 16. The computer-readable storage medium of claim 15, wherein the first DAG is generated by a declarative infrastructure provisioner, and the first DAG specifies a dependency of a first resource of the computing system on a capability of a second resource of the computing system.

17. 17. The computer-readable storage medium of claim 16, wherein each of the first resource or the second resource is one of a plurality of computing services, and the capability is part of a function of the second resource.

18. 18. The computer-readable storage medium of claim 15, wherein at least one node of the second DAG references a node of the first DAG and a node of the linked list data structure references at least one node of the second DAG.

19. The instructions for performing one or more analyses of the configuration data include: Detecting the first dependency via an explicit statement provided in the configuration data; or 19. The computer-readable storage medium of claim 15, further comprising detecting a second dependency based at least in part on identifying an implicit dependency provided in the configuration data.

20. 20. The computer-readable storage medium of claim 15, wherein the configuration data indicates an order in which to perform infrastructure deployment operations to deploy a plurality of resources via one or more dependencies, the one or more dependencies being defined using declarative statements.

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

22. A computer program product comprising computer instructions which, when executed by a processor, perform the steps of the method of any one of claims 1 to 9.

Images