Regional Capability-Aware Proxy Testing

Abstract

A test environment for testing block configurations is provided. A configuration file of the service is parsed to identify one or more capabilities for performing a release of the configuration file of the service. The one or more capabilities correspond to an operation to be performed with respect to one or more resource types. A capability-aware proxy server included in the test environment is configured based on the one or more capabilities identified from the configuration file of the service. A release of the configuration file of the service is performed in the test environment according to the configured capability-aware proxy server. The capability-aware proxy server generates a response message corresponding to a result of performing the release of the configuration file of the service.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This PCT application claims priority to U.S. Provisional Patent Application No. 63 / 308,003, entitled "Techniques for Bootstrapping a Region Build," filed February 8, 2022, U.S. Provisional Patent Application No. 63 / 312,814, entitled "Techniques for Implementing Virtual Data Centers," filed February 22, 2022, U.S. Provisional Patent Application No. 63 / 314,776, entitled "Regional Capability Aware Proxy Testing," filed February 28, 2022, and U.S. Provisional Patent Application No. 18 / 164,116, entitled "Regional Capability Aware Proxy Testing," filed February 3, 2023, the disclosures of each of which are incorporated by reference in their entirety herein for all purposes.

[0002] FIELD OF THEINVENTION The present disclosure relates to a test environment for performing a release of a configuration file of a service. The test environment includes a capability-aware proxy server configured based on one or more capabilities identified from the configuration file of the service. The test environment performs the release of the configuration file of the service according to the capability-aware proxy server, and generates a response message corresponding to the execution result of the release of the configuration file. [Background technology]

[0003] background Currently, cloud infrastructure services use many individual services to build a datacenter (e.g., to bootstrap various resources in a datacenter in a particular geographic region). In one example, a region is a logical abstraction that corresponds to a localized geographic area in which one or more datacenters are located (or will be located). Building a datacenter can include provisioning and configuring infrastructure resources and deploying code to those resources (e.g., for various services). The actions to build a datacenter are sometimes collectively referred to as "building a region."

[0004] Service teams involved in the region building process face a challenging scenario regarding testing of individual resources deployed in a region. Specifically, the question is raised to the service team whether their services will work in a partially built region. To build a region properly, most services need to be able to address some services that are not available at the time of region building. A common challenge faced by service teams is that such environments are ephemeral and not repeatable. Thus, service teams only have one opportunity per region building to test their processes. Also, service teams involved in the region building process want to test resources as if they were releasing them into the region being built. In other words, service teams want to test resources in an on-demand manner without having to wait for other services to be successfully deployed. The embodiments described herein address the above and other issues collectively and individually. Summary of the Invention

[0005] overview The present disclosure relates to providing a test environment for simulating the testing of flock configurations. In particular, the present disclosure provides a framework for provisioning the testing of flock configurations (of regions under construction) in a seamless and time-efficient manner.

[0006] One aspect of the present disclosure provides a method, the method including parsing a configuration file of a service to identify one or more capabilities for performing a release of the configuration file of the service, the one or more capabilities corresponding to an operation performed on one or more resource types, the method further including providing a test environment for performing the release of the configuration file of the service, configuring a capability-aware proxy server included in the test environment based on the one or more capabilities identified from the configuration file of the service, performing, in the test environment, the release of the configuration file of the service according to the capability-aware proxy server configured with the one or more capabilities, and generating a response message corresponding to a result of performing the release of the configuration file of the service.

[0007] Another embodiment is directed to a cloud computing system including one or more processors and instructions that, when executed by the one or more processors, cause an orchestration service of the cloud computing system to perform the methods disclosed herein.

[0008] Yet another embodiment is directed to a non-transitory computer-readable medium storing computer-executable instructions that, when executed by one or more processors of a cloud computing system, cause an orchestration service of the cloud computing system to perform the methods disclosed herein.

[0009] The features, embodiments and advantages of the present disclosure will become better understood from the following detailed description when read in conjunction with the accompanying drawings.

[0010] To facilitate identifying the description of any particular element or act, one or more most significant digits of a reference number may refer to the figure number in which that element first appears. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram illustrating an environment in which a Cloud Infrastructure Orchestration Service (CIOS) can operate to dynamically provide bootstrap services in a region, according to at least one embodiment. [Diagram 2] FIG. 1 is a block diagram illustrating an environment and method for building a virtual bootstrap environment (ViBE) according to at least one embodiment. [Diagram 3] 1 is a block diagram illustrating an environment and method for bootstrapping a service into a target region using ViBE, according to at least one embodiment. [Figure 4] FIG. 1 is a block diagram illustrating a system for testing the release of a flock configuration, according to an embodiment. [Figure 5A] FIG. 1 illustrates a flowchart showing steps taken in testing a flock configuration, according to at least one embodiment. [Figure 5B] FIG. 2 illustrates an example log generated by a capability-aware proxy server in accordance with at least one embodiment. [Figure 6] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 7] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, in accordance with at least one embodiment. [Figure 8]FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, in accordance with at least one embodiment. [Figure 9] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, in accordance with at least one embodiment. [Figure 10] FIG. 1 is a block diagram illustrating an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] Detailed Description In the following description, for purposes of explanation, specific details are set forth in order to provide a thorough understanding of certain embodiments. It will be understood, however, that various embodiments can be practiced without these specific details. The figures and descriptions are not intended to be limiting. The term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" should not necessarily be construed as preferred or advantageous over other embodiments or designs.

[0013] Example automated data center construction (region construction) infrastructure Recently, there has been an exponential increase in the adoption of cloud services. Currently, various types of cloud services are offered by various different cloud service providers (CSPs). The term cloud service is commonly used to refer to services or functionality provided on-demand (e.g., via a subscription model) by a CSP to a user or customer using systems and infrastructure (cloud infrastructure) provided by the CSP. Typically, the servers and systems that make up the CSP's infrastructure and that are used to provide cloud services to customers are separate from the customer's own on-premise services and systems. Thus, customers can utilize cloud services provided by the CSP without having to purchase separate hardware and software resources for the service. Cloud services are designed to provide subscribing customers with easy, scalable, on-demand access to applications and computing resources without the customer having to invest in procuring the infrastructure used to provide the service or functionality. Various different types or models of cloud services may be offered, such as Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), Infrastructure-as-a-Service (IaaS), etc. A customer may subscribe to one or more cloud services offered by a CSP. A customer may be any entity, such as an individual, an organization, or a business.

[0014] As mentioned above, a CSP is responsible for providing the infrastructure and resources used to provide cloud services to its subscribing customers. The resources provided by the CSP may include both hardware and software resources. These resources may include, for example, computational resources (e.g., virtual machines, containers, applications, processors), memory resources (e.g., databases, data stores), networking resources (e.g., routers, host machines, load balancers), identity and other resources. In one implementation, the resources provided by the CSP to provide a set of cloud services CSPs are organized as a data center. A data center can be configured to provide a particular set of cloud services. The CSP is responsible for equipping the data center with the infrastructure and resources used to provide that particular set of cloud services. A CSP may build one or more data centers.

[0015] Data centers offered by a CSP can be hosted in different regions. A region is a localized geographic area and can be identified by a region name. Regions are generally independent of each other and can be separated by great distances, such as across multiple countries or even continents. Regions are grouped into realms. Examples of CSP regions can include US West, US East, Australia East, Australia Southeast, etc.

[0016] A region may include one or more data centers, and the data centers may be located within a geographic area corresponding to the region. As an example, the data centers in a region may be located in a city within the region. For example, for a particular CSP, a data center in the US West region may be located in San Jose, California, a data center in the US East region may be located in Ashburn, Virginia, a data center in the Australia East region may be located in Sydney, Australia, a data center in the Australia Southeast region may be located in Melbourne, Australia, etc.

[0017] Data centers within a region can be organized into one or more availability domains, which are used for high availability and disaster recovery purposes. An availability domain can contain one or more data centers within a region. Availability domains within a region are isolated from each other, fault tolerant, and designed in a manner that makes it highly unlikely that data centers in multiple availability domains will fail simultaneously. For example, availability domains within a region can be built in a manner that makes it highly unlikely that a failure in one availability domain within a region will affect the availability of data centers in other availability domains in the same region.

[0018] When a customer or subscriber subscribes or signs up for one or more services offered by a CSP, the CSP creates a tenancy for that customer. A tenancy is like an account created for a customer. In one implementation, a customer's tenancy exists in a single realm and has access to all regions that belong to that realm. The customer's users can then access the services to which the customer subscribes under this tenancy.

[0019] As described above, a CSP builds or deploys a data center to provide cloud services to the CSP's customers. As the CSP's customer base grows, the CSP typically builds a new data center in a new region or expands the capacity of an existing data center to accommodate the growing demand of the customers and to better serve the customers. Preferably, the data center is built in close geographic proximity to the location of the customers served by the data center. The geographical proximity of a data center to the customers served by the data center facilitates more efficient use of resources and faster and more reliable service to the customers. Thus, a CSP typically builds a new data center in a new region in a geographic area that is geographically close to the customers served by the data center. For example, for a growing customer base in Germany, the CSP may build one or more data centers in a new region in Germany.

[0020] Building a data center (or multiple data centers) in a region may also be referred to as building a region. The term "region construction" is used to refer to building one or more data centers in a region. Building a data center in a region involves provisioning or creating a new set of resources that are needed or used to provide the set of services that the data center is configured to provide. The end result of the region construction process is the creation of a data center in the region that is capable of providing the set of services targeted to that data center and includes the set of resources used to provide the set of services.

[0021] Building a new data center in a region is a highly complex task that requires extensive coordination between various bootstrapping activities. Broadly speaking, it requires the execution and coordination of various tasks, such as identifying the set of services to be provided by the data center, identifying the various resources required to provide the set of services, creating, provisioning and deploying the identified resources, and properly connecting the resources so that they can be used in the intended manner. Each of these tasks has further subtasks that require coordination, which further increases the complexity. Due to this complexity, currently, building a data center in a region involves several manual initiation or manual control tasks that require careful manual coordination. As a result, the task of building a new region (i.e., building one or more data centers in a region) is very time-consuming. It can take time, for example, several months, to build a data center. Moreover, this process is highly error-prone and may require several re-runs before the desired configuration of the data center is achieved, thereby further increasing the time required to build the data center. These limitations and problems significantly limit the ability of CSPs to scale computing resources in a timely manner to meet growing customer needs.

[0022] The present disclosure describes techniques for reducing build times, reducing wasted computing resources, and reducing risk associated with building one or more data centers in a region. Using the techniques described herein, new data centers can be built in a region in a relatively much shorter time than the weeks and months required to build a data center in a traditional region, while reducing the risk of errors over traditional approaches. Additionally, embodiments of the present disclosure provide a mechanism for seamless testing of releases of configuration files in a test environment. Thus, testing can be performed prior to the actual region build to ensure that various configuration files are properly executed.

[0023] Disclosed herein is a cloud infrastructure orchestration service (CIOS) configured to bootstrap (e.g., provision and deploy) services to a new datacenter based on a predefined configuration file that identifies resources (e.g., infrastructure components and software to be deployed) to implement a given change to the datacenter. The CIOS can parse and analyze the configuration file (e.g., flock config) to identify dependencies between resources, execution targets, phases, and flocks. The CIOS can generate specific data structures from the analysis and can use these data structures to drive operations and to manage the order in which services are bootstrapped into regions. The CIOS can use these data structures to identify when the CIOS can bootstrap services, when bootstrapping is blocked, and / or when bootstrapping operations associated with previously blocked services can be resumed. Advantageously, the CIOS can identify circular dependencies in the data structures and perform operations to remove / resolve those circular dependencies prior to task execution. Using these techniques, the CIOS substantially reduces the risk of executing tasks before the resources they depend on are available.

[0024] Using the techniques disclosed herein, CIOS can optimize the parallelism of executing changes to datacenters while ensuring that tasks are not initiated until the functionality they depend on is available in the region. In this way, CIOS allows region construction to be performed more efficiently, thereby significantly reducing the time it takes to construct a datacenter and the wasted computing resources seen in traditional approaches.

[0025] Certain definitions A "region" is a logical abstraction that corresponds to a geographic location. A region may include any suitable number of one or more execution targets. In an embodiment, an execution target may correspond to a data center.

[0026] An "Execution Target" is the smallest unit of change for executing a release. A "Release" is an expression of intent to orchestrate a particular change to a service (e.g., deploy version 8, "add internal DNS record", etc.). For most services, an execution target represents an "instance" of the service. A single service can be bootstrapped onto one or more execution targets each. An execution target can be associated with a set of devices (e.g., a data center).

