Updating code in a distributed version control system

Abstract

Techniques are disclosed for implementing changes to a first service by a computer infrastructure orchestration service (CIOS). The CIOS can manage a declarative infrastructure provisioner to deploy infrastructure resources and artifacts based at least in part on declarative instructions. The CIOS can detect a first modification to a first service (e.g., a sidecar application). The CIOS can identify that configuration data of a second service references (e.g., via git submodules) the first service. In response to identifying a second modification to the second service, the CIOS can present a change via a graphical interface, the change comprising the first modification to the first service. User input can be received indicating acceptance or rejection of the change of the first modification. The CIOS can then implement the change to the first service according to the user input. For example, the CIOS can ensure that the modified first service is deployed alongside the second service in a subsequent deployment.

Description

[0001] This application is a non-provisional application of U.S. Provisional Application No. 62 / 963,478, filed January 20, 2020, entitled “TECHNIQUES FOR RESOLVING APPLICATION UPDATES,” and U.S. Non-Provisional Application No. 17 / 103,733, filed November 24, 2020, entitled “TECHNIQUES FOR RESOLVING APPLICATION UPDATES,” and claims their interest and priority under 35 USC 119(e), the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0002] Today, cloud infrastructure services use numerous individual services to deliver and deploy code and configuration across many regions of the cloud infrastructure service (separately). A significant amount of manual work is required to use these tools, especially given that provisioning is typically declarative and deployment code is imperative. Furthermore, as the number of service teams and regions grows, cloud infrastructure services will need to continue to grow. Strategies for deploying some cloud infrastructure services to a larger number of smaller regions involve per-region spending, which may not be well-adjustable. Summary of the Invention

[0003] This document discloses techniques for resolving application updates in a deployment environment. In some embodiments, a computer-implemented method can include various operations. In some embodiments, the operations include: a computing system managing a declarative infrastructure provider to deploy multiple infrastructure resources and multiple artifacts, at least in part based on declarative instructions (e.g., configuration files describing each of a plurality of infrastructure components and how they interact, configuration files declaring a desired deployment state without describing the control flow for obtaining the desired state, etc.). The computing system detects a first modification to a first service. In some embodiments, the first service includes at least one of the plurality of infrastructure resources, and the first service uses a first distributed version control repository to perform the modification. The computing system identifies that configuration data of a second service references the first service. The computing system detects a second modification to the second service. In some embodiments, the second service uses a second distributed version control repository to perform the modification. In response to identifying the second modification to the second service and identifying that the second service references the first service, the computing system presents a change via a graphical interface, the change including the first modification to the first service. The computing system receives user input indicating acceptance or rejection of the change including the first modification to the first service. The computing system implements the change to the first service based on the user input.

[0004] In other embodiments, a system for resolving application updates in a deployment environment is disclosed. The system may include: one or more processors; and one or more memory storing computer-executable instructions that, when executed by the one or more processors, configure the one or more processors to perform various operations. In some embodiments, the operations include: managing a declarative infrastructure provider to deploy multiple infrastructure resources and multiple artifacts, at least in part based on the declarative instructions. The system detects a first modification to a first service. In some embodiments, the first service includes at least one of the multiple infrastructure resources, and the first service uses a first distributed version control repository to perform the modification. The system identifies that configuration data of a second service references the first service. The system detects a second modification to the second service. In some embodiments, the second service uses a second distributed version control repository to perform the modification. In response to identifying the second modification to the second service and identifying that the second service references the first service, the system presents the change via a graphical interface, the change including the first modification to the first service. The system receives user input indicating acceptance or rejection of the change including the first modification to the first service. The system implements the change to the first service based on the user input.

[0005] In other embodiments, a computer-readable storage medium is disclosed that can store computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform various operations. In some embodiments, the operations include: managing a declarative infrastructure provider to deploy multiple infrastructure resources and multiple artifacts, at least in part based on the declarative instructions. The operations also include: detecting a first modification to a first service. In some embodiments, the first service includes at least one of the multiple infrastructure resources, and the first service uses a first distributed version control repository to perform the modification. The operations also include: identifying that configuration data of a second service references the first service. The system detects a second modification to the second service. In some embodiments, the second service uses a second distributed version control repository to perform the modification. The operations also include: in response to identifying the second modification to the second service and identifying that the second service references the first service, presenting a change via a graphical interface, the change including the first modification to the first service. The operations also include: receiving user input indicating acceptance or rejection of the change including the first modification to the first service. The operations also include: implementing the change to the first service based on the user input.

[0006] In other embodiments, an apparatus is disclosed. The apparatus may include tools for performing steps of any of the methods disclosed herein.

[0007] In other embodiments, a computer program product is disclosed. The computer program product may include computer instructions that, when executed by a processor, implement the steps of any of the methods disclosed herein. Attached Figure Description

[0008] To facilitate identification of any particular element or action being discussed, one or more of the most significant digits in the label indicate the figure number in which the element was first introduced.

[0009] Figure 1 It is a block diagram of an architecture for implementing cloud infrastructure provisioning services according to at least one embodiment.

[0010] Figure 2 It is a block diagram of an architecture for implementing cloud infrastructure provisioning services according to at least one embodiment.

[0011] Figure 3 This is a flowchart used to represent an exemplary group according to at least one embodiment.

[0012] Figure 4 This is a flowchart used to represent an exemplary group according to at least one embodiment.

[0013] Figure 5 This is a schematic diagram illustrating the use of various repositories for applications and auxiliary applications according to at least one embodiment.

[0014] Figure 6 This refers to an example of the code of an application that includes a reference to a data repository of another application, according to at least one embodiment.

[0015] Figure 7 This is a flowchart describing a method for obtaining code changes associated with a sidecar application according to at least one embodiment.

[0016] Figure 8 This is a schematic diagram illustrating an exemplary user interface for changes made to a sidecar application according to the description of at least one embodiment.

[0017] Figure 9 This is a flowchart of a method for implementing changes to a first service based on user input by a computer infrastructure dispatch service, according to at least one embodiment.

[0018] Figure 10 It is a block diagram of a distributed system according to at least one embodiment.

[0019] Figure 11 It is a block diagram of one or more components of a system environment according to at least one embodiment, through which services provided by one or more components of the embodiment system can be provided as cloud services.

[0020] Figure 12 This is a block diagram of an exemplary computer system that can implement various embodiments of the present disclosure. Detailed Implementation

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

[0022] In the IaaS model, cloud computing providers are able to host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.).

[0023] In some cases, IaaS providers may also offer a variety of services to accompany those infrastructure components (e.g., billing, monitoring, logging, security, load balancing, and clustering). Therefore, because these services can be policy-driven, IaaS users can implement policies to drive load balancing to maintain application availability and performance.

[0024] In some instances, IaaS customers can access resources and services over a wide area network (WAN) (such as the Internet) and can use the cloud provider's services to install the remaining elements of the application stack. For example, users can log into the IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware (such as a database), create buckets for workloads and backups, and even install enterprise software into the VM. Customers can then use the provider's services to perform various functions, including balancing network traffic, resolving application issues, monitoring performance, and managing disaster recovery.

[0025] In most cases, the cloud computing model will require the involvement of a cloud provider. The cloud provider can be a third-party service company that specializes in providing (e.g., selling) IaaS, but does not need to be that third-party service company. Entities may also choose to deploy a private cloud, becoming the provider of their own infrastructure services.

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

[0027] In some examples, IaaS provisioning may refer to acquiring computers or virtual hosts for use, or even installing necessary libraries or services on them. In most cases, deployment does not include provisioning, and such provisioning may need to be performed first.

[0028] In some cases, there are two distinct challenges with IaaS provisioning. First, there is the initial challenge of provisioning the initial set of infrastructure before anything is operational. Second, once everything is provided, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, these two challenges can be addressed by enabling the configuration of the infrastructure to be declaratively defined. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more profiles. Therefore, the overall topology of the infrastructure (e.g., what resources depend on which infrastructure and how each of them works together) can be declaratively described. In some instances, once the topology is defined, workflows can be generated that create and / or manage the different components described in the profiles.

[0029] In some examples, the infrastructure may have many interconnected components. For example, there may be one or more Virtual Private Clouds (VPCs) (e.g., potential on-demand pools of configurable and / or shared computing resources), also known as the core network. In some examples, there may also be one or more security group rules and one or more virtual machines (VMs) to define how network security will be configured. Other infrastructure components, such as load balancers, databases, etc., may also be provided. The infrastructure can evolve incrementally as more and more infrastructure components are needed and / or added.

[0030] As mentioned above, one way to provide infrastructure is to declaratively describe it. Thus, a configuration file can be a declarative document that describes only each of the aforementioned infrastructure components and how they interact. The configuration file can describe the resources and related fields required to create a component, and then it can describe other components that reference the previously described components. In some examples, the provisioning tool can then generate workflows for creating and managing the components described in the configuration file. The configuration file may also be referred to herein as a “declarative instruction.”

[0031] In some instances, the workflow of a provisioning tool can be configured to execute various commands. One function that can be executed is view tuning, where the provisioning tool can compare a view of the current infrastructure (e.g., the expected state of the infrastructure) with how the infrastructure is actually operating. In some instances, performing view tuning may include querying various resource providers or infrastructure resources to identify which resources are actually running. Another function that the provisioning tool can perform is planning, where the provisioning tool can compare the actually running infrastructure components with what the provisioning tool wants that state to look like (e.g., the desired configuration). In other words, the planning function can determine what changes need to be made to bring the resources to the latest expected state. In some instances, a third function is execution (e.g., application) functionality, where the provisioning tool can execute plans generated by the planning function.

[0032] Typically, provisioning tools can be configured to retrieve a configuration file, parse the declarative information included therein, and programmatically / automatically determine the order in which resources need to be provisioned for the execution plan. For example, if a VPC needs to be booted before security group rules and VMs are booted, the provisioning tool will be able to make that determination and perform the boot in that order, without user intervention and / or without the information necessarily being included in the configuration file.

