Technology for providing cloud services on demand

Abstract

To provide a method, a computing device, and a program for deploying computing resources (for example, services) in response to user input.SOLUTION: A method causes a computing device to receive a request including an identifier of a computing component of a cloud computing environment, determine whether the identifier is present in a routing table that is accessible through which the request has been received, and if so, forward the request to the computing component, and if not, sending an error code indicating that the computing component is unavailable and a bootstrap request to a deployment orchestrator that deploys the requested computing component, and once deployed, adding the computing component to the routing table such that subsequent requests are appropriately routed to and processed by the computing component.SELECTED DRAWING: Figure 8

Description

Technical Field

[0001] Cross-reference to related applications This application claims the priority of U.S. Patent Application No. 17 / 494,533 filed on October 5 , 2021 entitled "Techniques for Providing Cloud Services On Demand" and U.S. Patent Application No. 17 / 494,495 filed on October 5, 2021 entitled "Techniques for Providing Cloud Services On Demand", the entire disclosures of which are incorporated herein by reference for all purposes .

Background Art

[0002] Background In today's cloud computing environments, a predetermined set of cloud services may be deployed in a given region. It is not guaranteed that users in the region will use all deployed services. Deploying and maintaining unused services may waste valuable resources of the cloud computing environment. Additionally, it may be possible that a user may desire to use a service that was not initially deployed in the region. Currently, when a service call is made for an undeployed service, an error code is returned and the user's request remains unprocessed. Additionally, users may not be able to exercise any control over specific services deployed in the region. Modifications regarding the management and deployment of various services in a cloud computing environment can be made to improve user control and provide an improved overall user experience.

Summary of Invention

Means for Solving the Problems

[0003] Brief Summary Embodiments of this disclosure relate to providing the ability to deploy requested and / or ordered cloud computing resources (e.g., services) at runtime. More specifically, some embodiments provide a method, computer-readable medium, and system for implementing the ability to receive a request for a service that was previously not deployed, determine that the service is not currently deployed, and request bootstrap / deployment of the requested service via a cloud orchestration service. In some embodiments, a user interface can be provided that allows the service to be explicitly ordered / requested. The user interface provides the ability to request bootstrap / deployment of a particular service (e.g., via a cloud orchestration service).

[0004] One embodiment relates to a method for deploying cloud computing resources. The method may include a computing device in a cloud computing environment receiving a request containing an identifier for a computing component in the cloud computing environment. The method may further include the computing device determining whether the identifier exists in a routing table accessible to the computing device. The method may further include forwarding the request to the computing component according to the identifier present in the routing table. The method may include the computing device responding to the request by sending an error code indicating that the computing component is unavailable, in accordance with the absence of the identifier in the routing table, and the computing device computing the computing component to the cloud computing environment at least in part based on the bootstrap request. The method may further include sending to a deployment orchestrator in a cloud computing environment configured to deploy components. The method may further include receiving a subsequent request containing an identifier. The method may further include sending the subsequent request to the computing components for processing.

[0005] Another embodiment relates to another method for deploying cloud computing resources. This method may include a computing device in a cloud computing environment identifying a first set of computing components already deployed in the cloud computing environment. The method may further include the computing device identifying a second set of computing components available for deployment in the cloud computing environment. The method may further include the computing device receiving a request for deployment. In some embodiments, the request for deployment identifies a specific computing component of the second set of computing components available for deployment. The method may further include the computing device sending a bootstrap request corresponding to the specific computing component being requested to a deployment orchestrator in the cloud computing environment. In some embodiments, the deployment orchestrator is configured to deploy the specific computing component to the cloud computing environment based at least in part on the bootstrap request. The method may further include presenting a first set of status indicators for the first set of computing components already deployed in the cloud computing environment, and a user interface that presents status indicators corresponding to a specific computing component.

[0006] In some embodiments, the method may further include identifying that a particular computing component has been successfully deployed, adding an identifier associated with the particular computing component to a routing table, receiving a subsequent request containing the identifier, and sending the subsequent request to the particular computing component for processing.

[0007] In some embodiments, sending a bootstrap request causes the deployment orchestrator to perform actions including (at least) 1) identifying one or more computing components on which a particular computing component depends, and 2) deploying one or more computing components before deploying the particular computing component.

[0008] In some embodiments, identifying one or more computing components on which a particular computing component depends is at least partially based on determining one or more computing components from a directed acyclic graph that defines the computing component dependencies.

[0009] In some embodiments, the method may further include presenting information in a user interface that identifies one or more computing components on which a specific computing component being requested depends; receiving user input in the user interface indicating acceptance of deploying one or more computing components before deploying a specific computing component; and the computing device sending each bootstrap request corresponding to one or more computing components to the deployment orchestrator, each bootstrap request being sent before sending the bootstrap request corresponding to the specific computing component being requested.

[0010] In some embodiments, the method may further include sending a spin-down request to the deployment orchestrator corresponding to a particular computing component, the spin-down request being sent in response to 1) receiving a subsequent request to spin down the particular computing component, or 2) identifying the last time point in time when the last request for the particular computing component was received and determining that the difference between the last time point and the current time exceeds a predetermined threshold time.

[0011] In some embodiments, sending a spin-down request is further based at least in part on determining that none of the other components of the cloud computing environment depend on any particular computing component.

[0012] Another embodiment is directed towards a computing device in a cloud computing environment. In some embodiments, the computing device comprises one or more processors and memory that stores computer executable instructions, which, when executed by one or more processors, cause the computing device to perform one or both of the operations described above.

[0013] Another embodiment is directed to a non-temporary computer-readable storage medium containing computer-executable instructions, which, when executed by one or more processors of a computing device, cause a computing device in a cloud computing environment to perform one or both of the operations described above.

[0014] Another embodiment is directed to an apparatus for providing cloud services, comprising means for carrying out any step of the method described herein.

[0015] Another embodiment is directed to a computer program product that, when executed by a processor, includes computer instructions that perform any of the steps of the methods described herein.

[0016] To facilitate the identification of any particular element or behavior, one or more top-order digits in the reference number refer to the drawing number in which that element is first introduced. [Brief explanation of the drawing]

[0017] [Figure 1] This is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service, in at least one embodiment. [Figure 2] This is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service, in at least one embodiment. [Figure 3] This flowchart illustrates the flow of actions performed in response to an Application Programming Interface (API) call to a previously deployed service, according to at least one embodiment. [Figure 4] This flowchart illustrates the flow of actions performed in response to an API call to a service that has not yet been deployed, according to at least one embodiment. [Figure 5] This flowchart illustrates, in at least one embodiment, the flow of actions performed in response to an API call to another service that has not yet been deployed, when the service depends on another service that has also not yet been deployed. [Figure 6] This flowchart illustrates an exemplary process for orchestrating the execution of a task that includes a dependency on at least one function, according to at least one embodiment. [Figure 7]It is a flow diagram illustrating the flow of operations for spinning down unused services in accordance with at least one embodiment. [Figure 8] It is a flow diagram illustrating an exemplary process for orchestrating bootstrap of a service in response to receiving an API request in accordance with at least one embodiment. [Figure 9] It is a flow diagram for illustrating the flow of operations performed in response to ordering a service that has not yet been deployed in accordance with at least one embodiment. [Figure 10] It is a flow diagram for illustrating the flow of operations performed in response to ordering a service that has not yet been deployed when the service depends on another service that also has not yet been deployed, in accordance with at least one embodiment. [Figure 11] It is a diagram of an exemplary user interface for initiating the operations described above, inter alia, in accordance with at least one embodiment. [Figure 12] It is a flow diagram illustrating an exemplary process for orchestrating bootstrap of a resource in response to receiving an order request for the resource in accordance with at least one embodiment. [Figure 13] It is a block diagram illustrating one pattern for implementing cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 14] It is a block diagram illustrating another pattern for implementing cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 15] It is a block diagram illustrating another pattern for implementing cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 16] It is a block diagram illustrating another pattern for implementing cloud infrastructure as a service system in accordance with at least one embodiment. [Figure 17] It is a block diagram illustrating an exemplary computer system in accordance with at least one embodiment. [Modes for carrying out the invention]

[0018] Detailed explanation In some cases, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the internet). In some cases, IaaS is one of three main categories (or subcategories) of cloud computing services. Often, the other main categories are considered to be Software as a Service (SaaS) and Platform as a Service (PaaS), and sometimes SaaS is considered a broader category encompassing both PaaS and IaaS, and sometimes IaaS is considered a subcategory of PaaS.

[0019] 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)). In some cases, the IaaS provider can also supply various services to accompany these infrastructure components (e.g., billing, monitoring, logging, security, load balancing, and clustering). Therefore, since these services can be policy-driven, IaaS users may implement policies to drive load balancing in order to maintain application availability and performance.

[0020] In some cases, IaaS customers may use a wide area network (WAN) such as the internet. Through this, users can access resources and services and install the remaining elements of their application stack using the cloud provider's services. For example, a user can log into an IaaS platform, create virtual machines (VMs), install an operating system (OS) within each VM, deploy middleware such as databases, create storage buckets for workload and backups, and even install enterprise software on those VMs. Customers can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0021] In some cases, IaaS deployment is the process of placing a new application or a new version on a pre-configured application server, etc. This may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider under the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Therefore, the customer may take on roles such as handling (OS), middleware, and / or application deployment (e.g., on a self-service virtual machine, e.g., which can be spun up on demand).

[0022] In some cases, IaaS can be used to provision an initial set of infrastructure components (e.g., services). In some embodiments, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more configuration files. The overall topology of the infrastructure (e.g., which resources depend on which and how they each cooperate) can be described declaratively. In some cases, once the topology is defined, workflows can be generated to create and / or manage the different components described in the configuration files.

[0023] As mentioned above, one way to prepare infrastructure is to describe it declaratively. Therefore, a configuration file can be a declarative file that describes only each of the infrastructure components mentioned above and how they interact. A configuration file can describe resources and the relevant fields necessary to create elements, and therefore can describe other elements that reference previously described elements. In some examples, a preparation tool can then generate a workflow for creating and managing the elements described in the configuration file.

[0024] In some cases, the preparation tool's workflow can be configured to perform various commands. One function that can be performed is view matching, where the preparation tool can compare a current view of the infrastructure (e.g., the predicted state of the infrastructure) to how the infrastructure is actually operating. In some cases, performing the view matching function may involve querying various resource providers or infrastructure resources to identify which resources are actually operating. Another function that the preparation tool can perform is plan generation, where the preparation tool can compare the infrastructure components that are actually operating to what the preparation tool wants to approximate (e.g., a desired configuration). In other words, the plan generation function can determine the changes that need to be made to bring resources up to the latest forecast. In some cases, a third function may be an execution (e.g., apply) function, where the preparation tool can execute the plan generated by the plan generation function.

[0025] Generally, preparation tools can be configured to retrieve configuration files, parse the declarative information they contain, and programmatically / automatically determine the order in which resources need to be prepared to execute a plan. For example, if a virtual private cloud (VPC) needs to be booted before security group rules and VMs are booted, the preparation tool can make that determination and enable the booting to proceed in that order without user intervention and / or without that information necessarily being included in the configuration files.

[0026] In some cases, sequential deployment techniques may be used to enable the deployment of infrastructure code across various virtual computing environments. Additionally, the techniques described can enable infrastructure management within these environments. In some examples, a service team may write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across various different geographical locations, sometimes worldwide). However, in some examples, the infrastructure to which the code is deployed must first be set up. In some cases, this preparation can be done manually, with preparation tools being used to prepare resources and / or deployment tools being used to deploy the code once the infrastructure is prepared.

[0027] As mentioned above, generally speaking, there are two different tools used to handle the preparation of infrastructure resources and the deployment of code to control those infrastructure resources, respectively, with the orchestration between the two tools being done manually. However, as scale increases, manual implementations inevitably lead to deviations. Therefore, automated tools that can handle both the preparation and deployment of virtual infrastructure enable more efficient and reliable techniques for implementing virtual cloud environments.

[0028] In some cases, when two tools are used, problems can arise if a user manually makes code changes between the preparation and deployment phases. The technique of using a single tool for both preparation and deployment, as described herein, can mitigate this problem by automating the process so that there is no opportunity for manual code changes. It is possible that a slight change in how a user codes something can cause a major problem in the deployment phase. In some cases, if an operator first implements a new action in a new region (e.g., a typo in the code), the object coded with that typo may remain permanently. If the application is deployed with that typo and the application is not affected by that typo (e.g., it still functions), then at some point in the future, additional code changes may come under the influence of that typo, potentially crashing the entire system. Therefore, the techniques provided herein can often eliminate the gap between preparation and deployment that can cause problems.

[0029] Generally, modeling deployments are declarative, and as a result, infrastructure resources can be declared using configuration files. For example, create, read, update, and delete (CRUD) instructions are commonly used to generate deployment files using the concept of Representational State Transfer (REST) ​​(e.g., the REST Application Programming Interface (API)). However, deployment itself does not generally follow the same concept. Additionally, infrastructure preparation tools tend to be powerful and / or expressive, while tools for deployment tend to be much more restrictive in terms of the actions they can perform (e.g., they are declarative, as opposed to declarative). (This is a critical requirement.) Therefore, there has long been a need for a tool that can handle both functional requirements (e.g., preparing and deploying infrastructure elements) within a cloud environment.

[0030] Embodiments disclosed herein may utilize a Cloud Infrastructure Orchestration Service (CIOS), which can be configured to manage both the preparation and deployment of infrastructure assets within a cloud environment. In some cases, CIOS may include two classes of services: central and regional components (e.g., CIOS Central and CIOS Regional).

[0031] CIOS can be described as an orchestration layer that applies configuration to downstream systems (e.g., globally). It is designed to enable the preparation and code deployment of global infrastructure without manual effort from service teams (e.g., beyond initial approval in some cases). The high-level roles of CIOS include, but are not limited to, the following: • To provide teams with a view of the current state of resources managed by CIOS, including any ongoing change activities. • Help the team plan and release new changes. • Coordinating activities across various downstream systems within a region to implement approved release plans without human intervention. • Coordinating activities across multiple regions / domains to execute approved release plans globally.

[0032] Evolving existing infrastructure (e.g., adding new services, modifying services, removing services, etc.) after everything has been prepared can be difficult. Traditionally, if a service that was not previously prepared is requested (e.g., via an API call), the request will be rejected, and the user will be unable to access the service. Additionally, services that are no longer available (or at least not being utilized according to some predetermined threshold) may continue to operate even after they are no longer needed, wasting resources. To address these shortcomings, IaaS can be configured to implicitly identify when to add new services and / or when to remove services, and to take corresponding actions to automatically deploy or scale back services. Additionally, or alternatively, IaaS can be configured with a user interface from which users can explicitly request the addition or removal of services, view the current status of various services, etc. These techniques can provide improved control, as well as an overall more seamless and less frustrating user experience.