[0027] "Bootstrapping" is intended to refer to the collective tasks associated with the provisioning and deployment of any suitable number of resources (e.g., infrastructure components, artifacts, etc.) that correspond to a single service.

[0028] "Service" refers to functionality provided by a set of resources. The set of resources for a service includes any suitable combination of infrastructure, platform, or software (e.g., applications) hosted by a cloud provider that can be configured to provide the functionality of the service. Services can be provided to users over the Internet.

[0029] "Artifact" refers to infrastructure components or code that is deployed to a Kubernetes engine cluster, which may include software (e.g., applications), configuration information for infrastructure components (e.g., configuration files), etc.

[0030] "Flock config" refers to a configuration file (or set of configuration files) that describes the set of all resources (e.g., infrastructure components and artifacts) associated with a single service. A Flock config may contain declarative statements that specify one or more aspects that correspond to a desired state of the service's resources.

[0031] "Service State" refers to a point-in-time snapshot of all resources (e.g., infrastructure resources, artifacts, etc.) associated with a service. The service state indicates the situation corresponding to the provisioning and / or deployment tasks associated with the service resources.

[0032] IaaS provisioning (or "provisioning") refers to obtaining a computer or virtual host for use and installing the necessary libraries or services on it. The phrase "provisioning a device" refers to making a device available for use by an end user for a specific use. A device that has undergone the provisioning process may be called a "provisioned device." Preparing a provisioned device (installing libraries and daemons) may be part of provisioning. This preparation is distinct from deploying a new application or a new version of an application to a prepared device. In most cases, deployment does not include provisioning, which may need to be done first. After preparation, the device may be called an "infrastructure component."

[0033] IaaS deployment (or "deployment") refers to the process of providing and / or installing an application or a new version of an application onto provisioned infrastructure components. After the infrastructure components are provisioned (e.g., acquired, allocated, prepared, etc.), additional software can be deployed (e.g., provisioned and installed onto the infrastructure components). After provisioning and deployment are complete, the infrastructure components can be referred to as "resources." Examples of resources can include, but are not limited to, virtual machines, databases, object storage, block storage, load balancers, etc.

[0034] A "capability" identifies a unit of functionality associated with a service. A unit may be some or all of the functionality provided by a service. For example, a capability may be exposed that indicates that a resource is available for authorization / authentication processing (e.g., a subset of the functionality provided by the resource). As another example, a capability may be exposed that indicates that the full functionality of the service is available. Capabilities may be used to identify functionality on which a resource or service depends and / or functionality of the resource or service that is available for use.

[0035] A "virtual bootstrap environment" (ViBE) refers to a virtual cloud network that is provisioned in an overlay (e.g., a "host region") of an existing region. Once provisioned, the ViBE is connected to the new region using a communication channel (e.g., an IPSec tunnel VPN). Certain important core services (or "seed" services) can be provisioned in the ViBE, such as a deployment orchestrator, public key infrastructure (PKI) services, etc. These services can provide the capabilities required to bring the hardware online, establish a chain of trust to the new region, and deploy the remaining services in the new region. The use of a virtual bootstrap environment can prevent circular dependencies between bootstrap resources by using resources in the host region. Services can be staged and tested in the ViBE before the physical region (e.g., the target region) is available.

[0036] "Cloud Infrastructure Orchestration Services" (CIOS) may refer to a system configured to manage the provisioning and deployment operations of any suitable number of services as part of a region construction.

[0037] A Multi-Flock Orchestrator (MFO) can be a computing component (e.g., services) that coordinates events among components of the CIOS to provision and deploy services to a target region (e.g., a new region). The MFO tracks relevant events for each service in the region build and takes actions in response to those events.

[0038] "Host Region" refers to a region that hosts a Virtual Bootstrap Environment (ViBE). A host region can be used to bootstrap a ViBE.

[0039] "Target region" refers to the region being constructed. "Exposing a capability" refers to providing an indication that a particular capability is available (or unavailable), through "publishing" as used in "publisher-subscriber" computing design, or otherwise. Capabilities are "exposed" (e.g., collected by a capability service, provided to a capability service, pushed, pulled, etc.) to provide an indication that functionality of a resource / service is available. In one embodiment, capabilities can be exposed / transmitted via events, notifications, data submissions, function calls, API calls, etc. An event (or other notification / data submission, etc.) indicating availability of a particular capability can be broadcast / addressed (e.g., published) to the capability service.

[0040] A "capability service" can be a configured flock that models dependencies between different flocks. Capability services can be provided within a cloud infrastructure orchestration service and can define what capabilities, services, and features are made available in a region.

[0041] A "Real-time Regional Data Distributor" (RRDD) can be a service or system configured to manage regional data that can be populated into a flock config to dynamically create execution targets for new regions.

[0042] Described herein, in certain examples, are techniques for implementing a cloud infrastructure orchestration service (CIOS). Such techniques are configurable to manage the bootstrapping (e.g., provisioning and deployment of software to infrastructure components) in a cloud environment (e.g., a region), as briefly described above. In some cases, the CIOS may include computing components (e.g., CIOS central and CIOS regional, both of which are described in more detail below) that are configurable to manage the bootstrapping tasks (provisioning and deployment) for a given service and a multi-flock orchestrator (also described in more detail below) that is configured to initiate / manage a region build (e.g., a bootstrapping operation corresponding to multiple services).

[0043] CIOS enables region construction and worldwide infrastructure provisioning and code deployment with minimal manual run-time effort from service teams (e.g., beyond initial approval and / or physical transport of hardware, in some cases). High-level responsibilities of CIOS include, but are not limited to, coordinating region construction, providing users with a view of the current state of resources managed by CIOS (e.g., in a region, across multiple regions, worldwide, etc.), and managing bootstrapping operations for bootstrapping resources within a region.

[0044] CIOS can provide view reconciliation, where a view of a desired state of a resource (e.g., a desired configuration) can be matched with the current / actual state of the resource (e.g., a current configuration). In some cases, view reconciliation can include obtaining state data to determine what resources are actually running and the current configuration and / or state of the resource. Reconciliation can occur at various granularities, such as at the service level.

[0045] The CIOS may perform plan generation, where differences between desired and current states of resources are identified. Part of plan generation may include identifying actions that would need to be performed to bring resources from their current state to the desired state. In some examples, the CIOS may present the generated plan to a user for approval. In these examples, the CIOS may mark the plan as approved or rejected based on user input from the user. Thus, because the plan is generated by a machine, the user may spend less time making judgments about the plan, and the plan may be more accurate. Although the plan is too detailed for human use, the CIOS may provide this data via an advanced user interface (UI).

[0046] In one example, the CIOS can handle change control execution by executing the approved plan. Once an execution plan has been created and approved, engineers may not need to be involved in change control unless the CIOS initiates a rollback. The CIOS can handle rollbacks to a previous service version by generating a plan to return the service to a previous (e.g., pre-release) state (e.g., if the CIOS detects a deterioration in the service health (operational) state during execution).

[0047] CIOS can measure service health by monitoring alarms and running integration tests. CIOS can help teams quickly define rollback actions in case of service degradation, and CIOS can execute them. CIOS can generate and display plans, and track approvals. CIOS can combine provisioning and deployment functions into a single system that coordinates these tasks across region construction. CIOS also supports discovery of flocks (e.g., service resources such as flock configs corresponding to any suitable number of services), artifacts, resources, and dependencies. CIOS can discover dependencies between execution tasks at any level (e.g., resource level, execution target level, phase level, service level, etc.) by static analysis (e.g., including content parsing and processing) of one or more configuration files. Using these dependencies, CIOS can generate various data structures that can be used to drive task execution (e.g., tasks related to infrastructure resource provisioning and artifact deployment across regions) from these dependencies.

[0048] FIG. 1 is a block diagram of an environment 100 in which a cloud infrastructure orchestration (CIOS) 102 can operate to dynamically provide bootstrap services in a region, according to at least one embodiment. CIOS 102 can include, but is not limited to, the following components: a real-time regional data distributor (RRDD) 104, a multi-flock orchestrator (MFO) 106, a CIOS central 108, a CIOS regional 110, and a capability service 112. The specific functions of CIOS central 108 and CIOS regional 110 are described in more detail in U.S. patent application Ser. No. 17 / 016,754, entitled "Techniques for Deploying Infrastructure Resources with a Declarative Provisioning Tool," which is incorporated in its entirety for all purposes. In an embodiment, any suitable combination of the components of CIOS 102 can be provided as a service. In an embodiment, a portion of CIOS 102 can be deployed to a region (e.g., a data center represented by host region 103). In one embodiment, CIOS 102 may include any suitable number of cloud services (not shown in FIG. 1), as described in more detail in U.S. patent application Ser. No. 17 / 016,754 and with respect to FIGS. 2 and 3 below.

[0049] The real-time regional data distributor (RRDD) 104 can be configured to maintain and provide regional data that identifies realms, regions, execution targets, and availability domains. In some cases, the regional data can be in any suitable form (e.g., JSON format, data object / container, XML, etc.). The regional data maintained by the RRDD 104 can include any suitable number of subsets of data that can be individually referenced by a corresponding identifier. For example, an identifier "all_regions" can be associated with a data structure (e.g., a list, structure, object, etc.) that includes metadata for all defined regions. As another example, an identifier such as "realms" can be associated with a data structure that identifies metadata for a number of realms and a set of regions that correspond to each realm. In general, the regional data can maintain any suitable attributes, such as identifiers, DNS suffixes, state (e.g., region state), etc., for one or more realms, regions, availability domains (ADs), execution targets (ETs), etc. The RRDD 104 can be configured to manage regional state as part of the regional data. The regional state can include any suitable information indicative of the state of bootstrap in the region. For example, some example region states may include "initial," "under construction," "production," "suspended," or "to be decommissioned." The "initial" state may indicate a region that has not yet been bootstrapped. The "under construction" state may indicate that bootstrap of one or more flocks in the region has begun. The "production" state may indicate that bootstrap is complete and the region is ready for validation. The "suspended" state may indicate that CIOS Central 108 or CIOS Regional 110 has suspended internal interaction with the regional stack, possibly due to operational issues. The "decommissioned" state may indicate that the region has been decommissioned and is likely unavailable and / or will not be contacted again in the future.

[0050] CIOS central 108 may be configured to provide any suitable number of user interfaces through which a user (e.g., user 109) may interact with CIOS 102. For example, a user may make changes to region data through a user interface provided by CIOS central 108. CIOS central 108 may further provide various interfaces that allow a user to view changes made to flock configurations and / or artifacts, generate and view plans, approve / reject plans, and view the status of plan execution (e.g., corresponding to tasks involving infrastructure provisioning, deployment, region construction, and / or the desired state of any suitable number of resources managed by CIOS 102). CIOS central 108 may implement a control plane that may be configured to manage any suitable number of CIOS regional 110 instances. CIOS central 108 may provide one or more interfaces for presenting region data, thereby allowing user 109 to view and / or modify the region data. CIOS central 108 may be configured to invoke functions of RRDD 104 through any suitable number of interfaces. In general, CIOS central 108 can be configured to manage region data, either directly or indirectly (e.g., via RRDD 104). CIOS central 108 can be configured to edit the flock config to populate the region data as variables in the flock config.

[0051] Each instance of CIOS regional 110 may correspond to a module configured to perform bootstrapping tasks associated with a single service of the region. CIOS regional 110 may receive desired state data from CIOS central 108. In one embodiment, the desired state data may include a flock config that declares (e.g., by declarative statements) a desired state of resources associated with the service. CIOS central 108 may maintain current state data that indicates any suitable aspect of the current state of resources associated with the service. In one embodiment, CIOS regional 110 may identify that changes need to be made to one or more resources by comparing the desired state data to the current state data. For example, CIOS regional 110 may determine that one or more infrastructure components need to be provisioned, one or more artifacts need to be deployed, or any suitable changes need to be made to the resources of the service to match the desired state. When CIOS regional 110 performs a bootstrap operation, it may expose data that indicates various capabilities of the resources as the capabilities become available. A "capability" identifies a unit of functionality associated with a service. A unit may be some or all of the functionality provided by a service. For example, a capability may be exposed to indicate that a resource is available for authorization / authentication processing (e.g., a subset of the functionality provided by the resource). As another example, a capability may be exposed to indicate that the full functionality of a service is available. Capabilities may be used to identify functionality on which a resource or service depends and / or functionality of the resource or service that is available for use.