[0033] In some instances, continuous deployment techniques can be employed to enable the deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques enable infrastructure management within these environments. In some examples, service teams can write code that they wish to deploy to one or more (but often many) different production environments (e.g., across various geographical locations, sometimes across the world). However, in some examples, the infrastructure where the code will be deployed must first be set up. In some instances, provisioning can be done manually, provisioning tools can be used to provide resources, and / or once the infrastructure is provided, deployment tools can be used to deploy the code.

[0034] As mentioned above, there are typically two different tools for handling the provisioning of infrastructure resources and the deployment of code to control those resources, and the coordination between these two tools is performed manually. However, proportionally, manual implementation always leads to deviations. Therefore, automated tools that can both provide and deploy virtual infrastructure enable more efficient and reliable technologies for realizing virtual cloud environments.

[0035] In some examples, problems can arise when using two tools, particularly when users manually make changes to the code between the provisioning and deployment phases. As described here, techniques that use a single tool for both provisioning and deployment can mitigate this problem by automating the process, eliminating the opportunity for manual code changes. It's possible that a slight change to how a user codes something can cause significant problems during deployment. In some examples, when an operator first performs an action in a new area (e.g., a typo in the code), the object coded using that typo may remain that way forever. If the application deployment has the typo and the application is insensitive to it (e.g., it still works), it's possible that at some point along the way, another code change could become sensitive to the typo and crash the entire system. Therefore, the techniques presented here eliminate the gap between provisioning and deployment that can frequently cause problems.

[0036] Typically, deployment modeling is declarative, allowing configuration files to be used to declare infrastructure resources. For example, create, read, update, delete (CRUD) commands are often used to generate deployment files using common Representational State Transition (REST) ​​concepts (e.g., REST application programming interfaces (APIs)). However, deployment itself typically does not follow the same concept. Furthermore, while infrastructure provisioning tools are often very powerful and / or expressive, tools used for deployment are often far more limited in terms of the operations they can perform (e.g., they are imperative rather than declarative). Therefore, there has long been a need for tools capable of handling both functional requirements within cloud environments (e.g., provisioning and deployment of infrastructure components).

[0037] In some examples, technologies for implementing Cloud Infrastructure Provisioning Services (CIOS) are described here. As briefly described above, this technology can be configured to manage both the provisioning and deployment of infrastructure assets within a cloud environment. In some instances, CIOS can include two types of services: central and regional components (e.g., CIOS Central and CIOS Region). The following terms will be used throughout the text:

[0038] • Infrastructure components - The long-term infrastructure that supports running code.

[0039] Examples: application deployment, load balancer, Domain Name System (DNS) entry, object bucket, etc.

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

[0041] • Deployment tasks – Short-lived tasks often associated with deploying or testing code. Additionally, deployment tasks are modeled as resources that live beyond the release in which they were created.

[0042] Example: "Deploy the artifact to the environment", "Observe the alerts for 10 minutes", "Execute the testSuite", or "Wait for manual approval".

[0043] For example, CIOS can model deployment of a deployer as the creation of a resource that becomes available when it is completed.

[0044] Because CIOS maintains the state of its cloud infrastructure service declarative providers, CIOS is able to control the lifecycle of these short-lived resources when it is relevant to a release.

[0045] • Resources - Resources that enable CRUD operations.

[0046] CIOS models each of the constructs listed above as a resource. This modeling will be discussed in detail in the next chapter.

[0047] • Flock - A CIOS model that encapsulates the control region and all its components. Primarily used for modeling ownership of infrastructure components and pointing to infrastructure components.

[0048] • Group Configuration - Describes the collection of all infrastructure components, artifacts, and deployment tasks associated with a single service.

[0049] Each group has exactly one group configuration. The group configuration is checked in for source control.

[0050] The group configuration is declarative. They expect CIOS to provide the domain, region, ad, and artifact version as input.

[0051] o groups are granular - a group consists of a single service and supporting infrastructure.

[0052] • State - A snapshot of the state of each resource in the group at a specific point in time.

[0053] • Release - A tuple of a specific version of the group configuration and each artifact of a specific version that it references.

[0054] o Viewing a post as describing a state that may not yet exist.

[0055] • Release Plan - A set of measures CIOS will take to transition all zones from their current state to the state described in the release.

[0056] The release plan has a limited number of steps and clearly defined start and end times.

[0057] • Application - This is a noun. A single attempt to execute a release plan. To perform a change to the current state of a group.

[0058] CIOS can be described as a provisioning layer that applies configurations to downstream systems (e.g., worldwide). It is designed to allow worldwide infrastructure provisioning and code deployment without manual intervention from service teams (e.g., in some instances, beyond initial approval). The high-level responsibilities of CIOS include, but are not limited to:

[0059] • Provides the team with a view of the current status of resources managed by CIOS, including any ongoing change activities.

[0060] • Help the team plan and release new changes.

[0061] • Coordinate activities across various downstream systems within the region to execute approved release plans without human intervention.

[0062] • Coordinate activities across regions / sectors to implement approved release plans worldwide.

[0063] In some examples, CIOS handles onboarding by enabling teams to provide configuration information to CIOS via checked-in code. Furthermore, CIOS automates many more tasks, making this a more significant operation compared to previous implementations. In some instances, CIOS handles pre-deployment by providing teams with the ability to automatically deploy and test code. In some instances, CIOS handles the writing of change management (CM) policies by automatically generating plans to roll out new artifacts (e.g., worldwide) when teams create them. This is achieved by examining the current state and current CIOS configuration for each region (the CIOS configuration itself can be an artifact). Additionally, teams can review these plans and iterate on them by changing the CIOS configuration and requesting CIOS to replan. Once the team is satisfied with the plan, they can create a "release" referencing that plan. The plan can then be marked as approved or rejected. While teams can still write CMs, they are merely instructors on CIOS plans. Therefore, teams can spend less time reasoning about plans. The plans are more accurate because they are machine-generated. For human consumption, the plan is almost too detailed; however, it can be displayed through a sophisticated user interface (UI).

[0064] In some examples, CIOS can handle the execution of Change Management (CM) by automating deployment plans. Once a release plan has been created and approved, engineers no longer participate in CM unless CIOS initiates a rollback. In some cases, this may require teams to automate tasks that are currently performed manually. In some examples, CIOS can handle rollback change management (CM) by automatically generating a plan that returns the group to its original (e.g., pre-release) state when CIOS detects a service health degradation during execution. In some examples, CIOS can handle deployment emergency / tactical changes by receiving release plans whose scope is determined to be a subset of regions and / or a subset of resources managed by CIOS and then executing those plans.

[0065] Additionally, CIOS supports defining primitives required for fully automated global deployments. For example, CIOS can measure service health by monitoring alerts and performing integration tests. CIOS helps teams quickly define rollback behaviors in the event of service degradation and then automatically execute those behaviors. CIOS can automatically generate and display release plans and track approvals. In some instances, the language teams use to describe desired deployment behaviors can be declarative. CIOS can combine code deployment and infrastructure configuration (e.g., provisioning) capabilities within a single system. CIOS also supports flexible sequencing across regions and across components within regions. Teams can express sequencing through checked-in configurations. Teams can programmatically invoke CIOS's planning and release APIs.

[0066] Figure 1 This describes the architecture 100 used to represent the technologies employed to implement at least CIOS Central 102. In some examples, CIOS Central 102 is capable of handling services at the "group" level. CIOS Central 102 has several responsibilities, including but not limited to:

[0067] • Used as a verification gateway for group metadata changes and publishing operations.

[0068] • Store the authoritative mapping of group metadata in the group's deployment artifacts and CIOS repository.

[0069] • Coordinate global releases across phases and objectives.

[0070] • Synchronize to execute strategies such as "one ongoing release for a group at a time".

[0071] • Detect changes to group configurations and artifacts, and trigger releases based on these changes.

[0072] In some examples, the Source Code Version Control Management Service (SCVMS) 104 can be configured to store authoritative group configurations, and the Artifact Notification Service (ANS) 106 can be subscribed to by CIOS Central 102, allowing CIOS Central 102 to be notified of new artifact creation. CIOS Central 102 can then initiate release planning as needed for changes to the affected group map. Additionally, in some examples, the Artifact Push Service (APS) can be invoked by CIOS Central 102 prior to release to the target to ensure that any artifacts required for a successful release exist in the target's region before release.

[0073] In some examples, a customer (e.g., an engineer) 108 can invoke CIOS Central 102 to CRUD groups and / or publish, and view the status of ongoing CIOS activities. Group Management Service 110 can include one or more APIs to manipulate groups; View / Plan / Approve Service 112 can include a CRUD API to create and approve plans, and view a central copy of the status of all CIOS-managed resources; Change Monitoring Service 114 can observe changes to group configurations against SCVMS 104 and receive notifications from ANS 106 regarding changes to other artifacts; and Status Ingestor Service 116 can create copies of region statuses in the CIOS Central Database (DB) 118, which View / Plan / Approve 112 can then display. In some examples, CIOS Central DB 118 can be the DB for groups, plans, and statuses. Group information can be authoritative; everything else may be stale copies of data from CIOS Region 120. CIOS Central 102 can be configured to provide any suitable portion and / or number of user interfaces (e.g., user interface 800) for presenting any suitable data related to groups, releases, infrastructure components, artifacts, etc. In some embodiments, CIOS Central 102 may present data related to one or more releases via any suitable interface. A release may include any suitable combination of tasks related to one or more infrastructure components and / or one or more code changes to one or more applications (e.g., artifacts). References are as follows. Figure 8 An example of the user interface provided by CIOS Central 102.

[0074] In some examples, Engineer 108 can execute API calls for the Group Management Service 110 (e.g., via the entry proxy group 122) to create a list of groups. The protocol used for making such API calls can be Secure Hypertext Transfer Protocol (HTTPS), etc. The associated Access Control Lists (ACLs) for this operation can include a Local Area Network (LAN) 124 or other private connections. For example, instead of using the public internet to connect a customer's on-premises data center or network to CIOS (e.g., dedicated, leased, and / or private connections), CIOS can manage / control network connectivity. Additionally, authentication and authorization (e.g., for Engineer 108) can be performed by a reservation system portal that allows users to manage machine infrastructure (e.g., reservation services). In some instances, CIOS Central 102 can use Java Database Connectivity (JDBC), etc., to store group metadata, schedules, and status in a central DB 118. In some examples, ANS 106 can be configured to notify Change Monitoring Service 114 when a new artifact has been published. ANS 106 can use HTTPS, and authentication and authorization can be handled by the mutual transport layer security service. Additionally, in some instances, the Change Monitoring Service 114 can configure changes for the SCVMS 104 polling group. This polling can be performed using Secure Shell (SSH) or other protocols. Authentication for the Change Monitoring Service 114 can be handled by the CIOS system account, and authorization can be handled by SCVMS 104.

