Techniques for providing cloud services on demand

Abstract

To provide a method for deploying computing resources in response to user input, a computing device, and a storage medium.SOLUTION: The method includes a computing device of a cloud computing environment receiving a request including an identifier of a computing component of the cloud computing environment, determining whether the identifier is present in a routing table, forwarding the request to the computing component according to the identifier being present in the routing table, in response to the request, sending an error code indicating that the computing component is unavailable according to the identifier not being present in the routing table, sending a bootstrap request corresponding to the computing component to a deployment orchestrator of the cloud computing environment, receiving a subsequent request including the identifier, and sending the subsequent request to the computing component for processing.SELECTED DRAWING: Figure 8

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is filed in the U.S. District Court for the District of Columbia, ... This application claims priority to U.S. patent application Ser. No. 17 / 494,533, filed October 5, 2019, entitled "Techniques for Providing Cloud Services On Demand," and U.S. patent application Ser. No. 17 / 494,495, filed October 5, 2021, entitled "Techniques for Providing Cloud Services On Demand," the entire disclosures of which are incorporated by reference for all purposes. and is incorporated herein by reference. [Background technology]

[0002] background In today's cloud computing environment, a predetermined set of cloud services may be deployed in a given region. There is no guarantee that users in that region will use all of the deployed services. Deploying and maintaining unused services can waste valuable resources in the cloud computing environment. Additionally, it may be the case that a user desires to use a service that was not originally deployed in that region. If a service call is made to a service that is not currently deployed, an error code is returned and the user's request goes unprocessed. Additionally, a user may have no control over the specific services that are deployed in that region. Modifications can be made regarding the management and deployment of various services within a cloud computing environment that improve user control and provide an improved overall user experience. Summary of the Invention [Means for solving the problem]

[0003] A brief overview Embodiments of the present disclosure relate to providing the ability to deploy requested and / or ordered cloud computing resources (e.g., services) at runtime. More particularly, some embodiments provide methods, computer-readable media, and systems that implement the functionality of receiving a request for a previously undeployed service, determining that the service is not currently deployed, and requesting bootstrap / deployment of the requested service via a cloud orchestration service. In some embodiments, a user interface can be provided through which services can be explicitly ordered / requested. Utilizing the user interface, the ability to request bootstrap / deployment of a particular service (e.g., utilizing a cloud orchestration service) is provided.

[0004] One embodiment is directed to a method for deploying cloud computing resources. The method may include a computing device of a cloud computing environment receiving a request including an identifier of a computing component of 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 existing in the routing table. The method may further include the computing device responding to the request by transmitting an error code indicating that the computing component is unavailable according to the identifier not existing in the routing table, and the computing device forwarding a bootstrap request corresponding to the computing component to the cloud computing environment based at least in part on the bootstrap request. and transmitting the request to a deployment orchestrator of a cloud computing environment configured to deploy the component. The method may further include receiving a subsequent request including the identifier. The method may further include transmitting the subsequent request to the computing component for processing.

[0005] Another embodiment is directed to another method for deploying cloud computing resources. The method may include a computing device of a cloud computing environment identifying a first set of computing components already deployed within the cloud computing environment. The method may further include the computing device identifying a second set of computing components available for deployment within 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 specific computing components of the second set of computing components available for deployment. The method may further include the computing device sending a bootstrap request to a deployment orchestrator of the cloud computing environment corresponding to the specific computing components being requested. In some embodiments, the deployment orchestrator is configured to deploy the specific computing components into the cloud computing environment based at least in part on the bootstrap request. The method may further include presenting a user interface presenting a first set of status indicators of the first set of computing components already deployed within the cloud computing environment and the status indicators corresponding to the specific computing components.

[0006] In some embodiments, the method may further include identifying successful deployment of the particular computing component, adding an identifier associated with the particular computing component to a routing table, receiving a subsequent request including 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 operations including (at least) 1) identifying one or more computing components on which the particular computing component depends, and 2) deploying the 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 based at least in part on determining the one or more computing components from a directed acyclic graph that defines computing component dependencies.

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

[0010] In some embodiments, the method may further include sending a spin-down request corresponding to the particular computing component to the deployment orchestrator, 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 last request for the particular computing component was received and determining that the difference between the last time and the current time exceeds a predetermined threshold time.

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

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

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

[0014] Another embodiment is directed to an apparatus for providing cloud services, comprising means for performing the steps of any of the methods described herein.

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

[0016] To easily identify any particular element or discussion of act, one or more leading digits in a reference number refer to the figure number in which that element is first introduced. [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service, according to at least one embodiment. [Figure 2] FIG. 1 is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service, according to at least one embodiment. [Figure 3] FIG. 1 is a flow diagram illustrating the flow of operations performed in response to an application programming interface (API) call to a previously deployed service, according to at least one embodiment. [Figure 4] FIG. 1 is a flow diagram to illustrate the flow of operations performed in response to an API call for a service that has not yet been deployed, according to at least one embodiment. [Figure 5] FIG. 1 is a flow diagram illustrating the flow of operations performed in response to an API call to a service that is not yet deployed when the service depends on another service that is also not yet deployed, according to at least one embodiment. [Figure 6] FIG. 1 is a flow diagram illustrating an example process for orchestrating the execution of a task that includes a dependency on at least one feature, according to at least one embodiment. [Figure 7]FIG. 1 is a flow diagram illustrating a flow of operations for spinning down unused services, according to at least one embodiment. [Figure 8] FIG. 1 is a flow diagram illustrating an example process for orchestrating the bootstrapping of a service in response to receiving an API request, according to at least one embodiment. [Figure 9] FIG. 1 is a flow diagram to illustrate the flow of operations performed in response to an order for a service that has not yet been deployed, according to at least one embodiment. [Figure 10] FIG. 1 is a flow diagram illustrating the flow of operations 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. [Figure 11] 10A-10C are diagrams of exemplary user interfaces for, among other things, initiating the actions described above, according to at least one embodiment. [Figure 12] FIG. 1 is a flow diagram illustrating an example process for orchestrating bootstrapping of a resource in response to receiving an order request for the resource, according to at least one embodiment. [Figure 13] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 14] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 15] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 16] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system, according to at least one embodiment. [Figure 17] FIG. 1 is a block diagram illustrating an exemplary computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0018] Detailed Description In some examples, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In some examples, IaaS is one of three major categories (or subcategories) of cloud computing services. The other major categories are often considered to be Software as a Service (SaaS) and Platform as a Service (PaaS), although SaaS is sometimes considered a broader category that encompasses both PaaS and IaaS, and even IaaS is sometimes considered a subcategory of PaaS.

[0019] In the IaaS model, a cloud computing provider may 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 may also supply various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) to accompany those infrastructure components. Accordingly, these services may be policy-driven, allowing IaaS users to implement policies to drive load balancing to maintain application availability and performance.

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

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

[0022] In some examples, IaaS can be used to provision an initial set of infrastructure components (e.g., services, etc.). In embodiments, the infrastructure (e.g., which components are required 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 work together with each other) can be described declaratively. In some cases, once the topology is defined, workflows can be generated that create and / or manage the different components described in the configuration files.

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

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

[0025] Generally, a preparation tool can be configured to obtain a configuration file, parse the declarative information contained therein, 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 enforce the boot in that order without user intervention and / or without that information necessarily being included in the configuration file.

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

[0027] As mentioned above, there are generally two different tools used to handle the provisioning of infrastructure resources and the deployment of code to control the infrastructure resources, where the orchestration between the two tools is performed manually. However, at scale, manual implementations always result in deviations. Therefore, an automated tool that can both provision and deploy virtual infrastructure enables a more efficient and reliable technique for implementing virtual cloud environments.

[0028] In some instances, when two tools are used, problems can arise if a user manually makes changes to the code between the preparation and deployment phases. As described herein, techniques using a single tool for both preparation and deployment can mitigate that problem by automating the process so that there is no opportunity for manual code changes. It is possible that a small change to the way a user codes something can cause major problems in the deployment phase. In some instances, when an operator first performs an action in a new area (e.g., a typo in the code), the object coded with the typo may remain there forever. If an application is deployed with the typo and the application is unaffected by the typo (e.g., still functional), sometimes additional code changes in the future will become affected by the typo and may crash the entire system. Thus, the techniques provided herein can often eliminate the gap between preparation and deployment that can cause problems.

[0029] Generally, modeling deployment is declarative, such that configuration files can be used to declare infrastructure resources. For example, create, read, update, and delete (CRUD) operations are typically used to generate deployment files using popular Representational State Transfer (REST) ​​concepts (e.g., REST Application Programming Interfaces (APIs)). However, deployment itself does not typically follow the same concepts. Additionally, while infrastructure preparation tools tend to be powerful and / or expressive in nature, 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). Therefore, there has been a long-standing need for tools that can handle both functional requirements (e.g. provisioning and deployment of infrastructure elements) within a cloud environment.