[0052] The capability service 112 is configured to maintain capability data that indicates: 1) what capabilities of various services are currently available; 2) whether any resources / services are waiting for a particular capability; 3) what particular resources and / or services are waiting for a given capability; or any suitable combination of the above. The capability service 112 may provide an interface through which the capability data may be requested. The capability service 112 may provide one or more interfaces (e.g., application programming interfaces) that enable the capability service 112 to send capability data to the MFO 106 and / or the CIOS regional 110 (e.g., each instance of the CIOS regional 110). In an embodiment, any suitable component or module of the MFO 106 and / or the CIOS regional 110 may be configured to request the capability data from the capability service 112.

[0053] In one embodiment, a multi-flock orchestrator (MFO) 106 can be configured to drive region construction activities. In one embodiment, the MFO 106 can manage information describing what flocks / flock config versions and / or artifact versions to use to bootstrap a given service in a region (or to make a unit of change to a target region). In one embodiment, the MFO 106 can be configured to monitor (or otherwise be notified of) changes to the region data managed by the real-time regional data distributor 104. In one embodiment, region construction may be triggered by the MFO 106 upon receiving an indication that the region data has changed. In one embodiment, the MFO 106 may collect various flock configs and artifacts used in region construction. Some or all of the flock configs can be configured to be region agnostic. That is, the flock configs may not explicitly specify which flocks are to be bootstrapped into which regions. In one embodiment, the MFO 106 can trigger a data population process whereby the collected flock configs are recompiled (e.g., by the CIOS Central 108). During recompilation, operations may be performed (e.g., by the CIOS Central 108) to cause the region data maintained by the real-time regional data distributor 104 to be populated into the configuration files. The flock configs can reference the region data by variables / parameters, without requiring a hard-coded identity of the region data. The flock configs can use this data population to be dynamically modified at run time, without having the region data hard-coded and therefore more difficult to change.

[0054] The multi-flock orchestrator 106 may perform static flock analysis, in which the flock config is parsed to identify dependencies between resources, execution targets, phases, and flocks, specifically to identify circular dependencies that need to be removed. In an embodiment, the MFO 106 may generate any suitable number of data structures based on the identified dependencies. These data structures (e.g., directed acyclic graphs, linked lists, etc.) may be used by the cloud infrastructure orchestration service 102 to drive operations to perform region construction. For example, these data structures may collectively define the order in which services are bootstrapped within a region. Examples of such data structures are discussed in more detail below in connection with the construction dependency graph 338 of FIG. 3. If circular dependencies (e.g., service A requires service B and vice versa) exist and are identified by the static flock analysis and / or graph, the MFO may be configured to notify any appropriate service teams that changes need to be made to the corresponding flock config to correct these circular dependencies. The MFO 106 may be configured to traverse one or more data structures to manage the order in which services are bootstrapped into regions. The MFO 106 can identify capabilities available within a given region at any given time (e.g., using data obtained from the capabilities service 112). The MFO 106 can use this data to identify when the MFO 106 can bootstrap a service, when bootstrap is blocked, and / or when a bootstrap operation associated with a previously blocked service can be resumed. Based on this scanning, the MFO 106 can perform various releases in which instructions are sent by the MFO 106 to the CIOS central 108 to perform bootstrap operations corresponding to any suitable number of block configurations.In one example, the MFO 106 can be configured to identify that one or more flock configs may require multiple releases due to circular dependencies found in the graph, and as a result, the MFO 106 can send multiple sets of instructions to the CIOS central 108 for a given flock config to break the circular dependencies identified in the graph.

[0055] In one embodiment, a user may request that a new region (e.g., target region 114) be built. This may involve bootstrapping resources corresponding to various services. In one embodiment, the target region 114 may not be available for communication (and / or may not be secure) at the time the region build request is issued. Rather than deferring bootstrapping until the target region 114 is available and configured to perform the bootstrapping operation, CIOS 102 may initiate region build using a virtual bootstrap environment 116. The virtual bootstrap environment (ViBE) 116 may be an overlay network hosted by the host region 103 (an existing region that has previously been configured with a core set of services, is available for communication, and is secure). The MFO 106 may utilize the resources of the host region 103 to bootstrap resources to the ViBE 116 (commonly referred to as "building the ViBE"). For example, MFO 106 can provide instructions via CIOS central 108 to cause an instance of CIOS regional 110 in a host region (e.g., host region 103) to bootstrap another instance of CIOS regional in ViBE 116. After the CIOS regional in ViBE is available for processing, bootstrapping of services for the target region 114 can continue in ViBE 116. Services previously bootstrapped in ViBE 116 can be migrated to the target region 114 when the target region 114 is available to perform the bootstrap operation. Using these techniques, CIOS 102 can greatly increase the speed at which regions are built by greatly reducing the need for manual input and / or configuration to be provided.

[0056] 2 is a block diagram illustrating an environment 200 and method for building a virtual bootstrap environment (ViBE) 202 (an example of ViBE 116 of FIG. 1) according to at least one embodiment. ViBE 202 represents a virtual cloud network that is provisioned in an overlay of an existing region (e.g., hosted region 204, which is an example of hosted region 103 of FIG. 1 and in one embodiment is a hosted region service enclave). ViBE 202 represents an environment in which services can be staged for a target region (e.g., a region under construction, such as target region 114 of FIG. 1) before the target region is available.

[0057] To bootstrap a new region (e.g., target region 114 in FIG. 1), a core set of services can be bootstrapped. These core set of services exist in the host region 204 but do not yet exist in ViBE (nor in the target region). These basic core services provide the functionality required for provisioning devices, establishing a chain of trust to the new region, and deploying the remaining services (e.g., flocks) to the region. ViBE 202 may be a tenancy that is deployed in the host region 204. This can be thought of as a virtual region.

[0058] When the target region is available to provide the bootstrap operations, ViBE 202 can be connected to the target region such that services in the ViBE can interact with services and / or infrastructure components of the target region. This allows for the deployment of production-level services instead of a self-contained seed service as in previous systems, which would require connectivity over the Internet to the target region. Traditionally, a seed service would be deployed as part of a container collection and used to bootstrap the dependencies required to build the region. Using the existing region's infrastructure / tooling, resources can be bootstrapped (e.g., provisioned and deployed) to ViBE 202 until the target region is self-sufficient and can communicate directly, and it can connect to the service enclaves of the region (e.g., host region 204) to provision hardware and deploy services. The use of ViBE 202 allows for the maintenance of dependencies and services required to be able to provision / prepare infrastructure and deploy software while utilizing the host region's resources to break circular dependencies for core services.

[0059] A multi-flock orchestrator (MFO) 206 can be configured to perform operations to build (e.g., configure) ViBE 202. The MFO 206 can obtain appropriate flock configs corresponding to the various resources to be bootstrapped into a new region (in this case, the ViBE region, ViBE 202). For example, the MFO 206 can obtain a flock config (e.g., a "ViBE flock config") that specifies aspects of the bootstrap of capability services 208 and workers 210. As another example, the MFO 206 can obtain another flock config corresponding to the bootstrap of domain name services (DNS) 212 into ViBE 202.

[0060] In step 1, MFO 206 can instruct CIOS central 214 (e.g., an example of CIOS central 108 and CIOS central 214 of FIGS. 1 and 2, respectively). For example, MFO 206 can send a request (e.g., including a ViBE flock config) to request bootstrap of capability services 208 and workers 210 that do not yet exist in ViBE 202 at this point. In one embodiment, CIOS 214 has access to all flock configs. Thus, in one example, MFO 206 can send an identifier for a ViBE flock config rather than the file itself, and CIOS central 214 can retrieve it independently from storage (e.g., from DB 308 or Flock DB 312 of FIG. 3).

[0061] In step 2, CIOS central 214 can provide the ViBE Flock Config via a corresponding request to CIOS regional 216. CIOS regional 216 can parse the ViBE Flock Config to identify and execute specific infrastructure provisioning and deployment operations in step 3.

[0062] In one embodiment, CIOS regional 216 can use additional corresponding services for provisioning and deployment. For example, in step 4, CIOS regional 216 can instruct deployment orchestrator 218 (e.g., an example of a core service or other creation, build and deployment application software in host region 204) to execute instructions to bootstrap capability service 208 and worker 210 within ViBE 202.

[0063] In step 5, a capability may be sent to capability service 208 (from CIOS regional 216, deployment orchestrator 218 via worker 210, or otherwise) indicating that resources corresponding to the ViBE block are available. Capability service 208 may maintain this data. In one embodiment, capability service 208 adds this information to a list of available capabilities that capability service 208 maintains with ViBE. For example, the capability provided to capability service 208 in step 5 may indicate that capability service 208 and worker 210 are available for processing.

[0064] In step 6, the MFO 206 can determine that the capability service 208 and the worker 210 are available based on receiving or obtaining data (identifiers corresponding to capabilities) from the capability service 208.

[0065] In step 7, as a result of receiving / obtaining the data in step 6, MFO 206 can instruct CIOS Central 214 to bootstrap a DNS service (e.g., DNS 212) into ViBE 202. These instructions may specify or include a particular block config that corresponds to the DNS service.

[0066] In step 8, CIOS Central 214 can instruct CIOS Regional 216 to deploy DNS 212 to ViBe 202. In one embodiment, the DNS block config for DNS 212 is provided by CIOS Central 214.

[0067] In step 9, now that worker 210 is deployed to ViBE 202, worker 210 can be assigned by CIOS regional 216 to the task of deploying DNS 212. The worker can run a declarative infrastructure provisioner in the manner described above in connection with FIG. 3 to identify the set of operations that need to be performed to deploy DNS 212 (e.g., by comparing the flock config (desired state) with the current state of the resources associated with the flock (which currently do not exist)).

[0068] At step 10, deployment orchestrator 218 instructs worker 210 to deploy DNS 212 according to the actions identified at step 9. As shown, worker 210 proceeds to perform the actions to deploy DNS 212 to ViBE 202 at step 11. At step 12, worker 210 notifies capability service 208 that DNS 212 is available on ViBE 202. MFO 206 then determines that resources associated with the ViBE flock config and the DNS flock config are available, and any suitable number of additional resources can subsequently be bootstrapped into ViBE.

[0069] After steps 1 through 12 are completed, the process for building ViBE202 may be considered complete, and ViBE202 may be considered built.

[0070] FIG. 3 is a block diagram illustrating an environment 300 and method for bootstrapping a service into a target region using ViBE, according to at least one embodiment.

[0071] In step 1, a user 302 can use any suitable user interface provided by CIOS central 304 (e.g., an example of CIOS central 108 and CIOS central 214 of FIGS. 1 and 2, respectively) to modify region data. For example, a user 302 can create a new region into which several services are bootstrapped.

[0072] In step 2, CIOS central 304 may perform an operation to send the changes to RRDD 306 (e.g., an example of RRDD 104 in FIG. 1). In step 3, RRDD 306 may store the received region data in database 308, which is a data store configured to store region data including any suitable identifiers, attributes, states, etc., such as region, AD, realm, ET, etc. In one embodiment, updater 307 may be used to store the region data in database 308 or any suitable data store from which the updates may be accessible (by a service team). In one embodiment, updater 307 may be configured to notify (e.g., by any suitable electronic notification) of updates made to database 308.

[0073] In step 4, the MFO 310 (e.g., an example of the MFO 106 and MFO 206 of FIGS. 1 and 2, respectively) may detect the change in the region data. In one embodiment, the MFO 310 may be configured to poll the RRDD 306 for changes in the region data. In one embodiment, the RRDD 306 may be configured to publish or otherwise notify the MFO 310 of the region change.

[0074] In step 5, detection of a change in region data can trigger MFO 310 to retrieve a version set (e.g., a version set associated with a particular identifier, such as a "golden version set" identifier) ​​that identifies the specific version of each flock (e.g., service) to be bootstrapped into the new region and the specific version of each artifact corresponding to that flock. The version set can be retrieved from DB 312. As a flock evolves and changes, the corresponding config and artifact versions used for region construction can change. These changes can be maintained in flock DB 312 so that MFO 310 can identify which versions of flock config and artifacts to use for construction of the region (e.g., ViBE region, target region / non-ViBE region, etc.). Flock configs (e.g., all versions of flock configs) and / or artifacts (e.g., all versions of artifacts) can be stored in DB 308, DB 312, or any suitable data store accessible to CIOS Central 304 and / or MFO 310.

[0075] In step 6, MFO 310 can request CIOS Central 304 to recompile each of the flock configs associated with the version set with the current region data. In one embodiment, the request can indicate the version of each flock config and / or artifacts that correspond to those flock configs.

[0076] In step 7, CIOS Central 304 can obtain the current regional data from DB 308 (e.g., directly or via real-time regional data distributor 306) and retrieve any appropriate flock configurations and artifacts according to the version requested by MFO 310.