[0075] In some examples, Engineer 108 can use the View / Plan / Approve service 112 to perform one or more of the following operations. Engineer 108 can plan and / or approve plans by invoking CIOS Central 102 to generate and approve plans. Engineer 108 can view the status of ongoing CIOS activities worldwide by invoking CIOS Central 102. Additionally, Engineer 108 can invoke CIOS Central 102 to view a copy of the status of CIOS-managed resources worldwide. These API calls(etc.) can be executed via HTTPS or similar protocols. Furthermore, relevant ACLs can be controlled by LAN 124, and authentication and authorization can be handled by the reservation service. In some examples, the View / Plan / Approve service 112 can request planning and push plan approval to all areas of CIOS Zone 120 (e.g., using HTTPS, etc.). Relevant ACLs can be controlled using a security list 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 Ingestor Service 116 can observe job status or status changes for CIOS zones 120, allowing CIOS to provide a central view of themselves upon request (e.g., using HTTPS, etc.). ACLS for this purpose can also be handled by the WAN Gateway 126, and authentication and authorization can be handled by mutual transport layer security services.

[0076] Figure 2 This describes an architecture 200 representing the technologies used to implement at least CIOS Region 202. In some examples, CIOS Region 202 is where much of the work on declarative provisioning and planning, as well as the approval of application releases, can occur. In some instances, each instance of CIOS Region 202 may have a region frontend capable of handling operations at the "execution objective" level. It can be configured to perform the following operations:

[0077] • Process all CIOS verifications from incoming operations from CIOS Central 102.

[0078] • The rule is to ensure that, for a given execution objective, only one "execution" (planning / importing resources / applying the plan) can be performed at a time.

[0079] • Manages the binary artifact storage for declarative infrastructure provisioning artifacts used as inputs and outputs during declarative infrastructure provisioning execution. Examples of inputs are declarative infrastructure provisioning configuration files and input state files. Typical output is the final state file.

[0080] • For any given execution, request work from the CIOS executor and poll for the results.

[0081] In some instances, the CIOS frontend may depend on the CIOS executor 206 (also referred to herein as the "scheduler"), which is capable of handling the actual execution. In some examples, the CIOS executor operates at the "execution" level, and it is able to:

[0082] • Track the pool of available worker nodes

[0083] • Query incoming job requests and assign them to available qualified workers.

[0084] • Track worker status and perform updates to report to clients.

[0085] • Failed nodes are detected via the lease agreement, and tasks assigned to failed nodes can be invalidated based on their status.

[0086] • Provide facilities for canceling / terminating / pausing / restarting execution, and be able to map those facilities to facilities for transmitting cancellation / termination / pause / restart information to worker nodes.

[0087] In some instances, a CIOS executor can depend on a CIOS worker, which can assign tasks to workers for execution and provide facilities for workers to update job progress. Worker services operate at the "task" granularity. Each worker is an agent that executes the tasks assigned to it and reports task status and output. Each worker can:

[0088] • Poll the assigned work items for the executor worker API and take action to match the assignment status with its local status:

[0089] o Start using a container to poll for task items that do not exist locally.

[0090] o Terminate containers running locally that do not have corresponding assigned task items.

[0091] • Report the status of the task

[0092] • Provides inputs and outputs for job container execution.

[0093] • Launch and monitor the declarative infrastructure provisioning containers used to perform the actual work of publishing execution objectives.

[0094] CIOS workers can rely on CIOS executors to poll jobs from and report results to the CIOS executor's worker endpoints. Workers can rely on executors for all coordination. Additionally, CIOS workers can rely on CIOS Zone 202, where worker services read input from one or more APIs associated with a zone frontend service and write output to said one or more APIs. Examples of input are configuration and start-up state files and import mappings. Examples of output are declarative provisioning processing, output declarative provisioning state files, and import result states.

[0095] In some examples, CIOS Zone 202 can be a zone service used to manage CIOS zone instances / deployments. CIOS Zone 202 is responsible for authoritatively storing and managing plans and states associated with a specific zone. Zone DB 204 can be a CIOS DB used for the state and plans within said specific zone. This is Figure 1 The central DB 206 is an authoritative copy of a subset of the central DB 202. Scheduler 206 is responsible for managing worker swarm capacity, assigning tasks to workers, and tracking task status. In some instances, Task DB 208 is another CIOS DB used for task status. The data in this DB is primarily for operational purposes. Additionally, workers 210 can be a group of Java Virtual Machines (JVMs) that manage the declarative provisioning image. These JVMs receive instructions from scheduler 206 and transmit results to both scheduler 206 and CIOS region 202. CIOS container 212 can run declarative provisioning actions within its own private Docker container 214. This container does not need to contain secrets. Furthermore, in some examples, signing broker 216 can be configured to prevent secret leakage via declarative provisioning tools, thus avoiding placing secrets in the declarative provisioning image. Alternatively, CIOS can perform request signing or initiate mutual transport layer security (mTLS) services within the broker. This also makes it easier to use FIPS-compliant cryptographic libraries.

[0096] In some examples, CIOS Central 102 can invoke CIOS Zone 202 to create plans, push approvals, observe job status (service principal), and extract declarative provider status (service principal). Ingress proxy 218 can be configured as an ACL, and various identity policies can be used for both authentication and authorization. Alternatively, in some examples, ingress proxy 218 can be replaced by a load balancer configured to balance incoming requests, plans, etc. In some instances, CIOS Zone 202 can run a declarative provider by requesting scheduler 206 to run the declarative provider. Worker 210 can query scheduler 206 what it should run and report its status to scheduler 206 upon completion. In some cases, mTLS can handle both authentication and authorization for CIOS Zone 202 and worker 210. Additionally, when worker 210 needs to run a declarative provider, it does so within a Docker container by interacting with local Docker 214. Authentication at this stage can be handled by the local Unix socket. The Docker protocol can be used for this final step; however, HTTPS can be used for the preceding steps.

[0097] In some embodiments, CIOS area 202 may be configured to provide any suitable portion and / or number of user interfaces (e.g., user interface 800) for presenting any suitable data related to groups, releases, infrastructure components, artifacts, etc. In some embodiments, CIOS area 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). References are made below. Figure 8 An example describing the user interface provided by CIOS zone 202.

[0098] In some examples, CIOS container 212 enables declarative providers to interact (via API) with signature agent 216, which perceives itself as invoking various CIOS services. Signature agent 216 listens on a temporary port known only to that declarative provider for each invoking instance of the declarative provider. Signature agent 216 can initiate request signing or mTLS and can forward the declarative provider's invoices to other CIOS services within the service enclave. In some instances, signature agent 216 can also communicate with one or more public CIOS services 220. For example, if possible, signature agent 216 will use an internal endpoint of the public service. For services without an internal endpoint, it must use egress agent 222 to reach the external endpoint. This use of signature agent 216 cannot be used for cross-region communication; for example, the egress agent whitelist in each region is only available for the public IP range of that region. In some examples, worker 210 can subsequently permanently store the state and logs from declarative providers in CIOS region 202, which can then be revealed to CIOS Central 102.

[0099] With CIOS, there are several phases representing the customer experience: Launch, Pre-Release, Global Release, and Tactical Release. For the Pre-Release phase, here's an example of what happens between the creation of a new artifact and its release as Release 1 (e.g., R1). This should replace some or most of the current change management processes. When the relevant artifact is created, CIOS can automatically generate a release using "Latest Version of Everything in the Group." A release is a group configuration for a specific version with specific inputs (e.g., artifact version, domain, region, and ad). A release contains a roll-forward plan for each region and metadata describing the region order. Each region plan is a set of actions that the declarative provider will take to implement the group configuration in that region. Teams with a pre-release environment can use CIOS to automatically release and test software in that environment. Teams can configure CIOS to automatically test rollback plans. Teams will be able to review and approve releases through the CIOS UI. Teams can approve some, but not all, of the region plans within a release. If "Latest Version of Everything" does not generate a suitable plan, the team can request CIOS to generate a plan for a carefully selected artifact version.

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

[0101] For the tactical release phase, here's an example of how a team can execute a tomorrow's version of an "urgent CM." When a plan is generated, the team can ask CIOS to target the plan to specific resources in several ways: by topology (e.g., domain, region, AD, etc.), by resource type (e.g., "metrics-only" or "deploy provisioning service-only"), or a combination of these (e.g., in a separate manner). The team approves the tactical release, just like a global release. CIOS provisiones them in a similar manner. If the team needs to deploy a tactical release while an active global release exists, CIOS will stop executing the global release in the target region and then begin executing the tactical release.

[0102] In some examples, the state of a declarative provider (e.g., traditionally a file) is an authoritative record of the collection of resources managed by the declarative provider. It contains a mapping between the logical identifier of each resource from the configuration file and the actual identifier of that resource. Certain kinds of failures can prevent the actual identifier from being recorded in that state while the declarative provider is creating a resource. When this happens, the actual identifier is lost for the declarative provider. These can be referred to as "orphaned resources."

[0103] For most resources, orphans represent waste – a declarative provider starts (for example) an instance it forgot, but will instead start another instance on its next run. For resources with unique constraints or client-provided identifiers, orphans hinder the declarative provider's forward progress. For example, if a declarative provider creates user "nglass" and fails to orphanize it, the next run of the declarative provider will attempt to create "nglass" and fail because a user with that username already exists. In some cases, orphans become a problem only when a new resource is added to that state. In some instances, the declarative provider's refresh behavior naturally recovers from failures to record updates and deletions.