[0033] Figure 1 is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service according to at least one embodiment. For example, Figure 1 shows architecture 100 to illustrate the technology for implementing CIOS Central 102. In some examples, CIOS Central 102 is a service that handles operations at the "Flock" level. It is possible. A flock can be a model that CIOS can use to encapsulate the control plane and all its components. A flock can be used to model ownership of infrastructure components and to point out infrastructure components. Infrastructure components can be long-lived infrastructure that supports the execution of code (e.g., deploying applications, loading (e.g., balancers, Domain Name System (DNS) entries, object storage buckets). A flock configuration file can be used to describe a set of infrastructure components, artifacts, and deployment tasks associated with a single service. Each flock may have one flock configuration file (referred to herein as a “flock config”). Flock configs are checked into source control. Flock configs are declarative and take as input the domain, region, availability domain (AD), and artifact version. An artifact refers to code being deployed to a deployment application or Kubernetes engine cluster, or configuration information (hereinafter referred to as a “config”) being applied to an infrastructure component.

[0034] In some embodiments, the CIOS central 102 has several roles, including, but not limited to, the following: • To act as an authentication gateway for flock metadata changes and release operations. • Remember the deployment artifacts of the flock metadata for that flock and the authoritative mapping to the CIOS repository. • Coordinating global releases across multiple phases and objectives. Synchronization to enforce policies such as "one or fewer ongoing releases per flock at a time." • Detect changes to the flock configuration (config) and artifacts, and trigger release generation in response to such changes.

[0035] In some examples, the Source Code Version Control Management Service (SCVMS) 104 can be configured to store authoritative flock configurations, and the CIOS Central 102 can subscribe to the Artifact Notification Service (ANS) 106, thereby enabling the CIOS Central 102 to receive notifications of new artifact builds. The CIOS Central 102 can then map incoming changes to the affected flocks and, if desired, initiate a release plan. Additionally, in some examples, before releasing to the target, the CIOS Central 102 can invoke the Artifact Push Service (APS) to ensure that any artifacts required for a successful release are present in the target region before the release.

[0036] In some examples, a customer (e.g., an engineer) 108 may call CIOS Central 102 to perform CRUD operations on flocks and / or releases and to view the status of ongoing CIOS activities. A flock management service 110 may include one or more APIs for manipulating flocks, a browsing / planning / approval service 112 may include CRUD APIs for creating and approving plans and viewing a central copy of the state of all CIOS managed resources, a change monitoring service 114 may keep an eye on SCVMS 104 for changes to flock configurations and receive notifications from ANS 106 about changes to other artifacts, and a state ingestor service 116 may create copies of each region state in the CIOS Central Database (DB) 118 (e.g., point-in-time snapshots of the state of region resources), which the browsing / planning / approval 112 may then expose. The state ingestor service 116 may be any suitable service / computing device configured to determine the state of a region resource and generate a point-in-time snapshot of it. In some cases, the CIOS Central DB 118 can be the database for flocks, plans, and status. Flock information can be authoritative, while everything else is a trite copy of data from the CIOS Regional DB 120. It is possible. CIOS Central 102 can be configured to provide any suitable part and / or any suitable number of user interfaces for presenting any suitable data related to flocks, releases, infrastructure components, artifacts, etc. In some embodiments, CIOS Central 102 can present data related to one or more releases via any suitable interface. A release may include any suitable combination of tasks related to one or more infrastructure components and / or one or more code changes (e.g., artifacts) to one or more applications.

[0037] In some cases, engineer 108 may make API calls to the flock management service 110 (e.g., through the ingress proxy fleet 122) to create a list of flocks. The protocol for making such API calls may be Hypertext Transfer Protocol Secure (HTTPS), etc. The access control list (ACL) associated with this operation may include the local area network (LAN) 124 or other private connections. For example, CIOS may manage / control alternative network connections (e.g., dedicated, leased, and / or private connections) that use the public internet to connect a customer's business data center or network to CIOS. Additionally, authentication and authorization (e.g., of engineer 108) may be performed by a reservation system portal that enables users to manage the machine infrastructure (e.g., a reservation service). In some cases, CIOS Central 102 may store flock metadata, plans, and status in Central DB 118 using Java® Database Connection (JDBC), etc. In some examples, ANS106 can be configured to notify the change monitoring service 114 when a new artifact is issued. ANS106 may use HTTPS, and both authentication and authorization may be handled by the mutual transport layer security service. Additionally, in some cases, the change monitoring service 114 may poll SCVMS104 for flock configuration changes. This polling can be performed using Secure Shell (SSH) or other protocols. Authentication of the change monitoring service 114 may be handled by the CIOS system account, and authorization may be handled by SCVMS104.

[0038] In some examples, Engineer 108 can use the Browsing / Planning / Approval Service 112 to perform one or more of the following actions: Engineer 108 can plan and / or approve by calling CIOS Central 102 to generate and approve plans. Engineer 108 can perform browsing by calling CIOS Central 102 to view the status of ongoing CIOS activities on a global scale. Additionally, Engineer 108 can perform browsing by calling CIOS Central 102 to view replicas of the state of CIOS managed resources on a global scale. These API calls (or similar) can be made via the HTTPS protocol or a similar protocol. Additionally, the relevant access control lists (ACLs) can be controlled by LAN 124, and both authentication and authorization can be handled by the Reservation Service. In some examples, the Browsing / Planning / Approval Service 112 can request plans and push plan approvals to all regions of CIOS Regional 120 (e.g., using HTTPS or similar). The relevant ACLs can be controlled using security lists managed by the wide area network (WAN) gateway 126. Authentication can be handled by mutual transport layer security, and authorization can be handled by various identity policies. Furthermore, the state ingestor service 116 uses CIOS to check job status or state changes. The regional gateway 120 can be monitored, and as a result, CIOS can provide a central view of them upon request (for example, using HTTPS or similar). ACLs for this purpose can also be handled by the WAN gateway 126, and both authentication and authorization can be handled by the mutual transport layer security service.

[0039] Figure 2 shows Architecture 200 to illustrate the techniques for implementing at least CIOS Regional 202. In some examples, CIOS Regional 202 is where much of the declarative preparation and planning work, as well as the application of approved releases, may take place. In some cases, each instance of CIOS Regional 202 may handle operations at the level of "Execution Targets". It may have a region fronted. This can be configured to do the following: • Handle all CIOS authentication related to operations coming from CIOS Central 102. • Enforce the rule that only one "execution" (planning / resource import / plan application) can be in progress at a time for a given execution objective. • Manage binary artifact storage for declarative infrastructure preparation artifacts used as inputs and outputs during declarative infrastructure preparation execution. Examples of inputs are declarative infrastructure preparation configuration files and input state files. A typical output is the final state file. • Request work from the CIOS execution unit for any given execution and poll for the results from the CIOS execution unit.

[0040] In some cases, the CIOS frontend may be able to handle the actual execution and may rely on the CIOS execution unit 206 (also referred to herein as the “scheduler”). In some examples, the CIOS execution unit operates at the “execution” level and can do the following: • Track the pool of available worker nodes. • Inquiring about incoming job requests and assigning them to eligible workers as they become available. • Track worker status and execution updates to report to clients. • It is possible to detect dead nodes via the lease protocol and, depending on the task status, abandon tasks assigned to dead nodes. • Provides equipment for canceling / stopping / pausing / resumeing execution, and can map these to the equipment to communicate the cancel / stop / resume information to the worker nodes.

[0041] In some cases, the CIOS execution unit may rely on CIOS workers that can assign tasks for execution to workers and provide the facilities for workers to update job progress. Worker services operate at the "task" granularity. Each worker is an agent that executes the tasks assigned to it and reports the task status and output. Each worker can do the following: • Polling the execution unit worker API for assigned work items and taking measures to match the assigned state to its local state.

[0042] ○ Start a container to poll for task items that do not exist locally. ○ Stop a container that is running locally and does not have a corresponding assigned task item. • Report the job status. • Dividing inputs and outputs into stages for job container execution. • Launch and monitor declarative infrastructure-ready containers to perform the actual work required for the release of the execution goals.

[0043] A CIOS worker may depend on the CIOS execution unit to poll for work from its worker endpoint and report results to that worker endpoint. The worker may rely on the execution unit for all coordination. Additionally, a CIOS worker may also depend on CIOS Regional 202 if the worker service reads input from one or more APIs associated with a regional frontend service and writes output to those APIs. Examples of inputs include configuration and startup state files and import mappings. Examples of output include declarative preparation processes, output declarative preparation state files, and import result states.

[0044] In some examples, CIOS Regional 202 can be a regional service for managing regional instances / deployments of CIOS. CIOS Regional 202 covers the role of authoritatively storing and managing plans and states (stat) associated with a particular region. Regional DB 204 may be a CIOS DB for the states and plans of a particular region. This is an authoritative copy of a regional subset of the central DB 118 in Figure 1. Scheduler 206 may be responsible for managing worker fleet capacity, assigning tasks to workers, and tracking task states. In some cases, Task DB 208 is another CIOS DB for task states. The data in this DB is mostly for operational purposes. Additionally, workers 210 can be a fleet of Java Virtual Machines (JVMs) managing declarative preparation images. These receive instructions from Scheduler 206 and communicate the results to both Scheduler 206 and CIOS Regional 202. CIOS container 212 can perform declarative preparation actions in its own private Docker 214 container. This container does not need to contain secrets. Additionally, in some examples, the signing proxy 216 can be configured to prevent secret disclosure via the declarative preparation tool in order to avoid placing secrets within the declarative preparation image. Instead, CIOS can perform request signing or initiate a Mutual Transport Layer Security (mTLS) service at the proxy. This also makes it easier to use FIPS-compliant cryptographic libraries.

[0045] In some cases, CIOS Central 102 can call CIOS Regional 202 (service principal) to create plans, push approvals, monitor job status, and extract declarative provisioner status. Ingress proxy 218 can be configured as an ACL, and various identity policies may be used for both authentication and authorization. Alternatively, in some cases, ingress proxy 218 may be replaced by a load balancer configured to balance load-inducing requests, plans, etc. In some cases, CIOS Regional 202 can activate the declarative provisioner by asking Scheduler 206 to do so. Worker 210 can ask Scheduler 206 what the worker should be doing and report the status to Scheduler 206 when done. In some cases, mTLS can handle both authentication and authorization for CIOS Regional 202 and Worker 210. Additionally, when worker 210 needs to activate a declarative provisioner, the worker does so within the Docker container by interacting with local Docker 214. Authentication at this stage can be handled by a local Unix® socket. The Docker protocol may be used for this final step, while HTTPS may be used for the previous steps.

[0046] In some embodiments, CIOS Regional 202 can be configured to provide any suitable part and / or any suitable number of user interfaces for presenting flocks, releases, infrastructure components, artifacts, or any suitable data relating to such things. In some embodiments, CIOS Regional 202 can present data relating to one or more releases via any suitable interface. A release may include any suitable combination of tasks relating to one or more infrastructure components, and / or one or more code changes (e.g., artifacts) to one or more applications.

[0047] In some cases, the CIOS container 212 allows a declarative provisioner to interact with the signing proxy 216 (via an API), while the declarative provisioner considers this as calling various CIOS services. The signing proxy 216 listens on one ephemeral port for each instance of a call from the declarative provisioner, known only to that declarative provisioner. The signing proxy 216 can initiate request signing or mTLS and pass the declarative provisioner's call to other CIOS services within the service enclave. In some cases, the signing proxy 216 can also communicate with one or more public CIOS services 220. For example, the signing proxy 216 uses the internal endpoint of a public service where possible. For services without an internal endpoint, it must use the egress proxy 222 to reach the external endpoint. This use of the signing proxy 216 may not be for inter-regional communication; for example, each region's egress proxy whitelist may be for only the public IP range of that region. In some cases, worker 210 can then maintain the state and logs from the declarative provisioner in CIOS regional 202, and as a result, leak them to CIOS central 102.

[0048] Configuration files can be parsed using CIOS (or a declarative infrastructure provisioner such as the CIOS declarative preparation tool mentioned above). Through this parsing, CIOS (or the declarative preparation provisioner) can generate a directed acyclic graph (DAG) for each resource, module, and / or function, which compiles and defines an ordered list of dependencies on other resources, modules, and / or functions. While attempting to deploy a resource, CIOS can traverse the DAG to identify when a resource depends on another resource, module, and / or a function of another resource. The DAG for each resource can specify implicit dependencies, explicit dependencies, or a combination thereof, and can be used with CIOS to boot or otherwise deploy the corresponding resource.

[0049] Figure 3 is a flowchart illustrating the flow 300 of an operation performed in response to an application programming interface (API) call to a previously deployed service (e.g., service 302) according to at least one embodiment. Service 302 may be one of a set of previously deployed services deployed within a given region. The services discussed in the following drawings are examples of computing components in the cloud computing environment of Figures 1 and 2. The same examples can be applied to other computing components (e.g., databases, object storage, block storage, virtual machines, etc.). Computing components as used in this disclosure may include any suitable computing device, computer program product, processor, and / or service.

[0050] Flow 300 can be started at 304 and by user device 306 API requests can be made. In some embodiments, APIs can be made via the HTTPS protocol or a similar protocol. Requests may include any appropriate information, such as a user identifier, an identifier for the service associated with the request, etc. API calls may be received by a gateway computer 308, which may be an example of a computer implementing the WAN gateway 126 in Figure 1. The gateway computer 308 may be configured to maintain a routing table for previously deployed regional services (e.g., cloud services A-N in Figure 2). The routing table may include the Internet Protocol (IP) addresses of each service and / or infrastructure component in the environment provided by the architectures in Figures 1 and 2. The routing table may include any appropriate information necessary to forward data packets toward their destination. For example, the routing table may include the destination network identifier (e.g., IP address), the subnet mask used to match the destination IP address with the network ID, and any appropriate information configured to enable the data packets to be forwarded toward the destination.

[0051] In 310, the gateway computer 308 (or any suitable component in Figure 2, such as the ingress proxy 218, CIOS regional 202, etc.) can authenticate the user of the API call. In some embodiments, authentication may involve making API calls to one or more services (e.g., an identity service) configured to maintain authorization and / or identity data for one or more users of the system. For example, the gateway computer 308 may call an identity service which consists of authorization and / or identity data that can be made available along with a user identifier, which is received in the request to identify the user and / or one or more authorization policies associated with that user.

[0052] In 312, a determination can be made as to whether an API call can be routed. This determination may include any appropriate combination of identifying whether 1) the user is the intended person, 2) the user has the authority to invoke such a function of service 302, or 3) whether the service identifier (e.g., an IP address) is included in the current routing table maintained by gateway computer 308. For example, if the user's identity is known and / or the authorization associated with the user indicates that the user has the authority to make the API call, and the service identifier for service 302 is included in the routing table maintained by gateway computer 308, then gateway computer 308 can forward the request to service 302. This forwarding may include identifying the destination address associated with service 302 from the routing table and the service identifier received in the message and associated with service 302.

[0053] In 314, service 302 can receive an API call and perform any appropriate action to process the call. Once processing is complete, in 316, the service can return a response to gateway computer 308. In some embodiments, this response may indicate whether processing was successful (e.g., completed) or unsuccessful (e.g., not completed / not permitted).

[0054] In 316, the user device 306 can receive a response and perform any appropriate action, such as displaying to the user an indication that the API call was successfully processed, although this is not limited to such actions.

[0055] Alternatively, in 312, gateway computer 308 (or another suitable one in Figure 2) The gateway computer 308 (or other appropriate component) can determine that an API is not routable. For example, if the user is not the intended person and / or the user does not have permission to make such an API call and / or the service identifier (e.g., IP address) is not included in the current routing table maintained by the gateway computer 308, the gateway computer 308 (or other appropriate component) can determine that the API call is not routable and can forward a return error code (e.g., an alphanumeric code indicating a general or specific error) to the user device 306.

[0056] In 322, the user device 306 can be configured to perform one or more actions to handle errors, such as displaying an error instruction on the screen or enabling a user option to attempt another request.

[0057] Figure 4 is a flowchart illustrating the flow 400 of actions performed in response to an API call to a service that has not yet been deployed (e.g., service 402) according to at least one embodiment. In some embodiments, a predetermined set of services may have been previously deployed within a region and / or be accessible to a user device by an API call. Service 402 may not be included in that initial predetermined set of deployed services.

[0058] Flow 400 can be initiated at 404, and an API request may be made by a user device 406 (for example, an example of user device 306 in Figure 3). In some embodiments, the API call may be made via the HTTPS protocol or a similar protocol. The API call may contain any appropriate information, such as a user identifier, an identifier for the service associated with the request, etc. The API call may be received by a gateway computer 408, which may be the same as or similar to gateway computer 408, and may be an example of a computer implementing the WAN gateway 126 in Figure 1. Similar to the gateway computer described above, gateway computer 408 may be configured to maintain routing tables for previously deployed regional services (for example, cloud services A-N in Figure 2). The routing tables may include the Internet Protocol (IP) addresses of each service and / or infrastructure component in the environment provided by the architectures in Figures 1 and 2. The routing tables may contain any appropriate information necessary to forward data packets toward their destinations. For example, a routing table may include the destination network identifier (e.g., an IP address), the subnet mask used to match the destination IP address against the network ID, and any other appropriate information configured to allow the data packet to be forwarded toward the destination.