[0077] In step 8, CIOS central 304 can re-edit the flock config with the region data obtained in step 7 to populate the flock config with the current region data. CIOS central 304 can return the edited flock config to MFO 310. In one embodiment, CIOS central 304 can simply indicate that the edit is complete, and MFO 310 can access the re-edited flock config via RRDD 306.

[0078] In step 9, the MFO 310 may perform a static analysis of the recompiled flock config. As part of the static analysis, the MFO 310 may parse the flock config (e.g., using libraries associated with a declarative infrastructure provisioner (e.g., Terraform, etc.)) to identify dependencies between flocks. From this analysis and the identified dependencies, the MFO 310 may generate a build dependency graph 338. The build dependency graph 338 may be an acyclic directed graph that specifies the order in which flocks are bootstrapped (and / or changes indicated in the flock config are applied) into new regions. Each node in the graph may correspond to the bootstrap of any appropriate portion of a particular flock. A particular bootstrap order may be specified based at least in part on the dependencies. In an embodiment, the dependencies may be represented as attributes of the nodes and / or may be indicated by the edges of the graph connecting the nodes. The MFO 310 may traverse the graph (e.g., starting from the origin node) to drive the operation of region construction.

[0079] In an embodiment, MFO 310 can use a cycle detection algorithm to detect the presence of a cycle (e.g., service A depends on service B and vice versa). MFO 310 can identify orphan capability dependencies. For example, MFO 310 can identify an orphan node in construction dependency graph 338 that does not connect to any other node. MFO 310 can identify a capability that was published in error (e.g., when a capability is published prematurely and the corresponding functionality is not actually available yet). MFO 310 can detect from the graph that there are one or more instances of publication of the same capability. In an embodiment, any suitable number of such errors can be detected, and MFO 310 (or another suitable component, such as CIOS Central 304) can be configured to notify or otherwise present this information to a user (e.g., via an electronic notification, a user interface, etc.). In one embodiment, MFO 310 may be configured to force delete / recreate resources to break circular dependencies and may redirect CIOS Central 304 to perform bootstrap operations for those resources and / or the corresponding block configs.

[0080] The starting node may correspond to bootstrapping the ViBE flock, and the second node may correspond to bootstrapping the DNS. Steps 10-15 correspond to deployment (by deployment orchestrator 317, which is an example of deployment orchestrator 218 in FIG. 2) of the ViBE flock to ViBE 316 (e.g., an example of ViBE 116 and ViBE 202 in FIG. 1 and FIG. 2, respectively). That is, steps 10-15 of FIG. 3 generally correspond to steps 1-6 of FIG. 2. After being notified that capabilities exist corresponding to the ViBE flock to be deployed (e.g., indicating that capability service 318 and worker 320, which correspond to capability service 208 and worker 210 in FIG. 2, are available), MFO 310 resumes traversing build dependency graph 338 to identify the next operation to perform.

[0081] For example, MFO 310 may continue traversing construction dependency graph 338 to identify that a DNS block should be deployed. Steps 16-21 may be performed to deploy DNS 322 (an example of DNS 212 in FIG. 2). These operations may generally correspond to steps 7-12 in FIG. 2.

[0082] At step 21, a capability indicating that DNS 322 is available may be stored. Upon detecting this capability, MFO 310 may resume traversing build dependency graph 338. During this traversal, MFO 310 may identify that any appropriate portions of an instance of CIOS Regional (e.g., an instance of CIOS Regional 314) should be deployed to ViBE 316. In one embodiment, steps 16-21 may be substantially repeated with respect to the deployment of CIOS Regional (ViBE) 326 (an instance of CIOS Regional 314, CIOS Regional 110 in FIG. 1) and Worker 328 to ViBE 316. A capability that CIOS Regional (ViBE) 326 is available may be sent to capability service 318.

[0083] Upon detecting that CIOS Regional (ViBE) 326 is available, MFO 310 may resume traversing build dependency graph 338. During this traversal, MFO 310 may identify that a deployment orchestrator (e.g., deployment orchestrator 330, which is an example of deployment orchestrator 317) is deployed to ViBE 316. In one embodiment, steps 16-21 may be substantially repeated for the deployment of deployment orchestrator 330. Information may be sent to capability service 318 identifying capabilities indicating that deployment orchestrator 330 is available.

[0084] After the deployment orchestrator 330 is deployed, ViBE 316 can be considered available to process subsequent requests. Upon detecting that the deployment orchestrator 330 is available, MFO 310 can instruct that subsequent bootstrap requests are routed to the ViBE component without using the host region component (the component of the host region 332). Thus, MFO 310 can continue to traverse the build dependency graph 338 and at each node, instruct flock deployment to ViBE 316 via CIOS Central 304. CIOS Central 304 can request CIOS Regional (ViBE) 326 to deploy resources according to the flock configuration.

[0085] At some point during this process, the target region 334 may become available. An indication that the target region is available may be identifiable from region data for the target region 334 provided by the user 302 (e.g., as an update to the region data). The availability of the target region 334 may depend on the establishment of a network connection between the target region 334 and an external network (e.g., the Internet). The network connection may be supported over a public network (e.g., the Internet), but software security measures (e.g., IPSec) may be used to provide one or more encrypted tunnels (e.g., IPSec tunnels such as tunnel 336) from ViBE 316 to the target region 334. As used herein, "IPSec" refers to a protocol suite for authentication and encryption of network traffic over networks using the Internet Protocol (IP) and may include one or more available implementations of the protocol suite (e.g., Openswan, Libreswan, strongSwan, etc.). The network may connect ViBE 316 to a service enclave of the target region 334.

[0086] Prior to establishing the IPSec tunnel, the initial network connectivity to the target region 334 may be on a sufficient connection (e.g., an out-of-band VPN tunnel) to allow bootstrapping of networking services until an IPSec gateway can be deployed on an asset (e.g., a bare metal asset) in the target region 334. To bootstrap the network resources of the target region 334, the deployment orchestrator 330 can deploy an IPSec gateway on the asset in the target region 334. The deployment orchestrator 330 can then deploy a VPN host in the target region 334 configured to terminate the IPSec tunnel from ViBE 316. After a service in ViBE 316 (e.g., deployment orchestrator 330, service A, etc.) can establish an IPsec connection with a VPN host in the target region 334, the bootstrapping operation from ViBE 316 to the target region 334 can begin.

[0087] In an embodiment, the bootstrap operation may begin with a service in ViBE 316 provisioning resources in the target region 334 to support hosting instances of core services when deployed from ViBE 316. For example, a host provisioning service may provision a hypervisor on infrastructure (e.g., bare metal hosts) in the target region 334 to allocate computing resources to VMs. Once the host provisioning service completes the allocation of physical resources in the target region 334, the host provisioning service may publish information indicating a capability indicating that physical resources have been allocated in the target region 334. The capability may be published to the capability service 318 (e.g., by worker 328) via CIOS regional (ViBE) 326.

[0088] With the hardware allocation for the target region 334 established and notified to the capability service 318, CIOS regional (ViBE) 326 can orchestrate the deployment of instances of core services from ViBE 316 to the target region 334. This deployment may be similar to the process described above for building ViBE 316, but using ViBE components (e.g., CIOS regional (ViBE) 326, worker 328, deployment orchestrator 330) instead of host region 332 service enclave components. The deployment operations may generally correspond to steps 16-21 described above.

[0089] When a service is deployed from ViBE 316 to a target region 334, a DNS record associated with the service may correspond to an instance of the service in ViBE 316. The DNS record associated with the service can be updated later to complete the deployment of the service to the target region 334. In other words, the instance of the service in ViBE 316 can continue to receive traffic (e.g., requests) to the service until the DNS record is updated. The service can be partially deployed to the target region 334 and can publish information (e.g., to the capability service 318) indicating a capability that the service is partially deployed. For example, a service running in ViBE 316 can be deployed to the target region 334 along with corresponding compute instances, load balancers, and associated applications and other software, but may need to wait for database data to migrate to the target region 334 before being fully deployed. The DNS record (e.g., managed by DNS 322) can still be associated with the service in ViBE 316. Once the data migration for the service is complete, the DNS record can be updated to point to the operational service deployed in the target region 334. The deployed service in target region 334 can then receive traffic (eg, requests) for that service, while the instance of the service in ViBE 316 will no longer be able to receive traffic for that service.

[0090] Testing Infrastructure Figure 4 is a block diagram of a system for testing releases of flock configurations, according to one embodiment. As shown in Figure 4, system 400 includes a CIOS central module 421, a CIOS regional module 425, and a test environment 450. Test environment 450 includes a worker 415, one or more application hosts 453, one or more containers 455, and a capability-aware proxy server 457.

[0091] As discussed above with reference to FIG. 1, the CIOS central module 421 can be configured to provide any number of user interfaces through which a user (e.g., user 109 of FIG. 1) can interact with a cloud infrastructure orchestration system, e.g., CIOS 102. The CIOS central module 421 can provide one or more user interfaces that present the region data and allow the user 109 to view and / or modify the region data. The CIOS central module 421 can also be configured to invoke the functionality of a real-time regional data distributor (e.g., RRDD 104 of FIG. 1) through any suitable number of interfaces. In general, the CIOS central module 421 can be configured to manage the region data directly or indirectly (e.g., via RRDD 104). Additionally, the CIOS central module 421 can be configured to receive and edit flock configurations.

[0092] According to one embodiment, CIOS regional module 425 can be configured to perform bootstrapping tasks associated with a single service of a region. CIOS regional module 425 can receive desired state data from CIOS central module 421. In one embodiment, the desired state data can include a flock configuration that declares (e.g., by declarative statements) a desired state of resources associated with the service. As shown in FIG. 4, CIOS central module 421 can receive a flock configuration 411 (e.g., a configuration file for a service), which is sent over a network (indicated in FIG. 4 by cross-region call 423) to CIOS regional module 425.

[0093] According to one embodiment, the CIOS regional module 425 is configured to perform static flock analysis of the flock configuration 411 received from the CIOS central 421. In performing the static flock analysis, the CIOS regional module 425 parses the flock configuration 411 to identify one or more required capabilities required for execution of the flock. In one implementation, the one or more required capabilities correspond to operations that can be performed on one or more resource types, such as creating a key (e.g., a public or private key), deploying one or more data objects, etc. Upon completing the analysis of the flock configuration 411, the CIOS regional module 425 generates static flock analysis data 427. The static flock analysis data 427 includes information regarding dependencies between the required capabilities (i.e., operations that can be performed on resources associated with the service) and resources or resource types, execution targets, etc.

[0094] In one implementation, a capability-aware proxy server 457 included in the test environment 450 monitors the execution of a release configuration of a flock (e.g., a test release of a flock configuration 411 desired to be deployed in a particular region). To enable the capability-aware proxy server 457 to monitor the release configuration, one or more rules are configured for the capability-aware proxy server 457 (also referred to herein as proxy rules associated with the capability-aware proxy server). In one implementation, information included in the static flock analysis data 427 is used to configure one or more rules for the capability-aware proxy server 457. For example, each required capability may correspond to a rule associated with the capability-aware proxy server 457. As described below, an application host 453 included in the test environment 450 executes the release configuration of a flock. In such a case, when the application host attempts to perform an operation, such as accessing a particular resource type or deploying one or more containers in a particular data storage unit, the operation is monitored by the capability-aware proxy server 457. The capability-aware proxy server 457 allows such actions based on a set of one or more rules.

[0095] In other words, the capability-aware proxy server 457 determines whether the execution of the release proceeds according to one or more sets of rules. If a particular rule is violated (e.g., if an application host attempts to access a resource type that is not included in the required capabilities), the capability-aware proxy server 457 can stop the execution of the release and provide an exception error message in response. Thus, the capability-aware proxy server 457 is configured to monitor the execution of the release configuration 429 (e.g., a version of the flock configuration specific to the region being deployed) based on one or more sets of rules.

[0096] Upon configuring the capability-aware proxy server 457, the CIOS regional module 425 sends the release configuration of the flock (e.g., a test release) to a worker 451 included in the test environment 450 for execution of the release in the test environment 450. In one implementation, the worker 451 mediates the interaction between the CIOS regional module 425 and the capability-aware proxy server 457. The worker 451 orchestrates the execution of the flock by provisioning resources in the test environment, i.e., the worker performs mutations to the test environment 450 by creating resources such as compute instances, block storage, creating object buckets, etc. In one implementation, the worker 451 can provision the test environment with one or more application hosts 453 and containers 455 required to execute the flock release. It should be appreciated that the application host 453 executes the artifacts (i.e., code) associated with the flock, while the container 455, in one embodiment, may correspond to a Kubernetes container that includes software such as system libraries and other tools required to execute the flock.