[0104] In the event of downstream service outages or an outage of the CIOS itself, the CIOS needs to be robust. Because the CIOS can utilize declarative providers to apply changes, this means there should be robustness in running and maintaining the state of declarative providers. Declarative provider providers perform "small-scale" retries—sufficient to avoid outages lasting several minutes. For example, a cloud provider might retry for up to 30 minutes. Downstream system outages lasting longer than 30 minutes will cause the declarative provider to fail. When a declarative provider fails, it logs all the changes it successfully made in that state and then exits. For retrying, the CIOS must re-execute the declarative provider. Re-executing the declarative provider also allows the CIOS to retry in the event of a failure of the CIOS itself. In some instances, the CIOS is able to cycle through the following operations:

[0105] • Refresh – A declarative provider calls the GET API to retrieve a new snapshot of each resource described in its state.

[0106] • Planning - A declarative provider generates a plan (a set of specific API calls) that will take into account the most recently refreshed current state to achieve the desired state.

[0107] • Apply the set of steps described in the declarative provider execution plan.

[0108] When executing a declarative provider, CIOS always runs all three steps. The refresh operation helps recover any updates or deletions that were never logged. CIOS checks the results of the planned operation and compares them to the approved release plan. If the newly generated plan contains operations not in the approved release plan, CIOS may fail and can notify the service team.

[0109] Figure 3The description uses a directed acyclic graph (DAG) 300 to represent the exemplary group 302. For a single group configuration in CIOS, the progress of code / configuration from check-in to production can be described all the way from the first test deployment to the last production deployment. Internally, CIOS refers to each element in the progress as an Execution Objective (ET) – this is distributed throughout our internal API but does not leak into the group configuration. CIOS executes ETs based on the DAG 200 defined in the group configuration. Each ET (e.g., ET-1, ET-2, ET-3, ET-4, ET-5, ET-6, and ET-7) is generally a copy of the service described by the group configuration.

[0110] Figure 4 This describes the DAG 400 used to represent the exemplary group 402. In the group configuration, CIOS is very strict about how teams represent this progress – they must model it using cloud infrastructure leases and regions. Teams should not use domains to model progress. CIOS allows teams to use many leases within a domain and many regions within a lease. However, CIOS does not allow teams to use the same region twice within a lease (but they can use the same region twice within a domain in different leases). DAG 400 represents the progress represented using leases and regions. Figure 3 This is a version of DAG 300. This example is used for coverage services where the pre-production ET is in the production area. The service enclave service will have unstable and stable leases in Release 1. In DAG 400, IAD is the area airport code for Dulles Airport in Washington, DC, YYZ is the area airport code for Toronto, Ontario, PHX, LHR, and FRA are the area airport codes for Phoenix, London, and Frankfurt, respectively, and LUF and LFI are used for two different air force bases.

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

[0112] Figure 5This is a schematic diagram illustrating the use of various repositories for an application (e.g., application 502) and an auxiliary application (e.g., sidecar application 508) according to at least one embodiment. As an example, application 502 may use repository 504 to store any suitable combination of one or more configuration files (e.g., configuration file 506). Repository 504 may be a data structure that stores metadata of a set of files or a directory structure (e.g., a set of files associated with application 502). In some embodiments, repository 504 may be provided by... Figure 1 The source code version control management service (SCVMS) 104 manages the application 502. SCVMS 104 can be an example of a version control system, such as a Git repository (or another suitable distributed or centralized version control system and / or software). Some metadata contained in repository 504 can include, for example, a history of changes in repository 504, a set of committed objects, a set of references to committed objects, etc. Configuration file 506 (also referred to as "configuration file 506" for brevity) can be one or more files used to configure the parameters and initial settings of application 502. In some embodiments, configuration file 506 can include any suitable combination of parameters, settings, deployment code, and / or code for testing application 502.

[0113] In some embodiments, sidecar application 508 is a supporting process or service deployed alongside application 502. Sidecar application 508 may use repository 510 to store any suitable combination of one or more configuration files (e.g., configuration file 512). Repository 510 may be a data structure that stores metadata for a set of files or a directory structure (e.g., a set of files associated with application 502). In some embodiments, repository 510 may also be provided by... Figure 1 The source code version control management service (SCVMS) 104 (or another version control software and / or system) manages the application. Configuration file 512 (also referred to as "configuration file 512" for brevity) can be one or more files used to configure parameters and initial settings for the sidecar application 508. In some embodiments, configuration file 512 may include any suitable combination of parameters, settings, deployment code, and / or code for testing application 502. In some embodiments, changes may be made to any configuration file (e.g., configuration file 512) (or both). These changes may include any suitable combination of configuration code changes (e.g., code change 514, changes made to one or more configuration files of the sidecar application 508), deployment code changes 516 (e.g., changes to the code used to deploy the sidecar application 508), and / or test code changes 518 (e.g., changes to the code used to test the sidecar application 508).

[0114] According to some embodiments, application 502 may rely on data and / or functionality provided by sidecar application 508. Traditionally, if variations 514-518 exist, they would require manual updates, impacting how sidecar application 508 is deployed in various environments. Variations 514-518 will not be automatically detected and / or applied. This can cause various problems during deployment if application 502 relies on data and / or functionality provided by sidecar application 508. When variations 514-518 are not applied (e.g., when deploying with an older version of sidecar application 508), the data and / or functionality provided by the unchanged version of sidecar application 508 may be inaccurate, corrupted, or otherwise unavailable / unreliable.

[0115] To correct this problem, configuration file 506 of repository 504 may include a reference to configuration file 512 of repository 510. Figure 6 An example of code segment 600 representing an application (e.g., application 502) according to some embodiments, is provided, where code segment 600 includes a reference to a data repository of another application. As discussed above, Figure 5 Repository 504 and repository 510 can be separate repositories for storing the code associated with application 502 and sidecar application 508. These repositories can (e.g., by...) Figure 1 The SCVMS 104 repository is maintained separately, and changes to one repository may not affect the other. However, in instances where an application (e.g., application 502) might depend on data and / or functionality corresponding to another application (e.g., sidecar application 508), references (e.g., statement 602) may be placed separately from references to the other repository (e.g., [reference to another application]). Figure 5 The code associated with the application (e.g., application 502) in repository 510.