[0059] In 410, the gateway computer 408 (or any appropriate component in Figure 2, such as the ingress proxy 218, CIOS regional 202, etc.) can authenticate the user of the API call. As described above, authentication may involve making API calls to one or more services (e.g., an identity service) configured to maintain authorization and / or identity data for one or more users of the system. For example, the gateway computer 308 may call an identity service which consists of authorization and / or identity data that can be made available along with a user identifier, which is received in the request to identify the user and / or one or more authorization policies associated with that user. As another example, the gateway computer 408 may maintain user data associated with any appropriate number of users and API calls Any appropriate information obtained from the data (for example, an identifier associated with the user) can be used to authenticate the user against their user data.

[0060] In 412, a determination can be made as to whether or not an API call can be routed. This determination may include any appropriate combination of identifying whether 1) the user is the intended person, 2) the user has the authority to invoke such a function of service 302, or 3) whether the service identifier (e.g., an IP address) is included in the current routing table maintained by gateway computer 408. This determination may be the same as that made in 312 in Figure 3.

[0061] If the API call is not routable (for example, service 402 has not yet been deployed, is not included in the routing table, etc.), flow 400 can proceed to 414, which can forward the return error to user device 406 and send data to orchestrator 416 (e.g., CIOS Central 102 in Figure 1) indicating that the requested service (e.g., service 402) should be bootstrapped.

[0062] In 418, the user device 406 may be configured to perform one or more actions to handle the error, such as displaying an error instruction on the screen or enabling a user option to attempt another request. Once another API call is made, the flow may return to 404, and the remainder of the flow may be repeated any appropriate number of times. The actions in 414, 418, and 420 may be performed in any appropriate order.

[0063] In 420, the orchestrator 416 may receive a bootstrap request and perform any appropriate actions to bootstrap a non-existent service (e.g., service 402) (e.g., load it into memory (e.g., the memory of a virtual machine) and / or initialize it). In some embodiments, the orchestrator 416 may utilize a predetermined set of instructions associated with bootstrapping service 402. For example, a directed acyclic graph (DAG) associated with service 402 may be used to identify one or more instructions for bootstrapping service 402. In some embodiments, this DAG is part of a larger DAG that maintains the interdependence of various services with the functionality of other services (e.g., specific parts of functionality provided by another service). The DAG associated with service 402 may contain any appropriate number of nodes and edges, each edge of which may be any appropriate part of a finite directed graph directed from one node to another. The nodes and edges may be arranged and configured to avoid directed cycles. Therefore, a finite directed graph (e.g., a DAG) is constructed such that at any given node, it does not follow a consistently directed set of edges that start and eventually loop back to that same node. The last node of a finite directed graph can point to a null value or, in other ways, indicate the end of the finite directed graph.

[0064] In some embodiments, each node in a DAG corresponds to a set of actions or functions on which the next action node depends. Each directed edge in the DAG defines the order in which these actions should be performed, and / or the dependencies between a subset of actions associated with a node and a subset of functions associated with the preceding node. The actions of each node should be performed in an order corresponding to the node's order and may individually correspond to one or more dependencies. For example, a first node in the DAG may correspond to an action dependency of a third node in the DAG (e.g., corresponding to service 402) for a function associated with a different resource (e.g., service A). Similarly, a second node in the DAG may correspond to an action dependency of a third node in the DAG (e.g., corresponding to service 402). The node may correspond to the operational dependencies of a third node (e.g., representing service 402) for functions associated with different resources (e.g., resource B). In some embodiments, different function nodes (e.g., nodes that identify dependencies on one or more functions of a particular resource) may be used for different resources, or a single node may be used to specify all dependencies regardless of the number of resources the dependencies refer to. Thus, in some embodiments, the dependencies of service 402 on service A and resource B can be combined into a single node.

[0065] By traversing a DAG, it is possible to orchestrate the execution of actions to boot and / or deploy a resource (e.g., service 402) within a cloud computing environment with respect to one or more dependencies on the functionality of other resources (or the other resources themselves).

[0066] In 422, once service 402 is bootstrapped (for example, a predetermined image of service 402 is deployed to a specific computer in the environment / region) and ready to accept subsequent requests, the orchestrator 416 can send data (e.g., an IP address associated with service 402, an alphanumeric identifier associated with service 402, etc.) to the gateway computer 408 to update the routing table maintained by the gateway computer 408. The gateway computer 408 can be configured to update the routing table with any appropriate portion of the data provided by the orchestrator 416 and associated with service 402. Although not shown, in some embodiments, the gateway computer 408 can send any appropriate data to the user device 406 to indicate that service 402 is ready.

[0067] Subsequently, the user can initiate a new API call at 404, and the operations of 404-412 can be repeated. At this point, the routing table contains data associated with service 402 (e.g., service identifier, IP address of service 402, etc.), and the determination made at 412 can indicate that the API call is now routeable to service 402, allowing the API call to be forwarded to service 402 at 424. In some embodiments, service 402 (or gateway computer 408) can start a timer for a predetermined time. This timer can be configured to maintain knowledge of when service 402 was last called. The purpose here is to allow service 402 to be scaled down if no other API call is received for that service within a predetermined time period since the last received API call. An example of this process is described in more detail with reference to Figure 7.

[0068] In 426, the service may return a response to the gateway computer 408. In some embodiments, this response may indicate whether the processing was successful (e.g., completed) or unsuccessful (e.g., not completed / not permitted). The gateway computer 408 may forward the response to the user device 406.

[0069] In 428, the user device 406 receives the response and can perform any appropriate action, such as, but not limited to, displaying to the user an indication that the API call was successfully processed.

[0070] If service 402 becomes available first after the initial API call described above, then flow 400 will boot because the service was already available at the time of the API request. Please understand that you can proceed from 412 to 424 while skipping the entire strapping process and routing table update.

[0071] Figure 5 is a flowchart illustrating the flow of actions 500 performed in response to an API call to a service that has not yet been deployed (e.g., service 502), when the service depends on another service that has also not yet been deployed, according to at least one embodiment.

[0072] Flow 500 can be initiated in 504, and an API request may be made by a user device 506 (for example, an example of user device 406 in Figure 4). In some embodiments, the API may be performed via the HTTPS protocol or a similar protocol. The operations performed in 504, 510, 512, 514, and 518 may be substantially the same as the operations discussed in 404, 410, 412, 414, and 418 in Figure 4. The operations performed in 530 may be substantially the same as the operation discussed in 424 in Figure 4, and may be performed by service 502 or gateway computer 508. API calls may be received by gateway computer 508, which may be the same as or similar to gateway computer 408 in Figure 5, and may be an example of a computer implementing the WAN gateway 126 in Figure 1.

[0073] In 520, in response to receiving a request for a bootstrap request transmitted in 514 (e.g., an API request received from a user device 506), the orchestrator 516 (e.g., the CIOS central 102 in Figure 1) may perform any appropriate action to bootstrap a non-existent service (e.g., service 502, an example of service 402 in Figure 4) (e.g., load it into memory (e.g., the memory of the virtual machine) and / or initialize it). In some embodiments, the orchestrator 516 may utilize a predetermined set of instructions associated with bootstrapping service 502. For example, a directed acyclic graph (DAG) associated with service 502 may be obtained (e.g., from memory) and used to identify one or more instructions for bootstrapping service 502.

[0074] Figure 6 is a flowchart illustrating an exemplary process 600 for orchestrating the execution of a task (e.g., resource deployment / bootstrapping, such as service 502 in Figure 5) that involves dependencies on at least one function (e.g., a function of a different resource) by at least one embodiment. As shown in Figure 6, the process flow 600 includes a scheduler 602 (e.g., scheduler 206 in Figure 2), a worker 604 (e.g., worker 210 in Figure 2), and a process 606 (e.g., an example of CIOS container 212 in Figure 2).

[0075] In 608, the scheduler 602 can receive tasks to deploy one or more infrastructure components / resources (e.g., service 502) within a region, and the scheduler 602 can send data related to the tasks to the worker 604. In some embodiments, the scheduler 602 can instantiate the worker 604 to handle the deployment of the resources (e.g., service 502).

[0076] In 610, worker 604 can instantiate a computing process 606 which can be configured to run an instance of a declarative infrastructure provisioner (e.g., a declarative preparation tool such as Terraform).

[0077] In 612, the computing process 606 performs a configuration associated with the deployment. By analyzing the file, a directed acyclic graph (DAG) can be generated for a specific resource (e.g., service 502).

[0078] As described above, each node in the DAG corresponds to a set of operations or functions on which the next operation node depends. Each directed edge of the DAG defines the order in which these operations should be performed, and / or the dependencies between a subset of operations associated with a node and a subset of functions associated with the preceding node. The operations of each node should be performed in an order corresponding to the order of the nodes and may individually correspond to one or more dependencies. Through the analysis of the configuration, computing process 606 can identify any appropriate number of implicit and / or explicit dependencies on the functions of other resources. For example, computing process 606 may identify that service 502 depends on another service (referred to as "service B"). Once identified, computing process 606 constructs a DAG that potentially specifies a task for booting and / or deploying the resource by one or more nodes corresponding to the functions on which the resource depends (e.g., according to the implicit and / or explicit dependencies identified during the analysis). In some embodiments, the DAG may already be generated and stored in memory. In this situation, the DAG can be simply retrieved rather than regenerated through analysis.

[0079] In 614, the computing process 606 may begin traversing the DAG and, upon reaching various nodes of the DAG, perform at least a portion of the deployment and / or booting of a particular resource. Depending on at least one node of the DAG, any appropriate action may be performed to make a portion of the functionality corresponding to the resource available. Multiple portions of the functionality corresponding to a resource may become available. In some embodiments, the computing process 606 may send a notification (not shown) to the scheduler 602 indicating that one or more functions of a resource are currently available. At least one of the nodes of the DAG may correspond to the functionality of one or more other resources. Upon reaching these types of nodes, the computing process 606 may check to determine whether the functionality is available. If so, the computing process 606 may proceed by traversing the DAG.

[0080] In 616, the computing process 606 can reach a node in the DAG that corresponds to one or more functions of one or more other resources. In some embodiments, the computing process 606 can determine that at least one function associated with a node is not yet available.

[0081] In 620, in response to a determination that at least one function associated with a node is unavailable, computing process 606 may send data to scheduler 602 indicating one or more functions on which the resource corresponding to computing process 606, which has been determined to be unavailable, depends.

[0082] In 622, the computing process 606 may terminate after potentially storing state information indicating which operations and / or nodes of the DAG have already completed, and / or which particular node of the DAG the computing process 606 last accessed. The computing process 606 may terminate execution, be stopped, suspended, or otherwise aborted.

[0083] In 624, scheduler 602 waits for a specific resource to resume booting and / or for one or more specific functions required for deployment purposes. It can store information indicating that it was present.

[0084] In 626, the scheduler 602 may receive one or more notifications indicating that one or more functions that a resource has been waiting for have become available. In some embodiments, the scheduler 602 may receive various notifications from other computing processes (e.g., threads) indicating various functions of the corresponding resource when those functions become available. The scheduler 602 may maintain one or more records of the various functions that are available and / or various functions that the resource is currently waiting for. The scheduler 602 may identify from one or more records that a particular one or more functions that a resource corresponding to computing process 606 has been waiting for have become available. Thus, the scheduler 602 can proceed to 628.

[0085] In step 628, in response to the determination that a function on which the resource corresponding to computing process 606 depends has become available, the scheduler 602 may return to step 608 and send data related to the original task (e.g., deploying the resource) to worker 604. In some embodiments, the scheduler 602 may instantiate a new worker or utilize the previous worker 604 (as illustrated) to continue handling the task associated with the resource. Worker 604 may instantiate a process (not illustrated) that can be configured to parse a configuration file to generate (or otherwise obtain) a DAG of the resource. That process can access stored state information to identify the node that was last accessed in the DAG (e.g., the node corresponding to one or more functions that the resource was waiting for). At this point, since one or more functions are available, the process may proceed by traversing the DAG as described above, performing operations at each node, executing parts of the task, or checking the functions on which the next part of the task depends, until the operation to deploy / bootstrap the resource (e.g., service 502) is complete.

[0086] A process similar to that described above may be performed for all resources of the task. For example, when deploying a system with multiple resources (e.g., multiple services), process 600 may be performed on behalf of each resource to deploy each resource in the system.

[0087] Returning to Figure 5, in 520, the orchestrator 516 can identify one or more dependencies associated with service 502. As described above, a DAG associated with service 502 can be obtained (e.g., generated or retrieved from memory). One or more nodes in the DAG may correspond to one or more dependencies. As a non-limiting example, the DAG of service 502 (or the portion of the DAG associated with service 502) may indicate that service 502 depends on another service (e.g., service B). That is, a node corresponding to service B may be provided before the node corresponding to service 502.

[0088] In accordance with the identification of the dependency on Service B, in 522, the orchestrator 516 may perform any appropriate action for the deployment / bootstrapping of Service B. In 524, once Service B has been bootstrapped (e.g., a predetermined image of Service B has been deployed to a specific computer in the environment / region) and is ready to accept subsequent requests, the orchestrator 516 sends data (e.g., an IP address associated with Service B, an alphanumeric identifier associated with Service B, etc.) to the gateway computer 508, which is maintained by the gateway computer 508. The routing table can be updated. The gateway computer 508 can be configured to update the routing table with any appropriate portion of the data provided by the orchestrator 516 and associated with service B. Although not shown, in some embodiments, the gateway computer 508 can send any appropriate data to the user device 506 to indicate that service B is ready.

[0089] At 526, the orchestrator 516 can identify that service B is deployed and proceed to perform any appropriate action for deploying / bootstrapping service 502. At 528, once service 502 is bootstrapped (e.g., a predetermined image of service 502 is deployed to a specific computer in the environment / region) and ready to accept subsequent requests, the orchestrator 516 can send data (e.g., an IP address associated with service 502, an alphanumeric identifier associated with service 502, etc.) to the gateway computer 508 to update the routing table maintained by the gateway computer 508. The gateway computer 508 can be configured to update the routing table with any appropriate portion of the data provided by the orchestrator 516 and associated with service 502. In some embodiments, though not shown, the gateway computer 508 can send any appropriate data to the user device 506 to indicate that service 502 is ready.

[0090] Subsequently, the user can initiate a new API call at 504, and the actions at 504, 510, and 512 can be repeated. At this point, the routing table contains data associated with service 502 (e.g., service identifier, IP address of service 502, etc.), and the determination made at 512 can indicate that the API call is now routeable to service 502, allowing the API call to be forwarded to service 502 at 530. Starting at 530, the actions corresponding to service 502 and actions 424-428 in Figure 4 can be performed. For example, the service can return a response to gateway computer 508, which can forward the response to user device 506. This response can indicate whether the processing was successful (e.g., completed) or unsuccessful (e.g., not completed / not permitted). User device 506 receives the response and can perform any appropriate action, but is not limited to, displaying an indication to the user that the API call was successfully processed.

[0091] If service 502 becomes available first after the initial API call described above, it should be understood that since the service is already available at the time of the API request, flow 400 can proceed to 512 through 530, skipping the entire bootstrap process and routing table update.

[0092] Figure 7 is a flowchart showing the flow 700 of an operation to spin down an unused service according to at least one embodiment. Before executing the operation of flow 700, it can be assumed that service 702 (for example, service 402 in Figure 4) has been bootstrapped and a timer has been set to service 702 after receiving the last API call.