[0030] Embodiments disclosed herein may utilize a Cloud Infrastructure Orchestration Service (CIOS), which may be configured to manage both the provisioning and deployment of infrastructure assets within a cloud environment. In some cases, the CIOS may include two classes of services: a central component and a regional component (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 global infrastructure provisioning and code deployment without manual effort from service teams (e.g., beyond initial approval in some cases). High-level responsibilities of CIOS include, but are not limited to: · Providing the team with a view into the current state of resources managed by the CIOS, including any ongoing change activity. ·Helping the team plan and release new changes. · Coordinating activities across various downstream systems within the region to execute approved release plans without human intervention. ·Coordinate activities across multiple regions / territories to execute approved release plans globally.

[0032] Evolving existing infrastructure (e.g., adding new services, modifying services, removing services, etc.) once everything is in place can be difficult. Traditionally, if a service that was not previously in place is requested (e.g., via an API call), the request will be rejected, and the user will not be able to access the service. Additionally, services that are no longer available (or at least underutilized according to some predetermined threshold) may continue to operate, wasting resources, even when the service is no longer needed. To address these deficiencies, IaaS can be configured to implicitly identify when to add new services and / or when to remove services and can perform corresponding actions to automatically deploy or scale down 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 and an overall more seamless and less frustrating user experience.

[0033] FIG. 1 is a block diagram of an architecture for implementing at least some elements of a cloud infrastructure orchestration service, according to at least one embodiment. For example, FIG. 1 shows an architecture 100 for illustrating techniques for implementing CIOS Central 102. In some examples, CIOS Central 102 may be a service that handles operations at the "flock" level. A flock can be a model that a CIOS can use to encapsulate the control plane and all its components. A flock can be used to model ownership of and point to infrastructure components. An infrastructure component can be a long-lived infrastructure that supports the execution of code (e.g., deployed applications, loaded applications, etc.). Flock configuration files can be used to describe the set of all infrastructure components, artifacts, and deployment tasks associated with a single service. Each Flock can have one Flock configuration file (referred to herein as a "flock config"). Flock configs are checked into source control. Flock configs are declarative, providing region, geography, availability domain (AD), and artifact version as input. An artifact refers to code being deployed to a deployment application or Kubernetes engine cluster, or configuration information (hereafter "config") being applied to an infrastructure component.

[0034] In some embodiments, CIOS Central 102 has several roles, including but not limited to: Acting as an authentication gateway for flock metadata changes and release operations. · Storing an authoritative mapping of Flock metadata about that Flock to deployment artifacts and CIOS repositories. ·Coordinating global releases across multiple phases and goals. Synchronization to enforce policies like "no more than one in-progress release at a time for a flock." Detecting changes to flock configurations and artifacts and triggering 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 so that the CIOS Central 102 can be notified of new artifact builds. The CIOS Central 102 can then map incoming changes to affected flocks and initiate release planning if desired. Additionally, in some examples, an Artifact Push Service (APS) can be invoked by the CIOS Central 102 prior to releasing to the target to ensure that any artifacts required for a successful release are present in the target region before the release.

[0036] In some examples, customers (e.g., engineers) 108 can call CIOS Central 102 to perform CRUD on flocks and / or releases and view the status of ongoing CIOS activities. A flock management service 110 can include one or more APIs for manipulating flocks, a view / plan / approve service 112 can 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 can monitor SCVMS 104 for changes to flock configurations and receive notifications from ANS 106 regarding changes to other artifacts, and a state ingestor service 116 can create copies of each domain state (e.g., point-in-time snapshots of the state of domain resources) in a CIOS central database (DB) 118 so that view / plan / approve 112 can expose them. The state ingestor service 116 can be any suitable service / computing device configured to determine the state of domain resources and generate point-in-time snapshots. In some examples, the CIOS Central DB 118 can be a DB of flock, plans, and status. Flock information can be authoritative, while everything else is a stale copy of data from the CIOS Regional 120. CIOS Central 102 may be configured to provide any suitable portion of, and / or any suitable number of, user interfaces for presenting any suitable data related to blocks, releases, infrastructure components, artifacts, etc. In some embodiments, CIOS Central 102 may present data related to one or more releases via any suitable interface. A release may include any suitable combination of tasks related to one or more infrastructure components and / or one or more code changes (e.g., artifacts) to one or more applications.

[0037] In some examples, the engineer 108 can make an API call 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 an API call can be Hypertext Transfer Protocol Secure (HTTPS), etc. The associated access control list (ACL) for this operation can include a local area network (LAN) 124 or other private connection. For example, the CIOS may manage / control network connections (e.g., dedicated, leased, and / or private connections) instead of using the public Internet to connect a customer's on-premise data center or network with the CIOS. Additionally, authentication and authorization (e.g., of the engineer 108) may be performed by a reservation system portal (e.g., a booking service) that allows users to manage the machine infrastructure. In some cases, the CIOS central 102 can store flock metadata, plans, and states in the central DB 118 using Java Database Connectivity (JDBC), etc. In some examples, the ANS 106 can be configured to notify the change monitoring service 114 when new artifacts are published. The ANS 106 may use HTTPS, and both authentication and authorization may be handled by mutual transport layer security services. Additionally, in some cases, the change monitoring service 114 can poll the SCVMS 104 for block configuration changes. This polling can be performed using Secure Shell (SSH) or other protocols. Authentication for the change monitoring service 114 can be handled by a CIOS system account, and authorization can be handled by the SCVMS 104.

[0038] In some examples, the engineer 108 can use the view / plan / approval service 112 to perform one or more of the following operations: The engineer 108 can perform planning and / or approval by calling the CIOS central 102 to generate and approve a plan. The engineer 108 can perform viewing by calling the CIOS central 102 to view the status of ongoing CIOS activities on a global scale. Additionally, the engineer 108 can perform viewing by calling the CIOS central 102 to view replicas of the state of CIOS-managed resources on a global scale. These API calls (or the like) can be implemented via the HTTPS protocol or a similar protocol. Additionally, associated access control lists (ACLs) can be controlled by the LAN 124, and both authentication and authorization can be handled by the reservation service. In some examples, the view / plan / approval service 112 can request a plan and push plan approvals to all regions of the CIOS regionals 120 (e.g., using HTTPS or the like). Associated ACLs can be controlled using security lists managed by the Wide Area Network (WAN) Gateway 126. Authentication can be handled by mutual transport layer security, and authorization can be handled by various identity policies. Additionally, the State Ingester Service 116 can update the CIOS list about job status or state changes. Regional 120 can be monitored so that the CIOS can provide a central view of them upon request (e.g., also using HTTPS or the like). ACLs for this can also be handled by the WAN gateway 126, and both authentication and authorization can be handled by mutual transport layer security services.

[0039] Figure 2 shows an architecture 200 to illustrate 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, can occur. In some cases, each instance of CIOS Regional 202 can handle operations at the level of "Execution Targets." It may have a regional fronted, which may be configured to: · Handling all CIOS authentication for incoming actions from CIOS Central 102. · Enforcing the rule that only one "execution" (plan / resource import / apply plan) can be in progress at a time for a given execution goal. Managing binary artifact storage for declarative preparation artifacts used as inputs and outputs during declarative infrastructure preparation runs. Example inputs are declarative infrastructure preparation configuration files and input state files. A typical output is a final state file. · For any given execution, requesting work from the CIOS executor and polling for results from the CIOS executor.

[0040] In some cases, the CIOS front end may handle the actual execution and rely on the CIOS executor 206 (also referred to herein as the "scheduler"). The CIOS executor, in some examples, operates at the "execution" level and may: Keeping track of the pool of available worker nodes. · Querying incoming job requests and assigning them to eligible workers as they become available. · Tracking worker status and execution updates to report to clients. Detect dead nodes via the lease protocol and, depending on the task status, give up tasks assigned to the dead node. Providing facilities to cancel / stop / pause / resume execution, and mapping them to the facilities so that the cancel / stop / resume information can be communicated to the worker nodes.

[0041] In some cases, the CIOS execution unit may rely on CIOS workers, which can assign tasks to workers for execution and provide facilities for workers to update job progress. The worker service operates at the granularity of a "task". Each worker is an agent that executes the tasks assigned to it and reports task status and output. Each worker can: Polling the executor worker API for assigned work items and taking steps to match the assigned state with its local state.

[0042] Starting a container to poll for task items that do not exist locally. Stopping a container for locally running containers that do not have a corresponding assigned task item. · Reporting job status. ·Staging inputs and outputs for job container execution. · Launching and monitoring declarative infrastructure preparation containers to do the actual work of releasing execution targets.

[0043] A CIOS worker may rely on the CIOS executor to poll for work from the CIOS executor's worker endpoint and report results to the worker endpoint. The worker may rely on the executor for all coordination. Additionally, a CIOS worker may also rely on CIOS regional 202 where the worker service reads input from and writes output to one or more APIs associated with the regional front-end service. Examples of inputs are configuration and startup state files and import mappings. Examples of outputs are 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 stats related to a particular region. Regional DB 204 can be a CIOS DB for the state and plans of a particular region. This is an authoritative copy of the regional subset of central DB 118 in FIG. 1. Scheduler 206 can be responsible for managing worker fleet capacity, assigning tasks to workers, and tracking task status. In some cases, task DB 208 is another CIOS DB for task status. The data in this DB is mostly for operational purposes. Additionally, workers 210 can be a fleet of Java Virtual Machines (JVMs) that manage declarative preparation images. They receive instructions from scheduler 206 and communicate results to both scheduler 206 and CIOS regional 202. CIOS container 212 can execute declarative preparation actions in its own private Docker 214 container. This container does not need to contain secrets. Additionally, in some examples, signing proxy 216 can be configured to prevent secret leakage via declarative preparation tools to avoid placing secrets in the declarative preparation image. Instead, CIOS can perform request signing or initiate mutual Transport Layer Security (mTLS) services at the proxy. This also makes it easier to use FIPS-compliant cryptographic libraries.

[0045] In some examples, CIOS Central 102 can call CIOS Regional 202 to create plans, push approvals, watch job status, and extract declarative provisioner state (service principal). Ingress Proxy 218 can be configured as an ACL, and various identity policies can be used for both authentication and authorization. Alternatively, in some examples, Ingress Proxy 218 may be replaced by a load balancer configured to balance load-incurring 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 running and can report status to Scheduler 206 when it is done. In some cases, mTLS can handle both authentication and authorization for CIOS Regional 202 and Worker 210. Additionally, when a worker 210 needs to run a declarative provisioner, it does so in a Docker container by interacting with local Docker 214. Authentication for this stage can be handled by a local Unix socket. This final step can use the Docker protocol, while the previous steps can utilize HTTPS.

[0046] In some embodiments, CIOS regional 202 can be configured to provide any suitable portion of, and / or any suitable number of, user interfaces for presenting any suitable data related to blocks, releases, infrastructure components, artifacts, or the like. In some embodiments, CIOS regional 202 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.

[0047] In some examples, the CIOS container 212 allows the declarative provisioner to interact with the signing proxy 216 (via an API), which the declarative provisioner sees as calling various CIOS services. The signing proxy 216 listens on one ephemeral port per declarative provisioner call instance, 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 endpoints of public services when possible. For services without internal endpoints, the signing proxy 216 must use the egress proxy 222 to reach the external endpoints. This use of the signing proxy 216 may not be for inter-region communication; for example, each region's egress proxy whitelist may be for only that region's public IP ranges. In some examples, the worker 210 can then maintain state and logs from the declarative provisioner within the CIOS regional 202 so that they can leak to the CIOS central 102 .

[0048] CIOS (or a declarative infrastructure provisioner, such as the CIOS declarative preparation tool described above) can be utilized to parse the configuration file. Through this analysis, CIOS (or the declarative preparation provisioner) can generate a directed acyclic graph (DAG) for each resource, module, and / or function that 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 function of another resource. The DAG for each resource can specify implicit dependencies, explicit dependencies, or a combination thereof, and can be used to boot or otherwise deploy the corresponding resource using CIOS.

[0049] 3 is a flow diagram illustrating a flow 300 of operations 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 figures are examples of computing components of the cloud computing environments of FIGS. 1 and 2. The same examples can be applied to other computing components (e.g., databases, object storage, block storage, virtual machines, etc.). A computing component as used in this disclosure may include any suitable computing device, computer program product, processor, and / or service.

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

[0051] At 310, gateway computer 308 (or any suitable component of FIG. 2 , such as ingress proxy 218, CIOS regional 202, etc.) may authenticate the user of the API call. In some embodiments, authentication may include making an API call to one or more services (e.g., identity services) configured to maintain authorization and / or identity data for one or more users of the system. As an example, gateway computer 308 may call an identity service configured with authorization and / or identity data that may be utilized along with the user's identifier as received in the request to identify the user and / or one or more authorization policies associated with the user.

[0052] At 312, a determination can be made as to whether the API call can be routed. This determination can include any suitable combination of: 1) whether the user is the intended person; 2) whether the user has authorization to invoke such functionality of service 302; or 3) whether the identifier of the service (e.g., IP address) is included in a current routing table maintained by gateway computer 308. By way of example, if the user's identity is known and / or permissions associated with the user indicate that the user is authorized to make the API call, and the identifier of service 302 is included in a routing table maintained by gateway computer 308, gateway computer 308 can forward the request to service 302. This forwarding can include identifying a destination address associated with service 302 from the routing table and a service identifier received in the message and associated with service 302.

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