[0116] In some embodiments, statement 602 may reference a Git submodule (e.g., using statement 602). A git submodule is a host git repository (e.g., Figure 5 The record in the repository (504) points to another external repository (e.g., Figure 5 A specific commit in repository 510. When a submodule is added to a repository (e.g., using statement 602), a new .gitmodules file containing metadata about that module is created. When statement 602 is executed, SCVMS 104 clones the submodule so that the current state of the repository (e.g., repository 510) can be determined. From the current state of the repository, code changes can be identified (e.g., ...). Figure 5Any suitable combination of code changes 514, deployment code changes 516, and / or test code changes 518. These changes may be used when deploying application 502 and sidecar application 508 to make the current version of the code for sidecar application 508 usable.

[0117] Figure 7 This is a flowchart describing a method 700 for obtaining code changes associated with a sidecar application according to at least one embodiment. Before performing method 700, it is assumed that... Figure 5 Repositories 504 and 510 have been created and Figure 1 SCVMS104 has been configured to maintain repositories 504 and 510.

[0118] In 706, user equipment 702 can be used to [connect with / to / etc.]. Figure 5 The application 502 is associated with the repository 504, which is checked out. In some embodiments, the checked-out code may include one or more configuration files associated with application 502.

[0119] At 708, user device 702 can be used to insert a reference to a data repository associated with the sidecar application. As an example, statement 602 can be added to one or more configuration files of application 502.

[0120] At 710, the reference may be stored in repository 504 upon check-in, repository 504 being associated with... Figure 5 The application 502 is associated with a data repository (e.g., a git repository). Repository 502 can be maintained by SCVMS 104.

[0121] At 712, the change monitoring service 114 may poll for changes to SCVMS 104, or alternatively, SCVMS 104 may report changes made at 710 to the change monitoring service 114.

[0122] At 714, the change monitoring service 114 can obtain statement 602 from SCVMS 104 and dereference statement 602 to identify one or more files associated with the sidecar application (e.g., sidecar application 508).

[0123] At 716, the change monitoring service 114 may poll SCVMS 104 for changes made to the sidecar application (e.g., sidecar application 508). The change monitoring service 114 may determine that no changes have been made to the sidecar application since the last check-in of the file containing the referenced file in repository 504. Based on this determination, the change monitoring service 114 may terminate the process.

[0124] In 718, user device 704 can be used to... Figure 5The repository 510 associated with the sidecar application 508 checks out the code. In some embodiments, the checked-out code may include one or more configuration files associated with the sidecar application 508. In some embodiments, the checked-out code may include configuration code segments, code segments describing how the sidecar application 508 will be deployed, and / or code segments identifying how the sidecar application 508 will be tested.

[0125] At 720, user device 704 can be used to modify any appropriate number of code segments corresponding to the configuration, deployment, and / or testing of sidecar application 508.

[0126] In 722, code references can be stored in repository 210 upon check-in, and repository 210 is related to... Figure 5 The sidecar application 508 is associated with a data repository (e.g., a git repository). Repository 510 can be maintained by SCVMS 104.

[0127] At 724, the change monitoring service 114 may poll for changes to SCVMS 104, or alternatively, SCVMS 104 may report changes made at 722 to the change monitoring service 114. Although not described, in some embodiments, the change monitoring service 114 may identify changes made to code referenced in repository 504. Once identified, the change monitoring service 114 may perform any appropriate action to induce an update so that the modified version of the sidecar application is deployed alongside application 502 for any subsequent deployments provided by CIOS. Alternatively, method 700 may proceed to 726.

[0128] In 726, user equipment 702 can be used to [connect with / to / etc.] Figure 5 The application 502 is associated with the repository 504, which checks out the code. In some embodiments, the checked-out code may include one or more configuration files associated with application 502. As an example, the checked-out code may include one or more files containing statement 602.

[0129] In 728, user device 702 can be used to make one or more changes to the checked-out code.

[0130] At 730, the checked-out code (and the corresponding changes made at 728) can be stored in repository 504 upon check-in, repository 504 being associated with... Figure 5 The application 502 associated data repository (e.g., a git repository).

[0131] At 732, the change monitoring service 114 may poll for changes to SCVMS 104, or alternatively, SCVMS 104 may report changes made at 730 to the change monitoring service 114.

[0132] In 734, the change monitoring service 114 can obtain a reference (e.g., statement 602) from SCVMS 104 and dereference statement 602 to identify one or more files associated with the sidecar application (e.g., sidecar application 508).

[0133] In 736, the change monitoring service 114 can poll the sidecar application (e.g., sidecar application 508) for changes made by SCVMS 104.

[0134] At 738, change monitoring service 114 can determine that the changes made at 722 occurred after a previous check-in of application 502 (e.g., a check-in made at 710, including the check-in of one or more files including statement 602). Based on this determination, change monitoring service 114 can perform any appropriate action to induce an update so that the modified version of the sidecar application (e.g., including the changes made at 722) is deployed alongside application 502 for any subsequent deployments provided by CIOS. Method 700 can then terminate.

[0135] Figure 8 This is a schematic diagram illustrating an exemplary user interface (e.g., UI 800) according to at least one embodiment, UI 800 displaying an application for a sidecar (e.g., Figure 5 The changes made to the sidecar application 508). In some embodiments, the user interface 800 may be provided with Figure 7 The user of user device 704 is part of the operation performed by change monitoring service 114 at 738.

[0136] UI 800 can include a task list 802, which can be located anywhere suitable on UI 800, and as shown in the figure, the task list 802 is located at the top of UI 800. The task 802 can correspond to a software resource (e.g., ...) that will be associated with the execution target. Figure 5The configuration code of application 502 is modified from a first state to a second state. In some embodiments, UI 800 may be used to present a set of changes to be made to those software resources. As shown in the figure, the execution task list 802 contains execution tasks 804 (e.g., labeled "unstable") corresponding to the target. When execution task 804 is selected, execution task 804 can display module 806. When module 806 is selected, module 806 can display module 808 (as shown in the figure, labeled "app_deployment"). When module 808 is selected, module 808 can display module 810. Execution target 1304 can display any suitable number of modules and / or application deployments corresponding to execution task 804. In embodiments with more than one module, the modules can be ordered in descending order of the number of times they have been created, updated, deleted, or unchanged. As an example, modules 806-810 may be displayed such that the module with the highest number of creations is listed at the top of the list, and the remaining tasks are displayed in descending order according to the number of creation operations for each task. In some embodiments, modules 806-810 may be organized in different ways (e.g., in ascending order, or according to any other suitable method for organizing modules 806-810). In some embodiments, when module 810 is selected, UI 800 may present log 812 and any other suitable information corresponding to task 804.

[0137] Log 812 can be displayed anywhere suitable on UI 800. Log 812 can display information about the module corresponding to 810 (e.g., with...). Figure 5 The information pertains to changes made to the application code (corresponding to application 508 on the sidecar). For example, line 814 may describe an added line of code, while line 816 may describe a deleted line of code replaced by line 814. In some embodiments, line 814 (and / or any portion of the code to be added) can be displayed using a green background or any other color suitable for identifying one or more lines of code to be added. Line 816 (or, for example, any portion of the code to be deleted) can be displayed using a red background or any other color suitable for identifying one or more lines of code to be deleted.

[0138] Using UI 800, users can view code changes for each part of a task and for each plan. In some embodiments, users can approve or reject each change. Therefore, UI 800 can be controlled by the user (e.g., with...) Figure 5The user associated with application 502 can view changes made to the sidecar application, enabling them to approve or reject various changes. Through UI 800, the user is given control over a specific version of the sidecar application used in the deployment of application 502. Additionally, the user has visual access to specific details of the configuration, deployment, and / or testing associated with the sidecar application, allowing them to make informed decisions regarding modifications and / or specific configurations related to the use of sidecar application 508 and application 502.

[0139] Figure 9 This is a flowchart of a method 900, according to at least one embodiment, for implementing changes to a first service based on user input by a computer infrastructure dispatch service. Method 900 may be derived from... Figure 1 The CIOS central 102 is executed. As shown in the figure, method 900 includes many operations. However, compared with... Figure 9 Compared to the operations provided in the previous method, method 900 may include more or fewer operations. These operations may be performed in any suitable order.

[0140] In block 902, computer systems can manage declarative infrastructure providers (e.g., Figure 2 CIOS region 202 deploys multiple infrastructure resources and artifacts based at least in part on declarative instructions (e.g., configuration files that declare the desired deployment state without describing the control flow used to achieve the desired state). CIOS region 202 can provision resources using declarative files that describe components and how they interact. Configuration files can describe the resources and associated fields required to create components, and then describe other components that reference the previously described components. In some examples, the provisioning tool can subsequently generate workflows for creating and managing the components described in the configuration file. In some embodiments, the declarative infrastructure provider can use declarative statements formatted according to Terraform, a tool for building, modifying, and versioning infrastructure components.

[0141] In block 904, CIOS central 102 can detect (e.g., via) Figure 1 The first modification of the first service (e.g., to the change monitoring service 114) to the first service. Figure 5 (Changes to sidecar application 508). In some embodiments, the first service includes at least one of the plurality of infrastructure resources. The first service may use a first distributed version control repository (e.g., Figure 5 The repository (510) is used to perform modifications to the first service.

[0142] In block 906, CIOS central 102 (e.g., change monitoring service 114) can identify that the configuration data of the second service references the first service. As an example, change monitoring service 114 can detect interactions with applications (e.g., Figure 5 The code segment 600 in the configuration file associated with application 502)

[0143] At block 908, CIOS central 102 (e.g., change monitoring service 114) detects a second modification to the second service (e.g., a check-in of a configuration file associated with application 502). In some embodiments, the second service uses a second distributed version control repository ( Figure 5 The repository (504) is used to perform modifications to the second service.

[0144] In block 910, in response to recognizing a second modification to the second service and recognizing that the second service references the first service, CIOS central 102 may, via a graphical interface (e.g., by...), Figure 1 The UI 800 provided by the View / Plan / Approve service 112 has been changed, including a first modification to the first service.

[0145] In block 912, user input may be received (e.g., via UI 800) indicating acceptance or rejection of changes including a first modification to the first service.

[0146] In block 914, changes to the first service can be implemented by CIOS Central 102 based on user input. As an example, CIOS Central 102 can perform any appropriate operation to ensure that the modified sidecar application 508 is deployed alongside application 502 in a subsequent deployment (e.g., a deployment performed by CIOS Zone 202).

[0147] Explanatory System

[0148] Figure 10-12 This refers to various aspects of exemplary environments used to implement aspects of this disclosure, according to various embodiments. Figure 10 A simplified diagram illustrating a distributed system 1000 for implementing embodiments of the present disclosure is provided. In the illustrated embodiment, the distributed system 1000 includes one or more client computing devices 1002, 1004, 1006, and 1008, which are configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), via one or more networks 1010. A server 1012 may be communicatively coupled to the client computing devices 1002, 1004, 1006, and 1008 via one or more networks 1010.

[0149] In various embodiments, server 1012 may be adapted to run one or more services or software applications, such as services and applications providing identity management services. In some embodiments, server 1012 may also provide other services or software applications, capable of including non-virtual and virtual environments. In some embodiments, these services may be provided as web-based services or cloud services or under a Software as a Service (SaaS) model to users of client computing devices 1002, 1004, 1006, and / or 1008. Users operating client computing devices 1002, 1004, 1006, and / or 1008 may sequentially interact with server 1012 using one or more client applications to use the services provided by these components.

[0150] exist Figure 10 In the structure described herein, software components 1018, 1020, and 1022 of system 1000 are shown as being implemented on server 1012. In other embodiments, one or more components of system 1000 and / or the services provided by these components may also be implemented by one or more of client computing devices 1002, 1004, 1006, and / or 1008. A user operating a client computing device may then use 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 various different system architectures are possible and may differ from distributed system 1000. Figure 10 The embodiments shown are therefore an example of a distributed system for implementing the system of the embodiments, and should not be considered limiting.

[0151] Client computing devices 1002, 1004, 1006, and / or 1008 may include various types of computing systems. For example, client computing devices may include portable handheld devices (e.g., iPhone®, cellular 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 (e.g., various internet-related apps, email, short message service (SMS) applications) and may use various other communication protocols. Client computing devices may also include general-purpose personal computers, including, for example, personal computers and / or laptops running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. Client computing devices can be workstation computers, running any operating system from a variety of commercially available UNIX® or UNIX-like operating systems, including, without limitation, various GNU / Linux operating systems, such as, for example, Google Chrome OS. The client computing device may also include electronic devices such as thin client computers, internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices capable of communicating via the network(s) 1010.

[0152] Although Figure 10 The distributed system 1000 is shown as having four client computing devices, but can support any number of client computing devices. Other devices (such as devices with sensors) can interact with the server 1012.

[0153] The network(s) 1010(s) in the distributed system 1000 can be any type of network familiar to those skilled in the art, capable of supporting data communication using any of the various available protocols, including, without limitation, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (System Network Architecture), IPX (Internet Packet Switching), AppleTalk, etc. By way of example only, the network(s) 1010(s) can be a local area network (LAN), an Ethernet-based network, a token ring network, a wide area network (WAN), 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 protocol of the IEEE 1002.16 protocol suite, Bluetooth®, and / or any other wireless protocol), and / or any combination of these and / or other networks.

[0154] Server 1012 may include one or more general-purpose computers, special-purpose server computers (including, as examples, PC (personal computer) servers, UNIX® servers, mid-range servers, mainframes, rack-mounted servers, etc.), server farms, server clusters, or any other suitable arrangement and / or combination. Server 1012 may include one or more virtual machines running a virtual operating system or other computing architectures involving virtualization. One or more flexible pools of logical storage devices may be virtualized to maintain virtual storage devices for the server. The virtual network may be controlled by server 1012 using software-defined networking. In various embodiments, server 1012 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 1012 may correspond to a server for performing the processes described above according to embodiments of this disclosure.

[0155] Server 1012 may run an operating system, including any of the operating systems discussed above and any commercially available server operating system. Server 1012 may also run any of a variety of other server applications and / or mid-level applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, JAVA® servers, database servers, etc. Exemplary database servers include, without limitation, servers commercially available from Oracle, Microsoft, Sybase, IBM, etc.

[0156] In some implementations, server 1012 may include one or more applications to analyze and merge data feeds and / or event updates received from users of client computing devices 1002, 1004, 1006, and 1008. As an example, 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. These may include real-time events related to sensor data applications, financial market indicators, network performance measurement tools (e.g., network monitoring and business management applications), clickstream analysis tools, vehicle traffic monitoring, and the like. Server 1012 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of client computing devices 1002, 1004, 1006, and 1008.

[0157] The distributed system 1000 may also include one or more databases 1014 and 1016. These databases provide a mechanism for storing information, such as user identity information and other information used by embodiments of this disclosure. Databases 1014 and 1016 may be located in various locations. As an example, one or more of databases 1014 and 1016 may be located on a non-transitory storage medium that is local (and / or located within server 1012) relative to server 1012. Alternatively, databases 1014 and 1016 may be located remotely relative to server 1012 and communicate with server 1012 via a network-based connection or a dedicated connection. In one set of embodiments, databases 1014 and 1016 may be located in a storage area network (SAN). Similarly, any necessary files for performing functions belonging to server 1012 may be stored locally on server 1012 and / or remotely, as needed. In one set of embodiments, databases 1014 and 1016 may include relational databases (such as those provided by Oracle) adapted to store, update, and retrieve data in response to SQL formatting commands.

[0158] Figure 11 This indicates an exemplary computer system 1100 that can be used to implement embodiments of the present disclosure. In some embodiments, computer system 1100 can be used to implement any of the various servers and computer systems described above. Figure 11As shown, the computer system 1100 includes various subsystems, including a processing subsystem 1104 that communicates with a number of peripheral subsystems via a bus subsystem 1102. These peripheral subsystems may include a processing acceleration unit 1106, an I / O subsystem 1108, a storage subsystem 1118, and a communication subsystem 1124. The storage subsystem 1118 may include a tangible computer-readable storage medium 1122 and system memory 1110.

[0159] Bus subsystem 1102 provides a mechanism for allowing various components and subsystems of computer system 1100 to communicate with each other as needed. While bus subsystem 1102 is schematically shown as a single bus, alternative embodiments of the bus subsystem may use multiple buses. Bus subsystem 1102 can be any of several types of bus architectures, including memory buses or memory controllers, peripheral buses, and local buses using any of a variety of bus architectures. For example, such architectures may include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses that can be implemented as mezzanine buses manufactured according to the IEEE P1386.1 standard.

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

[0161] In some embodiments, the processing unit in the processing subsystem 1104 is capable of executing instructions stored in the system memory 1110 or on the computer-readable storage medium 1122. In various embodiments, the processing unit is capable of executing various program or code instructions and of maintaining multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can reside in the system memory 1110 and / or on the computer-readable storage medium 1110, including possibly residing on one or more storage devices. With appropriate programming, the processing subsystem 1104 can provide the various functions described above to dynamically modify documents (e.g., web pages) in response to usage patterns.

[0162] In some embodiments, the processing acceleration unit 1106 may be provided for performing custom processing or for offloading some of the processing performed by the processing subsystem 1104 in order to speed up the overall processing performed by the computer system 1100.

[0163] I / O subsystem 1108 may include means and mechanisms for inputting information into computer system 1100 and / or outputting information from or via computer system 1100. Generally, the term "input device" is used to include all possible types of means and mechanisms for inputting information into computer system 1100. User interface input devices may include, for example, keyboards, pointing devices (such as mice or trackballs), touchpads or touchscreens included in a display, scroll wheels, click wheels, dial pads, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may also include motion sensing and / or gesture recognition devices, such as the Microsoft Kinect® motion sensor that enables a user to control and interact with the input device, the Microsoft Xbox® 360 game controller, and means for providing an interface for receiving input using gestures and spoken commands. The user interface input device may also include an eye gesture recognition device (such as a Google Glass® blink detector) that detects eye activity from the user (e.g., “blinking” when taking a photo and / or making menu selections) and changes the eye gesture as input to the input device (e.g., Google Glass®). Additionally, the user interface input device may include a voice recognition sensing device that enables the user to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0164] Other examples of user interface input devices, without limitation, include three-dimensional (3D) mice, joysticks or pointers, game controllers, and graphical tablet computers, as well as audio / visual devices such as speakers, digital cameras, digital portable camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Additionally, user interface input devices may include, for example, medical imaging input devices, such as computed tomography (CT), magnetic resonance imaging (MRI), positional emission computed tomography (PECT), and medical ultrasound examination devices. User interface input devices may also include, for example, audio input devices, such as MIDI keyboards, digital musical instruments, etc.

[0165] User interface output devices may include display subsystems, indicator lights, or non-visual displays (such as audio output devices). Display subsystems may be cathode ray tubes (CRTs), flat panel devices (such as flat panel devices using liquid crystal displays (LCDs) or plasma displays), projection devices, touch screens, etc. Generally, the term "output device" is used to encompass all possible types of means and mechanisms for outputting information from computer system 1100 to a user or other computer. For example, user interface output devices may, without limitation, include various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0166] Storage subsystem 1118 provides a repository or data warehouse for storing information used by computer system 1100. Storage subsystem 1118 provides a tangible, non-transitory, computer-readable storage medium to store basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provides the above-described functionality when executed by processing subsystem 1104 may be stored in storage subsystem 1118. The software may be executed by one or more processing units of processing subsystem 1104. Storage subsystem 1118 may also provide a repository for storing data used according to this disclosure.

[0167] Storage subsystem 1118 may include one or more non-transitory storage devices, including volatile and non-volatile storage devices. For example... Figure 11 As shown, the storage subsystem 1118 includes system memory 1110 and computer-readable storage medium 1122. System memory 1110 may include a variety of memories, including volatile main random access memory (RAM) for storing instructions and data during program execution, and non-volatile read-only memory (ROM) or flash memory for storing fixed instructions. In some implementations, a basic input / output system (BIOS) containing basic routines that facilitate the transfer of information between elements within the computer system 1100, such as during startup, may be stored in the ROM. RAM may contain data and / or program modules currently being operated and executed by the processing subsystem 1104. In some implementations, system memory 1110 may include various types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0168] As an example and without limitation, such as Figure 11As described herein, system memory 1110 may store: application programs 1112, which may include client applications, web browsers, mid-level applications, relational database management systems (RDBMS), etc.; program data 1114; and operating system 1116. As an example, operating system 1116 may include various versions of Microsoft Windows®, Apple Macintosh® and / or Linux operating systems, various commercially available UNIX® or similar UNIX operating systems (including, without limitation, 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).

[0169] Computer-readable storage medium 1122 may store programming and data constructs that provide functionality for some embodiments. Software (programs, code modules, instructions) providing these functions, when executed by the processor of processing subsystem 1104, may be stored in storage subsystem 1118. As an example, computer-readable storage medium 1122 may include non-volatile memory, such as hard disk drives, disk drives, optical disc drives (such as CD ROMs, DVDs, Blu-ray® discs, or other optical media). Computer-readable storage medium 1122 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash memory drives, Secure Digital (SD) cards, DVD discs, digital videotapes, etc. Computer-readable storage medium 1122 may also include: solid-state drives (SSDs) based on non-volatile memory, such as flash-based SSDs, enterprise flash drives, solid-state ROMs, etc.; volatile memory-based SSDs, such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs; and hybrid SSDs using a combination of DRAM and flash-based SSDs. Computer-readable medium 1122 may provide storage for computer-readable instructions, data structures, program modules, and other data for computer system 1100.

[0170] In some embodiments, the storage subsystem 1100 may further include a computer-readable storage medium reader 1120, which is also capable of being connected to a computer-readable storage medium 1122. Together with, and optionally in conjunction with, the system memory 1110, the computer-readable storage medium 1122 may comprehensively represent remote, local, fixed, and / or removable storage devices and storage media for storing computer-readable information.

[0171] In some embodiments, computer system 1100 may support the execution of one or more virtual machines. Computer system 1100 may execute programs (such as hypervisors) to facilitate the configuration and management of the virtual machines. Each virtual machine may be allocated in memory, computer (e.g., processor, cores), I / O, and networking resources. Each virtual machine may run its own operating system, which may be the same as or different from the operating systems run by other virtual machines executed by computer system 1100. Therefore, multiple operating systems may potentially be run simultaneously by computer system 1100. Each virtual machine typically runs independently of other virtual machines.

[0172] The communication subsystem 1124 provides an interface with other computer systems and networks. The communication subsystem 1124 serves as an interface for receiving data from other systems and sending data from computer system 1100 to other systems. For example, the communication subsystem 1124 enables computer system 1100 to establish a communication channel via the Internet to one or more client devices to receive and send information to client devices. Additionally, the communication subsystem 1124 can be used to transmit successful login notifications or password re-entry notifications from the privileged account manager to the requesting user.

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

[0174] The communication subsystem 1124 is capable of receiving and transmitting data in various forms. For example, in some embodiments, the communication subsystem 1124 may receive input communications in the form of structured and / or unstructured data feeds 1126, event streams 1128, event updates 1130, etc. For example, the communication subsystem 1124 may be configured to receive (or send) data feeds 1126 in real time from users of social media networks and / or other communication services, such as Twitter® feeds, Facebook® updates, web feeds (such as Rich Site Summary (RSS) feeds), and / or real-time updates from one or more third-party information sources.

[0175] In some embodiments, the communication subsystem 1124 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1128 of real-time events and / or event updates 1130, the continuous data stream may be inherently continuous or infinite without a definite end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial market indicators, network performance measurement tools (e.g., network monitoring and business management applications), clickstream analysis tools, vehicle traffic monitoring, etc.

[0176] The communication subsystem 1124 may also be configured to output structured and / or unstructured data feeds 1126, event streams 1128, event updates 1130, etc., to one or more databases, which may communicate with one or more streaming data source computers coupled to the computer system 1100.

[0177] The computer system 1100 can be one of a variety of types, including handheld portable devices (e.g., iPhone® cellular phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), personal computers, workstations, mainframe computers, telephone booths, server racks, or any other data processing systems.

[0178] Due to the constantly changing nature of computers and networks, Figure 11 The description of the computer system 1100 depicted is intended only as a specific example. Figure 11 The system described herein is possible compared to many other structures with more or fewer components. Based on the disclosure and teachings provided herein, those skilled in the art will understand other ways and / or methods for implementing the various embodiments.

[0179] The systems depicted in some of the accompanying figures can be provided in various architectures. In some embodiments, the system can be configured as a distributed system, wherein one or more components of the system are distributed across one or more networks within one or more cloud infrastructure systems.

[0180] A cloud infrastructure system is a collection of one or more server computing devices, network devices, and / or storage devices. These resources may be partitioned by a cloud service provider and allocated to its customers in some way. For example, cloud service providers (such as Oracle Corporation of Redwood Shores, California) can provide various types of cloud services, including but not limited to one or more services offered under the Software as a Service (SaaS) category, services offered under the Platform as a Service (PaaS) category, services offered under the Infrastructure as a Service (IaaS) category, or other types of services that include hybrid services. Examples of SaaS services, without limitation, include the ability to build and deliver a suite of on-demand applications (such as Oracle Fusion applications). SaaS services enable customers to use applications running on a cloud infrastructure system without requiring the customer to purchase the software for said applications. Examples of PaaS services, without limitation, include the ability for organizations (such as Oracle) to consolidate existing applications on a shared public architecture and to build new applications that utilize shared services provided by the platform (such as Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.). IaaS services facilitate the management and control of underlying computing resources, such as storage, networking, and other basic computing resources for customers to use services provided by SaaS and PaaS platforms.

[0181] Figure 12 This is a simplified block diagram of one or more components of a system environment 1200 according to an embodiment of the present disclosure, through which services provided by one or more components of the embodiment system can be offered as cloud services. In the illustrated embodiment, the system environment 1200 includes one or more client computing devices 1204, 1206, and 1208 that can be used by a user to interact with a cloud infrastructure system 1202 providing cloud services. The client computing devices can be configured to operate client applications, such as web browsers, proprietary client applications (e.g., Oracle Forms), or some other application, which can be used by a user of the client computing devices to interact with the cloud infrastructure system 1202 to use the services provided by the cloud infrastructure system 1202.

[0182] It should be understood that the cloud infrastructure system 1202 described in the accompanying drawings may have components in addition to those described. Furthermore, the embodiments shown in the drawings are merely one example of a cloud infrastructure system that may include embodiments of this disclosure. In some other embodiments, the cloud infrastructure system 1202 may have more or fewer components than those shown in the drawings, may combine two or more components, or may have different configurations or arrangements of components.

[0183] Client computing devices 1204, 1206 and 1208 may be devices similar to those client computing devices described above for 1002, 1004, 1006 and 1008.

[0184] Although the exemplary system environment 1200 is shown as having three client computing devices, any number of client computing devices can be supported. Other devices (such as devices with sensors, etc.) can interact with the cloud infrastructure system 1202.

[0185] One or more networks 1210 can facilitate communication and exchange of data between client computing devices 1204, 1206, and 1208 and cloud infrastructure system 1202. Each network can be any type of network familiar to those skilled in the art that is capable of supporting data communication using any of a variety of commercially available protocols, including those described above for the one or more networks 1210.

[0186] The cloud infrastructure system 1202 may include one or more computers and / or servers, which may include those computers and / or servers described above for server 1212.

[0187] In some embodiments, services provided by a cloud infrastructure system may include a variety of services that users of the cloud infrastructure system can use on demand, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. Services provided by a cloud infrastructure system can be dynamically adjusted to meet the needs of its users. A specific instantiation of a service provided by a cloud infrastructure system is referred to herein as a "service instance." Generally, any service that a user can obtain from a cloud service provider's system via a communication network (such as the Internet) is referred to as a "cloud service." In a public cloud environment, the servers and systems constituting the cloud service provider's system are different from the customer's own on-premises servers and systems. For example, the cloud service provider's system may host applications, and users may subscribe to and use said applications on demand via a communication network (such as the Internet).

[0188] In some examples, services within a computer network cloud infrastructure may include protected computer network access to storage devices, hosted databases, hosted web servers, software applications, or other services provided to users by a cloud vendor or other services known in the art. For example, services may include password-protected access to remote storage devices in the cloud via the Internet. As another example, services may include web-based hosted relational databases and scripting language middleware engines for use by networking developers. As yet another example, services may include access to email software applications hosted on a cloud vendor's website.

[0189] In some embodiments, cloud infrastructure system 1202 may include a suite of application, middleware, and database service providers delivered to customers in a self-service, subscription-based, scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle public cloud provided by this assignee.

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

[0191] In some embodiments, the services provided by the cloud infrastructure system 1202 may include one or more services offered under the Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS) category, or other types of services including hybrid services. A customer may subscribe to one or more services provided by the cloud infrastructure system 1202 through a subscription order. The cloud infrastructure system 1202 then performs processing to provide the services in the customer's subscription order.