[0093] Flow 700 can be started at 704, and a timer set at 424 in Figure 4 (similarly at 530 in Figure 5 for service 502) will time out. In some embodiments, the timeout can trigger an event received by service 702. Identifying the timeout (e.g., receiving the event) In response to the signal, service 702 may be configured to send any appropriate data to orchestrator 706 (e.g., an example of orchestrator 416 in Figure 4) to indicate that service 702 is no longer in use (e.g., no requests have been received for a predetermined period of time, such as the last hour, or the amount of requests received in the previous predetermined period is below a threshold). Although service 702 is shown as receiving the event, the event may be received by gateway computer 708 (e.g., an example of gateway computer 408 in Figure 4) (or the timeout may be identified in other ways). For example, the gateway computer may be configured to periodically determine whether the service should be spun down based on identifying the last time point in time when the last request to service 702 was received and determining that the difference between that time point and the current time exceeds a threshold time. The timeout is used as a mechanism to trigger the spindown of service 702 for illustrative purposes, but any appropriate trigger may be used. For example, the spin-down of service 702 may be triggered at least in part on receiving a request (e.g., from a user device) to spin down one or more services (e.g., including service 702).

[0094] In some embodiments, a service can be considered safe to spin down if it has no active resource instances under its control (or if other components of the cloud computing environment are determined not to depend on the service in any other way). If a service manages one or more resource instances, it can monitor the status of these resource instances to determine when and if the service no longer manages any resource instances. As part of this monitoring, checks on these resource instances can be performed periodically according to a schedule or predetermined frequency (e.g., every minute, every 30 seconds).

[0095] In 710, the orchestrator 706 can receive data (messages and / or indicators requesting a spin-down) provided by service 702 (or alternatively by gateway computer 708). In response to receiving this data, the orchestrator 706 can be configured to perform any appropriate action to spin down service 702. In some embodiments, the action can be predefined by being provided in a DAG that identifies the order in which the actions should be performed to spin down the service. In some embodiments, the orchestrator 706 can determine whether other resources are needed (e.g., other services on which service 702 depends). For example, the orchestrator 706 can identify the request rate, i.e., the number of previous requests within a previous time period (e.g., the last 10 minutes, hour, day, etc.) when the functionality of the dependent resource (e.g., the service on which service 702 depends) was last utilized. The orchestrator 706 can utilize a predetermined set of rules to determine whether the dependent resource is still needed (e.g., by other resources, as suggested by the rate / number of violations of a predetermined threshold). In accordance with the determination that a dependent resource is no longer needed, the orchestrator 706 may perform an action to spin down the dependent resource and service 702. In some embodiments, the orchestrator 706 may be configured to request and receive user input indicating approval to recommend a spin-down request before sending a spin-down request for any resource (e.g., a dependent resource and / or service 702).

[0096] In 712, the orchestrator 706 can update the routing table maintained by the gateway computer 708. In some embodiments, Updating the routing table may include the orchestrator 706 sending data (e.g., by identifier) ​​indicating that service 702 (and, if applicable, one or more dependent resources) is no longer available. In response to receiving this data, the gateway computer 708 may delete or otherwise isolate the service and any appropriate number of one or more dependent services that are also indicated by the data received in 712 as being unavailable (or at least not sufficiently unavailable). Following the completion of flow 700, flow 400 may be executed any appropriate number of times.

[0097] Figure 8 is a flowchart illustrating an exemplary method 800 for orchestrating the bootstrap of a service in response to the receipt of an API request, according to at least one embodiment. The method is presented as a logical flowchart, and each of its operations can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation can represent a computer executable instruction stored in one or more computer-readable storage media that, when executed by one or more processors, performs the described operation. Generally, computer executable instructions include routines, programs, objects, components, data structures, etc., that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be interpreted as limiting, and any number of described operations can be combined in any order and / or in parallel to perform the process.

[0098] Additionally, Method 800 may be implemented under the control of one or more computing devices or computer systems comprising executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed collectively by hardware or in combination thereof on one or more processors. As mentioned above, the code may be stored, for example, on a computer-readable storage medium in the form of a computer program containing multiple instructions that can be executed by one or more processors. In some embodiments, Method 1000 may be implemented in parallel by multiple processors. The computer-readable storage medium may be non-temporary. In some embodiments, Method 800 is implemented by an orchestrator (e.g., Scheduler 206, Worker 210, and / or CIOS Regional 202 via CIOS Container 212 in Figure 2, and Orchestrators 416, 516, and / or 706 in Figures 4, 5, and 7, respectively).

[0099] Method 800 can be initiated in 802 when a request (e.g., an API call provided via an HTTP request) containing an identifier of a computing component of the cloud computing environment (e.g., service 402 in Figure 4) is received (e.g., by gateway computer 408 in Figure 4).

[0100] In 804, the computing device can determine whether an identifier (or any appropriate information corresponding to the service associated with that identifier) ​​exists in a routing table accessible to the computing device (for example, a routing table maintained / managed by the gateway computer 408 in Figure 4).

[0101] In 806, according to identifiers present in the routing table, the computing device (gateway computer 408) can forward requests to computing components (e.g., service 402).

[0102] In 808, if the identifier is not found in the routing table, the computing device may send an error code in response to the request. In some embodiments, the error code may indicate that the computing component is unavailable. The error code may be sent, for example, to the user device from which the request was initiated.

[0103] In 810, a bootstrap request corresponding to the compute component can be sent (for example, by the compute device to the deployment orchestrator of the cloud computing environment (e.g., orchestrator 406)) because the identifier does not exist in the routing table. In some embodiments, the deployment orchestrator is configured to deploy the compute component to the cloud computing environment based at least in part on the bootstrap request. Specific behaviors of such deployments can be identified from the DAG as described above in relation to Figures 5 and 6.

[0104] At 812, subsequent requests including an identifier can be received. In some embodiments, the identifier can be stored at this point in a routing table maintained by the computing component, according to the fact that it was added after the bootstrap was completed.

[0105] In 814, the subsequent request is sent to a computing component (e.g., service 402) for processing (e.g., by gateway computer 408).

[0106] Figure 9 is a flowchart illustrating the flow 900 of an operation performed in response to an order for a service that has not yet been deployed, according to at least one embodiment. In some embodiments, a predetermined set of services may have been previously deployed within a region and / or be accessible to a user device by an API call. Service 902 may not be included in that initial predetermined set of services being deployed. Alternatively, service 902 may have been operational but has been spun down and is no longer accessible. In any case, at the point in time when the operation of flow 900 begins, it is assumed that service 902 is inaccessible / inoperable (e.g., service 902 is not deployed).

[0107] Flow 900 can be initiated at 904, and a service (e.g., service 902) may be ordered. In some embodiments, a user can access the user interface via a user device 906. An exemplary interface is discussed in more detail below in relation to Figure 11. API requests can be made by the user device 906 (e.g., an example of user device 406 in Figure 4) according to the user input provided at the interface and the request to order service 1002. In some embodiments, API requests can be made via the HTTPS protocol or a similar protocol. The request may include any appropriate information, such as the user identifier, user authentication information, and the identifier of the service associated with the request. API calls can be received by a gateway computer 908, which may be the same as or similar to the gateway computer 408 in Figure 4, and may be an example of a computer implementing the WAN gateway 126 in Figure 1. Similar to the gateway computer described above, the gateway computer 908 may be configured to maintain routing tables for previously deployed regional services (e.g., cloud services A-N in Figure 2). The routing table is the internet routing table for each service and / or infrastructure component in the environment provided by the architecture in Figures 1 and 2. A routing table can include a local (IP) address. It can contain any appropriate information necessary to forward a data packet toward its destination. For example, a routing table may include the destination network identifier (e.g., an IP address), the subnet mask used to match the destination IP address against the network ID, and any other appropriate information configured to enable the data packet to be forwarded toward its destination.

[0108] In 910, the gateway computer 408 (or any appropriate component in Figure 2, such as the ingress proxy 218, CIOS regional 202, etc.) can authenticate the user of the API call and determine whether the user is authorized to order the service. As described in other examples above, authentication may involve making API calls to one or more services (e.g., an identity service) configured to maintain authorization and / or identity data for one or more users of the system. For example, the gateway computer 308 may call an identity service which consists of authorization and / or identity data that can be made available along with a user identifier, which is received in the request to identify the user and / or one or more authorization policies associated with that user. As another example, the gateway computer 908 may maintain user data associated with any appropriate number of users and can authenticate a user against that user data using any appropriate information obtained from the API call (e.g., a user identifier).

[0109] In 912, a determination can be made as to whether the request is permissible. This determination may include any appropriate combination of identifying 1) whether the user is the intended person, and 2) whether the user has the authority to order a resource (e.g., service 902). In some embodiments, user data obtained from the request, such as user authentication information, can be used to obtain authorization data indicating specific services or types of services that the user can order.

[0110] If the authorization data indicates that the user is not permitted to order the requested service (or service of that type), flow 900 can proceed to 914, where the gateway computer 908 can return an error code to the user device 906. The error code may be any appropriate value indicating that the user is not permitted to order service 902. In 916, the user device 906 may be configured to display any appropriate data in the user interface to indicate that the order was unsuccessful / not permitted in response to the receipt of the error code.

[0111] Alternatively, if the order for service 902 is deemed acceptable as determined in 912, flow 900 can proceed to 918, which can forward the return status to user device 906 and send data to orchestrator 916 (e.g., CIOS central 102 in Figure 1) indicating that the bootstrap for the requested service (e.g., service 902) should be initiated.

[0112] In 920, the user device 406 may be configured to perform one or more actions to display the status received from the gateway computer 908. For example, the user device 406 may display a status such as "Requested" to indicate that service 902 has been ordered but is not yet operational. It can be presented adjacent to the identifier 02.

[0113] In 922, the orchestrator 916 can receive a bootstrap request and perform any appropriate actions to bootstrap a non-existent service (e.g., service 902) (e.g., load it into memory (e.g., the memory of a virtual machine) and / or initialize it). In some embodiments, the orchestrator 916 can utilize a predetermined set of instructions associated with bootstrapping service 902. The orchestrator 916 can traverse the DAG associated with service 902 to identify and perform actions to boot and / or deploy service 902 to the cloud computing environment where the order was received. This process may be similar to or the same as that described above in relation to the DAG discussed in the description of Figure 4.

[0114] In 924, once service 402 has been bootstrapped (for example, a predetermined image of service 902 has been deployed to a specific computer in the environment / region) and is ready to accept subsequent requests, the orchestrator 916 can send data (e.g., an IP address associated with service 902, an alphanumeric identifier associated with service 902, etc.) to the gateway computer 908 to update the routing table maintained by the gateway computer 908. The gateway computer 908 can be configured to update the routing table with any appropriate portion of the data provided by the orchestrator 916 and associated with service 902. In some embodiments, the gateway computer 908 can send any appropriate data to the user device 906 to indicate that service 902 is ready. The user device 906 can receive the data and indicate its status (as shown in 920).

[0115] Subsequently, the user can initiate an API call corresponding to service 902 at 926. By performing the actions corresponding to blocks 404-412 on service 902, it is possible to determine whether the user is the intended person and authorized to make the API call. If not, an error code can be provided and displayed to the user on user device 906. Alternatively, the API call may be routed to service 902 by gateway computer 908 at 928, at which point the routing table includes data associated with service 902 (e.g., service identifier, service 902 IP address, etc.).

[0116] At 930, service 902 can process API calls. In some embodiments, service 902 can start a timer for a predetermined time period. The timer may alternatively be set by gateway computer 908. This timer can be configured to maintain knowledge of when service 902 was last called. If service 902 is not used again for a predetermined time period, service 902 can be spun down by performing the process described in relation to Figure 7. Service 902 can return a response to gateway computer 908 as a result of processing the API call. In some embodiments, this response may indicate that processing was successful (e.g., completed) or unsuccessful (e.g., not completed / not permitted). Gateway computer 908 can forward the response to user device 906. User device 906 receives the response and can perform any appropriate action, including, but not limited to, displaying an indication to the user that the API call was successfully processed.

[0117] Figure 10 is a flowchart illustrating the flow of operations 1000 performed in response to an order for a service that has not yet been deployed, when the service depends on another service that has also not yet been deployed, according to at least one embodiment. A predetermined set of services may have been previously deployed within the region and / or be accessible to the user device via API calls. Service 1002 may not be included in that initial predetermined set of services being deployed. Alternatively, service 1002 may have been operational previously but has been spun down and is no longer accessible. In any case, it is assumed that service 1002 is inaccessible / inoperable at the time flow 1000 begins to operate (e.g., service 1002 is not deployed).

[0118] Flow 1000 can be initiated at 1004, and a service (e.g., service 1002, an example of service 902 in Figure 9) may be ordered. In some embodiments, a user can access a user interface via a user device 1006. An exemplary interface is discussed in more detail below in relation to Figure 11. API calls can be made by the user device 1006 (e.g., an example of user device 406 in Figure 4) according to user input provided in the interface. In some embodiments, API calls can be made via the HTTPS protocol or a similar protocol. The request may include any appropriate information, such as a user identifier, user authentication information, an identifier for the service associated with the request, etc. API calls can be received by a gateway computer 1008, which may be the same as or similar to the gateway computer 408 in Figure 4, and may be an example of a computer implementing the WAN gateway 126 in Figure 1. Similar to the gateway computer described above, the gateway computer 1008 can be configured to maintain routing tables for previously deployed regional services (e.g., cloud services A-N in Figure 2).

[0119] The actions performed in 1004-1020 generally correspond to the same or similar actions discussed in 904-922 of Figure 9, and will not be discussed again for the sake of brevity.

[0120] In 1022, the orchestrator 1023 can identify one or more dependencies associated with service 1002. It can obtain (e.g., generate or retrieve from memory) a DAG associated with service 1002. One or more nodes in the DAG may correspond to one or more dependencies. As a non-limiting example, the DAG of service 1002 (or a portion of the DAG associated with service 1002) may indicate that service 1002 depends on another service (e.g., service B). That is, a node in the DAG corresponding to service B may be provided before the node corresponding to service 1002.

[0121] In accordance with the identification of the dependency on Service B, in 1024, the orchestrator 1023 may perform any appropriate action for the deployment / bootstrapping of Service B. In 1026, when Service B is bootstrapped (e.g., a predetermined image of Service B is deployed to a specific computer in the environment / region) and ready to accept subsequent requests, the orchestrator 1023 may send data (e.g., an IP address associated with Service B, an alphanumeric identifier associated with Service B, etc.) to the gateway computer 1008 to update the routing table maintained by the gateway computer 1008. The gateway computer 1008 may be configured to update the routing table with any appropriate portion of the data provided by the orchestrator 1023 and associated with Service B. In some embodiments, the gateway computer 1008 may send any appropriate data to the user device 1006 to indicate that Service B is ready. The user device 1006 (as shown in 1020) (Uni) It can receive a message and display its status.

[0122] At 1028, the orchestrator 516 can identify that service B is deployed and can proceed to perform any appropriate action for deploying / bootstrapping service 1002. At 1026, once service 1002 is bootstrapped (e.g., a predetermined image of service 1002 is deployed to a specific computer in the environment / region) and ready to accept subsequent requests, the orchestrator 1023 can send data (e.g., an IP address associated with service 1002, an alphanumeric identifier associated with service 1002, etc.) to the gateway computer 1008 to update the routing table maintained by the gateway computer 1008. The gateway computer 1008 can be configured to update the routing table with any appropriate portion of the data provided by the orchestrator 1023 and associated with service 1002. In some embodiments, the gateway computer 1008 can send any appropriate data to the user device 1006 to indicate that service 1002 is ready. The user device 1006 can receive and display its status (as shown in 1020). The operations described in 1024 and / or 1028 can be repeated any appropriate number of times, depending on the number of dependencies that service 1002 has on other functions / services in the system.