[0097] 4, real regional services 460 may correspond to a region that includes a complete set of resources and may host test environment 450. Application hosts 453 and containers 455 communicate with capability-aware proxy server 457 to gain access to one or more resources deployed in real regional services 460. Capability-aware proxy server 457 grants (to application hosts 453 and containers 455) access to such resources included in real regional services 460 based on a set of rules used to configure capability-aware proxy server 457.

[0098] In this manner, the test environment 450 provides a provisioning framework for simulation testing of flocks. In one embodiment, the capability-aware proxy server 457 monitors the execution of a release of a flock configuration in the test environment 450. The capability-aware proxy server 457 can be configured to determine whether the release is executed successfully in the test environment. In one implementation, the capability-aware proxy server 457 is configured to generate a transcript that includes one or more events that occur during the execution of the release of the configuration file of the service in the test environment.

[0099] In one scenario, for example, once a flock release is successfully executed, and the capability-aware proxy server is configured with all the necessary capabilities to execute the flock release, the capability-aware proxy server 457 can send a message to the CIOS regional module 425 indicating successful execution of the flock, as well as a transcript or log of the execution (including events that occurred during execution). The CIOS regional module 425 can further relay the transcript to the CIOS central module 421. Note that the message indicating successful execution can indicate to a system administrator that a particular flock is ready for real-time deployment.

[0100] On the other hand, in another scenario where the capability-aware proxy server 457 determines that the flock release was not successful, the capability-aware proxy server 457 can send a message indicating the unsuccessful execution of the CIOS regional module 425 and can send a detailed transcript including the events that occurred during the unsuccessful execution of the flock release. More details regarding the logs generated by the capability-aware proxy server 457 are described below with reference to FIG. 5B.

[0101] FIG. 5A illustrates a flow chart showing steps performed in testing a flock configuration, according to at least one embodiment. The process shown in FIG. 5A can be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of a respective system, hardware, or combination thereof. The method shown in FIG. 5A and described below is intended to be exemplary and non-limiting. Although FIG. 5A illustrates various processing steps performed in a particular sequence or order, this is not intended to be limiting. In some alternative implementations, steps may be performed in some different order, or some steps may be performed in parallel.

[0102] The process begins at 505, where a test environment is provided to simulate testing of a flock configuration. For example, referring to FIG. 4, a test environment 450 can be provided to simulate testing of a release of a flock configuration. It should be appreciated that the test environment includes a worker that provisions the necessary resources (e.g., application hosts, containers, etc.) to simulate the release of the flock configuration. It should be noted that the test environment also includes a capability-aware proxy server configured to monitor the testing of the flock configuration in the test environment. The process at 510 retrieves a configuration file (i.e., config file) for the flock. It should be noted that a configuration file corresponds to a file that describes the set of all resources (e.g., infrastructure components and artifacts) associated with a single service. A flock config may include declarative statements that specify one or more aspects that correspond to a desired state of the resources of the service. Meanwhile, capabilities identify units of functionality associated with a service, e.g., capabilities that correspond to operations to be performed on one or more resource types, such as the creation of a key, the deployment of one or more data objects, and the publication of authorization policies regarding the access of one or more resource types.

[0103] At 515, the configuration file of the flock is parsed to identify required capabilities required for execution of the flock. In one implementation, the configuration file of the flock may be parsed to extract metadata associated with the flock. The metadata includes information regarding one or more required capabilities required for execution of the flock. Alternatively, such capabilities may be included in the configuration file in the form of a declaration statement that specifies the one or more required capabilities. It should be appreciated that the one or more required capabilities may be explicitly declared or may be implicit in nature.

[0104] After parsing the configuration file to identify one or more capabilities, the process proceeds to 520. At 520, a capability-aware proxy server included in the test environment is configured with a set of rules based on the capabilities identified at 515. Specifically, the capability-aware proxy server is programmed with a set of required capabilities required to perform a release of the flock configuration. At 525, a release of the flock configuration is then performed in the test environment. It should be understood that the release of the flock configuration may correspond to a flock artifact (e.g., an infrastructure component or code deployed to a Kubernetes engine cluster) that is tested in the test environment. With reference to FIG. 4, it should be noted that the flock release can be performed by application hosts and containers provisioned in the test environment by workers.

[0105] The process then proceeds to 530, where the capability-aware proxy server can determine whether the release of the flock configuration is successfully executed. It should be noted that the capability-aware proxy server can make such a determination based on the configuration depending on the set of one or more capabilities identified in 515. In other words, the capability-aware proxy server determines whether the flock is successfully executed / executable, i.e., according to a given set of capabilities (explicit or implicit capabilities) programmed for the capability-aware proxy server. In one implementation, a query is performed in 535 to determine whether the execution of the release of the flock is successful. If the response to the query is negative, the process proceeds to 540, and if the response to the query is positive, the process proceeds to 545.

[0106] At 540 (i.e., in response to the unsuccessful determination at 535), the capability-aware proxy server generates (and transmits) a message to the CIOS regional indicating the failure of the execution of the release of the flock configuration. Furthermore, the capability-aware proxy server is also configured to generate (and transmit to the CIOS regional) a transcript (e.g., a transaction log) including one or more events that occurred during the execution of the release of the configuration file of the service in the test environment. With reference to FIG. 4, it is noted that such a transcript received by the CIOS regional may be further transmitted to the CIOS central for further analysis of the flock configuration by authorized personnel, e.g., a system administrator. It is noted that the execution of the release of the flock configuration file may be unsuccessful in one scenario as follows: i.e., the capability-aware proxy server is programmed, for example, with capabilities "A" and "B" as the required capabilities required for the execution of the release of the flock configuration. However, when a flock release is executed (e.g., when the code is executed on an application host in a test environment), it is discovered that another capability (e.g., capability "C" for which a capability-aware proxy is not configured) is required to execute the flock configuration.

[0107] At 545 (i.e., in response to the successful determination at 535), the capability-aware proxy server generates (and sends to the CIOS regional) a message indicating successful execution of the release of the flock configuration. Additionally, the capability-aware proxy server can also be configured to generate (and send to the CIOS regional) a transcript (e.g., a transaction log) including one or more events that occurred during the execution of the release of the configuration file of the service in the test environment. Note that successful execution of the flock release corresponds to a scenario in which the execution of the flock release is in accordance with a given set of capabilities (explicit or implicit capabilities) that are programmed in the capability-aware proxy. Additionally, in one implementation, upon determining that the release of the flock configuration in the test environment is successful, a deployment message may be sent (e.g., from the capability-aware proxy server to the CIOS central), where the message indicates that the flock has been successfully executed and is ready to be deployed in the target region (e.g., target region 114 or ViBE 116 in FIG. 1). In this manner, the testing environment 450 of FIG. 4 can be used to test releases of flock configurations in a time-efficient and seamless manner without the need to test the flocks in an actual build region.

[0108] FIG. 5B illustrates an example log / transcript generated by a capability-aware proxy server in accordance with at least one embodiment. Specifically, FIG. 5B illustrates a portion of a transcript / log generated by a capability-aware proxy server in one test run of a flock configuration release in a test environment. As shown in FIG. 5B, portions of transcript 560 and 570 include a series of time-stamped events. For example, portion of log 560 includes time-stamped event 561 indicating a failure caused by a worker in the execution of the flock configuration release. The failure situation is indicated, for example, by a 404 error (labeled 565) corresponding to message 562 indicating a failure caused by the worker's inability to access a particular resource type. Portion 570 of the log also includes a series of time-stamped events indicating a failure of a tested region.

[0109] 4, it can be seen that in one implementation, the capability-aware proxy server is configured to generate a transcript including one or more events that occur during execution of a release of a configuration file of a service in the test environment. Such a transcript can be sent by the capability-aware proxy server to a regional cloud infrastructure orchestration (CIOS) deployed outside the test environment. In one implementation, the capability-aware proxy server is configured to generate the transcript (i.e., a log that includes detailed information about events that occur during execution of the release configuration), but the worker may also be configured to send a message indicating the status of the execution of the release configuration to a CIOS regional module deployed outside the test environment.

[0110] Cloud Service Infrastructure Architecture Examples As mentioned above, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, an IaaS provider can also provide various services (e.g., billing, monitoring, logging, load balancing, clustering, etc.) that accompany those infrastructure components. Thus, these services can be policy-driven, so that an IaaS user can enforce policies to drive load balancing to maintain application availability and performance.

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

[0112] In most cases, the cloud computing model will require the involvement of a cloud provider, which can be, but is not necessarily, a third-party service that specializes in providing IaaS (e.g., offering, renting, selling). An entity may choose to deploy a private cloud, thereby becoming its own provider of infrastructure services.

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

[0114] In one example, IaaS provisioning refers to obtaining a computer or virtual host for use and then installing the required libraries or services on it. In many cases, deployment does not include provisioning, which may need to occur first.

[0115] In some cases, there are two different challenges in IaaS provisioning. First, there is the initial challenge of provisioning an initial set of instructions before anything can be put into production. Second, there is the challenge of evolving the existing infrastructure (e.g. adding new services, modifying services, removing services, etc.) after everything has been provisioned. In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, one or more configuration files can define the infrastructure (e.g. what components are needed and how they interact). Thus, the overall topology of the infrastructure (e.g. what resources depend on which resources and how each of them work together) can be defined declaratively. In some cases, after the topology is defined, workflows can be generated that create and / or manage the different components described in the configuration files.

[0116] In one example, an infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potentially on-demand pool of configurable and / or shared computing resources), also referred to as a core network. In one example, there may also be one or more inbound / outbound traffic group rules that are provisioned to define how the network's inbound / outbound traffic is configured and one or more virtual machines (VMs). Other infrastructure elements, such as load balancers, databases, etc., can also be provisioned. The infrastructure can evolve over time as more and more infrastructure elements are required and / or added.

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