[0192] In some embodiments, the services provided by the cloud infrastructure system 1202 may, without limitation, include application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services falling under the SaaS category. For example, a SaaS platform may provide the ability to build and deliver a suite of on-demand applications on an integrated development and deployment platform. The SaaS platform can manage and control the underlying software and infrastructure to provide SaaS services. By using the services provided by the SaaS platform, customers can use applications running on the cloud infrastructure system. Customers can access application services without having to purchase separate licenses and support. A variety of different SaaS services may be available. Examples, without limitation, include services that provide solutions for sales performance management, enterprise integration, and business agility for large organizations.

[0193] 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 falling under the PaaS category. Examples of platform services, without limitation, may include services that enable organizations (such as Oracle) to merge existing applications on a shared public architecture and the ability to build new applications that utilize the shared services provided by the platform. The PaaS platform manages and controls the underlying software and infrastructure to provide PaaS services. Customers can access PaaS services provided by the cloud infrastructure system without having to purchase separate licenses and support. Examples of platform services, without limitation, include Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.

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

[0195] Various infrastructure services can be provided by IaaS platforms within cloud infrastructure systems. Infrastructure services facilitate the management and control of underlying computing resources, such as storage devices, networks, and other basic computing resources for customers to use services provided by SaaS and PaaS platforms.