[0123] Subsequently, the user can initiate a new API call at 1030 to start an API call / response to service 1002. At this point, the routing table contains data associated with service 1002 (e.g., service identifier, IP address of service 1002, etc.), and at 1032, gateway computer 1008 can route the API call to service 1002. At 1034, service 1002 can receive and process the API call and then return a response to gateway computer 1008, which can forward the response to user device 1006. This response may indicate that processing was successful (e.g., completed) or unsuccessful (e.g., not completed / not permitted). User device 1006 receives the response and can perform any appropriate action, but is not limited to, displaying an indication to the user that the API call was successfully processed.

[0124] Figure 11 shows an exemplary user interface 1100, in at least one embodiment, for initiating the operations described above. In some embodiments, the user interface 1100 may be hosted by a gateway computer or any suitable computer in a cloud computing environment, as discussed above in relation to the drawings. If hosted by another computer, that computer may be configured to render the user interface 1100 on a user device and send API calls to the gateway computer in Figures 9 and 10. If the user interface 1100 is hosted by a computer different from the gateway computer, this computer may be configured to receive any suitable error codes, status values, etc., from the gateway computer and to display status information corresponding to that data in the user interface 1100.

[0125] The user interface 1100 may include a search area 1102 containing a search box 1104 and a button 1106. The user can use the search box 1104 to enter a search query (for example, some part of a service identifier). When button 1106 is selected, the search query can be executed using the input provided in the search box 1104. The search query may contain one or more matches to the query. To determine a service, this can be performed against a database of orderable services. In some embodiments, previously ordered and / or currently active services can be filtered from the list of search results. In some embodiments, the user can be presented with a list of search results (e.g., via user interface 1100 or another user interface) from which the user can select one or more services to order. The list of search results may look similar to the list of orderable services 1108 described later, and may provide similar functionality through the selection provided via the list, as described later.

[0126] The user interface 1100 may include a status area 1110. The status area 1110 can identify any appropriate number of services that are currently active, previously ordered, or being reduced. In some embodiments, the status area 1110 may include an identifier for each service in column 1112 and the corresponding status for each service in column 1114. There can be many status values, and they may vary based on the desired granularity of the status. Some exemplary status values ​​may include “Ready,” “Ordered,” “Bootstrap Initiated,” and “Spinning Down.” In some embodiments, there may be a menu or selection for requesting that one or more services be spun down. This menu or selection may be provided by selecting one or more services in the service area 1110, although it is not shown in Figure 11, or this menu / selection may be provided in other ways via the user interface 1100 or any appropriate interface. The gateway computer in the above-described drawings may be configured to provide service status at any appropriate time, not necessarily only at the times and triggers described above. Therefore, the gateway computer can provide a status immediately after receiving an order, displaying "Ordered" in column 1114 on the line corresponding to the ordered service. Once the orchestrator starts bootstrapping the service (or once the gateway computer sends a bootstrap request), the gateway computer can provide the user device with a status that can be presented as "Bootstrap Started" in column 1114 in the user interface 1100.When the gateway computer (or any suitable computing component) determines that a service should be spun down as discussed in relation to Figure 7, it can provide the service status value as "spin down" or "deactivating" and present it to the user interface 1100. When a service is no longer active, and to identify when a service becomes orderable, it can be returned to the set of orderable services according to a predetermined set of rules. When orderable, the service can be removed from the status area 1110 and added to the list of orderable services 1108.

[0127] The list of orderable services 1108 can contain any appropriate number of services. A predetermined set of rules can indicate when a service becomes available for order, and therefore when a service appears in the list of orderable services 1108. In some embodiments, a particular service that is orderable may depend on several factors, such as the type of service, a service identifier associated with the service, a specific user and / or permissions associated with that user. A user can select any service from the list of orderable services. In some embodiments, when a user selects an area 1116 (for example, by left-clicking within area 1116), a description area 1118 may be presented. In some embodiments, the description area 1118 may present a predetermined description of the service. This description describes the functionality of the service and / or various dependencies associated with the service. This allows the user to be informed of other services and / or resources on which the selected service depends. The description area 1118 may include an order button 1120 and a cancel button 1122. When the order button 1120 is selected, an API call corresponding to ordering the service can be sent, as described above in 904 and 1004 of Figures 9 and 10. If the user decides not to order the selected service, they can select the cancel button 1122, causing the description area 1118 for the selected service to be removed.

[0128] Figure 12 shows an exemplary flowchart illustrating a method 1200 for performing an operation to boot resources of a cloud computing system according to one embodiment of the present disclosure. The process is shown as a logical flowchart, and each operation therein can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation can represent a computer executable instruction stored in one or more computer-readable storage media that, when executed by one or more processors, performs the operation described. Generally, a computer executable instruction includes routines, programs, objects, components, data structures, etc., that perform a particular function or implement a particular data type. The order in which the operations are described is not intended to be interpreted as limiting, and any number of described operations can be combined in any order and / or in parallel to perform the process.

[0129] Additionally, Method 1200 may be implemented under the control of one or more computing devices or computer systems comprising executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed collectively by hardware or in combination thereof on one or more processors. As mentioned above, the code may be stored, for example, on a computer-readable storage medium in the form of a computer program containing multiple instructions that can be executed by one or more processors. In some embodiments, Method 1200 may be implemented in parallel by multiple processors. The computer-readable storage medium may be non-temporary. In some embodiments, Method 1200 is implemented by a computing device (e.g., the gateway computer in Figures 9 and 10).

[0130] Method 1200 can be initiated in block 1202, allowing a computing device in the cloud computing environment to identify a first set of computing components already deployed in the cloud computing environment. For example, a request message can be sent to an orchestrator (e.g., orchestrator 1023 in Figure 10) requesting a list of all services already deployed (and associated with a user) in the cloud computing environment. The data provided in the request may include a user identifier, user authentication information, etc. The orchestrator may be configured to compile this list (possibly based at least in part on the data provided in the request) and return a list of ordered or active services to the computing device, which may be configured to present this information in the status area 1110 in Figure 11. For example, the computing device may send one or more status indicators corresponding to the list of ordered or active services to the user device (directly or through a computing device configured to host a user interface 1100). Upon receipt, the user device may be configured to present this list in the status area 1110 in Figure 11.

[0131] In 1204, a computing device can identify a second set of computing components available for deployment within a cloud computing environment. For example, a request message can be sent to an orchestrator (e.g., orchestrator 1023 in Figure 10) requesting a list of all services available for ordering. The data provided in the request may include a user identifier, user authentication information, etc. The orchestrator may be configured to compile this list (possibly based at least partially on the data provided in the request) and return a list of orderable services to the computing device, which may be configured to present this information in area 1108 in Figure 11. For example, the computing device may send the list of orderable services (directly or through a computing device configured to host user interface 1100). Upon receipt, the user device may be configured to present this list in area 1108 in Figure 11.

[0132] In 1206, a request for deployment can be received. For example, a user can make a selection (e.g., service 4) from a user interface (e.g., user interface 1100 in Figure 11). As a result of the selection, an API call to order the service can be sent from the user device to the gateway computer (directly or through a computing device configured to host the user interface). A request for deployment (also referred to as an order request) can identify a specific computing component of a second set of computing components available for deployment (e.g., service 4 in Figure 11, and examples of services 902 and 1002 in Figures 9 and 10, respectively).

[0133] In 1208, a bootstrap request corresponding to a specific computing component being requested can be sent by the computing device to a deployment orchestrator in the cloud computing environment (e.g., orchestrators 916 and 1023 in Figures 9 and 10, respectively). In some embodiments, the deployment orchestrator can be configured to deploy a specific computing component to the cloud computing environment based at least partially on the bootstrap request. Thus, the deployment orchestrator can deploy the requested computing component in response to the bootstrap request.

[0134] In 1210, a first set of status indicators for a first set of computing components already deployed in a cloud computing environment, and a user interface (e.g., user interface 1100) that presents status indicators corresponding to a particular computing component (e.g., on a user device) can be presented.

[0135] As mentioned above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the internet). In the IaaS model, the 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, the IaaS provider can also supply various services to accompany those infrastructure components (e.g., billing, monitoring, logging, load balancing, and clustering, etc.). Therefore, since these services can be policy-driven, IaaS users may need to drive load balancing to maintain application availability and performance. It may be possible to implement C.

[0136] In some cases, IaaS customers can access resources and services through a wide area network (WAN), such as the internet, and install the remaining elements of their application stack using the cloud provider's services. For example, a user can log into the IaaS platform, 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 those VMs. The customer can then use the provider's services to perform various functions, including balancing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0137] In most cases, the cloud computing model requires the involvement of a cloud provider. This provider may, though not necessarily, be a third-party service specializing in IaaS provision (e.g., supply, lease, or sell). An entity could also choose to deploy a private cloud and become its own provider of infrastructure services.

[0138] In some cases, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. This may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is often managed by the cloud provider under the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Therefore, the customer may take on roles such as handling (OS), middleware, and / or application deployment (e.g., on a self-service virtual machine, e.g., which can be spun up on demand).

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

[0140] In some cases, IaaS preparation presents two distinct challenges. First, there is the initial challenge of preparing an initial set of infrastructure before anything can function. Second, there is the challenge of evolving the existing infrastructure after everything is prepared (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges can be addressed by allowing the infrastructure configuration to be defined declaratively. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which and how they each work together) can be described declaratively. In some cases, once the topology is defined, it can generate workflows to create and / or manage the different components described in the configuration files.

[0141] In some cases, infrastructure can have many interconnected elements. For example, one or more virtual private clouds (VPCs), also known as core networks (e.g., configurable and / or shared computing resources). Depending on the source, an on-demand pool may exist. In some examples, there may also be one or more inbound / outbound traffic group rules prepared to define how network inbound and / or outbound traffic is set up and one or more virtual machines (VMs). Other infrastructure elements, such as load balancers and databases, may also be prepared. As more and more infrastructure elements are desired and / or added, the infrastructure can evolve incrementally.

[0142] In some cases, sequential deployment techniques may be used to enable the deployment of infrastructure code across various virtual computing environments. Additionally, the techniques described can enable infrastructure management within these environments. In some examples, a service team may write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across various different geographical locations, sometimes worldwide). However, in some examples, the infrastructure to which the code is deployed must first be set up. In some cases, this preparation can be done manually, with preparation tools being used to prepare resources and / or deployment tools being used to deploy the code once the infrastructure is prepared.

[0143] Figure 13 is a block diagram 1300 showing an exemplary pattern of an IaaS architecture according to at least one embodiment. The service operator 1302 can communicately connect to a secure host tenancy 1304 which may include a virtual cloud network (VCN) 1306 and a secure host subnet 1308. In some examples, the service operator 1302 runs on software such as Microsoft Windows Mobile® and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc., and has Internet, email, short message service (SMS), Blackberry®, or other communication protocols enabled on portable handheld devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal data assistants (PDAs)) or wearable devices (e.g., Google® Glass) You may use one or more client computing devices, which may be head-mounted displays. Alternatively, the client computing devices may, for example, run various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. This can be a general-purpose personal computer, including personal computers and / or laptops, running on it. Client computing devices can be, but are not limited to, various GNU / Linux® operating systems such as Google Chrome OS. The workstation computer may run one of a variety of commercially available UNIX® or UNIX®-like operating systems, including a gaming system. Alternatively, or in addition, the client computing device may be a thin client computer capable of communicating over a network, having access to the VCN1306 and / or the Internet, an Internet-connected gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal computer. This could be any other electronic device, such as a messaging device.

[0144] VCN1306 may include a local peering gateway (LPG) 1310, which can be communicably coupled to SSH VCN1312 via LPG1310 included in Secure Shell (SSH) VCN1312. SSH VCN1312 may include an SSH subnet 1314, and SSH VCN1312 is a control network Lane VCN1316 can be communicatively coupled to control plane VCN1316 via LPG1310. Similarly, SSH VCN1312 can be communicatively coupled to data plane VCN1318 via LPG1310. Control plane VCN1316 and data plane VCN1318 can be included in a service tenancy 1319 owned and / or operated by the IaaS provider.

[0145] The control plane VCN 1316 may include a control plane demilitarized zone (DMZ) tier 1320 that acts as a peripheral network (e.g., a portion of the corporate network between the corporate intranet and the external network). DMZ-based servers may have their roles restricted and may help retain violations. Additionally, the DMZ tier 1320 may include a control plane application tier 1324 that may include one or more load balancer (LB) subnets 1322, an application subnet 1326, and a control plane data tier 1328 that may include database (DB) subnets 1330 (e.g., a frontend DB subnet and / or a backend DB subnet). The LB subnet 1322 included in the control plane DMZ tier 1320 can be communicatively coupled to the application subnet 1326 included in the control plane application tier 1324 and the Internet gateway 1334 which may be included in the control plane VCN 1316. The application subnet 1326 can be communicatively coupled to the DB subnet 1330 included in the control plane data tier 1328, as well as the service gateway 1336 and the network address translation (NAT) gateway 1338. The control plane VCN 1316 may include the service gateway 1336 and the NAT gateway 1338.

[0146] The control plane VCN 1316 may include a data plane mirror application tier 1340 that can include an application subnet 1326. The application subnet 1326 included in the data plane mirror application tier 1340 may include a virtual network interface controller (VNIC) 1342 that can run a compute instance 1344. The compute instance 1344 can connect the application subnet 1326 of the data plane mirror application tier 1340 to an application subnet 1326 that may be included in the data plane application tier 1346 in a communicative manner.

[0147] The data plane VCN 1318 can include a data plane application tier 1346, a data plane DMZ tier 1348, and a data plane data tier 1350. The data plane DMZ tier 1348 can include an LB subnet 1322 that can be communicatively joined to the application subnet 1326 of the data plane application tier 1346 and the internet gateway 1334 of the data plane VCN 1318. The application subnet 1326 can be communicatively joined to the service gateway 1336 of the data plane VCN 1318 and the NAT gateway 1338 of the data plane VCN 1318. The data plane data tier 1350 can also include a DB subnet 1330 that can be communicatively joined to the application subnet 1326 of the data plane application tier 1346.

[0148] The internet gateway 1334 of the control plane VCN1316 and data plane VCN1318 can communicately connect to a metadata management service 1352, which can communicately connect to the public internet 1354. The public internet 1354 can communicately connect to the NAT gateway 1338 of the control plane VCN1316 and data plane VCN1318. The service gateway 1336 of the control plane VCN1316 and data plane VCN1318 can communicately connect to a cloud service 1356.

[0149] In some cases, a service gateway 1336 of the control plane VCN1316 or data plane VCN1318 can make application programming interface (API) calls to a cloud service 1356 without going through the public internet 1354. API calls from the service gateway 1336 to the cloud service 1356 are one-way; that is, the service gateway 1336 can make API calls to the cloud service 1356, and the cloud service 1356 can send the requested data to the service gateway 1336. However, the cloud service 1356 cannot initiate API calls to the service gateway 1336.

[0150] In some examples, a secure host tenancy 1304 can connect directly to a service tenancy 1319, which may otherwise be isolated. A secure host subnet 1308 can communicate with an SSH subnet 1314 via an LPG 1310, which can enable bidirectional communication through systems that are otherwise isolated. By connecting the secure host subnet 1308 to the SSH subnet 1314, the secure host subnet 1308 can access other entities within the service tenancy 1319.

[0151] The control plane VCN1316 can enable users of service tenancy 1319 to set up or otherwise prepare desired resources. Desired resources prepared in the control plane VCN1316 can be deployed within the data plane VCN1318 or used in other ways. In some examples, the control plane VCN1316 can be separated from the data plane VCN1318, and the data plane mirror application layer 1340 of the control plane VCN1316 can communicate with the data plane application layer 1346 of the data plane VCN1318 via a VNIC 1342 which can be contained within the data plane mirror application layer 1340 and the data plane application layer 1346.