[0118] 6 is a block diagram 600 illustrating an example platform for an IaaS architecture in accordance with at least one embodiment. A service operator 602 can be communicatively coupled to a secure host tenancy 604, which can include a virtual cloud network (VCN) 606 and a secure host subnet 608. In one example, the service operator 602 can use one or more customer computing devices, which can be portable handheld devices (e.g., iPhones, mobile phones, iPads, 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 8, Palm OS, and capable of Internet, email, short message service (SMS), Blackberry, or other communications protocols. Alternatively, the customer computing devices may be general purpose personal computers, including, for example, personal and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The customer computing devices may be workstation computers running any of the various commercially available UNIX or UNIX-like operating systems, including, but not limited to, the various GNU / Linux operating systems, such as Google Chrome OS.Alternatively or additionally, the customer computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal messaging device capable of communicating via VCN 606 and / or an Internet-accessible network.

[0119] The VCN 606 may include a local peering gateway (LPG) 610 that may be communicatively coupled to an SSH VCN 612 via an LPG 610 that is included in a secure shell (SSH) VCN 612. The SSH VCN 612 may include an SSH subnet 614, which may be communicatively coupled to a control plane VCN 616 via an LPG 610 that is included in the control plane VCN 616. The SSH VCN 612 may also be communicatively coupled to a data plane VCN 618 via the LPG 610. The control plane VCN 606 and the data plane VCN 618 may be included in a service tenancy 619 that may be owned and / or operated by the IaaS provider.

[0120] The control plane VCN 616 may include a control plane demilitarized zone (DMZ) tier 620 that serves as a perimeter network (e.g., the portion of an enterprise network between the enterprise intranet and an external network). DMZ-based servers may have limited duties and help thwart intrusions. Additionally, the DMZ tier 620 may include one or more load balancer (LB) subnets 622, a control plane application tier 624 that may include application subnets 626, a control plane data tier 628 that may include database (DB) subnets 630 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 622 included in the control plane DMZ layer 620 can be communicatively coupled to an application subnet 626 included in the control plane application layer 624 and an Internet gateway 634 that can be included in the control plane VCN 616, which can be communicatively coupled to a DB subnet 630 included in the control plane data layer 628 and a service gateway 636 and a network address translation (NAT) gateway 638. The control plane VCN 616 can include the service gateway 636 and the NAT gateway 638.

[0121] The control plane VCN 616 may include a data plane mirrored application tier 640 that may include an application subnet 626. The application subnet 626 included in the data plane mirrored application tier 640 may include a virtual network interface controller (VNIC) 642 capable of running a compute instance 644. The compute instance 644 may communicatively couple the application subnet 626 of the data plane mirrored application tier 640 to the application subnet 626 that may be included in the data plane application tier 646.

[0122] The data plane VCN 618 may include a data plane application layer 646, a data plane DMZ layer 648, and a data plane data layer 650. The data plane DMZ layer 648 may include a LB subnet 622 that may be communicatively coupled to an application subnet 626 of the data plane application layer 646 and an Internet gateway 634 of the data plane VCN 618. The application subnet 626 may be communicatively coupled to a service gateway 636 of the data plane VCN 618 and a NAT gateway 638 of the data plane VCN 618. The data plane data layer 650 may also include a DB subnet 630 that may be communicatively coupled to the application subnet 626 of the data plane application layer 646.

[0123] The Internet gateways 634 of the control plane VCNs 616 and data plane VCNs 618 may be communicatively coupled to a metadata management service 652, which may be communicatively coupled to the public Internet 654. The public Internet 654 may be communicatively coupled to NAT gateways 638 of the control plane VCNs 616 and of the data plane VCNs 618. The service gateways 636 of the control plane VCNs 616 and of the data plane VCNs 618 may be communicatively coupled to cloud services 656.

[0124] In one example, a service gateway 636 in the control plane VCN 616 or in the data plane VCN 618 can make application programming interface (API) calls to cloud services 656 without traversing the public Internet 654. API calls from the service gateway 636 to the cloud services 656 can be one-way; that is, the service gateway 636 can make API calls to the cloud services 656 and the cloud services 656 can send requested data to the service gateway 636. However, the cloud services 656 cannot originate API calls to the service gateway 636.

[0125] In one example, secure host tenancy 604 can be directly connected to an otherwise separable service tenancy 619. Secure host subnet 608 can communicate with SSH subnet 614 through LPG 610, which can enable bidirectional communication through otherwise separate systems. Connecting secure host subnet 608 to SSH subnet 614 can provide secure host subnet 608 with access to other entities in service tenancy 619.

[0126] The control plane VCN 616 can enable users of a service tenancy 619 to configure or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 616 can be deployed or otherwise used in the data plane VCN 618. In an example, the control plane VCN 616 can be separate from the data plane VCN 618, and a data plane mirror application tier 640 of the control plane VCN 616 can communicate with a data plane application tier 646 of the data plane VCN 618 via a VNIC 642, which can be included in the data plane mirror application tier 640 and the data plane application tier 646.

[0127] In one example, a user or customer of the system may make a request, for example, a create, read, update or delete (CRUD) operation, via the public Internet 654, which may communicate the request to a metadata management service 652. The metadata management service 652 may communicate the request to the control plane VCN 616 via an Internet gateway 634. The request may be received by a LB subnet 622 included in the control plane DMZ layer 620. The LB subnet 622 may determine that the request is valid, and in response to this determination, the LB subnet 622 may send the request to an application subnet 626 included in the control plane application layer 624. If the validity of the request is verified and a call to the public Internet 654 is required, the call to the public Internet 654 may be sent to a NAT gateway 638, which may make the call to the public Internet 654. Memory that may be desired to be stored by the request may be stored in the DB subnet 630.

[0128] In one example, a data plane mirror application layer 640 can facilitate direct communication between the control plane VCN 616 and the data plane VCN 618. For example, it may be desired that configuration changes, updates, or other suitable modifications be applied to resources included in the data plane VCN 618. VNIC 642 allows the control plane VCN 616 to communicate directly with the resources included in the data plane VCN 618, thereby enabling it to perform configuration changes, updates, or other suitable modifications to those resources.

[0129] In an embodiment, the control plane VCN 616 and the data plane VCN 618 may be included in the service tenancy 619. In this case, a user or customer of the system may not own or operate the control plane VCN 616 or the data plane VCN 618. Instead, an IaaS provider may own or operate the control plane VCN 616 and the data plane VCN 618, both of which may be included in the service tenancy 619. This embodiment may allow for network isolation that may prevent a user or customer from interacting with the resources of other users or other customers. This embodiment may also allow a user or customer of the system to store databases privately without having to rely on the public Internet 654, which may not have the desired level of threat protection for storage.

[0130] In another embodiment, the LB subnet 622 included in the control plane VCN 616 can be configured to receive signals from the service gateway 636. In this embodiment, the control plane VCN 616 and the data plane VCN 618 can be configured to be called by the IaaS provider's customers without calling the public Internet 654. Customers of the IaaS provider may desire this embodiment because databases used by the customers can be controlled by the IaaS provider and stored on a service tenancy 619 that is separable from the public Internet 654.

[0131] 7 is a block diagram 700 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 702 (e.g., service operator 602 of FIG. 6) can be communicatively coupled to a secure host tenancy 704 (e.g., secure host tenancy 604 of FIG. 6), which can include a virtual cloud network (VCN) 706 (e.g., VCN 606 of FIG. 6) and a secure host subnet 608 (e.g., secure host subnet 608 of FIG. 6). The VCN 706 can include a local peering gateway (LPG) 710 (e.g., LPG 610 of FIG. 6), which can be communicatively coupled to an SSH VCN 712 (e.g., SSH VCH 612 of FIG. 6) via an LPG 610 included in a secure shell (SSH) VCN 712. SSH VCN 712 can include an SSH subnet 714 (e.g., SSH subnet 614 in FIG. 6), which can be communicatively coupled to a control plane VCN 716 (e.g., control plane VCN 616 in FIG. 6) via an LPG 710 included in the control plane VCN 716. The control plane VCN 716 can be included in a service tenancy 719 (e.g., service tenancy 619 in FIG. 6), and the data plane VCN 718 (e.g., data plane VCN 618 in FIG. 6) can be included in a customer tenancy 721, which can be owned or operated by a user or customer of the system.

[0132] The control plane VCN 716 may include a control plane DMZ layer 720 (e.g., control plane DMZ layer 620 of FIG. 6 ) that may include a LB subnet 722 (e.g., LB subnet 622 of FIG. 6 ), a control plane layer 724 (e.g., control plane application layer 624 of FIG. 6 ) that may include an application subnet 726 (e.g., application subnet 626 of FIG. 6 ), and a control plane data layer 728 (e.g., control plane data layer 628 of FIG. 6 ) that may include a database (DB) subnet 730 (e.g., similar to DB subnet 630 of FIG. 6 ). LB subnet 722 included in control plane DMZ tier 720 may be communicatively coupled to application subnet 726 included in control plane application tier 724 and to an Internet gateway 734 (e.g., Internet gateway 634 in FIG. 6 ) that may be included in control plane VCN 716, and application subnet 726 may be communicatively coupled to DB subnet 730 included in control plane data tier 728 and to a service gateway 736 (e.g., service gateway 636 in FIG. 6 ) and a network address translation (NAT) gateway 738 (e.g., NAT gateway 638 in FIG. 6 ). Control plane VCN 716 may include service gateway 736 and NAT gateway 738.

[0133] The control plane VCN 716 may include a data plane mirrored application tier 740 (e.g., data plane mirrored application tier 640 of FIG. 6 ), which may include an application subnet 726. The application subnet 726 included in the data plane mirrored application tier 740 may include a virtual network interface controller (VNIC) 742 (e.g., VNIC 642 ) that may run a compute instance 744 (e.g., similar to compute instance 644 of FIG. 6 ). The compute instance 744 may facilitate communication between the application subnet 726 of the data plane mirrored application tier 740 and the application subnet 726 that may be included in the data plane application tier 746 (e.g., data plane application tier 646 of FIG. 6 ) via the VNIC 742 included in the data plane mirrored application tier 740 and the VNIC 742 included in the data plane application tier 746.

[0134] The Internet gateway 734 included in the control plane VCN 716 may be communicatively coupled to a metadata management service 752 (e.g., metadata management service 652 of FIG. 6), which may be communicatively coupled to a public Internet 754 (e.g., public Internet 654 of FIG. 6). The public Internet 754 may be communicatively coupled to a NAT gateway 738 included in the control plane VCN 716. The service gateway 736 included in the control plane VCN 716 may be communicatively coupled to cloud services 756 (e.g., cloud services 656 of FIG. 6).

[0135] In one example, the data plane VCN 718 may be included in the customer tenancy 721. In this case, the IaaS provider may provide each customer with a control plane VCN 716, and the IaaS provider may configure a unique compute instance 744 included in the service tenancy 719 for each customer. Each compute instance 744 may enable communication between the control plane VCN 716 included in the service tenancy 719 and the data plane VCN 718 included in the customer tenancy 721. The compute instance 744 may enable resources provisioned in the control plane VCN 716 included in the service tenancy 719 to be deployed or otherwise used in the data plane VCN 718 included in the customer tenancy 721.

[0136] In another example, an IaaS provider customer may have a database that resides within customer tenancy 721. In this example, control plane VCN 716 may include a data plane mirrored application tier 740 that may include application subnet 726. The data plane mirrored application tier 740 may reside in data plane VCN 718, but the data plane mirrored application tier 740 may not reside in data plane VCN 718. That is, the data plane mirrored application tier 740 may have access to customer tenancy 721, but the data plane mirrored application tier 740 may not reside in data plane VCN 718 or be owned or operated by the IaaS provider customer. The data plane mirrored application tier 740 may be configured to make calls to the data plane VCN 718, but may not be configured to make calls to any entities included in control plane VCN 716. A customer may wish to deploy or otherwise use resources in the data plane VCN 718 that have been provisioned in the control plane VCN 716, and the data plane mirror application tier 740 may facilitate the desired deployment or other use of the customer's resources.

[0137] In one embodiment, an IaaS provider's customer can filter the data plane VCN 718. In this embodiment, the customer can determine what the data plane VCN 718 can access, and the customer can limit access to the public internet 754 from the data plane VCN 718. It may not be possible for the IaaS provider to filter or otherwise control the data plane VCN 718's access to external networks or databases. The application of filters and controls by the customer to the data plane VCN 718 contained in the customer tenancy 721 can facilitate isolating the data plane VCN 718 from other customers and from the public internet 754.

[0138] In an embodiment, cloud services 756 can be invoked by the service gateway 736 to access services that may not exist on the public internet 754, on the control plane VCN 716, or on the data plane VCN 718. The connection between the cloud services 756 and the control plane VCN 716 or the data plane VCN 718 may not be live or continuous. The cloud services 756 can exist on different networks owned or operated by the IaaS provider. The cloud services 756 can be configured to receive calls from the service gateway 736 and not receive calls from the public internet 754. Some cloud services 756 can be isolated from other cloud services 756, and the control plane VCN 716 can be isolated from cloud services 756 that may not be in the same region as the control plane VCN 716. For example, the control plane VCN 716 may be located in "region 1" and the cloud service deployments 756 may be located in region 1 and "region 2." If a call is made to a deployment by a service gateway 736 included in a control plane VCN 716 located in region 1, the call can be sent to a deployment in region 1. In this example, the control plane VCN 716, or the deployment in region 1, cannot be communicatively coupled or otherwise communicate with a deployment in region 2.

[0139] 8 is a block diagram 800 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 802 (e.g., service operator 602 of FIG. 6) can be communicatively connected to a secure host tenancy 804 (e.g., secure host tenancy 604 of FIG. 6), which can include a virtual cloud network (VCN) 806 (e.g., VCN 606 of FIG. 6), and a second secure host subnet 808 (e.g., secure host subnet 608 of FIG. 6). VCN 806 can include an LPG 810 (e.g., LPG 610 of FIG. 6), which can be communicatively connected to an SSH VCN 812 (e.g., SSH VCN 612 of FIG. 6) via an LPG 810 included in SSH VCN 812. SSH VCN 812 can include an SSH subnet 814 (e.g., SSH subnet 614 in FIG. 6), which can be communicatively connected to a control plane VCN 816 (e.g., control plane VCN 616 in FIG. 6) via an LPG 810 included in control plane VCN 816 and to a data plane VCN 818 (e.g., data plane 618 in FIG. 6) via an LPG 810 included in data plane VCN 818. The control plane VCN 816 and the data plane VCN 818 can be included in a service tenancy 819 (e.g., service tenancy 619 in FIG. 6).

[0140] The control plane VCN 816 may include a control plane DMZ tier 820 (e.g., control plane DMZ tier 620 of FIG. 6 ), which may include a load balancer (LB) subnet 822 (e.g., LB subnet 622 of FIG. 6 ), a control plane application tier 824 (e.g., control plane application tier 624 of FIG. 6 ), which may include an application subnet 826 (e.g., similar to application subnet 626 of FIG. 6 ), and a control plane data tier 828 (e.g., control plane data tier 628 of FIG. 6 ), which may include a DB subnet 830. The LB subnet 822 included in the control plane DMZ layer 820 can be communicatively coupled to an application subnet 826 included in the control plane application layer 824 and to an Internet gateway 834 (e.g., Internet gateway 634 in FIG. 6 ) that may be included in the control plane VCN 816, and the application subnet 826 can be communicatively coupled to a DB subnet 830 included in the control plane data layer 828 and to a service gateway 836 (e.g., service gateway in FIG. 6 ) and a network address translation (NAT) gateway 838 (e.g., NAT gateway 638 in FIG. 6 ). The control plane VCN 816 can include the service gateway 836 and the NAT gateway 838.

[0141] The data plane VCN 818 may include a data plane application layer 846 (e.g., data plane application layer 646 in FIG. 6 ), a data plane DMZ layer 848 (e.g., data plane DMZ layer 648 in FIG. 6 ), and a data plane data layer 850 (e.g., data plane data layer 650 in FIG. 6 ). The data plane DMZ layer 848 may include a LB subnetwork 822 that may be communicatively coupled to a trusted application subnetwork 860 and an untrusted application subnetwork 862 of the data plane application layer 846 and an Internet gateway 834 included in the data plane VCN 818. The trusted application subnetwork 860 may be communicatively coupled to a service gateway 836 included in the data plane VCN 818, a NAT gateway 838 included in the data plane VCN 818, and a DB subnetwork 830 included in the data plane data layer 850. The untrusted application subnetwork 862 may be communicatively coupled to a service gateway 836 included in the data plane VCN 818 and a DB subnetwork 830 included in the data plane data layer 850. The data plane data layer 850 may include a DB subnet 830 that may be communicatively coupled to a service gateway 836 included in the data plane VCN 818.

[0142] The untrusted application subnet 862 may include one or more primary VNICs 864(1)-(N) communicatively coupled to tenant virtual machines (VMs) 866(1)-(N). Each tenant VM 866(1)-(N) may be communicatively coupled to a respective application subnet 867(1)-(N) that may be included in a respective container egress VCN 868(1)-(N) that may be included in a respective customer tenancy 870(1)-(N). Each secondary VNIC 872(1)-(N) may facilitate communication between the untrusted application subnet 862 included in the data plane VCN 818 and the application subnet included in the container egress VCN 868(1)-(N). Each container egress VCN 868(1)-(N) may include a NAT gateway 838 communicatively coupled to the public Internet 854 (e.g., public Internet 654 of FIG. 6).

[0143] An Internet gateway 834 included in the control plane VCN 816 and included in the data plane VCN 818 may be communicatively coupled to a metadata management service 852 (e.g., metadata management system 652 of FIG. 6), which may be communicatively coupled to the public Internet 854. The public Internet 854 may be communicatively coupled to a NAT gateway 838 included in the control plane VCN 816 and included in the data plane VCN 818. A service gateway 836 included in the control plane VCN 816 and included in the data plane VCN 818 may be communicatively coupled to cloud services 856.

[0144] In one embodiment, data plane VCN 818 can be integrated with customer tenancy 870. This integration can be useful or desirable for an IaaS provider's customer in some cases, such as when support is desired when executing code. A customer can provide code for execution that may be disruptive, communicate with other customer resources, or otherwise cause undesirable effects. In response, the IaaS provider can determine whether or not to execute the code provided to the IaaS provider by the customer.

[0145] In one example, an IaaS provider customer can be granted temporary network access to the IaaS provider and can request to add functionality to data plane application layer 846. The code to perform that functionality can be executed in VMs 866(1)-(N), and the code cannot be configured to run anywhere else on data plane VCN 818. Each VM 866(1)-(N) can be connected to one customer tenancy 870. Each container 871(1)-(N) contained in VM 866(1)-(N) can be configured to run this code. In this case, there can be double isolation (e.g., container 871(1)-(N) executes code, and container 871(1)-(N) can be at least contained in VM 866(1)-(N) contained in untrusted application subnet 862), which can help prevent malformed or otherwise undesirable code from damaging the IaaS provider's network or from damaging a different customer's network. Containers 871(1)-(N) can be communicatively coupled to customer tenancy 870 and can be configured to send or receive respective data to or from customer tenancy 870. Containers 871(1)-(N) cannot be configured to send or receive data to or from any other entities in data plane VCN 818. Upon completion of code execution, the IaaS provider can disable or otherwise discard containers 871(1)-(N).

[0146] In one embodiment, trusted application subnet 860 may execute code owned or operated by the IaaS provider. In this embodiment, trusted application subnet 860 may be communicatively coupled to DB subnet 830 and may be configured to perform CRUD operations on DB subnet 830. Untrusted application subnet 862 may be communicatively connected to DB subnet 830, but in this embodiment, the untrusted application subnet may be configured to perform READ operations on DB subnet 830. Containers 871(1)-(N) may be included in each customer's VMs 866(1)-(N) and may execute code from the customer, but may not be communicatively coupled to DB subnet 830.

[0147] In other embodiments, the control plane VCN 816 and the data plane VCN 818 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 816 and the data plane 818. However, communication may be indirect by at least one method. An IaaS provider may configure an LPG 810 that may facilitate communication between the control plane VCN 816 and the data plane VCN 818. In another example, the control plane VCN 816 or the data plane VCN 818 may make a call to a cloud service 856 through a service gateway 836. For example, a call from the control plane VCN 816 to the cloud service 856 may include a request for a service that may communicate with the data plane VCN 818.

[0148] 9 is a block diagram 900 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 902 (e.g., service operator 602 of FIG. 6) can be communicatively connected to a secure host tenancy 904 (e.g., secure host tenancy 604 of FIG. 6), which can include a virtual cloud network (VCN) 906 (e.g., VCN 606 of FIG. 6) and a secure host subnet 908 (e.g., secure host subnet 608 of FIG. 6). VCN 906 can include an LPG 910 (e.g., LPG 610 of FIG. 6), which can be communicatively coupled to an SSH VCN 912 (e.g., SSH VCN 612 of FIG. 6) via an LPG 910 included in the SSH VCN 912. SSH VCN 912 can include an SSH subnet 914 (e.g., SSH subnet 614 in FIG. 6), which can be communicatively coupled to a control plane VCN 916 (e.g., control plane VCN 616 in FIG. 6) via an LPG 910 included in control plane VCN 916 and to a data plane VCN 918 (e.g., data plane 618 in FIG. 6) via an LPG 910 included in data plane VCN 918. The control plane VCN 916 and the data plane VCN 918 can be included in a service tenancy 919 (e.g., service tenancy 619 in FIG. 6).

[0149] The control plane VCN 916 may include a control plane DMZ layer 920 (e.g., control plane DMZ layer 620 of FIG. 6 ) that may include a LB subnet 922 (e.g., LB subnet 622 of FIG. 6 ), a control plane application layer 924 (e.g., control plane application layer 624 of FIG. 6 ) that may include an application subnet 926 (e.g., application subnet 626 of FIG. 6 ), and a control plane data layer 928 (e.g., control plane data layer 628 of FIG. 6 ) that may include a DB subnet 930 (e.g., DB subnet 830 of FIG. 8 ). The LB subnet 922 included in the control plane DMZ tier 920 can be communicatively coupled to an application subnet 926 included in the control plane application tier 924 and to an Internet gateway 934 (e.g., Internet gateway 634 in FIG. 6 ) that may be included in the control plane VCN 916, and the application subnet 926 can be communicatively coupled to a DB subnet 930 included in the control plane data tier 928 and to a service gateway 936 (e.g., service gateway in FIG. 6 ) and a network address translation (NAT) gateway 938 (e.g., NAT gateway 638 in FIG. 6 ). The control plane VCN 916 can include the service gateway 936 and the NAT gateway 938.

[0150] The data plane VCN 918 may include a data plane application layer 946 (e.g., data plane application layer 646 in FIG. 6 ), a data plane DMZ layer 948 (e.g., data plane DMZ layer 648 in FIG. 6 ), and a data plane data layer 950 (e.g., data plane data layer 650 in FIG. 6 ). The data plane DMZ layer 948 may include a LB subnetwork 922 that may be communicatively coupled to a trusted application subnetwork 960 (e.g., trusted application subnetwork 860 in FIG. 8 ), an untrusted application subnetwork 962 (e.g., untrusted application subnetwork 862 in FIG. 8 ) of the data plane application layer 946, and an Internet gateway 934 included in the data plane VCN 918. The trusted application subnetwork 960 may be communicatively coupled to a service gateway 936 included in the data plane VCN 918, a NAT gateway 938 included in the data plane VCN 918, and a DB subnetwork 930 included in the data plane data layer 950. The untrusted application subnet 962 may be communicatively coupled to a service gateway 936 included in the data plane VCN 918 and to a DB subnet 930 included in the data plane data layer 950. The data plane data layer 950 may include a DB subnet 930 that may be communicatively coupled to a service gateway 936 included in the data plane VCN 918.

[0151] The untrusted application subnet 962 may include primary VNICs 964(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 966(1)-(N) that are in the untrusted application subnet 962. Each tenant VM 966(1)-(N) may execute code in a respective container 967(1)-(N) and may be communicatively coupled to an application subnet 926 that may be included in a data plane application layer 946 that may be included in a container egress VCN 968. Each secondary VNIC 972(1)-(N) may facilitate communication between the untrusted application subnet 962 included in the data plane VCN 918 and the application subnet included in the container egress VCN 968. The container egress VCN may include a NAT gateway 938 that may be communicatively coupled to the public Internet 954 (e.g., public Internet 654 of FIG. 6).

[0152] An internet gateway 934 included in the control plane VCN 916 and in the data plane VCN 918 may be communicatively coupled to a metadata management service 952 (e.g., metadata management system 652 of FIG. 6 ), which may be communicatively coupled to the public internet 954. The public internet 954 may be communicatively coupled to a NAT gateway 938 included in the control plane VCN 916 and in the data plane VCN 918. A service gateway 936 included in the control plane VCN 916 and in the data plane VCN 918 may be communicatively coupled to cloud services 956.

[0153] In one example, the pattern illustrated by the architecture of block diagram 900 of FIG. 9 can be considered an exception to the pattern illustrated by the architecture of block diagram 800 of FIG. 8 and may be desirable for a customer of an IaaS provider when the IaaS provider cannot communicate directly with the customer (e.g., disconnected region). Each container 967(1)-(N) contained in a VM 966(1)-(N) for each customer is accessible in real time by that customer. The containers 967(1)-(N) can be configured to make calls to a respective secondary VNIC 972(1)-(N) contained in an application subnet 926 of a data plane application layer 946 that can be contained in a container egress VCN 968. The secondary VNIC 972(1)-(N) can send the calls to a NAT gateway 938 that can send the calls to the public Internet 954. In this example, containers 967(1)-(N) that are accessible to a customer in real time can be isolated from control plane VCN 916 and can be isolated from other entities contained within data plane VCN 918. Containers 967(1)-(N) can also be isolated from resources from other customers.

[0154] In another example, a customer can use container 967(1)-(N) to call cloud service 956. In this example, the customer can execute code in container 967(1)-(N) that requests a service from cloud service 956. Container 967(1)-(N) can send the request to secondary VNIC 972(1)-(N), which can send the request to a NAT gateway, which can send the request to public internet 954. Public internet 954 can send the request via internet gateway 934 to LB subnet 922 included in control plane VCN 916. In response to determining that the request is valid, the LB subnet can send the request to application subnet 926, which can send the request via service gateway 936 to cloud service 956.

[0155] It should be understood that the IaaS architectures 600, 700, 800, 900 depicted in the figures may have components other than those depicted, and the depicted embodiments are only some examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS systems may have more or fewer components than depicted in the figures, may combine two or more components, or may have a different configuration or arrangement of components.

[0156] In one embodiment, the IaaS system described herein may include a set of application, middleware, and database service offerings that are delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. One example of such an IaaS system is Oracle Cloud Infrastructure (OCI), offered by the assignee of the present application.

[0157] 10 illustrates an exemplary computer system 1000 in which various embodiments may be implemented. System 1000 may be used to implement any of the computer systems described above. As shown, computer system 1000 includes a processing unit 1004 that communicates with several peripheral subsystems via a bus subsystem 1002. These peripheral subsystems may include a processing acceleration unit 1006, an I / O subsystem 1008, a storage subsystem 1018, and a communication subsystem 1024. The storage subsystem 1018 includes a tangible computer readable storage medium 1022 and a system memory 1010.

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

[0159] A processing unit 1004, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1000. The processing unit 1004 may include one or more processors. These processors may include single-core or multi-core processors. In one embodiment, the processing unit 1004 may be implemented as one or more independent processing units 1032 and / or 1034, with each processing unit including a single-core or multi-core processor. In other embodiments, the processing unit 1004 may be implemented as a quad-core processing unit formed by integrating two dual-core processors on a single chip.

[0160] In various embodiments, the processing unit 1004 may execute various programs in response to program code and may maintain multiple parallel executing programs or processes. At any given time, some or all of the program code being executed may reside within the processor 1004 and / or within the storage subsystem 1018. With appropriate programming, the processor 1004 may provide the various functions discussed above. The computer system 1000 may further include a processing acceleration unit 1006, which may include a digital signal processor (DSP), special purpose processor, and / or the like.

[0161] The I / O subsystem 1008 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen integrated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include motion sensing and / or gesture recognition devices, such as, for example, a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device, such as a Microsoft Xbox® 360 game controller, through a natural user interface using gestures and speech commands. User interface input devices may also include eye gesture recognition devices, such as a Google Glass® blink detector, that detects eye activity from a user (e.g., “blinking” when taking a picture and / or selecting a menu) and translates the eye gesture as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® navigator) via voice commands.

[0162] User interface input devices may include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads, and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser distance meters, and eye-tracking systems. Additionally, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, and medical ultrasound devices. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0163] User interface output devices may include a display subsystem, non-visual displays such as indicator lights or audio output devices. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), a liquid crystal display (LCD) or a plasma display, a projection device, a touch screen, etc. In general, use of the term "output device" is intended to include any type of possible device and mechanism for outputting information from computer system 1000 to a user or to another computer. For example, user interface output devices may include a variety of display devices that visually convey text, graphics and audio / video information, such as, but not limited to, monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices and modems.