[0054] At 316, the user device 306 receives the response and may perform any appropriate action, such as, but not limited to, displaying an indication to the user that the API call was successfully processed.

[0055] Alternatively, at 312, the gateway computer 308 (or another suitable A determination that the API is not routable may be made by the gateway computer 308 (or other suitable component). For example, if the user is not the intended person and / or does not have authorization to make such an API call, and / or if the service's 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 suitable component) may determine that the API call is not routable and may forward 320 a return error code (e.g., an alphanumeric value indicating a general or specific error) to the user device 306.

[0056] At 322, the user device 306 can be configured to perform one or more actions to handle the error, such as displaying an indication of the error on a screen, enabling a user option to try another request, etc.

[0057] 4 is a flow diagram illustrating a flow 400 of operations performed in response to an API call for a service (e.g., service 402) 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 in a region and / or may be accessible to user devices via API calls. Service 402 may not be included in that initial predetermined set of deployed services.

[0058] Flow 400 may begin at 404, where an API request may be made by a user device 406 (e.g., an example of user device 306 in FIG. 3 ). In some embodiments, the API call may be implemented via HTTPS or a similar protocol. The API call may include any appropriate information, such as an identifier of the user, an identifier of 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 WAN gateway 126 in FIG. 1 . Similar to the gateway computers described above, gateway computer 408 may be configured to maintain a routing table of previously deployed regional services (e.g., cloud services A-N in FIG. 2 ). The routing table may include the Internet Protocol (IP) address of each service and / or infrastructure component in the environment provided by the architectures of FIGS. 1 and 2 . The routing table may contain any appropriate information necessary to forward a data packet toward its destination. For example, the routing table may include a destination network identifier (e.g., an IP address), a subnet mask used to match the destination IP address with the network ID, and any suitable information configured to allow a data packet to be forwarded toward its destination.

[0059] At 410, gateway computer 408 (or any suitable component of FIG. 2 , such as ingress proxy 218, CIOS regional 202, etc.) can authenticate the user of the API call. As described above, authentication can include making an API call to one or more services (e.g., identity services) configured to maintain authorization and / or identity data for one or more users of the system. As an example, gateway computer 308 can call an identity service configured with authorization and / or identity data that can be utilized along with a user identifier as received in the request to identify the user and / or one or more authorization policies associated with the user. As another example, gateway computer 408 can maintain user data associated with any suitable number of users and can make an API call to one or more services (e.g., identity services) configured to maintain authorization and / or identity data for one or more users of the system. Any suitable information obtained from the rule (eg, an identifier associated with the user) may be used to authenticate the user to the user data.

[0060] At 412, a determination can be made as to whether the API call can be routed. This determination can include any suitable combination of identifying 1) whether the user is the intended person, 2) whether the user has authorization to invoke such functionality of the service 302, or 3) whether the identifier (e.g., IP address) of the service is included in the current routing table maintained by the gateway computer 408. This determination can be similar to that made at 312 in FIG. 3.

[0061] If the API call is not routable (e.g., service 402 is not yet deployed, is not included in the routing table, etc.), flow 400 can proceed to 414, where a return error can be forwarded to user device 406 and data can be sent to orchestrator 416 (e.g., CIOS Central 102 of FIG. 1) indicating that bootstrapping of the requested service (e.g., service 402) should be initiated.

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

[0063] At 420, orchestrator 416 may receive the bootstrap request and perform any suitable operation to bootstrap (e.g., load into memory (e.g., the memory of a virtual machine) and / or initialize) a non-existent service (e.g., service 402). In some embodiments, orchestrator 416 may utilize a predetermined set of instructions associated with bootstrapping service 402. By way of example, a directed acyclic graph (DAG) associated with service 402 may be utilized to identify one or more instructions for bootstrapping service 402. In some embodiments, this DAG is part of a larger DAG that maintains the interdependencies of various services with the functionality of other services (e.g., particular portions of functionality provided by another service). The DAG associated with service 402 may be any suitable portion of a finite, directed graph that includes any suitable number of nodes and edges, with each edge directed from one node to another. The nodes and edges may be arranged to avoid directed cycles. Thus, a finite directed graph (e.g., a DAG) is constructed such that at any node, it is not possible to follow a consistently directed series 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 otherwise indicate the end of the finite directed graph.

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

[0065] The DAG can be traversed to orchestrate the execution of operations to boot and / or deploy resources (e.g., services 402) within a cloud computing environment with respect to one or more dependencies on the functionality of other resources (or other resources themselves).

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

[0067] The user can then initiate a new API call at 404, and operations 404-412 can be repeated. At this point, the routing table contains data associated with service 402 (e.g., an identifier for the service, an IP address for service 402, etc.), and the determination made at 412 can indicate that the API call is now routable to service 402, and the API call can be forwarded to service 402 at 424. In some embodiments, service 402 (or gateway computer 408) can start a timer of a predetermined duration. 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 another API call is not received for that service within a predetermined period of time since the last received API call. An example of this process is described in more detail in connection with FIG. 7.

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

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

[0070] If the service 402 first becomes available after the initial API call described above, the flow 400 will continue from the bootstrapping step because the service is already available at the time of the API request. It should be understood that one can proceed from 412 to 424, forgoing the strapping process and routing table update entirely.

[0071] FIG. 5 is a flow diagram illustrating a flow 500 of operations 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 may begin at 504, where an API request may be made by a user device 506 (e.g., an example of user device 406 of FIG. 4). In some embodiments, the API may be implemented via HTTPS or a similar protocol. The operations performed at 504, 510, 512, 514, and 518 may be substantially the same as the operations discussed at 404, 410, 412, 414, and 418 of FIG. 4. The operation performed at 530 may be substantially the same as the operation discussed at 424 of FIG. 4 and may be implemented by service 502 or gateway computer 508. The API call may be received by gateway computer 508, which may be the same as or similar to gateway computer 408 of FIG. 5, which may be an example of a computer implementing WAN gateway 126 of FIG. 1.

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

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

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

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

[0077] At 612, the computing process 606 generates a configuration file associated with the deployment. The file can be parsed to generate a directed acyclic graph (DAG) of a particular resource (eg, 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. The directed edges of each DAG define the order in which these operations should be performed and / or the dependencies between the subset of operations associated with the node and the subset of functions associated with the immediately preceding node. The operations of each node should be performed in an order corresponding to the node's order and may individually correspond to one or more dependencies. Through analysis of the configuration, computing process 606 can identify any suitable number of implicit and / or explicit dependencies on the functions of other resources. As an example, computing process 606 may identify that service 502 depends on another service (referred to as "Service B"). Once identified, computing process 606 potentially builds a DAG that specifies tasks for booting and / or deploying the resource with 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 analysis). In some embodiments, the DAG may already be generated and stored in memory. In this situation, the DAG can simply be retrieved rather than regenerated through analysis.

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

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

[0081] At 620, in response to determining that at least one function associated with the node is unavailable, the computing process 606 may transmit data to the scheduler 602 indicating one or more functions on which the resource corresponding to the computing process 606 depends that are determined to be unavailable.

[0082] At 622, the computing process 606 may terminate, potentially after 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 finish execution, be stopped, suspended, or otherwise cease execution.

[0083] At 624, the scheduler 602 schedules a particular resource to wait for one or more specific functions required for the resource to resume boot and / or for deployment purposes. It is possible to store information indicating that the

[0084] At 626, scheduler 602 may receive one or more notifications that one or more functions for which the resource was waiting have become available. In some embodiments, 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. Scheduler 602 may maintain one or more records of the various functions that are available and / or the various functions for which the resource is currently waiting. Scheduler 602 may identify from the one or more records that the particular one or more functions for which the resource corresponding to computing process 606 is waiting have become available. Accordingly, scheduler 602 may proceed to 628.

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

[0086] A similar process as described above may be performed for all resources of a task. By way of example, when deploying a system having 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 FIG. 5 , at 520, orchestrator 516 may identify one or more dependencies associated with service 502. As described above, a DAG associated with service 502 may be obtained (e.g., generated or retrieved from memory). One or more nodes of the DAG may correspond to one or more dependencies. As a non-limiting example, the DAG for 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, the node corresponding to service B may be provided before the node corresponding to service 502.

[0088] Following the identification of a dependency on service B, at 522, orchestrator 516 may perform any appropriate operations to deploy / bootstrap service B. At 524, once service B is bootstrapped (e.g., a predetermined image of service B is deployed to a particular computer within the environment / region) and is ready to accept subsequent requests, orchestrator 516 may send data (e.g., an IP address associated with service B, an alphanumeric identifier associated with service B, etc.) to gateway computer 508 to be updated by gateway computer 508. The gateway computer 508 may update the routing table containing the service B. The gateway computer 508 may be configured to update the routing table with any suitable portion of data provided by the orchestrator 516 and associated with service B. Although not shown, in some embodiments, the gateway computer 508 may send any suitable data to the user device 506 to indicate that service B is ready.

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

[0090] The user can then initiate a new API call at 504, and the operations of 504, 510, and 512 can be repeated. At this point, the routing table includes data associated with service 502 (e.g., an identifier for the service, an IP address for service 502, etc.), and the determination made at 512 can indicate that the API call is now routable to service 502, and at 530, the API call can be forwarded to service 502. Beginning at 530, operations corresponding to service 502 and operations 424-428 of FIG. 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. The response can indicate whether the processing was successful (e.g., completed) or unsuccessful (e.g., not completed / not authorized). User device 506 can receive the response and perform any appropriate operation, such as, but not limited to, displaying an indication to the user that the API call was successfully processed.

[0091] It should be appreciated that if service 502 first becomes available after the initial API call described above, flow 400 can proceed from 512 to 530, forgoing the entire bootstrapping process and routing table update, since the service is already available at the time of the API request.

[0092] 7 is a flow diagram illustrating a flow 700 of operations for spinning down unused services, according to at least one embodiment. Prior to performing the operations of flow 700, it can be assumed that service 702 (e.g., an example of service 402 of FIG. 4) has been bootstrapped and a timer has been set for service 702 upon receipt of its last API call.

[0093] Flow 700 may begin at 704 with the occurrence of a timeout of a timer set at 424 of FIG. 4 (and similarly at 530 of FIG. 5 for service 502). In some embodiments, the timeout may trigger an event to be received by service 702. Identification of the timeout (e.g., receipt of the event) may be performed. In response to the event, service 702 may be configured to send any suitable data to orchestrator 706 (e.g., an example of orchestrator 416 in FIG. 4 ) to indicate that service 702 is no longer in use (e.g., as indicated by no requests having been received for a predetermined period of time, such as the last hour, the amount of requests received within the previous predetermined period of time being less than a threshold, etc.). While service 702 is shown receiving the event, the event may be received (or the timeout identified in other manners) by gateway computer 708 (e.g., an example of gateway computer 408 in FIG. 4 ). By way of example, the gateway computer may be configured to periodically determine that the service should be spun down based on identifying the last time a last request for service 702 was received and determining that the difference between the last time and the current time exceeds a threshold time. For illustrative purposes, a timeout is used as a mechanism for triggering the spin-down of service 702, although any suitable trigger may be utilized. As an example, the spin-down of service 702 may be triggered based 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 may be considered safe to spin down if it has no active resource instances under its management (or if it is otherwise determined that other components of the cloud computing environment do not depend on the service). If a service manages one or more resource instances, the status of these resource instances may be monitored to determine when and if the service is no longer managing any resource instances. As part of this monitoring, checks may be made periodically on these resource instances according to a schedule or predetermined frequency (e.g., every minute, every 30 seconds, etc.).

[0095] At 710, orchestrator 706 may receive data (a message and / or indicator requesting a spin-down) provided by service 702 (or alternatively by gateway computer 708). In response to receiving this data, orchestrator 706 may be configured to perform any appropriate action to spin down service 702. In some embodiments, the actions may be predefined, provided within a DAG that identifies the order in which the actions should be performed to spin down the service. In some embodiments, orchestrator 706 may determine whether other resources (e.g., other services on which service 702 depends) are required. By way of example, orchestrator 706 may identify a request rate, i.e., the number of previous requests within a previous time period (e.g., the last 10 minutes, hours, days, etc.), when the functionality of the dependent resource (e.g., a service on which service 702 depends) was last utilized. Orchestrator 706 may utilize a predetermined rule set to identify whether the dependent resource is still required (e.g., by other resources as suggested by a rate / number violating a predetermined threshold). Pursuant to a determination that the dependent resources are no longer needed, orchestrator 706 may perform operations to spin down the dependent resources and services 702. In some embodiments, orchestrator 706 may be configured to request and receive user input indicating approval for the spin-down request before sending a spin-down request for any resources (e.g., dependent resources and / or services 702).

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

[0097] FIG. 8 is a flow diagram illustrating an example method 800 for orchestrating the bootstrapping of a service in response to receiving an API request, according to at least one embodiment. The method is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to perform a process.

[0098] Additionally, method 800 may be performed under the control of one or more computing devices or computer systems configured with executable instructions and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) collectively executing on one or more processors, by hardware, or a combination thereof. As mentioned above, code may be stored on a computer-readable storage medium, for example, in the form of a computer program including multiple instructions executable by one or more processors. In some embodiments, method 1000 may be performed in parallel by multiple processors. The computer-readable storage medium may be non-transitory. In some embodiments, method 800 is performed by an orchestrator (e.g., CIOS regional 202 via scheduler 206, worker 210, and / or CIOS container 212 of FIG. 2; orchestrator 416, 516, and / or 706 of FIGS. 4, 5, and 7, respectively).