[0196] In some embodiments, the cloud infrastructure system 1202 may also include infrastructure resources 1230 to provide resources for offering various services to customers of the cloud infrastructure system. In one embodiment, infrastructure resources 1230 may include a pre-integrated and optimized combination of hardware (such as servers, storage devices, and networking resources) to perform services provided by PaaS platforms and SaaS platforms.

[0197] In some embodiments, resources in cloud infrastructure system 1202 can be shared by multiple users and dynamically reallocated as needed. Additionally, resources can be allocated to users in different time zones. For example, cloud infrastructure system 1230 may enable a first group of users in a first time zone to use the resources of the cloud infrastructure system for a specified number of hours, and then allow the same resources to be reallocated to another group of users in a different time zone, thereby maximizing resource utilization.

[0198] In some embodiments, a number of internally shared services 1232 may be provided, shared by different components or modules of the cloud infrastructure system 1202 and by the services provided by the cloud infrastructure system 1202. These internally shared services may include, without limitation, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, services for starting cloud support, email services, notification services, file transfer services, etc.

[0199] In some embodiments, the cloud infrastructure system 1202 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) within the cloud infrastructure system. In one embodiment, cloud management functionality may include the ability to provision, manage, and track customer subscriptions received by the cloud infrastructure system 1202.

[0200] In one embodiment, as shown in the figure, cloud management functionality may be provided by one or more modules, such as an order management module 1220, an order allocation module 1222, an order supply module 1224, an order management and monitoring module 1226, and an identity management module 1228. These modules may include one or more computers and / or servers, or may be provided using one or more computers and / or servers, which may be general-purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0201] In exemplary operation 1234, a customer using a client device (such as client computing devices 1204, 1206, or 1208) can interact with cloud infrastructure system 1202 by requesting one or more services provided by cloud infrastructure system 1202 and placing an order to subscribe to one or more services provided by cloud infrastructure system 1202. In some embodiments, the customer can access cloud user interfaces (UIs) (cloud UI 1216, cloud UI 1214, and / or cloud UI 1216) and place subscription orders through these UIs. Order information received by cloud infrastructure system 1202 in response to a customer placing an order may include information identifying the customer and the one or more services provided by cloud infrastructure system 1202 that the customer wishes to subscribe to.

[0202] After a customer places an order, the order information is received via cloud UI 1212, 1214 and / or 1216.

[0203] In operation 1236, the order is stored in order database 1218. Order database 1218 can be one of several databases operated by cloud infrastructure system 1202 and in conjunction with other system components.

[0204] In operation 1238, the order information is forwarded to the order management module 1220. In some instances, the order management module 1220 can be configured to perform order-related invoicing and accounting functions, such as verifying the order and, upon verification, reserving the order.

[0205] In operation 1240, order information is transmitted to the order allocation module 1222. The order allocation module 1222 can use the order information to allocate the supply of services and resources for orders placed by customers. In some instances, the order allocation module 1222 can allocate the supply of resources to support subscribed services using the services of the order supply module 1224.

[0206] In some embodiments, the order allocation module 1222 is capable of managing the business processes associated with each order and applying business logic to determine whether an order should continue to be supplied. In operation 1242, upon receiving an order for a new subscription, the order allocation module 1222 sends a request to the order supply module 1224 to allocate resources and configure those resources required to satisfy the subscription order. The order supply module 1224 is capable of allocating resources for the services ordered by the customer. The order supply module 1224 provides an abstraction level between the cloud services provided by the cloud infrastructure system 1202 and the physical implementation layer, which is used to supply resources for providing the requested services. The order allocation module 1222 can therefore be isolated from implementation details such as whether services and resources are actually supplied on-premises or pre-supplied and allocated / distributed only upon request.