[0164] Computer system 1000 may include a storage subsystem 1018 that provides a tangible, non-transitory computer-readable storage medium for storing software and data structures that provide functionality of embodiments described in this disclosure. The software may include programs, code modules, instructions, scripts, etc. that, when executed by one or more cores or processors of processing unit 1004, provide the functionality described above. Storage subsystem 1018 may also provide a repository for storing data used in accordance with the present disclosure.

[0165] As shown in Figure 10, the storage subsystem 1018 may include various components including a system memory 1010, a computer readable storage medium 1022, and a computer readable storage medium reader 1020. The system memory 1010 may store program instructions that are loadable and executable by the processing unit 1004. The system memory 1010 may also store data used during execution of the instructions and / or data generated during execution of the program instructions. A variety of different types of programs may be loaded into the system memory 1010, including, but not limited to, client applications, web browsers, mid-tier applications, relational database management systems (RDBMS), virtual machines, containers, and the like.

[0166] The system memory 1010 may also store an operating system 1016. Examples of the operating system 1016 may include Microsoft Windows, Apple Macintosh, and / or Linux operating systems, various commercially available UNIX or UNIX-like operating systems (including but not limited to the GNU / Linux operating system, Google Chrome OS, etc.), and / or mobile operating systems, such as iOS, Windows Phone, Android OS, BlackBerry OS, and Palm OS operating systems. In certain implementations in which the computer system 1000 runs one or more virtual machines, the virtual machines, along with their guest operating systems (GOS), may be loaded into the system memory 1010 and executed by one or more processors or cores of the processing unit 1004.