[0099] Method 800 may begin at 802, when a request (e.g., an API call provided via an HTTP request) including an identifier of a computing component of a cloud computing environment (e.g., service 402 of FIG. 4) is received (e.g., by gateway computer 408 of FIG. 4).

[0100] At 804, the computing device may determine whether the identifier (or any suitable information corresponding to a service associated with the identifier) ​​is present in a routing table accessible to the computing device (e.g., a routing table maintained / managed by gateway computer 408 of FIG. 4).

[0101] At 806, the computing device (gateway computer 408) can forward the request to a computing component (eg, service 402) according to the identifier present in the routing table.

[0102] At 808, an error code may be sent by the computing device in response to the request pursuant to the identifier not being present in the routing table. 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] At 810, a bootstrap request corresponding to the computing component may be sent (e.g., by the computing device to a deployment orchestrator (e.g., orchestrator 406) of the cloud computing environment) in accordance with the identifier not being present in the routing table. In some embodiments, the deployment orchestrator is configured to deploy the computing component to the cloud computing environment based at least in part on the bootstrap request. The specific operations of such deployment may be identified from the DAG, as described above in connection with FIGS. 5 and 6.

[0104] A subsequent request including the identifier may be received at 812. In some embodiments, the identifier may be stored at this point in a routing table maintained by the computing component according to which it was added after bootstrapping was completed.

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

[0106] 9 is a flow diagram illustrating a flow 900 of operations 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 in a region and / or may be accessible to user devices via API calls. Service 902 may not have been included in that initial predetermined set of deployed services. Alternatively, service 902 may have been previously operational but has been spun down and is no longer accessible. In either case, at the time the operations of flow 900 begin, service 902 is assumed to be inaccessible / inoperable (e.g., service 902 is not deployed).

[0107] Flow 900 can begin at 904, where a service (e.g., service 902) can be ordered. In some embodiments, a user can access a user interface via a user device 906. An exemplary interface is discussed in further detail below in connection with FIG. 11 . An API request can be made by user device 906 (e.g., an example of user device 406 of FIG. 4 ) according to user input provided in the interface and a request for service 1002 to be ordered. In some embodiments, the API request can be made via the HTTPS protocol or a similar protocol. The request can include any appropriate information, such as an identifier of the user, user authentication information, an identifier of the service associated with the request, etc. The API call can be received by gateway computer 908, which can be the same as or similar to gateway computer 408 of FIG. 4 and can be an example of a computer implementing WAN gateway 126 of FIG. 1 . Similar to the gateway computers described above, gateway computer 908 can be configured to maintain a routing table of previously deployed regional services (e.g., cloud services A-N of FIG. 2 ). The routing table is the Internet protocol for each service and / or infrastructure component in the environment provided by the architectures in Figures 1 and 2. The routing table may include a destination network identifier (e.g., an IP address), a subnet mask used to match the destination IP address with the network ID, and any other suitable information configured to allow the data packet to be forwarded to its destination.

[0108] At 910, gateway computer 408 (or any suitable component of FIG. 2 , such as 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 can include making an API call to one or more services (e.g., identity services) configured to maintain authorization and / or identity data for one or more users of the system. As an example, gateway computer 308 can call an identity service configured with authorization and / or identity data that can be utilized along with the user's identifier as received in the request to identify the user and / or one or more authorization policies associated with the user. As another example, gateway computer 908 can maintain user data associated with any suitable number of users and can authenticate the user to that user data using any suitable information obtained from the API call (e.g., identifiers associated with the user).

[0109] At 912, a determination can be made as to whether the request is allowable. This determination can include any suitable combination of: 1) whether the user is the intended person; and 2) whether the user has authorization to order the resource (e.g., service 902). In some embodiments, user data obtained from the request, such as user authentication information, can be utilized to derive authorization data indicating the particular services or types of services that can be ordered by the user.

[0110] If the authorization data indicates that the user is not authorized to order the requested service (or type of service), flow 900 can proceed to 914, where an error code can be returned by gateway computer 908 to user device 906. The error code can be any suitable value that indicates that the user is not authorized to order service 902. At 916, user device 906 can be configured to present any suitable data in a user interface to indicate that the order was not successful / authorized in response to receiving the error code.

[0111] Alternatively, if the order for service 902 is acceptable as determined at 912, flow 900 can proceed to 918, where a return status can be forwarded to user device 906 and data can be sent to orchestrator 916 (e.g., CIOS Central 102 of FIG. 1) indicating that bootstrapping of the requested service (e.g., service 902) should be initiated.

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

[0113] At 922, orchestrator 916 may receive the bootstrap request and perform any suitable operations to bootstrap (e.g., load into memory (e.g., the memory of a virtual machine) and / or initialize) a non-existent service (e.g., service 902). In some embodiments, orchestrator 916 may utilize a predetermined instruction set associated with bootstrapping service 902. Orchestrator 916 may traverse the DAG associated with service 902 to identify and perform operations to boot and / or deploy service 902 to the cloud computing environment for which the order was received. This process may be similar or the same as that described above in connection with the DAG discussed in the description of FIG. 4.

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

[0115] The user may then initiate an API call corresponding to service 902 at 926. Operations corresponding to blocks 404-412 may be performed on service 902 to identify whether the user is the intended person and authorized to make the API call. If not, an error code may be provided and displayed to the user at 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., an identifier for the service, an IP address of service 902, etc.).

[0116] At 930, the service 902 may process the API call. In some embodiments, the service 902 may start a timer for a predetermined period of time. The timer may alternatively be set by the gateway computer 908. This timer may be configured to maintain knowledge of when the service 902 was last called. If the service 902 is not utilized again for a predetermined period of time, the process described in connection with FIG. 7 may be performed to spin down the service 902. The service 902 may return a response to the gateway computer 908 as a result of processing the API call. In some embodiments, the response may indicate whether the processing was successful (e.g., completed) or unsuccessful (e.g., not completed / not authorized). The gateway computer 908 may forward the response to the user device 906. The user device 906 may receive the response and perform any appropriate action, such as, but not limited to, displaying an indication to the user that the API call was successfully processed.

[0117] 10 is a flow diagram illustrating a flow 1000 of operations 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 in the region and / or may be accessible to user devices via API calls. Service 1002 may not have been included in that initial predetermined set of deployed services. Alternatively, service 1002 may have been previously operational but has been spun down and is no longer accessible. In either case, at the time operation of flow 1000 begins, service 1002 is assumed to be inaccessible / inoperable (e.g., service 1002 is not deployed).

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

[0119] The operations performed at 1004-1020 may generally correspond to the same or similar operations discussed at 904-922 of FIG. 9 and will not be discussed again for the sake of brevity.

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

[0121] Pursuant to the identification of a dependency on service B, at 1024, orchestrator 1023 may perform any appropriate operation to deploy / bootstrap service B. At 1026, once service B is bootstrapped (e.g., a predetermined image of service B is deployed to a particular computer within the environment / region) and is ready to accept subsequent requests, orchestrator 1023 may send data (e.g., an IP address associated with service B, an alphanumeric identifier associated with service B, etc.) to gateway computer 1008 to update a routing table maintained by gateway computer 1008. Gateway computer 1008 may be configured to update the routing table with any appropriate portion of the data provided by orchestrator 1023 and associated with service B. In some embodiments, gateway computer 1008 may send any appropriate data to user device 1006 to indicate that service B is ready. User device 1006 may then receive a notification (as shown at 1020) indicating that service B is ready. (like this) and can provide status upon receipt.

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

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

[0124] 11 is an exemplary user interface 1100 for, among other things, initiating the operations described above, according to at least one embodiment. In some embodiments, user interface 1100 may be hosted by the gateway computer discussed in connection with the figures above or any suitable computer in a cloud computing environment. If hosted by a separate computer, that computer may be configured to render user interface 1100 on a user device and send API calls to the gateway computer of FIGS. 9 and 10. If user interface 1100 is hosted by a separate computer different from the gateway computer, that computer may be configured to receive any suitable error codes, status values, etc. from the gateway computer and present status information corresponding to that data in user interface 1100.