[0152] In some examples, a user or customer of the system can make requests, such as create, read, update, or delete (CRUD) operations, through the public internet 1354, and the public internet can communicate the requests to the metadata management service 1352. The metadata management service 1352 can communicate the requests to the control plane VCN 1316 through the internet gateway 1334. The requests can be received by the LB subnet 1322, which is contained within the control plane DMZ layer 1320. The LB subnet 1322 can determine if the request is valid, and in response to this determination, the LB subnet 1322 can send the request to the application subnet 1326, which is contained within the control plane application layer 1324. If the request is validated and requires a call to the public internet 1354, it can send a call to the public internet 1354 to the NAT gateway 1338, which can make the call to the public internet 1354. Memory that may be desired to be stored by the request can be stored in the DB subnet 1330.

[0153] In some examples, the data plane mirror application layer 1340 can facilitate direct communication between the control plane VCN 1316 and the data plane VCN 1318. For example, it may be desirable to make configuration changes, updates, or other appropriate modifications to resources contained within the data plane VCN 1318. Through VNIC 1342, the control plane VCN 1316 can communicate directly with the data plane VCN 1318, thereby enabling it to perform configuration changes, updates, or other appropriate modifications to resources contained within the data plane VCN 1318.

[0154] In some embodiments, the control plane VCN1316 and the data plane VCN1318 can be included in the service tenancy 1319. In this case, the system user or customer does not have to own or operate either the control plane VCN1316 or the data plane VCN1318. Instead, the IaaS provider can own or operate the control plane VCN1316 and the data plane VCN1318, both of which can be included in the service tenancy 1319. This embodiment can enable network isolation that can prevent a user or customer from interacting with the resources of other users or other customers. This embodiment can also enable the system user or customer to store databases privately without having to rely on the public internet 1354, which may not have the desired level of threat protection with respect to storage.

[0155] In another embodiment, the LB subnet 1322, which is contained within the control plane VCN 1316, can be configured to receive signals from the service gateway 1336. In this embodiment, the control plane VCN 1316 and the data plane VCN 1318 can be configured to be called by the IaaS provider's customer without having to call the public internet 1354. The IaaS provider's customer may desire this embodiment because the database used by the customer can be stored in a service tenancy 1319 that can be controlled by the IaaS provider and isolated from the public internet 1354.

[0156] Figure 14 is a block diagram 1400 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1402 (e.g., service operator 1302 in Figure 13) can be communicatively coupled to a secure host tenancy 1404 (e.g., secure host tenancy 1304 in Figure 13), which may include a virtual cloud network (VCN) 1406 (e.g., VCN1306 in Figure 13) and a secure host subnet 1408 (e.g., secure host subnet 1308 in Figure 13). The VCN 1406 may include a local peering gateway (LPG) 1410 (e.g., LPG1310 in Figure 13), which may be communicatively coupled to a secure shell (SSH) VCN 1412 (e.g., SSH VCN1312 in Figure 13) via the LPG1310 contained within the secure shell (SSH) VCN 1412. SSH VCN1412 may include SSH subnet 1414 (e.g., SSH subnet 1314 in Figure 13), and SSH VCN1412 may be communicably coupled to control plane VCN1416 (e.g., control plane VCN1316 in Figure 13) via LPG1410 included in control plane VCN1416. Control plane VCN1416 may be included in service tenancy 1419 (e.g., service tenancy 1319 in Figure 13), and data plane VCN1418 (e.g., data plane VCN1318 in Figure 13) may be included in customer tenancy 1421, which may be owned or operated by a user or customer of the system.

[0157] The control plane VCN 1416 may include a control plane DMZ tier 1420 (e.g., control plane DMZ tier 1320 in Figure 13) which may include an LB subnet 1422 (e.g., LB subnet 1322 in Figure 13), a control plane application tier 1424 (e.g., control plane application tier 1324 in Figure 13) which may include an application subnet 1426 (e.g., application subnet 1326 in Figure 13), and a control plane data tier 1428 (e.g., control plane data tier 1328 in Figure 13) which may include a database (DB) subnet 1430 (e.g., similar to DB subnet 1330 in Figure 13). The LB subnet 1422 included in the control plane DMZ tier 1420 may include an application subnet 1426 included in the control plane application tier 1424 and an internet gateway 1434 (e.g., Figure 13) which may be included in the control plane VCN 1416. The application subnet 1426 can be communicatively coupled to the Internet gateway 1334, and can be communicatively coupled to the DB subnet 1430, as well as the service gateway 1436 (e.g., the service gateway in Figure 13) and the network address translation (NAT) gateway 1438 (e.g., the NAT gateway 1338 in Figure 13), which are included in the control plane data hierarchy 1428. The control plane VCN 1416 may include the service gateway 1436 and the NAT gateway 1438.

[0158] The control plane VCN 1416 may include a data plane mirror application tier 1440 (e.g., data plane mirror application tier 1340 in Figure 13) which may include an application subnet 1426. The application subnet 1426 included in the data plane mirror application tier 1440 may include a virtual network interface controller (VNIC) 1442 (e.g., VNIC 1342) which may run a compute instance 1444 (e.g., similar to compute instance 1344 in Figure 13). The compute instance 1444 can facilitate communication between the application subnet 1426 of the data plane mirror application tier 1440 and the application subnet 1426 which may be included in the data plane application tier 1446 (e.g., data plane application tier 1346 in Figure 13) via the VNIC 1442 included in the data plane mirror application tier 1440 and the VNIC 1442 included in the data plane application tier 1446.

[0159] The Internet gateway 1434, contained within the control plane VCN 1416, can communicate with the metadata management service 1452 (e.g., the metadata management service 1352 in Figure 13), which can communicate with the public internet 1454 (e.g., the public internet 1354 in Figure 13). The public internet 1454 can communicate with the NAT gateway 1438, contained within the control plane VCN 1416. The service gateway 1436, contained within the control plane VCN 1416, can communicate with the cloud service 1456 (e.g., the cloud service 1356 in Figure 13).

[0160] In some examples, the data plane VCN1418 can be included in a customer tenancy 1421. In this case, the IaaS provider can provide a control plane VCN1416 for each customer, and the IaaS provider can set up a unique compute instance 1444 for each customer, contained within a service tenancy 1419. Each compute instance 1444 can enable communication between the control plane VCN1416 contained within the service tenancy 1419 and the data plane VCN1418 contained within the customer tenancy 1421. The compute instance 1444 can enable resources prepared within the control plane VCN1416 contained within the service tenancy 1419 to be deployed or used in other ways within the data plane VCN1418 contained within the customer tenancy 1421.

[0161] In another example, an IaaS provider's customer may have a database residing within customer tenancy 1421. In this example, control plane VCN 1416 may include a data plane mirror application tier 1440 that can include application subnet 1426. The data plane mirror application tier 1440 may reside within data plane VCN 1418, but does not have to reside within data plane VCN 1418. That is, the data plane mirror application tier 1440 can access customer tenancy 1421, but does not have to reside within data plane VCN 1418, nor does it have to be owned or operated by the IaaS provider's customer. The Lane Mirror App Tier 1440 can be configured to call the Data Plane VCN 1418, but does not have to be configured to call any entities contained within the Control Plane VCN 1416. Customers may want to deploy or otherwise use resources in the Data Plane VCN 1418 that are prepared within the Control Plane VCN 1416, and the Data Plane Mirror App Tier 1440 can facilitate the deployment or other use of the resources desired by the customer.

[0162] In some examples, a customer of the IaaS provider can apply filters to the data plane VCN1418. In this embodiment, the customer can determine what the data plane VCN1418 can access, and the customer can restrict access from the data plane VCN1418 to the public internet 1454. The IaaS provider may not be able to apply filters to or otherwise control the data plane VCN1418's access to any external network or database. The application and control of filters by the customer to the data plane VCN1418 contained within the customer tenancy 1421 can help isolate the data plane VCN1418 from other customers and the public internet 1454.

[0163] In some embodiments, the cloud service 1456 may be called by a service gateway 1436 to access services that may not reside on the public internet 1454, the control plane VCN 1416, or the data plane VCN 1418. The connection between the cloud service 1456 and the control plane VCN 1416 or the data plane VCN 1418 may not be live or continuous. The cloud service 1456 may reside on different networks owned or operated by the IaaS provider. The cloud service 1456 may be configured to receive calls from the service gateway 1436 and not to receive calls from the public internet 1454. Some cloud services 1456 may be isolated from other cloud services 1456, and the control plane VCN 1416 may be isolated from cloud services 1456 that may not be in the same region as the control plane VCN 1416. For example, the control plane VCN 1416 may be located in "Region 1", and the cloud service "Deployment 13" may be located in both Region 1 and "Region 2". If a call to deployment 13 is made by a service gateway 1436 contained within a control plane VCN 1416 located in region 1, the call may be sent to deployment 13 in region 1. In this example, the control plane VCN 1416 or deployment 13 in region 1 does not have to be communicatively coupled to or otherwise communicate with deployment 13 in region 2.

[0164] Figure 15 is a block diagram 1500 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1502 (e.g., service operator 1302 in Figure 13) can be communicatively coupled to a secure host tenancy 1504 (e.g., secure host tenancy 1304 in Figure 13) which can include a virtual cloud network (VCN) 1506 (e.g., VCN 1306 in Figure 13) and a secure host subnet 1508 (e.g., secure host subnet 1308 in Figure 13). VCN 1506 can include an LPG 1510 (e.g., LPG 1310 in Figure 13), which can be communicatively coupled to an SSH VCN 1512 (e.g., SSH VCN 1312 in Figure 13) via an LPG 1510 contained in an SSH VCN 1512. SSH VCN1512 may include SSH subnet 1514 (for example, SSH subnet 1314 in Figure 13), and SSH VCN1512 may be communicably coupled to control plane VCN1516 (for example, control plane VCN1316 in Figure 13) via LPG1510 included in control plane VCN1516. The control plane VCN1516 can be communicatively coupled to the data plane VCN1518 (for example, the data plane VCN1318 in Figure 13) via the LPG1510 included in the data plane VCN1518. The control plane VCN1516 and data plane VCN1518 can be included in the service maintenance 1519 (for example, the service maintenance 1319 in Figure 13).

[0165] The control plane VCN1516 may include a control plane DMZ tier 1520 (e.g., control plane DMZ tier 1320 in Figure 13) which can include a load balancer (LB) subnet 1522 (e.g., LB subnet 1322 in Figure 13), a control plane application tier 1524 (e.g., control plane application tier 1324 in Figure 13) which can include an application subnet 1526 (e.g., similar to application subnet 1326 in Figure 13), and a control plane data tier 1528 (e.g., control plane data tier 1328 in Figure 13) which can include a DB subnet 1530. The LB subnet 1522 included in the control plane DMZ tier 1520 can be communicatively coupled to the application subnet 1526 included in the control plane application tier 1524 and the Internet gateway 1534 (e.g., Internet gateway 1334 in Figure 13) which may be included in the control plane VCN 1516. The application subnet 1526 can be communicatively coupled to the DB subnet 1530 included in the control plane data tier 1528 and the service gateway 1536 (e.g., the service gateway in Figure 13) and the network address translation (NAT) gateway 1538 (e.g., NAT gateway 1338 in Figure 13). The control plane VCN 1516 may include the service gateway 1536 and the NAT gateway 1538.

[0166] The data plane VCN 1518 can include a data plane application tier 1546 (e.g., data plane application tier 1346 in Figure 13), a data plane DMZ tier 1548 (e.g., data plane DMZ tier 1348 in Figure 13), and a data plane data tier 1550 (e.g., data plane data tier 1350 in Figure 13). The data plane DMZ tier 1548 can include a trusted application subnet 1560 and an untrusted application subnet 1562 of the data plane application tier 1546, as well as an LB subnet 1522 that can be communicatively coupled to an internet gateway 1534 contained within the data plane VCN 1518. The trusted application subnet 1560 can be communicatively coupled to a service gateway 1536 contained within the data plane VCN 1518, a NAT gateway 1538 contained within the data plane VCN 1518, and a DB subnet 1530 contained within the data plane data tier 1550. The untrusted application subnet 1562 can be communicatively coupled to the service gateway 1536, which is contained within the data plane VCN 1518, and to the DB subnet 1530, which is contained within the data plane data tier 1550. The data plane data tier 1550 may include the DB subnet 1530, which can be communicatively coupled to the service gateway 1536, which is contained within the data plane VCN 1518.