[0167] The system memory 1010 may be provided in different configurations depending on the type of computer system 1000. For example, the system memory 1010 may be volatile memory (such as random access memory (RAM)) and / or non-volatile memory (such as read only memory (ROM), flash memory, etc.). Different types of RAM configurations can be provided, including static random access memory (SRAM), dynamic random access memory (DRAM), etc. In some embodiments, the system memory 1010 may include a basic input / output system (BIOS), which contains the basic routines that help to transfer information between elements within the computer system 1000, such as during start-up.

[0168] Computer-readable storage medium 1022 may represent remote, local, fixed and / or removable storage devices, as well as storage media for temporarily and / or more permanently containing and storing computer-readable information for use by computer system 1000, including instructions executable by processing unit 1004 of computer system 1000.

[0169] The computer readable storage medium 1022 may include any suitable medium known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media, implemented in any method or technology for storage and / or transmission of information. This may include tangible computer readable storage media, such as RAM, ROM, Electrically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or other tangible computer readable media.

[0170] For example, the computer readable storage medium 1022 may include hard disk drives that read or write non-removable non-volatile magnetic media, magnetic disk drives that read or write removable non-volatile magnetic disks, and optical disk drives that read or write removable non-volatile optical disks such as CD ROMs, DVDs and Blu-Ray disks or other optical media. The computer readable storage medium 1022 may include, but is not limited to, Zip drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, and the like. The computer readable storage medium 1022 may also include solid state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, solid state ROMs, SSDs based on volatile memory such as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules and other data for the computer system 1000.

[0171] Machine-readable instructions executable by one or more processors or cores of the processing unit 1004 may be stored on a non-transitory computer-readable storage medium. A non-transitory computer-readable storage medium may include physically tangible memory or storage devices, including volatile memory storage devices and / or non-volatile storage devices. Examples of non-transitory computer-readable storage media include magnetic storage media (e.g., disks or tapes), optical storage media (e.g., DVDs, CDs), various types of RAM, ROM or flash memory, hard drives, floppy drives, removable memory drives (e.g., USB drives), or other types of storage devices.

[0172] The communications subsystem 1024 provides an interface to other computer systems and networks. The communications subsystem 1024 serves as an interface for receiving and transmitting data to and from systems other than the computer system 1000. For example, the communications subsystem 1024 may enable the computer system 1000 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 1024 may include a radio frequency (RF) transceiver component for accessing wireless voice and / or data networks (e.g., using cellular technology, advanced data network technologies such as 3G, 4G, or EDGE (Enhanced Data Rates for Global Evolution), WiFi (IEEE 802.11 family standard, or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communications subsystem 1024 may provide a wired network connection (e.g., Ethernet) in addition to or instead of a wireless interface.

[0173] In some embodiments, the communications subsystem 1024 may also receive incoming communications in the form of structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, etc., on behalf of one or more users who may use the computer system 1000.

[0174] For example, the communications subsystem 1024 can be configured to receive data feeds 1026 in real time from users of social networks and / or other communications services, such as web feeds, such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party sources.

[0175] Additionally, the communications subsystem 1024 may be configured to receive data in the form of a continuous data stream, which may include an event stream 1028 of real-time events and / or event updates 1030, which may be continuous or unbounded in nature with no apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc.

[0176] The communications subsystem 1024 may also be configured to output structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, etc. to one or more databases in communication with one or more streaming data source computers coupled to the computer system 1000.

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

[0178] Due to the ever-changing nature of computers and networks, the description of the computer system 1000 shown in the figures is intended as an example only. Many other configurations having more or fewer components than the system shown in the figures are possible. For example, customized hardware may also be used, and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Also, connections to other computing devices, such as network input and / or output devices, may be employed. Based on this disclosure and the teachings presented herein, one of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments.

[0179] Although specific embodiments have been described, various modifications, variations, alternative constructions and equivalents are encompassed within the scope of the disclosure. The embodiments are not limited to operating in one particular data processing environment, but can freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a particular sequence of transactions and steps, it will be apparent to those skilled in the art that the scope of the disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments can be used individually or in combination.

[0180] Also, while embodiments are described using a particular combination of hardware and software, it should be understood that other combinations of hardware and software are within the scope of the present disclosure. The embodiments can be implemented using only hardware, only software, or a combination thereof. The various processes described herein can be performed on the same processor or on different processors in any combination. Thus, when a component or module is described as being configured to perform an operation, such configuration can be achieved, for example, by designing an electronic circuit to perform the operation, or by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or a combination thereof. Processes can communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0181] The embodiments may be implemented using a computer program product comprising a computer program / instructions which, when executed by a processor, cause the processor to perform any of the methods described in the present disclosure.

[0182] Accordingly, the specification and drawings are to be regarded in an illustrative and not a restrictive sense. However, it will be apparent that additions, substitutions, deletions and other modifications and alterations may be made thereto without departing from the broader spirit and scope of the appended claims. Thus, although certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are also intended to be encompassed within the scope of the appended claims.

[0183] Use of the terms "a," "an," "the," and similar referents in the context of describing embodiments of the present disclosure (particularly in the context of the appended claims) should be construed to include both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" should be construed as open-ended (i.e., meaning "including, but not limited to"), unless otherwise indicated. The term "connected" should be construed as being partly or wholly contained within, attached to, or joined to one another, even if there are intervening elements. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated herein as if it were individually set forth herein. All methods described herein can be performed in any suitable order, unless otherwise indicated herein or clearly contradicted by context. The use of any examples and illustrative language (e.g., "etc.") described herein, unless otherwise required, is intended merely to facilitate a better understanding of the embodiments and does not limit the scope of the disclosure. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0184] Disjunctive phrases such as "at least one of X, Y, or Z" are intended to be interpreted as generally used within the context to indicate that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X, Y and / or Z), unless specifically stated otherwise. Thus, such disjunctive phrases are generally not intended to, and should not, imply that an embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0185] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the present disclosure. Variations of these preferred embodiments will become apparent to those skilled in the art upon reading the above description. Those skilled in the art should be able to adopt such variations as appropriate, and the present disclosure may be carried out in a manner different from that specifically described herein. Accordingly, the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Also, unless otherwise indicated herein, any combination of the above-described elements is encompassed by the present disclosure in all its possible variations.

[0186] All references cited in this specification, including publications, patent applications, and patents, are hereby incorporated by reference to the same extent as if each reference was individually and specifically incorporated by reference and was set forth in its entirety herein.

[0187] Although aspects of the disclosure have been described hereinabove with reference to specific embodiments thereof, those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the disclosure above can be used individually or in combination. Also, the embodiments can be used in any number of environments and applications other than those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.

Claims

1. 1. A computer-implemented method comprising: parsing the configuration file for the service to identify one or more capabilities for performing the release of the configuration file for the service; the one or more capabilities correspond to actions to be performed with respect to one or more resource types; The method comprises: providing a test environment for executing the release of the configuration file of the service; configuring a capability-aware proxy server included in the test environment based on the one or more capabilities identified from the configuration file of the service; performing the release of the configuration file of the service in accordance with the capability-aware proxy server in the test environment; generating a response message corresponding to a result of the release of the configuration file for the service.

2. 2. The method of claim 1, wherein the test environment includes a worker configured to provision at least one of an application host and a container in the test environment to perform the release of the configuration file of the service.

3. The method of claim 1 , further comprising generating a transcript comprising one or more events that occur during execution of the release of the configuration file of the service in the test environment.

4. The method of claim 1 , wherein the response message is sent by the capability-aware proxy server to a regional cloud infrastructure orchestration system (CIOS) deployed outside the test environment.

5. Performing the release of the configuration file of the service includes: determining whether the release of the configuration file of the service is successful; and 10. The method of claim 1, further comprising: in response to unsuccessful execution, identifying at least one capability for which the capability-aware proxy server is not configured but which is required to execute the release of the configuration file for the service.

6. 10. The method of claim 1, further comprising: the capability-aware proxy server being deployed in an actual region and providing access to at least one resource type necessary to perform the release of the configuration file for the service.

7. the action taken with respect to the one or more resource types is: Creating a key, Deploying one or more data objects; or publishing an authorization policy for access of said one or more resource types; The method of claim 1 , comprising at least one of:

8. Configuring the capability-aware proxy server included in the test environment includes:

10. The method of claim 1, further comprising: setting rules for the capability-aware proxy server based on the one or more capabilities identified from the configuration file, the rules specifying one or more actions permitted for performing the release of the configuration file for the service.

9. A program for causing a computer to execute the method according to any one of claims 1 to 8.

10. one or more processors; a memory containing instructions, The instructions, when executed by the one or more processors, cause the system to: parsing a configuration file for a service to identify one or more capabilities for performing a release of the configuration file for the service, the one or more capabilities corresponding to operations to be performed with respect to one or more resource types; providing a test environment for executing the release of the configuration file of the service; configuring a capability-aware proxy server in the test environment based on the one or more capabilities identified from the configuration file for the service; performing the release of the configuration file of the service in accordance with the capability-aware proxy server in the test environment; The system generates a response message corresponding to a result of executing the release of the configuration file for the service.

11. 11. The system of claim 10, wherein the test environment includes a worker configured to provision at least one of an application host and a container in the test environment to perform the release of the configuration file of the service.

12. The instructions, when executed by the one or more processors, cause the system to: The system of claim 10 or 11, further comprising generating a transcript comprising one or more events that occur during execution of the release of the configuration file of the service in the test environment.

13. The system of claim 10 or 11, wherein the response message is sent by the capability-aware proxy server to a regional cloud infrastructure orchestration system (CIOS) deployed outside the test environment.

14. Performing the release of the configuration file of the service includes: determining whether the release of the configuration file of the service is successful; and 12. The system of claim 10 or 11, further comprising: in response to unsuccessful execution, identifying at least one capability for which the capability-aware proxy server is not configured but which is required to perform the release of the configuration file of the service.

Images