[0125] The user interface 1100 may include a search area 1102 that includes a search box 1104 and a button 1106. A user may utilize the search box 1104 to enter a search query (e.g., some portion of a service identifier). When the button 1106 is selected, the search query may be executed using the input provided in the search box 1104. The search query may return one or more results that match the query. To determine the services, a search may be performed against a database of orderable services. In some embodiments, previously ordered and / or currently active services may be filtered from the list of search results. In some embodiments, the user may 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 search results list may appear similar to the list of orderable services 1108 described below and may provide similar functionality through selections provided through the list, as described below.

[0126] User interface 1100 may include a status area 1110. Status area 1110 may identify any suitable number of services that are currently active, previously ordered, or being scaled down. In some embodiments, status area 1110 may include an identifier for each service in column 1112 and a corresponding status for each service in column 1114. The status values ​​may be numerous and may vary based on the desired status granularity. Some example status values ​​may include "Ready," "Ordered," "Bootstrap Initiated," and "Spinning Down." In some embodiments, a menu or option exists for requesting that one or more services be spun down. This menu or option, although not shown in FIG. 11 , may be provided upon selection of one or more services in services area 1110, or this menu / option may be provided in other manners via user interface 1100 or any suitable interface. The gateway computers of the above-described figures may be configured to provide the status of services at any suitable time, not necessarily at the times and triggers described above. Thus, the gateway computer can provide a status immediately after the order is received, displaying "Ordered" in column 1114 on the line corresponding to the ordered service. Once the orchestrator begins bootstrapping the service (or the gateway computer sends a bootstrap request), the gateway computer can provide a status to the user device that can be presented in the user interface 1100 as "Bootstrap Initiated" in column 1114.When the gateway computer (or any suitable computing component) determines that a service should be spun down as discussed in connection with FIG. 7, a status value for the service may be provided as "Spun Down" or "Deactivating" and presented in the user interface 1100. When a service is no longer active, it may be added back into the set of orderable services according to a predetermined set of rules to identify when the service will be orderable. If orderable, the service may be removed from the status area 1110 and added to the list of orderable services 1108.

[0127] List of orderable services 1108 may include any suitable number of services. A set of predetermined rules may dictate when a service becomes available for ordering and, therefore, when the service appears in list of orderable services 1108. In some embodiments, the particular service that is orderable may depend on multiple factors, such as the type of service, a service identifier associated with the service, a particular user and / or permissions associated with the user, etc. A user may select any service in the list of orderable services. In some embodiments, when a user selects area 1116 (e.g., by left-clicking within area 1116), for example, description area 1118 may be presented. In some embodiments, description area 1118 may present a predetermined description of the service. This description may describe the functionality of the service and / or various dependencies associated with the service. 9 and 10, 904 and 1004, respectively. If the user determines that they do not want to order the selected service, they can select the cancel button 1122, which causes the description area 1118 of the selected service to be removed.

[0128] FIG. 12 illustrates an exemplary flow diagram illustrating a method 1200 for performing operations for booting resources of a cloud computing system, according to certain embodiments of the present disclosure. The process is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions stored on one or more computer-readable storage media that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform particular functions or implement particular data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to perform the process.

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

[0130] Method 1200 may begin at block 1202, where a first set of computing components already deployed in the cloud computing environment may be identified by a computing device of the cloud computing environment. By way of example, a request message may be sent to an orchestrator (e.g., orchestrator 1023 of FIG. 10 ) requesting a list of all services already deployed in the cloud computing environment (and associated with the user). 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 cause this information to be presented in status area 1110 of FIG. 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 (either 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 status area 1110 of FIG. 11 .

[0131] At 1204, a second set of computing components available for deployment within the cloud computing environment may be identified by the computing device. By way of example, a request message may be sent to an orchestrator (e.g., orchestrator 1023 of FIG. 10 ) requesting a list of all services available for ordering. Data provided in the request may include a user identifier, user credentials, 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 the list of orderable services to the computing device, which may be configured to cause this information to be presented in area 1108 of FIG. 11 . For example, the computing device may send the list of orderable services (either 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 of FIG. 11 .

[0132] At 1206, a request for deployment may be received. By way of example, a user may make a selection (e.g., of service 4) from a user interface (e.g., user interface 1100 of FIG. 11 ). As a result of the selection, an API call to order the service may be sent from the user device to the gateway computer (either directly or through a computing device configured to host the user interface). The request for deployment (also referred to as an order request) may identify a particular computing component of a second set of computing components available for deployment (e.g., service 4 of FIG. 11 , an example of services 902 and 1002 of FIGS. 9 and 10 , respectively).

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

[0134] At 1210, a user interface (e.g., user interface 1100) may be presented that presents (e.g., at a user device) a first set of status indicators for a first set of computing components already deployed within the cloud computing environment and status indicators corresponding to the particular computing components.

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

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

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

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

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

[0140] In some cases, IaaS provisioning presents two distinct challenges. First, there is the initial challenge of preparing an initial set of infrastructure before anything is operational. Second, there is the challenge of evolving the existing infrastructure (e.g., adding new services, modifying services, removing services, etc.) once everything is in place. In some cases, these two challenges can be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g., which components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which and how they work together with each other) 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.

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

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

[0143] FIG. 13 is a block diagram 1300 illustrating an exemplary pattern of an IaaS architecture, according to at least one embodiment. A service operator 1302 can be communicatively coupled to a secure host tenancy 1304, which can include a virtual cloud network (VCN) 1306 and a secure host subnet 1308. In some examples, the service operator 1302 can communicate with portable handheld devices (e.g., iPhones, mobile phones, iPads, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass Headsets, Google Home ... The present invention may utilize one or more client computing devices, which may be a desktop computer (e.g., a head-mounted display). Alternatively, the client computing devices may be running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems, by way of example. The client computing devices may be general-purpose personal computers, including personal computers and / or laptops running various GNU / Linux operating systems, such as, but not limited to, Google Chrome OS. Alternatively, or in addition, the client computing devices may be thin-client computers, internet-enabled gaming systems (e.g., Microsoft Xbox gaming consoles with or without Kinect gesture input devices), and / or personal computers capable of communicating over a network that have access to VCN 1306 and / or the internet. It may also be any other electronic device, such as a mobile messaging device.

[0144] The VCN 1306 can include a local peering gateway (LPG) 1310, which can be communicatively coupled to a secure shell (SSH) VCN 1312 via the LPG 1310 included in the SSH VCN 1312. The SSH VCN 1312 can include an SSH subnet 1314, which is a control plane. The SSH VCN 1312 may be communicatively coupled to a control plane VCN 1316 via an LPG 1310 included in the data plane VCN 1316. The SSH VCN 1312 may also be communicatively coupled to a data plane VCN 1318 via an LPG 1310. The control plane VCN 1316 and the data plane VCN 1318 may be included in a service tenancy 1319, which may be owned and / or operated by an IaaS provider.

[0145] The control plane VCN 1316 may include a control plane demilitarized zone (DMZ) tier 1320 that acts as a perimeter network (e.g., a portion of an enterprise network between the enterprise intranet and an external network). DMZ-based servers may have limited roles and may help keep breaches contained. Additionally, the DMZ tier 1320 may include one or more load balancer (LB) subnets 1322, a control plane app tier 1324 that may include an app subnet 1326, and a control plane data tier 1328 that may include a database (DB) subnet 1330 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 1322 included in the control plane DMZ tier 1320 can be communicatively coupled to an app subnet 1326 included in the control plane app tier 1324 and an internet gateway 1334 that may be included in the control plane VCN 1316, and the app subnet 1326 can be communicatively coupled to a DB subnet 1330 included in the control plane data tier 1328, as well as a service gateway 1336 and a network address translation (NAT) gateway 1338. The control plane VCN 1316 can include the service gateway 1336 and the NAT gateway 1338.

[0146] The control plane VCN 1316 can include a data plane mirror app tier 1340, which can include an app subnet 1326. The app subnet 1326 included in the data plane mirror app tier 1340 can include a virtual network interface controller (VNIC) 1342 on which a compute instance 1344 can run. The compute instance 1344 can communicatively couple the app subnet 1326 of the data plane mirror app tier 1340 to the app subnet 1326, which can be included in the data plane app tier 1346.

[0147] The data plane VCN 1318 can include a data plane app tier 1346, a data plane DMZ tier 1348, and a data plane data tier 1350. The data plane DMZ tier 1348 can include a LB subnet 1322 that can be communicatively coupled to an app subnet 1326 of the data plane app tier 1346 and an internet gateway 1334 of the data plane VCN 1318. The app subnet 1326 can be communicatively coupled to a service gateway 1336 of the data plane VCN 1318 and a 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 coupled to the app subnet 1326 of the data plane app tier 1346.

[0148] The internet gateways 1334 of the control plane VCN 1316 and the data plane VCN 1318 can be communicatively coupled to a metadata management service 1352, which can be communicatively coupled to the public internet 1354. The public internet 1354 can be communicatively coupled to NAT gateways 1338 of the control plane VCN 1316 and the data plane VCN 1318. The service gateways 1336 of the control plane VCN 1316 and the data plane VCN 1318 can be communicatively coupled to cloud services 1356.

[0149] In some examples, a service gateway 1336 of the control plane VCN 1316 or the data plane VCN 1318 can make application programming interface (API) calls to cloud services 1356 without traversing the public Internet 1354. API calls from the service gateway 1336 to the cloud services 1356 are unidirectional, i.e., the service gateway 1336 can make API calls to the cloud services 1356, and the cloud services 1356 can send the requested data to the service gateway 1336. However, the cloud services 1356 cannot initiate API calls to the service gateway 1336.

[0150] In some examples, secure host tenancy 1304 can connect directly to service tenancy 1319, which may be otherwise separate. Secure host subnet 1308 can communicate with SSH subnet 1314 through LPG 1310, which may enable bidirectional communication through otherwise separate systems. Connecting secure host subnet 1308 to SSH subnet 1314 allows secure host subnet 1308 to access other entities in service tenancy 1319.

[0151] The control plane VCN 1316 can enable users of the service tenancy 1319 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 1316 can be deployed or otherwise used in the data plane VCN 1318. In some examples, the control plane VCN 1316 can be separate from the data plane VCN 1318, and the data plane mirror app tier 1340 of the control plane VCN 1316 can communicate with the data plane app tier 1346 of the data plane VCN 1318 via a VNIC 1342, which can be contained within the data plane mirror app tier 1340 and the data plane app tier 1346.

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

[0153] In some examples, data plane mirror app tier 1340 can facilitate direct communication between control plane VCN 1316 and data plane VCN 1318. For example, it may be desired that a configuration change, update, or other appropriate modification be made to the resources contained within data plane VCN 1318. Via VNIC 1342, control plane VCN 1316 can communicate directly with data plane VCN 1318, thereby performing the configuration change, update, or other appropriate modification on the resources contained within data plane VCN 1318.

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

[0155] In another embodiment, the LB subnet 1322 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 customers without having to call the public internet 1354. The IaaS provider's customers may desire this embodiment because databases used by the customers can be stored in the service tenancy 1319, which can be controlled by the IaaS provider and isolated from the public internet 1354.

[0156] Figure 14 is a block diagram 1400 illustrating another example 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 can include a virtual cloud network (VCN) 1406 (e.g., VCN 1306 in Figure 13) and a secure host subnet 1408 (e.g., secure host subnet 1308 in Figure 13). VCN 1406 can include a local peering gateway (LPG) 1410 (e.g., LPG 1310 in Figure 13), which can be communicatively coupled to a secure shell (SSH) VCN 1412 (e.g., SSH VCN 1312 in Figure 13) via the LPG 1310 included in the secure shell (SSH) VCN 1412. SSH VCN 1412 can include SSH subnet 1414 (e.g., SSH subnet 1314 in FIG. 13 ), which can be communicatively coupled to control plane VCN 1416 (e.g., control plane VCN 1316 in FIG. 13 ) via LPG 1410 included in control plane VCN 1416. Control plane VCN 1416 can be included in service tenancy 1419 (e.g., service tenancy 1319 in FIG. 13 ), and data plane VCN 1418 (e.g., data plane VCN 1318 in FIG. 13 ) can be included in customer tenancy 1421, which can 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., the control plane DMZ tier 1320 in FIG. 13 ) that may include a LB subnet 1422 (e.g., the LB subnet 1322 in FIG. 13 ), a control plane app tier 1424 (e.g., the control plane app tier 1324 in FIG. 13 ) that may include an app subnet 1426 (e.g., the app subnet 1326 in FIG. 13 ), and a control plane data tier 1428 (e.g., the control plane data tier 1328 in FIG. 13 ) that may include a database (DB) subnet 1430 (e.g., similar to the DB subnet 1330 in FIG. 13 ). The LB subnet 1422 included in the control plane DMZ tier 1420 may be connected to the app subnet 1426 included in the control plane app tier 1424 and to an Internet gateway 1434 (e.g., the control plane data tier 1328 in FIG. 13 ) that may be included in the control plane VCN 1416. 13 ) and a network address translation (NAT) gateway 1438 (e.g., NAT gateway 1338 in FIG. 13 ) included in the control plane data layer 1428. The control plane VCN 1416 may include the service gateway 1436 and the NAT gateway 1438.

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