[0167] An untrusted application subnet 1562 may contain one or more primary VNICs 1564(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 1566(1)-(N). Each tenant VM 1566(1)-(N) may be communicatively coupled to each application subnet 1567(1)-(N) that can be contained within each container egress VCN 1568(1)-(N) that can be contained within each customer tenancy 1570(1)-(N). Each secondary VNIC 1572(1)-(N) can facilitate communication between the untrusted application subnet 1562 contained within the data plane VCN 1518 and the application subnet contained within the container egress VCN 1568(1)-(N). Each container egress VCN 1568 (1) to (N) may include a NAT gateway 1538 that can be communicatively connected to the public internet 1554 (for example, the public internet 1354 in Figure 13).

[0168] The Internet Gateway 1534 contained within the control plane VCN1516 and the Internet Gateway 1534 contained within the data plane VCN1518 can communicately connect to a metadata management service 1552 (for example, the metadata management system 1352 in Figure 13), which can communicately connect to the public internet 1554. The public internet 1554 can communicately connect to the NAT Gateway 1538 contained within the control plane VCN1516 and the NAT Gateway 1538 contained within the data plane VCN1518. The Service Gateway 1536 contained within the control plane VCN1516 and the Service Gateway 1536 contained within the data plane VCN1518 can communicately connect to a cloud service 1556.

[0169] In some embodiments, the data plane VCN1518 can be integrated with a customer tenancy 1570. This integration may be useful or desirable for the IaaS provider's customer in several cases, such as when support may be desired when executing code. The customer may 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.

[0170] In some examples, a customer of an IaaS provider may grant the IaaS provider temporary network access and request functionality associated with the data plane tier application 1546. The code for executing the functionality can run within VMs 1566(1) to (N), and the code does not need to be configured to run elsewhere on the data plane VCN 1518. Each VM 1566(1) to (N) can connect to one customer tenancy 1570. Each container 1571(1) to (N) contained within VMs 1566(1) to (N) may be configured to run the code. In this case, a double isolation may exist (for example, containers 1571(1)-(N) execute code, where containers 1571(1)-(N) may be contained within VM1566(1)-(N) which are contained within at least an untrusted application subnet 1562), which can help prevent incorrect or otherwise undesirable code from damaging the IaaS provider's network or the networks of different customers. Containers 1571(1)-(N) can be communicatively coupled to customer tenancy 1570 and can be configured to send or receive data from customer tenancy 1570. Containers 1571(1)-(N) do not have to be configured to send or receive data from any other entities in the data plane VCN1518. Once code execution is complete, the IaaS provider can stop or otherwise destroy containers 1571(1)-(N).

[0171] In some embodiments, a trusted application subnet 1560 can execute code owned or operated by the IaaS provider. In this embodiment, the trusted application subnet 1560 can be communicatively coupled to a DB subnet 1530 and configured to perform CRUD operations in the DB subnet 1530. An untrusted application subnet 1562 can be communicatively coupled to a DB subnet 1530, but in this embodiment, the untrusted application subnet can be configured to perform read operations in the DB subnet 1530. It may be contained within each customer's VM1566(1)~(N) and may execute code from the customer. Containers 1571(1) to (N) do not need to be connected to DB subnet 1530 in a way that allows them to communicate with it.

[0172] In other embodiments, the control plane VCN1516 and the data plane VCN1518 do not have to be directly communicatively coupled. In this embodiment, direct communication between the control plane VCN1516 and the data plane VCN1518 is not required. However, communication can be performed indirectly through at least one method. An LPG1510 that can facilitate communication between the control plane VCN1516 and the data plane VCN1518 may be established by the IaaS provider. In another example, the control plane VCN1516 or the data plane VCN1518 can make a call to the cloud service 1556 via the service gateway 1536. For example, a call from the control plane VCN1516 to the cloud service 1556 may include a request for a service that can communicate with the data plane VCN1518.

[0173] Figure 16 is a block diagram 1600 showing another exemplary pattern of an IaaS architecture according to at least one embodiment. A service operator 1602 (e.g., service operator 1302 in Figure 13) can be communicatively coupled to a secure host tenancy 1604 (e.g., secure host tenancy 1304 in Figure 13), which may include a virtual cloud network (VCN) 1606 (e.g., VCN 1306 in Figure 13) and a secure host subnet 1608 (e.g., secure host subnet 1308 in Figure 13). VCN 1606 may include an LPG 1610 (e.g., LPG 1310 in Figure 13), which may be communicatively coupled to an SSH VCN 1612 (e.g., SSH VCN 1312 in Figure 13) via an LPG 1610 contained within an SSH VCN 1612. SSH VCN1612 may include SSH subnet 1614 (e.g., SSH subnet 1314 in Figure 13), and SSH VCN1612 may be communicatively coupled to control plane VCN1616 (e.g., control plane VCN1316 in Figure 13) via LPG1610 included in control plane VCN1616, and may be communicatively coupled to data plane VCN1618 (e.g., data plane VCN1318 in Figure 13) via LPG1610 included in data plane VCN1618. Control plane VCN1616 and data plane VCN1618 may be included in service tenancy 1619 (e.g., service tenancy 1319 in Figure 13).

[0174] The control plane VCN1616 may include a control plane DMZ tier 1620 (e.g., control plane DMZ tier 1320 in Figure 13) which can include an LB subnet 1622 (e.g., LB subnet 1322 in Figure 13), a control plane application tier 1624 (e.g., control plane application tier 1324 in Figure 13) which can include an application subnet 1626 (e.g., application subnet 1326 in Figure 13), and a control plane data tier 1628 (e.g., control plane data tier 1328 in Figure 13) which can include a DB subnet 1630 (e.g., DB subnet 1530 in Figure 15). The LB subnet 1622 included in the control plane DMZ layer 1620 can be communicatively coupled to the application subnet 1626 included in the control plane application layer 1624 and the Internet gateway 1634 (e.g., Internet gateway 1334 in Figure 13) which may be included in the control plane VCN 1616. The application subnet 1626 can be communicatively coupled to the DB subnet 1630 included in the control plane data layer 1628 and the service gateway 1636 (e.g., the service gateway in Figure 13) and the network address translation (NAT) gateway 1638 (e.g., NAT gateway 1338 in Figure 13). The control plane VCN 1616 may include the service gateway 1636 and the NAT gateway 1638.

[0175] The data plane VCN 1618 may include a data plane application tier 1646 (e.g., data plane application tier 1346 in Figure 13), a data plane DMZ tier 1648 (e.g., data plane DMZ tier 1348 in Figure 13), and a data plane data tier 1650 (e.g., data plane data tier 1350 in Figure 13). The data plane DMZ tier 1648 may include trusted application subnets 1660 (e.g., trusted application subnet 1560 in Figure 15) and untrusted application subnets 1662 (e.g., untrusted application subnet 1562 in Figure 15) of the data plane application tier 1646, as well as an LB subnet 1622 that can be communicatively coupled to an internet gateway 1634 contained within the data plane VCN 1618. A trusted application subnet 1660 can communicately connect to a service gateway 1636, a NAT gateway 1638, and a DB subnet 1630, all contained within a data plane VCN 1618. An untrusted application subnet 1662 can communicately connect to a service gateway 1636, a data plane VCN 1618, and a DB subnet 1630, all contained within a data plane data tier 1650. The data plane data tier 1650 may include a DB subnet 1630 that can communicately connect to a service gateway 1636, a data plane VCN 1618.

[0176] An untrusted application subnet 1662 may include primary VNICs 1664(1)-(N) that can communicately connect to tenant virtual machines (VMs) 1666(1)-(N) residing within the untrusted application subnet 1662. Each tenant VM 1666(1)-(N) can execute code within its respective container 1667(1)-(N) and can communicately connect to an application subnet 1626 that may be contained within a data plane application tier 1646 that may be contained within a container egress VCN 1668. Each secondary VNIC 1672(1)-(N) can facilitate communication between the untrusted application subnet 1662 contained within a data plane VCN 1618 and the application subnet contained within a container egress VCN 1668. The container egress VCN may include a NAT gateway 1638 that can communicately connect to the public internet 1654 (e.g., the public internet 1354 in Figure 13).

[0177] The Internet Gateway 1634 contained within the control plane VCN1616 and the Internet Gateway 1634 contained within the data plane VCN1618 can communicately connect to a metadata management service 1652 (for example, the metadata management system 1352 in Figure 13), which can communicately connect to the public internet 1654. The public internet 1654 can communicately connect to the NAT Gateway 1638 contained within the control plane VCN1616 and the NAT Gateway 1638 contained within the data plane VCN1618. The Service Gateway 1636 contained within the control plane VCN1616 and the Service Gateway 1636 contained within the data plane VCN1618 can communicately connect to a cloud service 1656.

[0178] In some cases, the pattern shown by the architecture in block diagram 1600 of Figure 16 can be considered an exception to the pattern shown by the architecture in block diagram 1500 of Figure 15, and may be desirable for the IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in isolated regions). Each of the contents contained within VM1666(1)~(N) of each customer Containers 1667(1)-(N) can be accessed in real time by the customer. Containers 1667(1)-(N) can be configured to make calls to their respective secondary VNICs 1672(1)-(N) contained within the application subnet 1626 of the data plane application hierarchy 1646, which may be contained within the container egress VCN 1668. The secondary VNICs 1672(1)-(N) can send calls to the NAT gateway 1638, which in turn can send calls to the public internet 1654. In this example, containers 1667(1)-(N), which can be accessed in real time by the customer, can be isolated from the control plane VCN 1616 and from other entities contained within the data plane VCN 1618. Containers 1667(1)-(N) can also be isolated from other customer resources.

[0179] In another example, a customer can call cloud service 1656 using containers 1667(1)-(N). In this example, the customer can execute code within containers 1667(1)-(N) that requests a service from cloud service 1656. Containers 1667(1)-(N) can send this request to secondary VNICs 1672(1)-(N), which can send the request to the NAT gateway, which can send the request to the public internet 1654. The public internet 1654 can send the request to LB subnet 1622, which is contained within control plane VCN 1616, via internet gateway 1634. In response to the determination that the request is valid, the LB subnet can send the request to application subnet 1626, which can send the request to cloud service 1656 via service gateway 1636.

[0180] It should be understood that the IaaS architectures 1300, 1400, 1500, and 1600 shown in the drawings may have components other than those shown. Furthermore, the embodiments shown in the drawings are only examples of some cloud infrastructure systems that may incorporate embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than those shown, may combine two or more components, or may have different configurations or arrangements of components.

[0181] In one embodiment, the IaaS system described herein may include a suite of applications, middleware, and database service supplies that are self-service, subscription-based, elastically scalable, reliable, highly available, and securely delivered to the customer. An example of such an IaaS system is the Oracle Cloud Infrastructure (OCI) provided by the Assignee.

[0182] Figure 17 shows an exemplary computer system 1700 that can implement various embodiments. System 1700 can be used to implement any of the computer systems described above. As shown in the drawing, computer system 1700 includes a processing unit 1704 that communicates with several peripheral subsystems via a bus subsystem 1702. These peripheral subsystems may include a processing acceleration unit 1706, an I / O subsystem 1708, a storage subsystem 1718, and a communication subsystem 1724. The storage subsystem 1718 includes a tangible computer-readable storage medium 1722 and system memory 1710.

[0183] The bus subsystem 1702 comprises various components of the computer system 1700 and It provides a mechanism for subsystems to communicate with each other as intended. Although the bus subsystem 1702 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1702 may be one of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using one of various bus architectures. For example, such architectures include the Industry Standard Architecture (ISA) bus, the Microchannel Architecture (MCA) bus, the Extended ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the IEEE P1386.1 Interconnection of peripheral components that can be implemented as a Mezzanine bus manufactured according to standards It may include a PCI bus.

[0184] A processing unit 1704, which can be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1700. One or more processors may be included in the processing unit 1704. These processors may include single-core or multi-core processors. In one embodiment, the processing unit 1704 may also be implemented as one or more independent processing units 1732 and / or 1734, each containing a single or multi-core processor. In other embodiments, the processing unit 1704 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors onto a single chip.

[0185] In various embodiments, the processing unit 1704 can execute various programs in response to program code and can maintain multiple programs or processes running simultaneously. At any given time, some or all of the program code to be executed may reside within the processor 1704 and / or the storage subsystem 1718. Through appropriate programming, the processor 1704 can provide the various functions described above. The computer system 1700 may additionally include a processing acceleration unit 1706 which may include a digital signal processor (DSP), a dedicated processor, etc.

[0186] The I / O subsystem 1708 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, acoustic input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include motion detection and / or motion detection sensors such as Microsoft Kinect® motion sensors that enable users to control and interact with input devices such as Microsoft Xbox® 360 game controllers through a natural user interface using gestures and voice commands. This may include gesture recognition devices. User interface input devices may also include eye gesture recognition devices such as the Google Glass® Blink Detector, which detects eye activity from the user (e.g., blinking while taking a picture and / or making a menu selection) and translates that eye gesture into input to an input device (e.g., Google Glass®). Additionally, user interface input devices may include voice recognition detection devices that enable the user to interact with a voice recognition system (e.g., Siri® Navigator) through voice commands.

[0187] User interface input devices also include, but are not limited to, three-dimensional (3D) mice. This may also include joysticks or pointing sticks, gamepads and graphics tablets, as well as acoustic / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Additionally, user interface input devices may include medical imaging input devices such as computed tomography, magnetic resonance imaging, position emission tomography, and medical ultrasound devices. User interface input devices may also include acoustic input devices such as MIDI keyboards and digital musical instruments.

[0188] User interface output devices may include non-visual displays such as display subsystems, indicator lights, or audio output devices. Display subsystems may also include flat panel devices such as those using cathode ray tubes (CRTs), liquid crystal displays (LDCs), or plasma displays, projection devices, touchscreens, etc. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1700 to a user or another computer. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphic, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, audio output devices, and modems.

[0189] The computer system 1700 may include a storage subsystem 1718 containing software elements, which are currently shown as being located in the system memory 1710. The system memory 1710 can store program instructions that can be loaded and executed on the processing unit 1704, and data generated during the execution of these programs.

[0190] Depending on the configuration and type of the computer system 1700, the system memory 1710 may be volatile (e.g., random access memory (RAM)) and / or non-volatile (e.g., read-only memory (ROM), flash memory). RAM typically contains data and / or program modules that are immediately accessible to the processing unit 1704 and / or currently operating and executing by the processing unit 1704. In some embodiments, the system memory 1710 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some embodiments, a basic input / output system (BIOS) containing basic routines that help transfer information between elements within the computer system 1700 during startup, etc., may typically be stored in ROM. As an example, but not an limitation, the system memory 1710 also exemplified application programs 1712, program data 1714, and an operating system 1716, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc. For example, Operating System 1716 is compatible with various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. This may include various commercially available UNIX® or UNIX-like operating systems (but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® OS, and Palm® OS.

[0191] The memory subsystem 1718 also provides a tangible computer-readable storage medium for storing basic programming and data structures that provide functionality in several embodiments. This is possible. When executed by the processor, software (programs, code modules, instructions) that provides the above-described functions may be stored in the storage subsystem 1718. These software modules or instructions may be executed by the processing unit 1704. The storage subsystem 1718 may also provide a repository for storing data used in accordance with this disclosure.

[0192] The memory subsystem 1700 may also include a computer-readable storage medium reader 1720 which can be further connected to the computer-readable storage medium 1722. Together with the system memory 1710, and optionally in combination with the system memory 1710, the computer-readable storage medium 1722 can comprehensively represent remote, local, fixed, and / or removable storage devices + storage media for temporarily and / or more persistently containing, storing, transmitting, and retrieving computer-readable information.

[0193] The computer-readable storage medium 1722, which includes the code or a portion of the code, may also include any suitable medium known or used in the art, including storage and communication media, such as volatile and non-volatile, removable and non-removable media, which are implemented in any way or technique for storing and / or transmitting information. This may include tangible computer-readable storage media such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer-readable media. This may also include non-tangible computer-readable media such as any other media that can be used to transmit data signals, data transmissions, or desired information and can be accessed by the computing system 1700.

[0194] For example, computer-readable storage media 1722 include hard disk drives that read from or write to non-removable non-volatile magnetic media, magnetic disk drives that read from or write to removable non-volatile magnetic disks, and removable non-volatile magnetic media such as CD-ROMs, DVDs, and Blu-ray® discs or other optical media. This may include optical disc drives that read from or write to volatile optical discs. Computer-readable storage media 1722 may include, but are not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, digital videotapes, etc. Computer-readable storage media 1722 may also include solid-state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, solid-state ROM, etc., SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, etc., DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. Disk drives and their associated computer-readable media can provide computer system 1700 with non-volatile storage of computer-readable instructions, data structures, program modules, and other data.

[0195] The communication subsystem 1724 provides an interface to other computer systems and networks. The communication subsystem 1724 acts as an interface for receiving data from other systems and transmitting data from computer system 1700 to other systems. For example, the communication subsystem 1724 can enable computer system 1700 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1724 connects to wireless voice and / or data networks (e.g., cellular technology, 3G). This may include radio frequency (RF) transceiver components for accessing 4G or EDGE (Global Evolutionary High Speed ​​Data Rate), WiFi (using advanced data network technologies such as the IEEE 802.11 family of standards or other mobile communication technologies, or any combination thereof), a Global Positioning System (GPS) receiver component, and / or other components. In some embodiments, the communication subsystem 1724 may provide a wired network connection (e.g., Ethernet®) in addition to or instead of a wireless interface.

[0196] In some embodiments, the communication subsystem 1724 may also receive input communications in the form of structured and / or unstructured data feeds 1726, event streams 1728, event updates 1730, etc., on behalf of one or more users who can use the computer system 1700.

[0197] For example, the communication subsystem 1724 handles Twitter® feeds, Facebook ( It can be configured to receive data feeds 1726 in real time from users of social networks and / or other communication services, such as updates from registered trademarks, web feeds like rich site summary (RSS) feeds, and / or real-time updates from one or more third-party sources.

[0198] Additionally, the communication subsystem 1724 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 1728 and / or event updates 1730 of real-time events that are continuous or unlimited, and which essentially have no clear 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, and automotive traffic monitoring.

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

[0200] Computer system 1700 supports handheld portable devices (e.g., iPhone® mobile phones, iPad® computing tablets, PDAs), wearable devices (e.g., Google Glass® head-mounted displays), It can be one of various types, including PCs, workstations, mainframes, kiosks, server racks, or any other data processing systems.

[0201] Due to the constantly changing nature of computers and networks, the description of the computer system 1700 shown in the drawings is intended only as a specific example. Many other configurations are possible, having more or fewer components than the system shown in the drawings. For example, customized hardware may also be used, and / or certain elements may be implemented in hardware, firmware, software (including applets), or a combination thereof. Furthermore, connectivity to other computing devices, such as network input / output devices, may be utilized. Based on this disclosure and the teachings provided herein, those skilled in the art will understand other forms and / or methods for implementing various embodiments.

[0202] Exemplary embodiments of this disclosure can be described in light of the following sections. Item 1. The methods performed by a computer may include one or more of the following: 1) a computing device in a cloud computing environment identifies a first set of computing components already deployed in the cloud computing environment; 2) a computing device identifies a second set of computing components available for deployment in the cloud computing environment; 3) a computing device receives a deployment request that identifies a specific computing component from the second set of computing components available for deployment; 4) a computing device sends a bootstrap request corresponding to the specific computing component to a deployment orchestrator in the cloud computing environment configured to deploy the specific computing component to the cloud computing environment based at least in part on the bootstrap request; and / or 5) a computing device presents a first set of status indicators for the first set of computing components already deployed in the cloud computing environment, and a user interface that presents a status indicator corresponding to the specific computing component.