[0207] In operation 1244, once services and resources are provisioned, notification of the provisioned services can be sent by the order provisioning module 1224 of the cloud infrastructure system 1202 to customers on client computing devices 1204, 1206, and / or 1208. In operation 1246, customer subscription orders can be managed and tracked by the order management and monitoring module 1226. In some instances, the order management and monitoring module 1226 can be configured to collect service usage statistics from subscription orders, such as the amount of storage used, the amount of data transmitted, the number of users, and the amount of system uptime and downtime.

[0208] In some embodiments, the cloud infrastructure system 1202 may include an identity management module 1228. The identity management module 1228 may be configured to provide identity services, such as access management and authorization services within the cloud infrastructure system 1202. In some embodiments, the identity management module 1228 may control information about customers who wish to use services provided by the cloud infrastructure system 1202. This information may include information to verify the identity of such customers and information describing which actions those customers are authorized to perform relative to various system resources (e.g., files, directories, applications, communication ports, storage segments, etc.). The identity management module 1228 may also include descriptive information about each customer and management of how and by whom that descriptive information can be accessed and modified.

[0209] While specific embodiments of this disclosure have been described, various modifications, alterations, alternative constructions, and equivalents are also included within the scope of this disclosure. The embodiments of this disclosure are not limited to operation within certain specific data processing environments, but are freely operable within multiple data processing environments. Furthermore, although embodiments of this disclosure have been described using a specific set of transactions and steps, it should be clear to those skilled in the art that the scope of this disclosure is not limited to the described set of transactions and steps. Various features and aspects of the above embodiments may be used individually or collectively.

[0210] Furthermore, although embodiments of this disclosure have been described using specific combinations of hardware and software, it should be appreciated that other combinations of hardware and software are also within the scope of this disclosure. Embodiments of this disclosure may be implemented solely in hardware, solely in software, or using combinations thereof. The various processes described herein can be implemented on the same processor or different processors in any combination. Therefore, when a component or module is described as being configured to perform certain operations, such a configuration can be implemented, for example, by: electronic circuitry designed to perform said operations; programming programmable electronic circuitry (such as a microprocessor) to perform said operations; or any combination thereof. Processes can communicate using various technologies (including, but not limited to, conventional technologies for inter-process communication), and different pairs of processes may use different technologies, or the same pair of processes may use different technologies at different times.

[0211] Therefore, the specification and drawings are to be viewed in an illustrative rather than restrictive sense. However, it will be clear that additions, omissions, deletions, and other modifications and changes may be made therein without departing from the broader spirit and scope set forth in the claims. Thus, while specific disclosed embodiments have been described, they should not be considered limiting. Various variations and equivalents fall within the scope of the following claims.

Claims

1. A computer-implemented method, comprising: A declarative infrastructure provider is managed by a computing system configured to provide cloud infrastructure as a service. The declarative infrastructure provider is configured to provision multiple infrastructure resources within a cloud computing environment and deploy multiple artifacts to one or more of the multiple infrastructure resources. The multiple infrastructure resources are provided at least in part based on acquiring one or more virtual hosts in the cloud computing environment for use. The multiple artifacts are deployed at least in part based on newly acquired computers or virtual hosts that deploy code corresponding to one or more services to the cloud computing environment. The computing system detects a first modification to a first service, the first service being associated with at least one of the plurality of infrastructure resources, and the first service using a first distributed version control repository to perform the modification to the first service; In response to the detection of a first modification to the first service, a clone submodule of a second distributed version control repository is generated, the second distributed version control repository being associated with modifications performed on the artifacts of the second service, and the clone submodule is generated at least in part based on statements that dereference the configuration file corresponding to the first service; The computing system detects the second modification to the second service from the cloned submodule; In response to the detection of a second modification to the second service, the computing system presents the changes including the second modification to the second service via a graphical interface; The computing system receives user input, which indicates acceptance or rejection of a second modification to the second service; Infrastructure resources within a cloud computing environment are supplied by declarative infrastructure providers; as well as At least in part, based on user input indicating acceptance of a second modification to the second service, operations are performed such that a modified version of the second service, including the second modification, is deployed together with the first service to infrastructure resources supplied by the computing system.

2. The computer-implemented method of claim 1, wherein the second modification to the second service includes modifications to at least two of the implementation code, deployment instructions, or test instructions associated with the second service.

3. The computer-implemented method as described in claim 1 or 2, further comprising: Parse the configuration data associated with the first service; and The configuration data is identified as referencing a second distributed version control repository.

4. The computer-implemented method as described in claim 1 or 2, wherein the first distributed version control repository and the second distributed version control repository are git repositories, and the second service is a sidecar application.

5. The computer-implemented method of claim 1 or 2, wherein implementing the change based on user input comprises: When the user input is accepted, at least a portion of the second modification to the second service is executed within the second distributed version control repository.

6. The computer-implemented method of claim 1 or 2, wherein the user input indicates acceptance of a first portion of the second modification and rejection of a second portion of the second modification.

7. The computer-implemented method of claim 1 or 2, wherein implementing the change based on user input includes performing an operation to cause a second distributed version control repository to reference a previous version of the second service, the previous version existing prior to the second modification of the second service.

8. A system configured to provide cloud computing Infrastructure as a Service, the system comprising: One or more processors; and One or more memories store computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to: Manage a declarative infrastructure provider, which is configured to provision multiple infrastructure resources within a cloud computing environment and deploy multiple artifacts to one or more of the multiple infrastructure resources, the multiple infrastructure resources being provisioned at least in part based on acquiring one or more virtual hosts in the cloud computing environment for use, and the multiple artifacts being deployed at least in part based on deploying code corresponding to one or more services to newly acquired computers or virtual hosts in the cloud computing environment. Detect a first modification to a first service, the first service being associated with at least one of the plurality of infrastructure resources, the first service using a first distributed version control repository to perform the modification to the first service; In response to the detection of a first modification to the first service, a clone submodule of a second distributed version control repository is generated, the second distributed version control repository being associated with modifications performed on the artifacts of the second service, and the clone submodule is generated at least in part based on statements that dereference the configuration file corresponding to the first service; The detection of a second modification to the second service is based at least in part on the cloned submodule. In response to the detection of a second modification to the second service, the changes including the second modification to the second service are presented via a graphical interface; Receive user input, the user input indicating acceptance or rejection of a second modification to the second service; and Infrastructure resources within a cloud computing environment are supplied by declarative infrastructure providers; as well as At least in part, based on user input indicating acceptance of a second modification to the second service, operations are performed such that a modified version of the second service, including the second modification, is deployed together with the first service to infrastructure resources supplied by the computing system.

9. The system of claim 8, wherein the second modification to the second service includes modifications to at least two of the implementation code, deployment instructions, or test instructions associated with the second service.

10. The system of claim 8 or 9, wherein executing the computer-executable instructions further causes the one or more processors to: Parse the configuration data associated with the first service; and The configuration data is identified as referencing a second distributed version control repository.

11. The system of claim 8 or 9, wherein the first distributed version control repository and the second distributed version control repository are git repositories, and the second service is a sidecar application.

12. The system of claim 8 or 9, wherein implementing the change based on user input comprises: When the user input is accepted, at least a portion of the second modification to the second service is executed within the second distributed version control repository.

13. The system of claim 8 or 9, wherein the user input indicates acceptance of the first portion of the second modification and rejection of the second portion of the second modification.

14. The system of claim 8 or 9, wherein executing the computer-executable instructions further causes the one or more processors to implement the change based on user input, and wherein implementing the change based on user input includes performing an operation to cause a second distributed version control repository to reference a previous version of the second service, the previous version existing prior to the second modification of the second service.

15. A computer-readable storage medium storing computer-executable instructions, which, when executed by one or more processors of a computer system configured to provide cloud computing Infrastructure as a Service, cause the one or more processors to perform operations, the operations including: Manage a declarative infrastructure provider, which is configured to provision multiple infrastructure resources within a cloud computing environment and deploy multiple artifacts to one or more of the multiple infrastructure resources, the multiple infrastructure resources being provisioned at least in part based on acquiring one or more virtual hosts in the cloud computing environment for use, and the multiple artifacts being deployed at least in part based on deploying code corresponding to one or more services to newly acquired computers or virtual hosts in the cloud computing environment. Detect a first modification to a first service, the first service being associated with at least one of the plurality of infrastructure resources, the first service using a first distributed version control repository to perform the modification to the first service; In response to the detection of a first modification to the first service, a clone submodule of a second distributed version control repository is generated, the second distributed version control repository being associated with modifications performed on the artifacts of the second service, and the clone submodule is generated at least in part based on statements that dereference the configuration file corresponding to the first service; Detect the second modification to the second service from the cloned submodule; In response to detecting a second modification to the second service, present changes including the second modification to the second service; Receive user input, the user input indicating acceptance or rejection of a second modification to the second service; Infrastructure resources within a cloud computing environment are supplied by declarative infrastructure providers; as well as At least in part, based on user input indicating acceptance of a second modification to the second service, operations are performed such that a modified version of the second service, including the second modification, is deployed together with the first service to infrastructure resources supplied by the computer system.

16. The computer-readable storage medium of claim 15, wherein the second modification to the second service includes modifications to at least two of the implementation code, deployment instructions, or test instructions associated with the second service.

17. The computer-readable storage medium of claim 15 or 16, wherein executing the computer-executable instructions further causes the one or more processors to: Parse the configuration data associated with the first service; and The configuration data is identified as referencing a second distributed version control repository.

18. The computer-readable storage medium of claim 15 or 16, wherein the first distributed version control repository and the second distributed version control repository are git repositories, and the second service is a sidecar application.

19. The computer-readable storage medium of claim 15 or 16, wherein implementing the change based on user input comprises: When the user input is accepted, at least a portion of the second modification to the second service is executed within the second distributed version control repository.

20. The computer-readable storage medium of claim 15 or 16, wherein executing the computer-executable instructions further causes the one or more processors to implement the change based on user input, and wherein implementing the change based on user input includes performing an operation to cause a second distributed version control repository to reference a previous version of the second service, the previous version existing prior to the second modification of the second service.

21. An apparatus comprising means for performing the steps of the method as claimed in any one of claims 1-7.

22. A computer program product comprising computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-7.

Images