[0159] The internet gateway 1434 contained within the control plane VCN 1416 can be communicatively coupled to a metadata management service 1452 (e.g., metadata management service 1352 of FIG. 13), which can be communicatively coupled to the public internet 1454 (e.g., public internet 1354 of FIG. 13). The public internet 1454 can be communicatively coupled to a NAT gateway 1438 contained within the control plane VCN 1416. The service gateway 1436 contained within the control plane VCN 1416 can be communicatively coupled to cloud services 1456 (e.g., cloud services 1356 of FIG. 13).

[0160] In some examples, data plane VCN 1418 can be included in customer tenancy 1421. In this case, an IaaS provider can provide a control plane VCN 1416 for each customer, and the IaaS provider can set up a unique compute instance 1444 for each customer that is contained within service tenancy 1419. Each compute instance 1444 can enable communication between the control plane VCN 1416 contained within service tenancy 1419 and the data plane VCN 1418 contained within customer tenancy 1421. The compute instance 1444 can enable resources provisioned in the control plane VCN 1416 contained within service tenancy 1419 to be deployed or otherwise used within the data plane VCN 1418 contained within customer tenancy 1421.

[0161] In another example, an IaaS provider customer may have a database that resides in customer tenancy 1421. In this example, control plane VCN 1416 may include data plane mirror app tier 1440, which may include app subnet 1426. Data plane mirror app tier 1440 may reside in data plane VCN 1418, but data plane mirror app tier 1440 may not reside in data plane VCN 1418. That is, data plane mirror app tier 1440 may have access to customer tenancy 1421, but data plane mirror app tier 1440 may not reside in data plane VCN 1418 or be owned or operated by the IaaS provider customer. The data plane mirror app tier 1440 can be configured to make calls to the data plane VCN 1418, but may not be configured to make calls to any entities contained within the control plane VCN 1416. A customer may wish to deploy or otherwise use resources in the data plane VCN 1418 that are provisioned in the control plane VCN 1416, and the data plane mirror app tier 1440 can facilitate the deployment or other use of the resources that the customer desires.

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

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

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

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

[0166] The data plane VCN 1518 may include a data plane app tier 1546 (e.g., data plane app tier 1346 in FIG. 13 ), a data plane DMZ tier 1548 (e.g., data plane DMZ tier 1348 in FIG. 13 ), and a data plane data tier 1550 (e.g., data plane data tier 1350 in FIG. 13 ). The data plane DMZ tier 1548 may include a trusted app subnet 1560 and an untrusted app subnet 1562 of the data plane app tier 1546, as well as an LB subnet 1522 that may be communicatively coupled to an Internet gateway 1534 contained within the data plane VCN 1518. The trusted app subnet 1560 may 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 app subnet 1562 may be communicatively coupled to a service gateway 1536 contained within the data plane VCN 1518 and a DB subnet 1530 contained within the data plane data tier 1550. The data plane data tier 1550 may include a DB subnet 1530 that may be communicatively coupled to a service gateway 1536 contained within the data plane VCN 1518.

[0167] The untrusted app subnet 1562 can include 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) can be communicatively coupled to a respective app subnet 1567(1)-(N), which can be contained within a respective container egress VCN 1568(1)-(N), which can be contained within a respective customer tenancy 1570(1)-(N). Each secondary VNIC 1572(1)-(N) can facilitate communication between the untrusted app subnet 1562 contained within the data plane VCN 1518 and the app subnet contained within the container egress VCN 1568(1)-(N). Each container egress VCN 1568 (1)-(N) may include a NAT gateway 1538 that may be communicatively coupled to the public Internet 1554 (e.g., the public Internet 1354 of FIG. 13).

[0168] The internet gateway 1534 contained within the control plane VCN 1516 and the internet gateway 1534 contained within the data plane VCN 1518 can be communicatively coupled to a metadata management service 1552 (e.g., metadata management system 1352 of FIG. 13 ), which can be communicatively coupled to the public internet 1554. The public internet 1554 can be communicatively coupled to a NAT gateway 1538 contained within the control plane VCN 1516 and the NAT gateway 1538 contained within the data plane VCN 1518. The service gateway 1536 contained within the control plane VCN 1516 and the service gateway 1536 contained within the data plane VCN 1518 can be communicatively coupled to cloud services 1556.

[0169] In some embodiments, data plane VCN 1518 can be integrated with customer tenancy 1570. This integration can be useful or desirable for an IaaS provider's customer in some cases, such as when they may want support when executing code. A 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 to execute the code provided to the IaaS provider by the customer.

[0170] In some examples, a customer of an IaaS provider can grant temporary network access to the IaaS provider to request a function associated with data plane tier app 1546. The code to perform the function can run within VMs 1566(1)-(N), and the code need not be configured to run anywhere else on data plane VCN 1518. Each VM 1566(1)-(N) can be connected to one customer tenancy 1570. Each container 1571(1)-(N) contained within VM 1566(1)-(N) can be configured to run code. In this case, there may be double isolation (e.g., containers 1571(1)-(N) executing code, where containers 1571(1)-(N) may be contained within VMs 1566(1)-(N) that are contained within at least untrusted app subnet 1562), which may help prevent incorrect or otherwise unwanted code from damaging the IaaS provider's network or a different customer's network. Containers 1571(1)-(N) may be communicatively coupled to customer tenancy 1570 and configured to send or receive data from customer tenancy 1570. Containers 1571(1)-(N) may not be configured to send or receive data from any other entity in data plane VCN 1518. Once the code execution is complete, the IaaS provider may stop or otherwise destroy containers 1571(1)-(N).

[0171] In some embodiments, trusted app subnet 1560 can execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 1560 can be communicatively coupled to DB subnet 1530 and configured to perform CRUD operations on DB subnet 1530. Untrusted app subnet 1562 can be communicatively coupled to DB subnet 1530, but in this embodiment, the untrusted app subnet can be configured to perform read operations on DB subnet 1530. VMs 1566(1)-(N) can be contained within each customer's VMs 1566(1)-(N) and can execute code from the customer. The containers 1571(1) to (N) do not have to be communicatively coupled to the DB subnet 1530.

[0172] In other embodiments, the control plane VCN 1516 and the data plane VCN 1518 may not be directly communicatively coupled. In this embodiment, there may not be direct communication between the control plane VCN 1516 and the data plane VCN 1518. However, communication can occur indirectly through at least one method. An LPG 1510 may be established by an IaaS provider that can facilitate communication between the control plane VCN 1516 and the data plane VCN 1518. In another example, the control plane VCN 1516 or the data plane VCN 1518 can make a call to a cloud service 1556 through a service gateway 1536. For example, a call from the control plane VCN 1516 to the cloud service 1556 can include a request for a service that can communicate with the data plane VCN 1518.

[0173] Figure 16 is a block diagram 1600 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1602 (e.g., service operator 1302 of Figure 13) can be communicatively coupled to a secure host tenancy 1604 (e.g., secure host tenancy 1304 of Figure 13), which can include a virtual cloud network (VCN) 1606 (e.g., VCN 1306 of Figure 13) and a secure host subnet 1608 (e.g., secure host subnet 1308 of Figure 13). VCN 1606 can include an LPG 1610 (e.g., LPG 1310 of Figure 13), which can be communicatively coupled to an SSH VCN 1612 (e.g., SSH VCN 1312 of Figure 13) via the LPG 1610 included in SSH VCN 1612. SSH VCN 1612 can include SSH subnet 1614 (e.g., SSH subnet 1314 in FIG. 13 ), which can be communicatively coupled to control plane VCN 1616 (e.g., control plane VCN 1316 in FIG. 13 ) via LPG 1610 included in control plane VCN 1616, and can be communicatively coupled to data plane VCN 1618 (e.g., data plane VCN 1318 in FIG. 13 ) via LPG 1610 included in data plane VCN 1618. Control plane VCN 1616 and data plane VCN 1618 can be included in service tenancy 1619 (e.g., service tenancy 1319 in FIG. 13 ).

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