[0203] Section 2. The methods performed by the computer described in Section 1 may further include one or more of the following: 1) the computing device identifies that it has successfully deployed a particular computing component; 2) the computing device adds an identifier associated with the particular computing component to its routing table; 3) the computing device receives a subsequent request containing the identifier (e.g., user device 906 in Figure 9); and / or 4) the computing device sends the subsequent request to the particular computing component for processing.

[0204] 3. A method performed by a computer as described in either Section 1 or 2, which may cause a deployment orchestrator to perform one or more actions including 1) identifying one or more computing components on which a particular computing component depends, and / or 2) deploying one or more computing components before the computing device deploys a particular computing component.

[0205] 4. A method performed by the computer described in 3, on which identifying one or more computing components on which a particular computing component depends may be at least in part on determining one or more computing components from a directed acyclic graph that defines computing component dependencies.

[0206] Section 5. The method may further include one or more of the following: 1) the computing device presents information in a user interface that identifies one or more computing components on which a specific computing component being requested depends; 2) the computing device receives user input in a user interface indicating acceptance of deploying one or more computing components before deploying a specific computing component; and / or 3) the computing device sends each bootstrap request corresponding to one or more computing components to the deployment orchestrator, wherein each bootstrap request is sent before sending the bootstrap request corresponding to the specific computing component being requested.

[0207] Section 6. The method may further include the computing device sending a spin-down request to the deployment orchestrator corresponding to a specific computing component, the spin-down request being 1) the computing device (e.g., the U in Figure 9) A method performed by the computer described in any of paragraphs 1 to 5, transmitted in response to the computing device receiving a subsequent request from device 906 to spin down a particular computing component, or 2) the computing device identifying the last time point in time when the last request for a particular computing component was received and determining that the difference between the last time point and the present time exceeds a predetermined threshold time.

[0208] 7. A method performed by the computer described in 6, wherein sending a spin-down request is further based at least in part on determining that none of the other components of the cloud computing environment depend on any particular computing component.

[0209] Item 8. A computing device in a cloud computing environment may comprise one or more processors and one or more memories storing computer executable instructions, which, when executed by one or more processors, cause the computing device to perform one or more of the following actions: 1) identify a first set of computing components already deployed in the cloud computing environment; 2) identify a second set of computing components available for deployment in the cloud computing environment; 3) receive a request for deployment that identifies a specific computing component of the second set of computing components available for deployment; 4) send a bootstrap request corresponding to the requested specific computing component to a deployment orchestrator of the cloud computing environment configured to deploy the specific computing component to the cloud computing environment based at least in part on the bootstrap request; and / or 5) present a first set of status indicators for the first set of computing components already deployed in the cloud computing environment, and a user interface that presents a status indicator corresponding to a specific computing component.

[0210] Item 9. The computing device described in Item 8 may, by executing an instruction, perform additional actions including one or more of the following: 1) identifying that a particular computing component has been successfully deployed; 2) adding an identifier associated with the particular computing component to a routing table; 3) receiving a subsequent request containing the identifier; and / or 4) sending a subsequent request to the particular computing component for processing.

[0211] Item 10. A computing device as described in either Item 8 or 9, which causes a deployment orchestrator to perform actions including identifying one or more computing components on which a particular computing component depends, and deploying one or more computing components before deploying the particular computing component.

[0212] Item 11. The computing device according to Item 10, wherein identifying one or more computing components on which a particular computing component depends is at least in part based on determining one or more computing components from a directed acyclic graph that defines computing component dependencies.

[0213] Section 12. Executing such an instruction means that the computing device 1) presents information in the user interface that identifies one or more computing components on which the requested specific computing component depends, and 2) in the user interface that, before deploying the specific computing component A computing device as described in any of sections 8 to 11, which further performs additional actions including receiving user input indicating acceptance of deploying multiple computing components, and / or 3) sending each bootstrap request corresponding to one or more computing components to the deployment orchestrator, wherein each bootstrap request is sent before sending the bootstrap request corresponding to the specific computing component being requested.

[0214] Item 13. The computing device described in any of items 8 to 12, wherein executing such instruction causes the computing device to perform additional operations, including sending a spin-down request to the deployment orchestrator for a particular computing component, the spin-down request being sent in response to 1) receiving a subsequent request to spin down a particular computing component, or 2) identifying the last time a last request for a particular computing component was received and determining that the difference between the last time and the present time exceeds a predetermined threshold time.

[0215] Item 14. The computing device described in Item 13 further submits a spin-down request, at least in part, based on determining that none of the other components of the cloud computing environment depend on any particular computing component.

[0216] Item 15. A non-temporary computer-readable storage medium can store computer-executable instructions, which, when executed by one or more processors of a computing device, cause the computing device to: 1) identify a first set of computing components already deployed in a cloud computing environment; 2) identify a second set of computing components available for deployment in a cloud computing environment; 3) receive a request for deployment that identifies a specific computing component of the second set of computing components available for deployment; 4) send a bootstrap request corresponding to the requested specific computing component to a deployment orchestrator of the cloud computing environment configured to deploy the specific computing component to the cloud computing environment based at least in part on the bootstrap request; and / or 5) present a first set of status indicators for the first set of computing components already deployed in a cloud computing environment, and a user interface that presents a status indicator corresponding to a specific computing component.

[0217] Section 16. A non-temporary computer-readable storage medium as described in Section 15, which, when the instruction is executed, causes the computing device to further perform one or more of the following: 1) identify that a particular computing component has been successfully deployed; 2) add an identifier associated with the particular computing component to a routing table; 3) receive a subsequent request containing the identifier; and / or 4) send a subsequent request to the particular computing component for processing.

[0218] Item 17. A non-temporary computer-readable storage medium as described in either Item 15 or 16, which causes the deployment orchestrator to perform actions including 1) identifying one or more computing components on which a particular computing component depends, and / or 2) deploying one or more computing components before deploying a particular computing component.

[0219] Section 18. One or more computing components on which a particular computing component depends Identifying computing components is at least in part based on determining one or more computing components from a directed acyclic graph that defines computing component dependencies, as described in paragraph 17, for a non-temporary computer-readable storage medium.

[0220] Item 19. Executing such instruction further causes the computing device to: 1) present information in a user interface identifying one or more computing components on which a specific computing component being requested depends; 2) receive user input in a user interface indicating acceptance of deploying one or more computing components before deploying a specific computing component; and / or 3) have the computing device send each bootstrap request corresponding to one or more computing components to the deployment orchestrator, wherein each bootstrap request is sent before sending the bootstrap request corresponding to the specific computing component being requested, on a non-temporary computer-readable storage medium as described in any of Items 15 to 18.

[0221] 20. Executing such instruction further causes the computing device to send a spin-down request to the deployment orchestrator corresponding to a particular computing component, the spin-down request being sent in response to 1) receiving a subsequent request to spin down the particular computing component, or 2) identifying the last time a request for the particular computing component was received and determining that the difference between the last time and the present time exceeds a predetermined threshold time, the non-temporary computer-readable storage medium described in any of paragraphs 15 to 19.

[0222] While specific embodiments have been described, various modifications, alterations, alternative configurations, and equivalents are also included within the scope of this disclosure. The embodiments are not limited to operation within a particular data processing environment, but are free to operate within multiple data processing environments. Additionally, while the embodiments are described using a specific series of transactions and steps, it will be apparent to those skilled in the art that the scope of this disclosure is not limited to the described series of transactions and steps. Various features and aspects of the embodiments described above may be used individually or in combination.

[0223] Furthermore, while embodiments are described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of this disclosure. Embodiments may be implemented using hardware only, software only, or a combination thereof. Various processes described herein may be implemented on the same processor or on multiple different processors in any combination. Thus, where a component or module is described as being configured to perform a certain operation, such a configuration can be achieved, for example, by designing electronic circuits to perform the operation, by programming programmable electronic circuits (such as a microprocessor) to perform the operation, or by any combination thereof. Processes may 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 points in time.

[0224] Therefore, this specification and the drawings should be considered in an illustrative rather than restrictive sense. However, it will be apparent that additions, subtractions, deletions, and other modifications and changes can be made thereto without departing from the broader idea and scope set forth in the claims. Thus, if a particular embodiment of the disclosure is described... However, these are not intended to be limiting. Various modifications and equivalents are within the scope of the attached claims.

[0225] In the context describing embodiments of this disclosure (in particular, in the context of the following claims), the terms “a” and “an” and “the” and similar reference subjects should be construed to cover both singular and plural, unless otherwise indicated herein or unless explicitly contradicted by the context. The term "..." should be interpreted as an open-ended term (i.e., meaning "not limited to, but including...") unless otherwise indicated. The term "connected" should be interpreted as encompassing, attaching, or joining together, in part or in whole, even if something is intervening. The descriptions of value ranges herein are merely intended to serve as a simplified way of referring individually to each distinct value within that range unless otherwise indicated herein, and each distinct value is incorporated herein as if it were individually stated herein. All methods described herein may be implemented in any appropriate order unless otherwise indicated herein or unless it is clearly inconsistent with the context. Any examples or illustrative language given herein (e.g., "such as") is intended to improve understanding of the embodiments. This disclosure is intended solely to be helpful and, unless otherwise asserted, does not limit its scope. Nothing in this specification should be construed as indicating that any unclaimed element is essential to the practice of this disclosure.

[0226] Disjunctive phrases such as "at least one of X, Y, or Z" are intended to be understood in the context of their general use to indicate that an item, category, etc., can be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise specifically stated. Therefore, such disjunctive phrases are not, and should not, be intended to imply that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z be presented.

[0227] Preferred embodiments of the Disclosure, including the best known mode for carrying out the Disclosure, are described herein. Variations of these preferred embodiments may become apparent to those skilled in the art by reading the above description. Those skilled in the art should be able to appropriately utilize such variations, and the Disclosure may be practiced in ways other than those specifically described herein. Accordingly, the Disclosure includes all modifications and equivalent forms of the subject matter listed in the claims appended herein, as permitted by applicable law. Furthermore, unless otherwise indicated herein, any combination of the elements described above in all possible variations is encompassed by the Disclosure.

[0228] All references cited herein, including publications, patent applications, and patents, are incorporated herein by reference to the same extent as they are individually and specifically directed to be incorporated by reference and to the same extent as they are incorporated herein in whole.

[0229] In the above specification, aspects of the disclosure are described with reference to specific embodiments, but it will be recognized by those skilled in the art that the disclosure is not limited thereto. The various features and aspects of the disclosure described above may be used individually or in combination. Furthermore, embodiments can be used in any number of environments and applications beyond those described herein without departing from the broader idea and scope of this specification. Accordingly, this specification and the drawings should be considered illustrative, not limiting. Thus, while specific embodiments of the disclosure are described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims.

Claims

1. A method performed by a computer, A computing device in a cloud computing environment identifies a first set of computing components already deployed within the cloud computing environment, The computing device identifies a second set of computing components available for deployment within the cloud computing environment, The computing device includes receiving a request for deployment, the request for deployment identifies a specific computing component of the second set of computing components available for deployment, and the method further includes: The computing device includes sending a bootstrap request to a deployment orchestrator of the cloud computing environment corresponding to the requested specific computing component, the deployment orchestrator is configured to deploy the specific computing component to the cloud computing environment at least in part based on the bootstrap request, and the method further includes: A method performed by a computer, comprising presenting status indicators for a first set of computing components already deployed in the cloud computing environment and status indicators corresponding to a particular computing component in a user interface.

2. Identifying that the deployment of the aforementioned specific computing component has been successful, Adding an identifier associated with the aforementioned specific computing component to the routing table, Receiving a subsequent request containing the aforementioned identifier, A method performed by a computer according to claim 1, further comprising transmitting the subsequent request to the specific computing component for processing.

3. Sending the bootstrap request means that the deployment orchestrator, Identifying one or more computing components on which the aforementioned specific computing component depends, Before deploying the specific computing component, deploy one or more computing components, A method performed by a computer according to claim 1, which involves causing the computer to perform an operation including the following.

4. Identifying one or more computing components on which a particular computing component depends is a method performed by a computer according to claim 3, at least in part by determining one or more computing components from a directed acyclic graph that defines computing component dependencies.

5. The user interface presents information identifying one or more computing components on which the requested specific computing component depends, The user interface receives user input indicating acceptance of deploying one or more computing components before deploying the specific computing component, The method performed by a computer according to claim 3, further comprising the computing device transmitting to the deployment orchestrator a bootstrap request for each of the one or more computing components, wherein each of the bootstrap requests is transmitted before transmitting the bootstrap request for the specific computing component being requested.

6. A method performed by a computer according to claim 1, further comprising sending a spin-down request corresponding to the particular computing component to the deployment orchestrator, wherein the spin-down request is sent in response to 1) receiving a subsequent request to spin down the particular computing component, or 2) identifying the last time a last request for the particular computing component was received and determining that the difference between the last time and the present time exceeds a predetermined threshold period.

7. The method of transmitting the spin-down request performed by the computer according to claim 6, further comprising determining, at least in part, that none of the other components of the cloud computing environment depend on the particular computing component.

8. A computing device in a cloud computing environment, wherein the computing device is One or more processors, The computer includes one or more memories that store a plurality of executable instructions, and when the plurality of instructions are executed by the one or more processors, the computing device is configured to: Identifying a first set of computing components already deployed within the aforementioned cloud computing environment, Identifying a second set of computing components available for deployment within the aforementioned cloud computing environment, The system receives a request for deployment, the request for deployment identifies a specific computing component of the second set of computing components available for deployment, and the plurality of instructions, once executed by one or more processors, further cause the computing device to The system is configured to send a bootstrap request corresponding to the requested specific computing component to the deployment orchestrator of the cloud computing environment, the deployment orchestrator being configured to deploy the specific computing component to the cloud computing environment at least in part based on the bootstrap request, and the plurality of instructions, once executed by the one or more processors, further to the computing device. A computing device that causes a user interface to display status indicators for a first set of computing components already deployed in the cloud computing environment, and status indicators corresponding to specific computing components.

9. Executing the aforementioned multiple instructions further involves the computing device, Identifying that the deployment of the aforementioned specific computing component has been successful, Adding an identifier associated with the aforementioned specific computing component to the routing table, Receiving a subsequent request containing the aforementioned identifier, The computing device according to claim 8, which causes the subsequent request to be transmitted to the specific computing component for processing.

10. Sending the bootstrap request means that the deployment orchestrator, Identifying one or more computing components on which the aforementioned specific computing component depends, Before deploying the specific computing component, deploy one or more computing components, A computing device according to claim 8, which causes the device to perform an operation including the above.

11. The computing device according to claim 10, wherein identifying one or more computing components on which a particular computing component depends is at least in part based on determining one or more computing components from a directed acyclic graph that defines computing component dependencies.

12. Executing the aforementioned multiple instructions further involves the computing device, The user interface presents information identifying one or more computing components on which the requested specific computing component depends, The user interface receives user input indicating acceptance of deploying one or more computing components before deploying the specific computing component, The computing device according to claim 10, wherein the computing device causes the deployment orchestrator to transmit a bootstrap request for each of the one or more computing components, and each of the bootstrap requests is transmitted before transmitting the bootstrap request for the specific computing component being requested.

13. Executing the aforementioned multiple instructions further involves the computing device, The computing device according to claim 8, wherein the device causes the deployment orchestrator to send a spin-down request corresponding to the specific computing component, the spin-down request being sent in response to 1) receiving a subsequent request to spin down the specific computing component, or 2) identifying the last time a last request for the specific computing component was received and determining that the difference between the last time and the current time exceeds a predetermined threshold period.

14. The computing device according to claim 13, wherein the transmission of the spin-down request is further at least in part based on determining that none of the other components of the cloud computing environment depend on the particular computing component.

15. A computer program for causing a computing device to perform the method according to any one of claims 1 to 7.

Images