[0175] The data plane VCN 1618 can include a data plane app tier 1646 (e.g., data plane app tier 1346 in FIG. 13 ), a data plane DMZ tier 1648 (e.g., data plane DMZ tier 1348 in FIG. 13 ), and a data plane data tier 1650 (e.g., data plane data tier 1350 in FIG. 13 ). The data plane DMZ tier 1648 can include a trusted app subnet 1660 (e.g., trusted app subnet 1560 in FIG. 15 ) and an untrusted app subnet 1662 (e.g., untrusted app subnet 1562 in FIG. 15 ) of the data plane app 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. The trusted app subnet 1660 may be communicatively coupled to a service gateway 1636 contained within the data plane VCN 1618, a NAT gateway 1638 contained within the data plane VCN 1618, and a DB subnet 1630 contained within the data plane data tier 1650. The untrusted app subnet 1662 may be communicatively coupled to the service gateway 1636 contained within the data plane VCN 1618 and the DB subnet 1630 contained within the data plane data tier 1650. The data plane data tier 1650 may include a DB subnet 1630 that may be communicatively coupled to the service gateway 1636 contained within the data plane VCN 1618.

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

[0177] The internet gateway 1634 contained within the control plane VCN 1616 and the internet gateway 1634 contained within the data plane VCN 1618 can be communicatively coupled to a metadata management service 1652 (e.g., metadata management system 1352 of FIG. 13 ), which can be communicatively coupled to the public internet 1654. The public internet 1654 can be communicatively coupled to a NAT gateway 1638 contained within the control plane VCN 1616 and the NAT gateway 1638 contained within the data plane VCN 1618. The service gateway 1636 contained within the control plane VCN 1616 and the service gateway 1636 contained within the data plane VCN 1618 can be communicatively coupled to cloud services 1656.

[0178] In some instances, the pattern illustrated by the architecture of block diagram 1600 in FIG. 16 can be considered an exception to the pattern illustrated by the architecture of block diagram 1500 in FIG. 15 and may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in an isolated region). Containers 1667(1)-(N) can be accessed in real time by customers. Containers 1667(1)-(N) can be configured to make calls to respective secondary VNICs 1672(1)-(N) contained within app subnet 1626 of data plane app tier 1646, which can be contained within container egress VCN 1668. Secondary VNICs 1672(1)-(N) can send calls to NAT gateway 1638, which can send calls to public Internet 1654. In this example, containers 1667(1)-(N) that can be accessed in real time by customers can be isolated from control plane VCN 1616 and can be isolated from other entities contained within 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 the request to secondary VNICs 1672(1)-(N), which can send the request to a NAT gateway, which can send the request to public Internet 1654. 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 determining that the request is valid, LB subnet 1626 can send the request to app 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, 1600 depicted in the figures may have components other than those depicted. Additionally, the embodiments depicted in the figures are only some examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than those depicted, may combine two or more components, or may have a different configuration or arrangement of components.

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

[0182] 17 illustrates an exemplary computer system 1700 on which various embodiments may be implemented. System 1700 may be used to implement any of the computer systems described above. As shown in the figure, computer system 1700 includes a processing unit 1704 that communicates with multiple 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. Storage subsystem 1718 includes a tangible computer-readable storage medium 1722 and a system memory 1710.

[0183] The bus subsystem 1702 connects the various components of the computer system 1700 and The bus subsystem 1702 provides a mechanism for allowing the subsystems to communicate with each other as intended. While the bus subsystem 1702 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. The bus subsystem 1702 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures include the Industry Standard Architecture (ISA) bus, the MicroChannel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the IEEE P1386.1 Peripheral component interconnects that can be implemented as standard manufactured Mezzanine buses The PCI bus may include a PCI bus.

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

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

[0186] I / O subsystem 1708 can include user interface input devices and user interface output devices. User interface input devices can include pointing devices such as a keyboard, a mouse or trackball, a touchpad or a touchscreen integrated into a display, a scroll wheel, a click wheel, dials, buttons, switches, keypads, acoustic input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices can include, for example, motion-sensing and / or audio input devices such as a Microsoft Kinect® motion sensor that allows a user to control and interact with input devices such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and voice instructions. or gesture recognition devices. The user interface input devices may also include eye gesture recognition devices, such as a Google Glass® blink detector, that detects eye activity from the user (e.g., "blinking" while taking a picture and / or making a menu selection) and translates the eye gestures as input to the input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows 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, a three-dimensional (3D) mouse. , joysticks or pointing sticks, gamepads and graphics tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. Additionally, user interface input devices may include medical imaging input devices such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound devices, etc. User interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, etc.

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

[0189] Computer system 1700 may include a storage subsystem 1718 that includes software elements that are currently shown as residing in system memory 1710. System memory 1710 may store program instructions that are loadable and executable on processing unit 1704, as well as data generated during the execution of these programs.

[0190] Depending on the configuration and type of computer system 1700, system memory 1710 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated on and executed by processing unit 1704. In some embodiments, 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 the basic routines that help to transfer information between elements within computer system 1700, such as during start-up, may typically be stored in ROM. By way of example and not limitation, system memory 1710 also illustrates application programs 1712, program data 1714, and operating system 1716, which may include client applications, a web browser, a middle-tier application, a relational database management system (RDBMS), etc. By way of example, operating system 1716 may be any of various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. systems, various commercially available UNIX or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome OS, etc.), and / or mobile operating systems such as iOS, Windows Phone, Android OS, BlackBerry 17 OS, and Palm OS operating systems.

[0191] Storage subsystem 1718 also provides a tangible computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by a processor, provide the functionality described above may be stored in storage subsystem 1718. These software modules or instructions may be executed by processing unit 1704. Storage subsystem 1718 may also provide a repository for storing data used in accordance with the present disclosure.

[0192] Storage subsystem 1700 may also include computer-readable storage medium reader 1720, which may further connect to computer-readable storage medium 1722. Together with, and optionally in combination with, system memory 1710, computer-readable storage medium 1722 may collectively represent remote, local, fixed, and / or removable storage devices+media for containing, storing, transmitting, and retrieving computer-readable information on a temporary and / or more persistent basis.

[0193] The computer-readable storage medium 1722 containing code or portions of code can also include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information. This can include tangible computer-readable storage media, such as RAM, ROM, Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer-readable media. This can also include non-tangible computer-readable media, such as a data signal, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by computing system 1700.

[0194] By way of example, computer-readable storage medium 1722 may include a hard disk drive that reads from or writes to non-removable nonvolatile magnetic media, a magnetic disk drive that reads from or writes to removable nonvolatile magnetic disks, and removable non-volatile magnetic media such as CD-ROMs, DVDs, and Blu-ray discs or other optical media. The computer-readable storage medium 1722 may include an optical disk drive that reads from or writes to a volatile optical disk. The computer-readable storage medium 1722 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, etc. The computer-readable storage medium 1722 may also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on non-volatile memory such as 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. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1700.

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

[0196] In some embodiments, the communications subsystem 1724 may also receive incoming 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 may use the computer system 1700.

[0197] For example, the communication subsystem 1724 may provide a Twitter feed, Facebook feed, The system may be configured to receive data feeds 1726 in real time from users of social networks and / or other communication services, such as RealTime Networks (RTN) updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party sources.

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

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

[0200] The computer system 1700 may be implemented in a variety of devices, including 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 a variety of types, including a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

[0201] Due to the ever-changing nature of computers and networks, the description of computer system 1700 shown in the drawings is intended as a specific example only. 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 particular elements may be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections 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 recognize other ways and / or methods for implementing the various embodiments.

[0202] Exemplary embodiments of the present disclosure can be described in light of the following sections. Item 1. The computer-implemented method can include one or more of: 1) a computing device of a cloud computing environment identifying a first set of computing components already deployed in the cloud computing environment; 2) the computing device identifying a second set of computing components available for deployment in the cloud computing environment; 3) receiving, by the computing device, a request for deployment that identifies a particular computing component of the second set of computing components available for deployment; 4) the computing device sending a bootstrap request corresponding to the particular computing component to a deployment orchestrator of the cloud computing environment, the deployment orchestrator being configured to deploy the particular computing component in the cloud computing environment based at least in part on the bootstrap request; and / or 5) the computing device presenting a user interface that presents a first set of status indicators of the first set of computing components already deployed in the cloud computing environment and a status indicator corresponding to the particular computing component.

[0203] The computer-implemented method described in Section 2. Section 1 may further include one or more of: 1) the computing device identifying successful deployment of the particular computing component; 2) the computing device adding an identifier associated with the particular computing component to a routing table; 3) the computing device receiving a subsequent request (e.g., user device 906 of FIG. 9 ) that includes the identifier; and / or 4) the computing device sending the subsequent request to the particular computing component for processing.

[0204] Item 3. The computer-implemented method of either Item 1 or Item 2, wherein sending a bootstrap request may cause the deployment orchestrator to perform operations including one or more of: 1) the computing device identifying one or more computing components on which the particular computing component depends, and / or 2) the computing device deploying one or more computing components before deploying the particular computing component.

[0205] Clause 4. The computer-implemented method of clause 3, wherein identifying one or more computing components on which a particular computing component depends may be based at least in part on determining the one or more computing components from a directed acyclic graph defining computing component dependencies.

[0206] Clause 5. The computer-implemented method of clause 3, wherein the method may further include one or more of: 1) the computing device presenting, in a user interface, information identifying one or more computing components on which the particular computing component being requested depends; 2) receiving, in the user interface, user input indicating acceptance of deploying the one or more computing components before deploying the particular computing component; and / or 3) the computing device sending, to the deployment orchestrator, respective bootstrap requests corresponding to the one or more computing components, wherein each bootstrap request is sent before sending the bootstrap request corresponding to the particular computing component being requested.

[0207] Item 6. The method can further include the computing device sending a spin-down request corresponding to the particular computing component to the deployment orchestrator, the spin-down request being received when: 1) the computing device (e.g., the user of FIG. 9 ) 9. The computer-implemented method of claim 1, wherein the request is sent in response to: 1) receiving a subsequent request to spin down the particular computing component (from the device 906); or 2) the computing device 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 current time exceeds a predetermined threshold time.

[0208] Clause 7. The computer-implemented method of clause 6, wherein sending the spin-down request is further based at least in part on determining that no other components of the cloud computing environment are dependent on the particular computing component.

[0209] Section 8. A computing device of a cloud computing environment may include one or more processors and one or more memories storing computer-executable instructions that, when executed by the one or more processors, cause the computing device to perform one or more of the following operations: 1) identifying a first set of computing components already deployed within the cloud computing environment; 2) identifying a second set of computing components available for deployment within the cloud computing environment; 3) receiving a request for deployment that identifies a particular computing component of the second set of computing components available for deployment; 4) sending a bootstrap request corresponding to the particular computing component being requested to a deployment orchestrator of the cloud computing environment, the deployment orchestrator being configured to deploy the particular computing component in the cloud computing environment based at least in part on the bootstrap request; and / or 5) presenting a user interface that presents a first set of status indicators of the first set of computing components already deployed within the cloud computing environment and status indicators corresponding to the particular computing component.

[0210] Clause 9. The computing device of clause 8, wherein by executing the instructions, the computing device can further perform additional operations including one or more of: 1) identifying successful deployment of a particular computing component; 2) adding an identifier associated with the particular computing component to a routing table; 3) receiving a subsequent request including the identifier; and / or 4) sending the subsequent request to the particular computing component for processing.

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

[0212] Clause 11. The computing device of clause 10, wherein identifying one or more computing components on which a particular computing component depends is based at least in part on determining the one or more computing components from a directed acyclic graph defining computing component dependencies.

[0213] Section 12. Executing the instructions causes the computing device to: 1) present, in a user interface, information identifying one or more computing components on which the particular computing component being requested depends; 2) in the user interface, request one or more computing components before deploying the particular computing component; or 1) receiving user input indicating acceptance of deploying a plurality of computing components; and / or 2) sending respective bootstrap requests corresponding to one or more computing components to a deployment orchestrator, each bootstrap request being sent before sending a bootstrap request corresponding to the particular computing component being requested.

[0214] Clause 13. A computing device as described in any of clauses 8 to 12, wherein executing the instructions further causes the computing device to perform the additional operation of sending a spin-down request corresponding to a particular computing component to a deployment orchestrator, 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 last request for the particular computing component was received and determining that the difference between the last time and the current time exceeds a predetermined threshold time.

[0215] Clause 14. The computing device of clause 13, wherein sending the spin-down request is further based at least in part on determining that no other components of the cloud computing environment are dependent on the particular computing component.

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

[0217] Clause 16. The non-transitory computer-readable storage medium of clause 15, wherein executing the instructions further causes the computing device to perform one or more of: 1) identifying successful deployment of a particular computing component; 2) adding an identifier associated with the particular computing component to a routing table; 3) receiving a subsequent request including the identifier; and / or 4) sending the subsequent request to the particular computing component for processing.

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

[0219] Section 18. One or more computing components on which a particular computing component depends 20. The non-transitory computer-readable storage medium of claim 17, wherein identifying the computing component is based at least in part on determining one or more computing components from a directed acyclic graph defining computing component dependencies.

[0220] Clause 19. A non-transitory computer-readable storage medium described in any of clauses 15 to 18, wherein executing the instructions further causes the computing device to perform one or more of the following: 1) presenting, in a user interface, information identifying one or more computing components on which the particular computing component being requested depends; 2) receiving, in the user interface, user input indicating acceptance of deploying one or more computing components before deploying the particular computing component; and / or 3) the computing device sending, to a deployment orchestrator, respective bootstrap requests corresponding to one or more computing components, each bootstrap request being sent before sending the bootstrap request corresponding to the particular computing component being requested.

[0221] Clause 20. A non-transitory computer-readable storage medium as described in any of clauses 15 to 19, wherein executing the instructions further causes the computing device to send a spin-down request corresponding to a particular computing component to a deployment orchestrator, 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 last request for the particular computing component was received and determining that the difference between the last time and the current time exceeds a predetermined threshold time.

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

[0223] Furthermore, while embodiments are described using particular combinations of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments may be implemented exclusively in hardware, exclusively in software, or using a combination thereof. The 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 configuration may be achieved, for example, by designing electronic circuitry to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using various techniques, including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0224] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and changes may be made thereto without departing from the broader spirit and scope of the appended claims. Accordingly, certain disclosed embodiments have been described. However, these are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims.

[0225] Use of the terms "a" and "an" and "the" and similar referents in the context of describing embodiments of the present disclosure (particularly in the context of the claims that follow) should be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The term "connected" should be construed as open-ended (i.e., meaning "including, but not limited to") unless otherwise stated. The term "connected" should be construed as partially or wholly contained within, attached to, or joined together, even if there is something intervening. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of individually referring to each separate value falling within the range, unless otherwise stated herein, and each separate value is incorporated herein as if it were individually set forth herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or clearly contradicted by context. Any examples or illustrative language (e.g., "such as") provided herein may be used to better understand the embodiments. They are intended to be helpful only and do not impose limitations on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

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

[0227] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the disclosure. Variations of these preferred embodiments may become apparent to those skilled in the art upon reading the above description. Those skilled in the art will be able to adapt such variations, and the present disclosure may be practiced otherwise than as specifically described herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, unless otherwise indicated herein, any combination of the above-described elements in all possible variations is encompassed by the present disclosure.

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

[0229] In the foregoing specification, aspects of the present disclosure have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the present disclosure is not limited thereto. Various features and aspects of the above-described disclosure may be used individually or in combination. Moreover, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the present disclosure. Thus, the present disclosure The specification and drawings should be regarded in an illustrative rather than a restrictive sense. Accordingly, while certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the appended claims.

Claims

1. 1. A computer-implemented method comprising: receiving, by a computing device of a cloud computing environment, a request including an identifier of a computing component of said cloud computing environment; determining, by the computing device, whether the identifier is present in a routing table accessible to the computing device; the computing device forwarding the request to the computing component according to the identifier present in the routing table; pursuant to which the identifier is not present in the routing table; the computing device responding to the request by transmitting an error code indicating that the computing component is unavailable; the computing device sending a bootstrap request corresponding to the computing component to a deployment orchestrator of the cloud computing environment configured to deploy the computing component in the cloud computing environment based at least in part on the bootstrap request; receiving, by the computing device, a subsequent request including the identifier; and the computing device sending the subsequent request to the computing component for processing.

2. pursuant to which the identifier is not present in the routing table; the computing device presenting an indication that the computing component was successfully deployed; and The computer-implemented method of claim 1 , further comprising the computing device updating the routing table with the identifier.

3. 3. The computer-implemented method of claim 1 or claim 2, wherein the deployment orchestrator is configured to identify one or more computing components on which the computing component depends and to deploy the one or more computing components before deploying the computing component.

4. The computer-implemented method comprises: and determining, based at least in part on a timer corresponding to the computing component and set to a predetermined time period, that the computing component has not been called for at least the predetermined time period; The computer-implemented method further includes the computing device sending a spin-down request corresponding to the computing component to the deployment orchestrator of the cloud computing environment; 4. The computer-implemented method of claim 1, wherein sending the spin-down request causes the deployment orchestrator to remove the computing component from the cloud computing environment.

5. 5. The computer-implemented method of claim 4, wherein sending the spin-down request is further based at least in part on the computing device determining that no other components of the cloud computing environment depend on the computing component.

6. 6. The computer-implemented method of claim 4 or claim 5, further comprising, before sending the spin-down request, requesting and receiving user input indicating approval to proceed with the spin-down request.

7. 7. The computer-implemented method of claim 1, further comprising the computing device sending a spin-down request corresponding to the computing component to the deployment orchestrator, the spin-down request being sent in response to: 1) receiving a subsequent request to spin down the computing component; or 2) identifying the last time a last request for the computing component was received and determining that a difference between the last time and a current time exceeds a predetermined threshold time.

8. 1. A computing device in a cloud computing environment, comprising: one or more processors; one or more memories storing computer-executable instructions; The computer-executable instructions, when executed by the one or more processors, cause the computing device to: receiving a request including an identifier of a computing component of the cloud computing environment; determining whether the identifier is present in a routing table accessible to the computing device; forwarding the request to the computing component according to the identifier present in the routing table; pursuant to which the identifier is not present in the routing table; Responding to the request, transmitting an error code indicating that the computing component is unavailable; and sending a bootstrap request corresponding to the computing component to a deployment orchestrator of the cloud computing environment configured to deploy the computing component in the cloud computing environment based at least in part on the bootstrap request; receiving a subsequent request including the identifier; and transmitting the subsequent request to the computing component for processing.

9. Executing the instructions causes the computing device to: presenting an indication that the computing component was successfully deployed; and 10. The computing device of claim 8, further comprising: updating the routing table with the identifier.

10. 10. The computing device of claim 8 or claim 9, wherein the deployment orchestrator is configured to identify one or more computing components on which the computing component depends and to deploy the one or more computing components before deploying the computing component.

11. Executing the instructions causes the computing device to: determining, based at least in part on a timer corresponding to the computing component and set to a predetermined time period, that the computing component has not been called for at least the predetermined time period; The cloud computing device sends a spin-down request corresponding to the computing component to the cloud computing device. and transmitting the deployment orchestrator of the deployment environment; The computing device of claim 8 , whereby sending the spin-down request causes the deployment orchestrator to remove the computing component from the cloud computing environment.

12. 12. The computing device of claim 11, wherein sending the spin-down request is further based at least in part on determining that no other components of the cloud computing environment depend on the computing component.

13. 13. The computing device of claim 11 or claim 12, wherein executing the instructions further causes the computing device to request user input indicating approval to proceed with the spin-down request before sending the spin-down request.

14. By executing the instructions, the computing device:

10. The computing device of claim 8, further comprising: sending a spin-down request corresponding to the computing component to the deployment orchestrator, the spin-down request being sent in response to: 1) receiving a request to spin down the computing component; or 2) identifying a last time point at which a last request for the computing component was received and determining that a difference between the last time point and a current time point exceeds a predetermined threshold time.

15. 1. A non-transitory computer-readable storage medium comprising computer-executable instructions that, when executed by one or more processors of a computing device, cause the computing device in a cloud computing environment to: receiving a request including an identifier of a computing component of the cloud computing environment; determining whether the identifier is present in a routing table accessible to the computing device; forwarding the request to the computing component according to the identifier present in the routing table; pursuant to which the identifier is not present in the routing table; Responding to the request, transmitting an error code indicating that the computing component is unavailable; and sending a bootstrap request corresponding to the computing component to a deployment orchestrator of the cloud computing environment configured to deploy the computing component in the cloud computing environment based at least in part on the bootstrap request; receiving a subsequent request including the identifier; and transmitting the subsequent request to the computing component for processing.

16. Executing the instructions causes the computing device to: presenting an indication that the computing component was successfully deployed; and and updating the routing table with the identifier.

17. The deployment orchestrator may also be configured to:

17. The non-transitory computer-readable storage medium of claim 15 or claim 16, configured to identify a plurality of computing components and deploy one or more of the computing components prior to deploying the computing component.

18. Executing the instructions causes the computing device to: determining, based at least in part on a timer corresponding to the computing component and set to a predetermined time period, that the computing component has not been called for at least the predetermined time period; sending a spin-down request corresponding to the computing component to the deployment orchestrator of the cloud computing environment; 16. The non-transitory computer-readable storage medium of claim 15, whereby sending the spin-down request causes the deployment orchestrator to remove the computing component from the cloud computing environment.

19. 20. The non-transitory computer-readable storage medium of claim 18, wherein sending the spin-down request is further based at least in part on determining that no other components of the cloud computing environment are dependent on the computing component.

20. Executing the instructions causes the computing device to:

16. The non-transitory computer-readable storage medium of claim 15, further causing the deployment orchestrator to send a spin-down request corresponding to the computing component, the spin-down request being sent in response to: 1) receiving a request to spin down the computing component; or 2) identifying a last time point at which a last request for the computing component was received and determining that a difference between the last time point and a current time point exceeds a predetermined threshold time.

21. An apparatus for providing cloud services, comprising means for performing the steps of the method according to any one of claims 1 to 7.

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

Images