Connecting and isolating compute instances owned by different tenants

Abstract

Techniques for creating a connection between two computing instances are disclosed. An infrastructure and generalized method for connecting two or more cloud resources (e.g., two computing instances) is described, even though the computing resources are provisioned by two different services from different cloud tenants. An automated process is described that is performed to wire the computing instances. The automated process can generally be applied to connect any two computing instances that offer two different services and are provisioned from two different service tenants.

Description

[Technical Field]

[0001] Related Applications This application is related to U.S. Non-Provisional Application No. 17 / 459,167, entitled "Restricting Operation Through Connection of Computing Instances Owned by Different Tenants," the entire contents of which are incorporated herein by reference for all purposes. [Background technology]

[0002] background When a customer signs up as a subscriber to an IaaS service offered by an IaaS cloud service provider (CSP), an account, or tenant, is created for the customer. In one implementation, the tenant created for the customer (also referred to as a customer tenant) provides a root-level compartment that holds all of the customer's cloud resources. In a typical scenario, the customer and its users can only access resources located within that customer's tenant. These resources may include, for example, one or more computing instances that are provisioned for the customer to provide one or more services to the customer. Summary of the Invention [Problem to be solved by the invention]

[0003] For a particular service to which a customer subscribes and a customer instance is provisioned for the customer, the compute instance is typically created and provided by a separate service infrastructure configured to provision and manage cloud resources related to the particular service. For example, if a customer subscribes to Service A and Service B, the Service A infrastructure, associated with its own tenant (referred to as a service tenant), is configured to create and provision compute instance A, which provides Service A to the customer. Similarly, the Service B infrastructure, associated with its own tenant, is configured to create and provision compute instance B, which provides Service B to the customer. The lifecycle management of compute instance A is exclusively controlled by the Service A infrastructure, and the lifecycle management of compute instance B is exclusively controlled by the Service B infrastructure. Furthermore, the compute instances created by the separate service infrastructures cannot directly communicate or interact with each other because they are provisioned by the infrastructures of two different tenants. However, there may be cases where a customer can utilize resources received from two different service infrastructures (e.g., compute instance A and compute instance B in the example above) to interact and collaborate with each other; however, the isolation of the compute instances based on service tenant makes this difficult.

[0004] This disclosure describes a solution to the above-mentioned problems. Quick Overview The present disclosure generally relates to creating connections between computing instances. As described herein, an infrastructure and generalized method for connecting (also referred to as "wiring") two (or more) cloud resources (e.g., two computing instances) is described, even though the computing resources are provisioned by two different services from different cloud tenants. An automated process performed to wire the computing instances is described. The automated process is generally applicable to connecting any two computing instances that offer two different services and are provisioned from two different service tenants.

[0005] For example, a customer may send a request to a first service infrastructure to connect a first service computing instance with a second service computing instance. The request may be received and processed by a first service control plane of the first service infrastructure. A workflow for connecting the two computing instances is then executed. The workflow includes processing performed by the first service control plane, the second service control plane, and an identity management and authorization service (IDMAS). [Means for solving the problem]

[0006] In an embodiment, a method includes a first control plane for a first service receiving a request to create a connection between a first computing instance of the first service and a second computing instance of a second service, where the first computing instance is controlled by the first control plane and the second computing instance is controlled by the second control plane, where the first computing instance is within a customer tenant and the second computing instance is within the customer tenant, and the first computing instance is isolated from the second computing instance within the customer tenant. The method further includes the first control plane performing a set of processing operations to create the connection between the first computing instance and the second computing instance, and after performing the set of processing operations, gaining control of the second computing instance through the connection and enabling communication between the first computing instance and the second computing instance.

[0007] In yet another embodiment, a first control plane obtains a token indicating that the first control plane can communicate with a second control plane on behalf of a customer.

[0008] In yet another embodiment, executing the set of processing operations includes the first control plane determining a set of permitted operations that can be executed on the second computing instance.

[0009] In yet another embodiment, performing the set of processing operations includes a first control plane sending a connection request to a second control plane, the connection request including information identifying the first computing instance and the second computing instance, the second control plane storing information regarding the connection, and performing the set of processing operations includes the first control plane storing information regarding the connection.

[0010] In yet another embodiment, the first control plane is a dominant control plane, the second control plane is a passive control plane, the first computing instance is a dominant computing instance, and the second computing instance is a passive computing instance.

[0011] In yet another embodiment, the first control plane further includes creating a first computing instance of the first service in the customer tenant before performing the set of processing operations to create the connection.

[0012] In yet another embodiment, performing the set of processing operations includes the first control plane sending a request to the second control plane to create a second computing instance within the customer tenant, the second control plane creating the second computing instance within the customer tenant in response to the request.

[0013] In yet another embodiment, the first service is an enterprise resource planning (ERP) service and the second service is a conversational artificial intelligence (AI) service.

[0014] In yet another embodiment, after executing the set of processing operations, the connection restricts the second control plane from executing at least one operation on the second computing instance.

[0015] In an embodiment, a non-transitory computer-readable storage medium storing computer-executable instructions is disclosed that, when executed, cause one or more processors of a computer system to perform a method, the method including receiving a request to create a connection between a first computing instance of a first service and a second computing instance of a second service, wherein the first computing instance is controlled by a first control plane of the computer system and the second computing instance is controlled by a second control plane, the first computing instance is within a customer tenant and the second computing instance is within the customer tenant, and the first computing instance is isolated from the second computing instance within the customer tenant, the method including performing a set of processing operations to create the connection between the first computing instance and the second computing instance, and after performing the set of processing operations, gaining control of the second computing instance through the connection and enabling communication between the first computing instance and the second computing instance.

[0016] In one embodiment, a computer system is disclosed that includes a processor and a memory configured to store a plurality of instructions executable by the processor and that, when executed by the processor, cause the processor to perform a process, the process including receiving a request to create a connection between a first computing instance of a first service and a second computing instance of a second service, wherein the first computing instance is controlled by a first control plane of the computer system and the second computing instance is controlled by a second control plane, the first computing instance is within a customer tenant and the second computing instance is within the customer tenant, and the first computing instance is isolated from the second computing instance within the customer tenant, the process including performing a set of processing operations to create the connection between the first computing instance and the second computing instance, and after performing the set of processing operations, gaining control of the second computing instance through the connection and enabling communication between the first computing instance and the second computing instance.

[0017] In an embodiment, an apparatus for connecting computing instances is disclosed, comprising means for performing any of the steps of the method according to the embodiments of the present disclosure.

[0018] In an embodiment, a computer program product is disclosed that includes computer instructions that, when executed by a processor, implement any of the steps of the methods according to the embodiments of the present disclosure.

[0019] The foregoing, together with other features and embodiments, will become more apparent with reference to the following specification, claims, and accompanying drawings. [Brief explanation of the drawings]

[0020] [Figure 1]FIG. 1 illustrates a simplified block diagram of a distributed environment in accordance with some embodiments. [Figure 2] FIG. 1 illustrates a simplified swim chart illustrating the process of connecting two computing instances within a customer tenant, according to an embodiment. [Figure 3] FIG. 1 illustrates a simplified swim chart illustrating the process of separating two connected computing instances within a customer tenant, according to an embodiment. [Figure 4] FIG. 1 illustrates a simplified swim chart illustrating the process of connecting two computing instances within a customer tenant, according to an embodiment, where a passive instance does not yet exist and is created as part of the process. [Figure 5] FIG. 1 illustrates a simplified swim chart illustrating the process of connecting two computing instances within a customer tenant, according to one embodiment, where the dominant instance does not yet exist and is created as part of the process. [Figure 6] FIG. 1 illustrates a simplified swim chart illustrating the process of connecting two computing instances within a customer tenant, according to one embodiment, where both computing instances do not yet exist but are created as part of the process. [Figure 7] FIG. 1 illustrates a process for determining whether an action is permitted, according to an embodiment. [Figure 8] 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 9] 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 10] 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 11] 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 12] FIG. 1 is a block diagram illustrating an exemplary computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE INVENTION

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

[0022]

[0001] The present disclosure generally relates to creating connections between computing instances. When a customer signs up as a subscriber to an IaaS service offered by an IaaS cloud service provider (CSP), an account, or tenant, is created for the customer. In one implementation, the tenant created for the customer (also referred to as a customer tenant) provides a root-level compartment that holds all of the customer's cloud resources. In a typical scenario, the customer and its users can only access resources located within that customer's tenant. These resources may include, for example, one or more computing instances provisioned for the customer to provide one or more services to the customer.

[0023] For a particular service to which a customer subscribes and a customer instance is provisioned for the customer, the compute instance is typically created and provided by a separate service infrastructure configured to provision and manage cloud resources related to the particular service. For example, if a customer subscribes to Service A and Service B, the Service A infrastructure, associated with its own tenant (referred to as a service tenant), is configured to create and provision compute instance A, which provides Service A to the customer. Similarly, the Service B infrastructure, associated with its own tenant, is configured to create and provision compute instance B, which provides Service B to the customer. The lifecycle management of compute instance A is exclusively controlled by the Service A infrastructure, and the lifecycle management of compute instance B is exclusively controlled by the Service B infrastructure. Furthermore, the compute instances created by the separate service infrastructures cannot directly communicate or interact with each other because they are provisioned by the infrastructures of two different tenants. However, there may be cases where a customer can utilize resources received from two different service infrastructures (e.g., compute instance A and compute instance B in the example above) to interact and collaborate with each other; however, the isolation of the compute instances based on service tenant makes this difficult.

[0024] In this sense, a customer may wish to "connect" two computing instances to enable such cooperative functioning of the computing instances. Previously, such a connection could only be achieved by making customized changes to the code implementing the two computing instances being connected. However, such a solution was specific only to those computing instances and typically not applicable to other connected cloud resources. Furthermore, because specific code changes must be applied to the two computing instances being connected, the process was time-consuming and specific only to those computing instances and not applicable to other types of computing instances. As a result, customers could not request such a connection on demand.

[0025] This disclosure describes a solution to the above-mentioned problem. As described herein, an infrastructure and generalized method for connecting (also called "wiring") two (or more) cloud resources (e.g., two computing instances) is described, even though the computing resources are provisioned by two different services from different cloud tenants. An automated process performed to wire the computing instances is described. The automated process is generally applicable to connecting any two computing instances that offer two different services and are provisioned from two different service tenants.

[0026] For example, a customer may send a request to a first service infrastructure to connect a first service computing instance with a second service computing instance. The request may be received and processed by a first service control plane of the first service infrastructure. A workflow for connecting the two computing instances is then executed. This workflow includes operations performed by the first service control plane, the second service control plane, and an identity management and authorization service (IDMAS). Details related to the operations performed as part of this workflow are shown in Figures 2, 3, 4, 5, 6, and 7 and described below.

[0027] 1 is a simplified block diagram of a distributed environment 100 according to some embodiments. The distributed environment 100 may comprise multiple computer systems communicatively coupled to each other via one or more communication links over one or more communication networks. The distributed environment 100 of FIG. 1 includes a Service A infrastructure 110, a Service B infrastructure 120, a customer tenant 130, an identity management and authorization service 140, and a user actions console 106.

[0028] The distributed environment depicted in Figure 1 is merely an example and is not intended to unduly limit the scope of the claimed embodiments. Many variations, alternatives, and modifications are possible. For example, in some implementations, distributed environment 100 may have more or fewer computer systems or components than those depicted in Figure 1, or may have a different configuration or arrangement of computer systems and communication lines.

[0029] The various components illustrated in FIG. 1 can be implemented using one or more computer systems. An exemplary computer system may include computing resources (e.g., one or more processors or CPUs), memory resources (e.g., system memory, non-volatile memory), and network resources (e.g., network interface cards (NICs)). The computer systems can use the network resources to communicate with one or more other computer systems over one or more communication networks. Communication networks may include, for example, the Internet, an intranet, an extranet, a local area network (LAN), a wide area network (WAN), and other networks that facilitate communication, as well as combinations thereof. Communication may occur over wired or wireless links using one or more wired or wireless communication protocols. In some implementations, the communication network may include a physical substrate network provided by an IaaS provider.

[0030] In one implementation, the various components shown in Figure 1 may be hosted by infrastructure provided by a cloud service provider (CSP), such as an infrastructure-as-a-service (IaaS) provider. In the IaaS model, the CSP provides infrastructure (called cloud service provider infrastructure or CSPI) that customers can use to build their own customizable private networks called virtual cloud networks (VCNs). Customers can deploy one or more customer resources or workloads, such as computing instances, into these VCNs. Compute instances can be virtual machines or bare metal instances. A virtual machine (VM) compute instance can be an independent virtualized machine running on a physical bare metal computer system. Virtualization technologies, such as hypervisors, enable multiple virtual machine compute instances to run on the same physical computer system (also called a host machine). Bare metal compute instances are hosted by bare metal servers or host machines without a hypervisor. When a bare metal compute instance is provisioned, a single customer or tenant maintains control of the physical CPU, memory, and network interfaces of the computer system hosting the bare metal instance, and the computer system is not shared with other customers or tenants.

[0031] When a customer signs up as a subscriber to an IaaS service offered by an IaaS CSP, an account called a customer tenant is created for the customer. For example, as shown in FIG. 1, customer tenant 130 may be created for a subscribing customer. In one implementation, a tenant such as customer tenant 130 provides a root-level compartment that holds all of the customer's cloud resources. Specific, separate tenants can be created for distinct customers. In a typical scenario, a customer can only access resources located within that customer's tenant. A customer can create additional compartments within the customer's root tenant (root compartment) to further control access to resources located within the additional compartments. This is achieved by associating one or more access policies with the compartments to control access to resources within the compartments. When cloud resources (e.g., compute instances, block volumes, cloud networks, etc.) are created for a customer, the customer can specify a specific compartment in which to place the resources. In the simplest, default scenario, a customer's cloud resources are located within the customer's root tenant. For example, in FIG. 1, a customer's cloud resources, such as service A computing instance 131 and service B computing instance 132, may be located within a root compartment created for customer tenant 130.

[0032] In addition to subscribing to IaaS services, customers can subscribe to a variety of other services that may be offered by one or more CSPs. These services may include services offered in the Software-as-a-Service (SaaS) model, the Platform-as-a-Service (PaaS) model, and other types of cloud services. The term cloud service is generally used to refer to services made available by a CSP to users or customers on demand (e.g., via a subscription model) using systems and infrastructure provided by the CSP (cloud infrastructure). Typically, the servers and systems that make up the CSP's infrastructure are separate from the customer's own on-premises servers and systems. Therefore, customers can use cloud services offered by CSPs without having to separately purchase hardware and software resources for the services. Cloud services are designed to provide subscribing customers with easy and scalable access to applications and computing resources without requiring the customer to invest in procuring the infrastructure used to deliver the services.

[0033] For example, in the embodiment shown in FIG. 1 , a customer may subscribe to a “Service A” offered by a CSP using Service A infrastructure 110 and another “Service B” offered by a CSP using Service B infrastructure 120. Service A infrastructure 110 is configured to provision and manage cloud resources related to Service A for one or more subscribing customers. Service A infrastructure 110 may operate within a Service A tenant 115 created specifically for that service. A user 105 of the subscribing customer may use console 106 to send a request to Service A infrastructure 110 requesting a computing instance providing Service A. In response, Service A infrastructure 110 may provision a Service A computing instance 131 (e.g., a particular instance providing Service A) to user 105. As shown in FIG. 1 , the provisioned Service A computing instance 131 may be stored within customer tenant 130. Service A infrastructure 110 is responsible for the lifecycle management and configuration of Service A computing instance 131.

[0034] In one implementation, as shown in FIG. 1, Service A infrastructure 110 may include a Service A control plane 112 that is responsible for provisioning cloud resources for a customer (e.g., Service A computing instance 131), configuring the computing instance, updating the computing instance, and performing lifecycle management of Service A computing instance 131. Service A control plane 112 may provide similar services to other customers who subscribe to Service A. Service A control plane 112 may include a front end 113 component for receiving commands and otherwise communicating with users 105, for example, via console 106. Service A infrastructure 110 may also include a workflow component 114 that is responsible for performing processing corresponding to user requests received by front end 113. In one embodiment, workflow component 114 may be responsible for configuring and executing one or more workflow processes for performing processing corresponding to user requests received by control plane 112.

[0035] Service B infrastructure 120 is configured to provision and manage cloud resources related to Service B for a subscribing customer. Service B infrastructure 120 may operate within a Service B tenant 125 that is created specifically for that service. A user 105 of the subscribing customer may use console 106 to send a request to Service B infrastructure 120 requesting a computing instance that provides Service B. In response, Service B infrastructure 120 may provision a Service B computing instance 132 (e.g., a particular instance that provides Service B) to user 105. As shown in FIG. 1 , the provisioned Service B computing instance 132 may be stored within customer tenant 130. Service B infrastructure 120 is responsible for lifecycle management and configuration of Service B computing instance 132.

[0036] In one implementation, as shown in FIG. 1 , Service B infrastructure 120 may include a Service B control plane 122 that is responsible for provisioning cloud resources for customers (e.g., Service B computing instances 132), configuring the computing instances, updating the computing instances, and performing lifecycle management of Service B computing instances 132. Service B control plane 122 may provide similar services to other customers that subscribe to Service B. Service B control plane 122 may include a front end 123 component for receiving commands and otherwise communicating with users 105, for example, via console 106. Service B infrastructure 120 may also include a workflow component 124 that is responsible for performing processing corresponding to user requests received by front end 123. In one embodiment, workflow component 124 may be responsible for configuring and executing one or more workflow processes for performing processing corresponding to user requests received by control plane 122.

[0037] Note that Service A tenant 115, Service B tenant 125, and customer tenant 130 are three separate tenants. Service A infrastructure 110 cannot access or control cloud resources provisioned by Service B infrastructure 120. For example, Service A infrastructure 110 cannot access Service B compute instance 132. Similarly, Service B infrastructure 120 cannot access or control cloud resources provisioned by Service A infrastructure 110. For example, Service B infrastructure 120 cannot access Service A compute instance 131.

[0038] Because Service A computing instance 131 and Service B computing instance 132 are provisioned and controlled by entities within two different tenants, e.g., Service A tenant 115 and Service B tenant 125, the two computing instances cannot and do not interact with each other. However, there may be situations in which a customer can utilize resources received from two different services to interact and collaborate with each other. For example, a customer with customer tenant 130 can utilize Service A computing instance 131 and Service B computing instance 132 to collaborate. In this sense, the customer may wish to “connect” the two computing instances to enable such collaborative functionality of the computing instances. For example, assume Service A is a SaaS service that provides enterprise application services, such as enterprise resource planning (ERP) services. Therefore, Service A computing instance 131, provisioned by Service A infrastructure 110, can provide ERP services to the customer. Further, assume Service B is a conversational artificial intelligence (AI) service (also known as a digital assistant or chatbot service). Service B infrastructure 120 is configured to create and train a chatbot service instance (e.g., Service B computing instance 132) for a customer, where the chatbot service instance is configured to respond to spoken and / or written language. A customer may want to interact with their ERP service via a chatbot. To accomplish this, the customer may want to connect their chatbot service instance (e.g., Service B computing instance 132) to an ERP computing instance (e.g., Service A computing instance 131).

[0039] Previously, such connectivity could only be achieved by making customized changes to the code implementing the two computing instances being connected. However, such solutions were specific only to those computing instances and typically not applicable to other connected cloud resources. Furthermore, because specific code changes had to be applied to the two computing instances being connected, the process was time-consuming and specific only to those computing instances and not applicable to other types of computing instances. As a result, customers could not request such connectivity on demand.

[0040] This disclosure describes a solution to the above-mentioned problem. As described herein, an infrastructure and generalized method for connecting (also called "wiring") two (or more) cloud resources (e.g., two computing instances) is described, even though the computing resources are provisioned by two different services from different cloud tenants. An automated process performed to wire the computing instances is described. The automated process is generally applicable to connecting any two computing instances that offer two different services and are provisioned from two different service tenants.

[0041] For example, in the embodiment shown in FIG. 1 , user 105 may send a request via console 106 to Service A infrastructure 110 to connect Service A computing instance 131 and Service B computing instance 132. The request may be received and processed by Service A control plane 112. A workflow is then executed to connect the two computing instances, which includes processing performed by Service A control plane 112, Service B control plane 122, and Identity Management and Authorization Service (IDMAS) 140. Details related to the processing performed as part of this workflow are shown in FIGS. 2, 3, 4, 5, 6, and 7 and described below. The overall workflow for connecting the two computing instances may include separate workflows performed by Service A infrastructure 110, Service B infrastructure 120, and IDMAS 140.

[0042] For example, in the example described above with respect to the ERP service computing instance and the chatbot computing instance, a user may request that the two computing instances be connected. Processing is then performed to perform the connection. As a result of the connection, a user of the ERP computing instance can interact with the ERP instance using conversations with the chatbot instance.

[0043] When a connection between two connected computing instances is no longer desired by a customer, a customer user can, upon request, request the separation (i.e., disconnection) of the previously connected computing instances. For example, in the embodiment shown in FIG. 1 , user 105 can send a request to Service A infrastructure 110 via console 106 to separate previously connected Service A computing instance 131 and Service B computing instance 132. The request can be received and processed by Service A control plane 112. A workflow is then executed to separate the two computing instances, which workflow includes processing performed by Service A control plane 112, Service B control plane 122, and identity management and authorization service 140. Details related to the processing performed as part of this workflow are shown in FIG. 3 and described below.

[0044] Thus, the embodiments described herein allow a user 105 to request that two computing instances be connected and able to communicate with each other, or, again, be separated, upon request. As shown in Figure 1, the connection is symbolically illustrated using a connection link 133 representing the communication link between a service A computing instance 131 and a service B computing instance 132.

[0045] Information associated with the connect / disconnect process may be stored by Service A infrastructure 110 as connect / disconnect information 111. Similarly, information associated with the connect / disconnect process may be stored by Service B infrastructure 120 as connect / disconnect information 121.

[0046] The identity management and authorization service 140 is configured to provide a service for checking whether a requesting user is authorized to request the connection or disconnection of a particular set of computing instances to be connected or disconnected. The authorization may be based on access control policies defined for the service instances to be connected or disconnected. For example, policies may be defined for the customer tenant 130 that control which instances can be connected / disconnected, which users can request connection / disconnection, etc. The identity management and authorization service 140 may evaluate such policies to determine whether the request can be authorized. The identity management and authorization service 140 may enable the service A infrastructure 110 and the service B infrastructure 120 to communicate with each other on behalf of the user 105 during the connection process (or disconnection process).

[0047] FIG. 2 illustrates a simplified swim chart 200 depicting a process for connecting two computing instances within a customer tenant, according to one embodiment. The process illustrated in FIG. 2 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device). The method illustrated in FIG. 2 and described below is intended to be exemplary and non-limiting. While FIG. 2 depicts various process operations occurring in a particular sequence or order, this is not intended to be limiting. In an alternative embodiment, the process may be performed in some different order, or some steps may be performed in parallel.

[0048] Swim chart 200 illustrates the process of connecting two computing instances. The process illustrated in FIG. 2 assumes that the two computing instances to be connected already exist before receiving the connection request. For example, the two computing instances being connected may have been pre-created before receiving the connection request. In one embodiment, when a request to connect two instances is received from two services, if the instances do not already exist, as part of the process, the computing instances are first created by interacting with the respective service infrastructure, and then the computing instances may be connected according to the process illustrated in FIG. 2.

[0049] For example, in the embodiment shown in FIG. 1 , user 105 can send (e.g., via console 106) an instruction to service A control plane front end 113 to create a first computing instance of service A. In response to receiving the user instruction, service A control plane workflow 114 can create and configure service A computing instance 131 (e.g., an instance of the first service) within the user's customer tenant 130. Service A control plane 112 can continue to control and manage service A computing instance 131. Similarly, user 105 can send (e.g., via console 106) an instruction to service B control plane 122 to create a second computing instance of service B. In response to receiving the user instruction, service B control plane 122 can create and configure service B computing instance 132 (e.g., an instance of the second service) within the user's customer tenant 130. Service B control plane 122 can continue to control and manage service B computing instance 132.

[0050] While both Service A computing instance 131 and Service B computing instance 132 may exist within customer tenant 130, Service A computing instance 131 and Service B computing instance 132 may be created independently and are initially isolated from each other within customer tenant 130. Typically, Service A control plane 112 has ownership of Service A computing instance 131, such that only Service A control plane 112 can access and configure Service A computing instance 131. Similarly, Service B control plane 122 typically has ownership of Service B computing instance 132, such that only Service B control plane 122 can access and configure Service B computing instance 132. Due to this isolation, Service A computing instance 131 and Service B computing instance 132 typically cannot communicate or share information with each other.

[0051] 2 and described below, based on a user's instructions, can connect Service A computing instance 131 and Service B computing instance 132. As a result of the connection, Service A computing instance 131 and Service B computing instance 132 can communicate and exchange information. Additionally, Service A control plane 112 can own, control, and / or configure both Service A computing instance 131 and Service B computing instance 132.

[0052] As shown in FIG. 2, processing may begin at S202 when a user 105 using a user device (e.g., console 106) sends a request to the Service A control plane 112 to connect the Service A computing instance 131 and the Service B computing instance 132.

[0053] For purposes of this disclosure, the control plane that receives the connection request from the user is referred to as the "dominant" control plane, and the other control plane is referred to as the "passive" control plane. The dominant control plane initiates the connection process and contains the functions and APIs necessary to perform the connection. For example, in Figure 2, Service A control plane 112 receives the connection request at S202 and is therefore the dominant control plane, while Service B control plane 122 is the passive control plane.

[0054] In the example shown in FIG. 2, the command is received by Service A control plane front end 113. Because two separate computing instances created by two separate service control planes are being connected, in one embodiment, the connection request may be sent to either one of the two service control planes. For example, when connecting Service A computing instance 131 and Service B computing instance 132, the connection request may be sent by a user device (e.g., console 106) to either Service A control plane 112 or Service B control plane 122. A user 105, via a user device (e.g., console 106), can determine to which service the command is to be sent. For example, a user 105, via a user device (e.g., console 106), can select Service A from a list displayed in a user interface.

[0055] In some other implementations, connecting two computing instances may require sending a connection request to a specific one of two service control planes. For example, in order for service A computing instance 131 and service B computing instance 132 to be connected, the connection request may need to be sent to service A control plane 112 rather than service B control plane 122. In such implementations, only one of the control planes (e.g., service A control plane 112) may be the dominant control plane (e.g., based on available processing power and APIs). In such cases, the user device (e.g., console 106) must send the connection request to the specific control plane that may be the dominant control plane.

[0056] In some embodiments, after the connection process is complete, the connection causes the dominant control plane to have control and ownership of the computing instances (within the customer tenant) of the passive control plane. As a result, certain operations that the passive control plane can perform on the computing instances (e.g., deleting the computing instances) are not permitted as long as the connection remains. Instead, in such embodiments, the passive control plane receives and follows connection messages and instructions from the dominant control plane, enabling the dominant control plane to gain control of the computing instances of the passive control plane.

[0057] After receiving the connection request, the dominant control plane may then initiate a process to determine whether the connection request can be fulfilled. For example, a process may be performed to determine whether the user requesting the connection authorizes such request. In one implementation, the identity management and authorization service 140 may perform the process for authorization. Thus, at S204, the dominant control plane (in this example, the Service A control plane 112) may send the identity management and authorization service 140 information related to the request received at S202. The identity management and authorization service 140 may then initiate the authorization process. If the authorization is successful (i.e., the user may request a connection between the two identified computing instances), then, as part of S204, the identity management and authorization service 140 may send a response back to the dominant control plane (i.e., the Service A control plane 112) providing authorization to continue the connection process.

[0058] In some embodiments, the response sent by the identity management and authorization service 140 to the Service A control plane 112 may include an On-Behalf-Of (OBO) token. The OBO token sent to the Service A control plane 112 serves as a token or evidence that the Service A control plane 112 is authorized to send connection-related instructions to the Service B control plane 122 on behalf of the user device (e.g., the console 106). In one implementation, the OBO token may be included as evidence of authorization in all subsequent communications from the Service A control plane 112 to the Service B control plane 122 (generally, communications from the dominant control plane to the passive control plane).

[0059] In some embodiments, a check may also be performed to verify whether a connection between two computing instances is permitted. In such implementations, connections may be permitted only between computing instances of a certain type, i.e., only between computing instances of a certain service. Information identifying connections between permitted services may be stored. If the request received at S202 identifies two computing instances that are not permitted to connect, the connection process may be terminated and an error message may be returned to the requesting user. For example, if a connection between a service A computing instance and a service B computing instance is not permitted, a request to connect computing instances 131 and 132 may not be permitted. In some implementations, this check to verify whether a connection between the two identified computing instances is permitted is performed by a dominant control plane after receiving the connection request. The dominant control plane may have access to information identifying permitted connections to determine where a particular requested connection is permitted. In some other implementations, this check may be performed by identity management and authorization service 140.

[0060] The process of performing the connection may be performed synchronously or asynchronously. In some implementations, an asynchronous implementation is preferred because the requesting user does not have to wait (or is not locked out) for the entire process to complete. Thus, in implementations using asynchronous processing, at S206, the Service A control plane front end 113 creates an asynchronous work request to perform the process and provides a work request identifier to the user device (e.g., the console 106). The user device (e.g., the console 106) can request an update on the status of the connection process by sending the work request ID.

[0061] In S208, after completing the identity management and authorization processing in step S204, Service A control plane front end 113 instructs Service A control plane workflow 114 component to initiate a workflow to create the connection. In some embodiments, Service A control plane front end 113 can provide an OBO token to Service A control plane workflow 114 for use in communicating with Service B control plane 122 to create the connection.

[0062] At S210, the Service A control plane workflow 114 (i.e., the dominant control plane) sends a connection request to the Service B control plane 122 (i.e., the passive control plane). The connection request notifies the Service B control plane 122 that a computing instance owned by the Service B control plane 122 is connected to another computing instance owned by the dominant control plane (i.e., the Service A control plane 122). The connection request message includes a payload of any appropriate information associated with the connection. For example, the connection request may include identity / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, the OBO token received by the Service A control plane 112 at S204 may be included in the request sent at S210. Furthermore, the connection request may indicate the instances to be connected (e.g., the Service A computing instance 131 and the Service B computing instance 132). The computing instances may be identified using an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifiers (OCIDs).

[0063] Additionally, the connection request may indicate the identity of the dominant and passive control planes. For example, in the example of Figure 2, the dominant control plane is Service A control plane 112 and the passive control plane is Service B control plane 122. This also identifies the dominant and passive computing instances. Because Service A control plane 112 is the dominant control plane, Service A computing instance 131 is referred to as the dominant computing instance. Similarly, because Service B control plane 122 is the passive control plane, the connection refers to Service B computing instance 132 as the passive computing instance.

[0064] Furthermore, in some embodiments, the connection imposes restrictions on the operations that (a) the customer and (b) the passive control plane can perform on the passive computing instance. In some implementations, the connection request sent at S210 may include information indicating these restrictions. For example, the request may identify, for each customer and passive control plane, a list of one or more operations that the connection allows or does not allow on the passive computing instance by the customer and / or the passive control plane. The request may identify a list of one or more operations that the connection allows or does not allow on the passive computing instance by the customer. In some implementations, a list of allowed operations is provided for each customer and passive service control plane. Operations not specifically specified in the list are not allowed while the connection exists. In some embodiments, the operation to delete the passive computing instance (e.g., service B computing instance 132) may no longer be included in the customer's new list of allowed operations. In some embodiments, the operation to delete the connection may be allowed only for the owner, not the customer.

[0065] Below is an example of an attachment request that may be called with the CREATE ATTACH API: POST / ServiceBInstances / <instanceid> / attachments / { "attachToId": "ocid1.ServiceAinstance.oc1..aaaaaaaat733hgqhsleueh6yeqyx3gnbiik47cca4juksmlodvzr3B6cwbpa", "attachmentType":"ServiceA", / / known enumeration type "attachmentMetadata":{}, / / Connection-specific metadata "ownerMetadata":{ / / Owner-specific metadata "ownerService":["ServiceA-control-plane"], / / SP name of ServiceACP. This is a list to support multiple SP names for the same service. / / Any * means manage all permissions for this resource. "allowedOwnerOperations": / / List of operations that the owner should be able to perform "allowedCustomerOperations": / / List of control plane permission strings allowed for all other callers } }

[0066] As shown in the above request, a passive computing instance (in the above example, the Service B instance) is attached to a dominant computing instance (in the above example, the Service A instance). The "attachToId" in the request provides the identifier (e.g., OCID) of the dominant computing instance to which the passive computing instance is attached. The "attachmentType" identifies the type of the dominant computing instance, i.e., the service provided by the dominant computing instance. The "attachmentMetadata" provides connection-specific metadata. The "ownerMetadataattachmentType" provides owner-specific metadata. The "ownerService" identifies the service provider name associated with the dominant control plane. In the above example, the name is "ServiceA-control-plane". The "allowedOwnerOperations" identifies the operations that are allowed by the owner (i.e., the dominant control plane) while the connection exists. For example, the dominant control plane (i.e., the Service A control plane 112) may be allowed to perform GET, LIST, UPDATE, and DELETE ATTACHMENT operations on the passive computing instance. "allowedCustomerOperations" identifies the operations that are allowed by the customer while the connection exists. For example, a customer may only be allowed to perform GET, LIST, and UPDATE operations on the passive computing instance.

[0067] Note that neither the customer (e.g., a customer tenant administrator), the dominant control plane (i.e., Service A control plane 112), nor the passive control plane (i.e., Service B control plane 122) is permitted to delete the passive computing instance (i.e., Service B computing instance 132) while a connection exists. Thus, even though the passive control plane (i.e., Service B control plane 122) is the creator and owner of the passive computing instance (i.e., Service B computing instance 132), it is not permitted to delete the passive computing instance (i.e., Service B computing instance 132) while the connection exists.

[0068] At S212, Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving the connection request, which may include storing (also referred to as “posting”) details of the connection request received from Service A control plane 112 (i.e., the dominant control plane) in a record to persist the connection information, and modifying the ownership and permitted operations associated with Service B computing instance 132 (i.e., the passive computing instance).

[0069] For example, Service B control plane 122 may create and store a record within customer tenant 130 indicating that Service B computing instance 132 (e.g., identified by an associated OCID) is currently connected to Service A computing instance 131 (e.g., identified by an associated OCID). This record may indicate that Service B computing instance 132 is the passive computing instance and Service A computing instance 131 is the dominant computing instance. Additionally, the record may indicate the associated control planes and their respective roles. For example, the dominant control plane may be Service A control plane 112, and the passive control plane may be Service B control plane 122. This record may also include information indicating the type of service to which the passive computing instance is connected (i.e., the service provided by the dominant computing instance). Additionally, the record may indicate that Service A control plane 112 is currently the owner of Service B computing instance 132 (i.e., because Service A control plane 112 is the dominant control plane in this example). This allows the Service B control plane 122 to grant control and ownership of the Service B computing instance 132 to the Service A control plane 112. The record may also indicate what operations are permitted on the Service B computing instance 132 while the connection exists, which may be modifications of previously permitted operations. The operations may include customer-permitted and owner-permitted operations (e.g., operations that a dominant control plane may perform) on the Service B computing instance 132. For example, a delete operation may not be included in the customer-permitted operations and therefore may not be permitted while the connection exists.

[0070] In some embodiments, Service B control plane 122 can verify that Service A control plane 112 is authorized to initiate the creation of the connection. For example, Service B control plane 122 can verify the authenticity of the OBO token and / or the permissions associated with the OBO token.

[0071] In some embodiments, as part of S212, the Service B control plane 122 may modify and configure the Service B computing instance 132 in the customer tenant 130 to indicate that a connection exists.

[0072] As mentioned above, in some implementations, the process of performing the connection can be performed asynchronously. In that case, Service A control plane 112 may periodically poll Service B control plane 122 to determine the status of the processing of the connection request being performed by Service B control plane 122. In some embodiments, Service B control plane 122 can provide an asynchronous request identifier to Service A control plane 112 to confirm that the connection request has been received and is being processed. Service A control plane 112 can then use the asynchronous request identifier when polling Service B control plane 122 for the current processing status. Finally, Service B control plane 122 responds with a message indicating that the connection processing is complete in Service B control plane 122. The message can indicate either the success or failure of the processing performed by Service B control plane 122.

[0073] Accordingly, in S214, Service B control plane 122 sends a connection response to Service A control plane 112 indicating that the connection will be handled by Service B control plane 122. The connection response message may inform Service A control plane 112 that the connection details will be confirmed and implemented according to the connection request message sent in step S210.

[0074] An example of a connection response message sent from a passive control plane (eg, Service B control plane 122) to a dominant control plane (eg, Service A control plane 112) is shown below: Response==> { "iD":"ocid1.serviceattachment.oc1.uK-london-1.aaaaa...." / / Connection ID generated by the passive control plane "instanceID": "ocid1.ServiceBinstance.oc1.uK-london- 1.amaaaaaaaxki4uqarjeyspipvniykktxvdglpc52ycz7rrxibl5tcvfkcoaa" "attachToId": "ocid1.ServiceAinstance.oc1..aaaaaaaat733hgqhsleueh6yeqyx3gnbiik47cca4juksmlodvzr3B6cwbpa" "compartmentId":"The compartment of the instance or this connection" "attachmentType":"ServiceA” "ownerMetadata":{ "attachmentType":"ServiceA" / / Polymorphic identifier "ownerService":["ServiceA-control-plane"] / / Additional custom fields per service provider. For example, Service A control plane can define the following two: Other service providers can define their own services. "allowedCustomerOperations": / / List of control plane permission strings allowed for all other callers "allowedOwnerOperations": / / List of operations that the owner can perform "" } "LifecycleState":"ATTACHIMG” }

[0075] As shown in the request above, "id" provides an identifier for the connection. "instanceID" provides an identifier (e.g., OCID) of the passive computing instance currently attached to the dominant computing instance. "attachToId" provides an identifier (e.g., OCID) of the dominant computing instance to which the passive computing instance is currently attached. "compartmentId" identifies the compartment of the passive computing instance or connection (e.g., the compartment within the customer tenant 130 in which the passive computing instance is located). "attachmentType" identifies the type of dominant computing instance, i.e., the service provided by the dominant computing instance. "ownerMetadata" indicates the following additional data fields: "ownerService" identifies the service provider name associated with the dominant control plane. In the example above, the name is "ServiceA-control-plane". Additional data fields configured for specific services and control planes may be included. For example, "allowedCustomerOperations" identifies the allowed operations by the customer when a connection exists. For example, a customer may be allowed to perform GET, LIST, UPDATE, and ATTACH operations on the passive computing instance. "allowedOwnerOperations" identifies the operations that are allowed by the owner (i.e., the dominant control plane) while the connection exists. For example, the dominant control plane (i.e., Service A control plane 112) may be allowed to perform GET, LIST, and UPDATE operations on the passive computing instance. "lifecycleState" indicates what operations are currently being performed on the connection. In the above example, the connection is being established, so "lifecycleState" is "attaching."

[0076] Optionally, at S216, Service A control plane 112 (i.e., the dominant control plane) may send instructions to Service B control plane 122 (i.e., the passive control plane) to configure and / or update Service B computing instance 132 in customer tenant 130. For example, depending on the type of computing instance, Service A control plane 112 may install functionality (e.g., skills for a chatbot computing instance) in Service B computing instance 132 that enables communication between Service B computing instance 132 and Service A computing instance 131.

[0077] At S218, Service A control plane 112 (i.e., the dominant control plane) performs processing to connect the computing instances in response to receiving the connection response from Service B control plane 122 (i.e., the passive control plane). For example, Service A control plane 112 may store any appropriate information in a record to persist the connection information in the dominant control plane. This may include storing the compartment ID (e.g., within customer tenant 130) of the Service B computing instance 132 indicated by Service B control plane 122. Additionally, Service A control plane 112 may identify what permitted operations are agreed to and / or provided by Service B control plane 122.

[0078] In some embodiments, as part of the processing performed at S218, Service A control plane 112 may perform identity wiring so that Service A computing instance 131 and Service B computing instance 132 can communicate with each other. This may include setting and persisting Oracle Identity Cloud Service (IDCS) OAuth credentials so that future service calls can be made using the OAuth credentials.

[0079] In some embodiments, as part of the processing performed at S218, the Service A control plane 112 may configure the Service A computing instance 131 and / or the Service B computing instance 132 to indicate the connection.

[0080] At this point, both control planes agree to the connection, store information associated with the connection, and perform operations to complete the connection, such as modifying certain permissions, ownership, and configuration. The Service B control plane 122 (i.e., the passive control plane) has granted control and ownership of the Service B computing instance 132 (i.e., the passive computing instance) to the Service A control plane 112 (i.e., the dominant control plane). As a result, the Service A control plane 112 (i.e., the dominant control plane) now has control and ownership of both the Service A computing instance 131 (i.e., the dominant computing instance) and the Service B computing instance 132 (i.e., the passive computing instance), and no other service control plane can claim ownership of the Service B computing instance 132. Both the Service A computing instance 131 and the connected Service B computing instance 132 continue to exist within the customer tenant 130.

[0081] The connection and the Service A control plane's temporary ownership of the Service B computing instance 132 remain in effect until the connection is removed by a subsequent detach API call. In some embodiments, the Service B computing instance 132 cannot be deleted while the connection exists. To delete the Service B computing instance 132, the computing instance must first be detached, and then the Service B computing instance 132 can be deleted. If a user device (e.g., the console 106) attempts to delete the Service B computing instance 132 through the Service B control plane 122, which no longer has ownership of the Service B computing instance 132, the deletion attempt is rejected due to the existing connection. If a user device (e.g., the console 106) attempts to delete the Service B computing instance 132 through the Service A control plane 112, which currently has ownership, the user device (e.g., the console 106) is notified that a connection exists and therefore cannot delete the Service B computing instance 132 until the computing instance is detached.

[0082] At S220, the Service A control plane workflow 114 can send a completion message indicating that the connection was successfully established (or, in the case of failure), back to the Service A control plane front end 113. Then, at S222, the Service A control plane front end 113 can send a completion message indicating that the connection was successfully established (or, in the case of failure), back to the user 105 (e.g., via a user device such as the console 106).

[0083] 2, two computing instances from two different services operating in two different service tenants, which would normally be separate and independent, can now be connected to communicate and collaborate (e.g., via API calls) with each other, without any dependencies or connections, as desired by user 105. Embodiments allow for the interaction or communication between the two computing instances to be unidirectional or bidirectional.

[0084] As an example, Service A computing instance 131 can be a computing instance of a Fusion application service that can provide customer relationship management services. Service B computing instance 132 can be a computing instance of an Oracle Digital Assistant (ODA) application that can provide customer interaction services, such as a chatbot. A user can provide information to configure and / or train the ODA instance, such as a set of questions and corresponding responses stored in the Fusion application service. As a result, when a customer submits a question to the chatbot, the chatbot can retrieve an answer from the Fusion application service based on the question and provide the response to the customer.

[0085] A user 105 may wish to connect a Fusion Computing instance and an ODA Computing instance so that the two instances can interact and share information. Typically, the two instances cannot interact, and the sharing of information between the two instances is done manually by a human user. However, connecting using the process described above allows for automatic sharing of information without the need for a human user. For example, an ODA Computing instance can interact with a customer to receive the customer's purchase order, the ODA Computing instance can provide the purchase order information to the connected Fusion Computing instance, and the Fusion Computing instance can fulfill the purchase order.

[0086] In the example described above and shown in FIG. 1, the dominant and passive computing instances (e.g., service A computing instance 131 and service B computing instance 132) are both created for the same customer and are therefore under the same customer tenant. However, in other embodiments, the two instances being connected may reside in two different customer tenants. This can be done in the same manner as described with respect to FIG. 2 above, connecting two computing instances that are within the same customer tenant. In other words, cross-tenant connection of instances is possible.

[0087] The above process describes connecting one computing instance to another computing instance, i.e., a one-to-one connection. However, it is not limited to this. In other embodiments, other types of connections involving multiple computing instances can be created, such as one-to-many (e.g., one dominant computing instance and multiple passive computing instances), many-to-one (e.g., multiple dominant computing instances and one passive computing instance), and / or many-to-many type connections (e.g., multiple dominant computing instances connected to multiple passive computing instances). In embodiments with multiple computing instances, the computing instances are instances of different services (e.g., multiple passive computing instances each corresponding to a different service).

[0088] FIG. 3 illustrates a simplified swim chart 300 depicting a process for separating two connected computing instances within a customer tenant, according to one embodiment. The process illustrated in FIG. 3 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device). The method illustrated in FIG. 3 and described below is intended to be exemplary and non-limiting. While FIG. 3 depicts various processing operations occurring in a particular sequence or order, this is not intended to be limiting. In an alternative embodiment, the process may be performed in some different order, or some steps may be performed in parallel.

[0089] Swim chart 300 illustrates the process of separating two computing instances. The process illustrated in Figure 3 assumes that the two computing instances to be separated already exist and are already connected before receiving the separation request. For example, the two computing instances to be separated may have previously been connected through the process described above with respect to Figure 2.

[0090] As shown in FIG. 3, the process may begin at S302 when a user 105 using a user device (e.g., console 106) sends a request to the Service A control plane 112 to separate the Service A computing instance 131 and the Service B computing instance 132 within the user's customer tenant 130.

[0091] In implementations using asynchronous processing, at S304, the Service A control plane front end 113 creates an asynchronous work request to perform the processing and provides a work request identifier to the user device (e.g., the console 106). The user device (e.g., the console 106) can request an update on the status of the connection processing by sending the work request ID.

[0092] At S306, Service A control plane front end 113 instructs Service A control plane workflow 114 component to initiate a workflow for separating the two computing instances. In some embodiments, Service A control plane front end 113 can provide an OBO token to Service A control plane workflow 114 for use in communicating with Service B control plane 122 for separating the two computing instances.

[0093] At S308, the Service A control plane workflow 114 (i.e., the dominant control plane) sends a detach request to the Service B control plane 122 (i.e., the passive control plane). The detach request notifies the Service B control plane 122 that a computing instance associated with the Service B control plane 122 is being detached from another computing instance associated with the dominant control plane (i.e., the Service A control plane 122), thereby restoring the previous computing instance configuration. The detach request message includes a payload of any appropriate information related to the attachment and detachment. For example, the detachment request may include identity / authorization information indicating that the Service A control plane 112 is authorized to initiate the detachment. For example, an OBO token received by the Service A control plane 112 (e.g., S204 of FIG. 2) may be included in the request sent at S308. Additionally, the attachment request may indicate the instances to be detached (e.g., the Service A computing instance 131 and the Service B computing instance 132). The computing instances can be identified using an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifiers (OCIDs). Additionally, the isolation request can indicate the IDs of the dominant and passive control planes as well as the IDs of the corresponding dominant and passive control planes. The isolation request can also include an identifier for the connection.

[0094] Additionally, in some embodiments, the removal of the connection may remove limitations previously imposed on operations that can be performed on the passive computing instance. In some implementations, the detachment request sent at S308 may include information indicating the removal of these limitations. For example, the request may identify a list of one or more operations, per customer and passive control plane, that are either permitted or disallowed on the passive computing instance by the customer and / or passive control plane due to the connection and therefore should be restored when the connection is removed. In some embodiments, the list of operations associated with the connection may be deleted, thereby removing the limitations associated with the connection.

[0095] At S310, the Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving the detachment request. This may include removing connection details from posted records and modifying the ownership and permitted operations associated with the Service B computing instance 132 (i.e., the passive computing instance). In some embodiments, the Service B control plane 122 may verify that the Service A control plane 112 is authorized to remove the connection. For example, the Service B control plane 122 may verify the authenticity of the OBO token and / or the permissions associated with the OBO token. In some embodiments, as part of S310, the Service B control plane 122 may modify and configure the Service B computing instance 132 in the customer tenant 130 to indicate that the previous connection no longer exists.

[0096] In S312, Service B control plane 122 sends a detach response to Service A control plane 112 indicating that the detachment is processed in Service B control plane 122. The detach response message informs Service A control plane 112 that the previous connection details are removed, so that it can calculate the instance configuration to be restored according to the detach request message sent in step S308.

[0097] At S314, Service A control plane 112 (i.e., the dominant control plane) performs processing to isolate the computing instances in response to receiving the isolation response from Service B control plane 122 (i.e., the passive control plane). For example, Service A control plane 112 may remove stored information about the previous connection in the dominant control plane, restore the previous set of allowed operations, remove ID wiring, and / or configure Service A computing instance 131 and / or Service B computing instance 132 to no longer indicate the connection.

[0098] At this point, both control planes agree to remove the connection and perform operations to isolate the computing instances, such as deleting stored information associated with the connection and restoring certain permissions, ownership, and configuration. The Service B control plane 122 (i.e., the passive control plane) has regained control and ownership of the Service B computing instance 132 (i.e., the passive computing instance). As a result, the Service A control plane 112 (the dominant control plane) no longer has control and ownership of the Service B computing instance 132 (i.e., the passive computing instance). Both the Service A computing instance 131 and the Service B computing instance 132 continue to exist within the customer tenant 130.

[0099] At S316, the Service A control plane workflow 114 can send a completion message indicating successful completion of the separation (or, if unsuccessful), back to the Service A control plane front end 113. Then, at S318, the Service A control plane front end 113 can send a completion message indicating successful removal of the connection (or indicating failure) back to the user 105 (e.g., via a user device such as the console 106).

[0100] FIG. 4 illustrates a simplified swim chart 400 showing the process of connecting two computing instances within a customer tenant, according to one embodiment. Here, the passive instance does not yet exist and is created as part of the process. The process illustrated in FIG. 4 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device). The method illustrated in FIG. 4 and described below is intended to be exemplary and non-limiting. While FIG. 4 illustrates various processing operations occurring in a particular sequence or order, this is not intended to be limiting. In an alternative embodiment, the process may be performed in some different order, or some steps may be performed in parallel.

[0101] 4 , it is assumed that the dominant computing instance being connected already exists before receiving the connection request, and that the passive computing instance being connected does not yet exist before receiving the connection request. For example, the dominant computing instance being connected may be pre-created before receiving the connection request, but the passive computing instance being connected is not created before receiving the connection request.

[0102] For example, in the embodiment shown in FIG. 1 , user 105 may send (e.g., via console 106) an instruction to service A control plane front end 113 to create a first computing instance of service A. In response to receiving the user instruction, service A control plane workflow 114 may create and configure service A computing instance 131 (e.g., an instance of the first service) within the user's customer tenant 130. Service A control plane 112 may continue to control and manage service A computing instance 131. However, user 105 may not have sent an instruction to service B control plane 122 to create a second computing instance of service B, and thus service B's computing instance 132 (e.g., an instance of the second service) may not yet exist within the user's customer tenant 130.

[0103] As shown in FIG. 4, the process may begin at S402 when a user 105 using a user device (e.g., console 106) sends a request to the Service A control plane 112 to connect a Service A computing instance 131 and a Service B computing instance 132 within the user's customer tenant 130, which may be the same as or similar to step S202 of FIG. 2.

[0104] After receiving the connection request, the dominant control plane may initiate a process to determine whether the connection request can be fulfilled. For example, a process may be performed to determine whether the user requesting the connection authorizes such request. In some implementations, the identity management and authorization service 140 may perform the process for authorization. Thus, in S404, which may be the same as or similar to step S204 of FIG. 2, the dominant control plane (in this example, the Service A control plane 112) may send information related to the request received in S402 to the identity management and authorization service 140. The identity management and authorization service 140 may then initiate the authorization process. If the authorization is successful (i.e., the user can request a connection between two computing instances), then, as part of S404, the identity management and authorization service 140 may send a response back to the dominant control plane (i.e., the Service A control plane 112) providing authorization to continue the connection process. In some embodiments, the response sent by the identity management and authorization service 140 to the Service A control plane 112 may include an On-Behalf-Of (OBO) token.

[0105] In an implementation using asynchronous processing, in S406, which may be the same as or similar to step S206 of Figure 2, the service A control plane front end 113 creates an asynchronous work request to perform the processing and provides a work request identifier to the user device (e.g., the console 106). The user device (e.g., the console 106) can request an update on the status of the connection processing by sending the work request ID.

[0106] 2, after completing the identity management and authorization processing in step S404, Service A control plane front end 113 instructs Service A control plane workflow 114 component to initiate a workflow to create the connection. In some embodiments, Service A control plane front end 113 can provide an OBO token to Service A control plane workflow 114 for use in communicating with Service B control plane 122 to create the connection.

[0107] At S409A, the Service A control plane workflow 114 determines that a Service B computing instance 132 (e.g., an instance of a second service) does not exist within the user's customer tenant 130. Therefore, it is determined to create a Service B computing instance 132 before the connection can be created.

[0108] At S409B, the Service A control plane workflow 114 sends a request to the Service B control plane 122 (i.e., the passive control plane) to create a Service B computing instance 132 (e.g., an incarnation of a second service) within the user's customer tenant 130. The create request includes a payload of any appropriate information related to the creation. For example, the create request may include identity / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the computing instance. For example, the OBO token received by the Service A control plane 112 at S404 may be included in the request sent at S409B.

[0109] At S409C, Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving the creation request. This may include creating and configuring Service B computing instance 132 (e.g., an incarnation of a second service) within the user's customer tenant 130. Service B control plane 122 may continue to control and manage Service B computing instance 132. Service B control plane 122 may then send a creation response to Service A control plane 112 indicating that the computing instance is created within the user's customer tenant 130. The response message may inform Service A control plane 112 of the instance identifier (e.g., OCID) of Service B computing instance 132 and any other appropriate information. After Service B computing instance 132 is created, Service A control plane 112 may continue the process of connecting the two computing instances.

[0110] At S410, which may be the same as or similar to step S210 of FIG. 2, the Service A control plane workflow 114 (i.e., the dominant control plane) sends a connection request to the Service B control plane 122 (i.e., the passive control plane). The connection request notifies the Service B control plane 122 that a computing instance owned by the Service B control plane 122 is connected to another computing instance owned by the dominant control plane (i.e., the Service A control plane 122). The connection request message includes a payload of any appropriate information associated with the connection. For example, the connection request may include identity / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, the OBO token received by the Service A control plane 112 at S404 may be included in the request sent at S410. Additionally, the connection request may indicate the instances to be connected (e.g., the Service A computing instance 131 and the Service B computing instance 132). Compute instances can be identified using an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifier (OCID). Furthermore, connection requests can indicate the IDs of the dominant and passive control planes as well as the IDs of the corresponding dominant and passive control planes.

[0111] Further, in some embodiments, the connection imposes restrictions on the operations that (a) the customer and (b) the passive control plane can perform on the passive computing instance. In some implementations, the connection request sent at S410 may include information indicating these restrictions. For example, the request may identify, for each customer and passive control plane, a list of one or more operations that the connection allows or does not allow on the passive computing instance by the customer and / or the passive control plane. The request may identify a list of one or more operations that the connection allows or does not allow on the passive computing instance by the customer. In some implementations, a list of allowed operations is provided for each customer and passive service control plane. Operations not specifically specified in the list are not allowed while the connection exists. In some embodiments, the operation to delete the passive computing instance (e.g., service B computing instance 132) may no longer be included in the customer's new list of allowed operations. In some embodiments, the operation to delete the connection may be allowed only for the owner, not for the customer.

[0112] At S412, which may be the same as or similar to step S212 of FIG. 2, the Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving the connection request. This may include storing (also referred to as “posting”) details of the connection request received from the Service A control plane 112 (i.e., the dominant control plane) in a record to persist the connection information and modifying the ownership and permitted operations associated with the Service B computing instance 132 (i.e., the passive computing instance). In some embodiments, the Service B control plane 122 may verify that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, the Service B control plane 122 may verify the authenticity of the OBO token and / or the permissions associated with the OBO token. In some embodiments, as part of S412, the Service B control plane 122 may modify and configure the Service B computing instance 132 in the customer tenant 130 to indicate that the connection exists.

[0113] 2, the Service B control plane 122 sends a connection response to the Service A control plane 112 indicating that the connection will be handled by the Service B control plane 122. The connection response message may inform the Service A control plane 112 that the connection details will be confirmed and implemented according to the connection request message sent in step S410.

[0114] Optionally, at S416, which may be the same as or similar to step S216 of FIG. 2, the Service A control plane 112 (i.e., the dominant control plane) may send instructions to the Service B control plane 122 (i.e., the passive control plane) to configure and / or update the Service B computing instance 132 in the customer tenant 130. For example, depending on the type of computing instance, the Service A control plane 112 may install functionality (e.g., skills for a chatbot computing instance) in the Service B computing instance 132 that enables communication between the Service B computing instance 132 and the Service A computing instance 131.

[0115] At S418, which may be the same as or similar to step S218 of FIG. 2, the Service A control plane 112 (i.e., the dominant control plane) performs processing to connect the computing instances in response to receiving the connection response from the Service B control plane 122 (i.e., the passive control plane). For example, the Service A control plane 112 may store any appropriate information in a record to maintain the connection information in the dominant control plane. This may include storing the compartment ID (e.g., within the customer tenant 130) of the Service B computing instance 132 indicated by the Service B control plane 122. Additionally, the Service A control plane 112 may identify what permitted operations have been agreed to and / or provided by the Service B control plane 122. In some embodiments, as part of the processing performed at S418, the Service A control plane 112 may perform ID wiring to enable the Service A computing instance 131 and the Service B computing instance 132 to communicate with each other. In some embodiments, as part of the processing performed at S418, the service A control plane 112 may configure the service A computing instance 131 and / or the service B computing instance 132 to indicate the connection.

[0116] At this point, both control planes have agreed to the connection and are performing operations to complete the connection, such as storing information associated with the connection and modifying certain permissions, ownership, and configurations. The Service B control plane 122 (i.e., the passive control plane) has granted control and ownership of the Service B computing instance 132 (i.e., the passive computing instance) to the Service A control plane 112 (i.e., the dominant control plane). As a result, the Service A control plane 112 (i.e., the dominant control plane) now has control and ownership of both the Service A computing instance 131 (i.e., the dominant computing instance) and the Service B computing instance 132 (i.e., the passive computing instance). Both the Service A computing instance 131 and the connected Service B computing instance 132 continue to exist within the customer tenant 130.

[0117] In S420, which may be the same as or similar to step S220 of Figure 2, the service A control plane workflow 114 can send a completion message indicating that the connection was successfully established (or if it failed) back to the service A control plane front end 113. Then, in S422, which may be the same as or similar to step S222 of Figure 2, the service A control plane front end 113 can send a completion message indicating that the connection was successfully established (or if it failed) back to the user 105 (e.g., via a user device such as the console 106).

[0118] As a result of the process shown in FIG. 4, two computing instances from two different services running on two different service tenants, which would normally be separate and independent with no dependencies or connections, can be connected and able to communicate with each other as desired by user 105.

[0119] FIG. 5 illustrates a simplified swim chart 500 showing the process of connecting two computing instances within a customer tenant, according to one embodiment, where a dominant instance does not yet exist and is created as part of the process. The process illustrated in FIG. 5 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device). The method illustrated in FIG. 5 and described below is intended to be exemplary and non-limiting. While FIG. 5 illustrates various process operations occurring in a particular sequence or order, this is not intended to be limiting. In an alternative embodiment, the process may be performed in some different order, or some steps may be performed in parallel.

[0120] Swim chart 500 illustrates the process of connecting two computing instances. The process illustrated in Figure 5 assumes that the passive instance being connected already exists before receiving the connection request, and that the dominant instance being connected does not yet exist before receiving the connection request. For example, the passive computing instance being connected may be pre-created before receiving the connection request, but the dominant computing instance being connected is not created before receiving the connection request.

[0121] For example, in the embodiment shown in FIG. 1 , user 105 may send (e.g., via console 106) an instruction to service B control plane 122 to create a second computing instance of service B. In response to receiving the user instruction, service B control plane 122 may create and configure service B computing instance 132 (e.g., an instance of the second service) within the user's customer tenant 130. Service B control plane 122 may continue to control and manage service B computing instance 132. However, user 105 may not have sent an instruction to service A's control plane front end 113 to create a first computing instance of service A, and thus service A computing instance 131 (e.g., an instance of the first service) may not yet exist within the user's customer tenant 130.

[0122] As shown in FIG. 5, the process may begin at S502 when a user 105 using a user device (e.g., console 106) sends a request to the Service A control plane 112 to connect a Service A computing instance 131 and a Service B computing instance 132 within the user's customer tenant 130, which may be the same as or similar to step S202 of FIG. 2.

[0123] After receiving the connection request, the dominant control plane can initiate a process to determine whether the connection request can be performed. For example, a process may be performed to determine whether the user requesting the connection is authorized for such a request. In one implementation, the identity management and authorization service 140 can perform the process for authorization. Thus, in S504, which may be the same as or similar to step S204 of FIG. 2, the dominant control plane (in this example, the Service A control plane 112) can send the identity management and authorization service 140 information related to the request received in S502. The identity management and authorization service 140 can then initiate the authorization process. If the authorization is successful (i.e., the user can request a connection between two computing instances), then, as part of S504, the identity management and authorization service 140 can send a response back to the dominant control plane (i.e., the Service A control plane 112) providing authorization to continue the connection process. In some embodiments, the response sent by the identity management and authorization service 140 to the Service A control plane 112 may include an On-Behalf-Of (OBO) token.

[0124] In implementations using asynchronous processing, in S506, which may be the same as or similar to step S206 of Figure 2, the Service A control plane front end 113 creates an asynchronous work request to perform the processing and provides a work request identifier to the user device (e.g., the console 106). The user device (e.g., the console 106) can request an update on the status of the connection processing by sending the work request ID.

[0125] 2, after completing the identity management and authorization processing of step S504, Service A control plane front end 113 instructs Service A control plane workflow 114 component to initiate a workflow to create the connection. In some embodiments, Service A control plane front end 113 can provide an OBO token to Service A control plane workflow 114 for use in communicating with Service B control plane 122 to create the connection.

[0126] At S509-A, the Service A control plane workflow 114 determines that a Service A computing instance 131 (e.g., an instance of the first service) does not exist in the user's customer tenant 130. Therefore, it is determined to create a computing instance 131 of Service A before the connection can be created.

[0127] At S509-B, the Service A control plane workflow 114 creates and configures a Service A computing instance 131 (e.g., an instance of a first service) within the user's customer tenant 130. The Service A control plane 112 can continue to control and manage the Service A computing instance 131. After the Service A computing instance 131 is created, the Service A control plane 112 can continue the process of connecting the two computing instances.

[0128] At S510, which may be the same as or similar to step S210 of FIG. 2, the Service A control plane workflow 114 (i.e., the dominant control plane) sends a connection request to the Service B control plane 122 (i.e., the passive control plane). The connection request notifies the Service B control plane 122 that a computing instance owned by the Service B control plane 122 is connected to another computing instance owned by the dominant control plane (i.e., the Service A control plane 122). The connection request message includes a payload of any appropriate information associated with the connection. For example, the connection request may include identity / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, the OBO token received by the Service A control plane 112 at S504 may be included in the request sent at S510. Additionally, the connection request may indicate the instances to be connected (e.g., the Service A computing instance 131 and the Service B computing instance 132). Compute instances can be identified using an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifier (OCID). Furthermore, connection requests can indicate the IDs of the dominant and passive control planes as well as the IDs of the corresponding dominant and passive control planes.

[0129] Furthermore, in some embodiments, the connection imposes restrictions on the operations that (a) the customer and (b) the passive control plane can perform on the passive computing instance. In some implementations, the connection request sent at S510 may include information indicating these restrictions. For example, the request may identify, for each customer and passive control plane, a list of one or more operations that the connection allows or does not allow on the passive computing instance by the customer and / or the passive control plane. The request may identify a list of one or more operations that the connection allows or does not allow on the passive computing instance by the customer. In some implementations, a list of allowed operations is provided for each customer and passive service control plane. Operations not specifically specified in the list are not allowed while the connection exists. In some embodiments, the operation to delete the passive computing instance (e.g., service B computing instance 132) may no longer be included in the customer's new list of allowed operations. In some embodiments, the operation to delete the connection may be allowed only for the owner, not for the customer.

[0130] At S512, which may be the same as or similar to step S212 of FIG. 2, the Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving the connection request. This may include storing (also referred to as “posting”) details of the connection request received from the Service A control plane 112 (i.e., the dominant control plane) in a record to persist the connection information and modifying the ownership and permitted operations associated with the Service B computing instance 132 (i.e., the passive computing instance). In some embodiments, the Service B control plane 122 may verify that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, the Service B control plane 122 may verify the authenticity of the OBO token and / or the permissions associated with the OBO token. In some embodiments, as part of S512, the Service B control plane 122 may modify and configure the Service B computing instance 132 in the customer tenant 130 to indicate that the connection exists.

[0131] 2, the Service B control plane 122 sends a connection response to the Service A control plane 112 indicating that the connection will be handled by the Service B control plane 122. The connection response message may inform the Service A control plane 112 that the connection details will be confirmed and implemented according to the connection request message sent in step S510.

[0132] Optionally, in S516, which may be the same as or similar to step S216 of FIG. 2, the Service A control plane 112 (i.e., the dominant control plane) may send instructions to the Service B control plane 122 (i.e., the passive control plane) to configure and / or update the Service B computing instance 132 in the customer tenant 130. For example, depending on the type of computing instance, the Service A control plane 112 may install functionality in the Service B computing instance 132 (e.g., skills for a chatbot computing instance) that enables communication between the Service B computing instance 132 and the Service A computing instance 131.

[0133] At S518, which may be the same as or similar to step S218 of FIG. 2, the Service A control plane 112 (i.e., the dominant control plane) performs processing to connect the computing instances in response to receiving the connection response from the Service B control plane 122 (i.e., the passive control plane). For example, the Service A control plane 112 may store any appropriate information in a record to maintain the connection information in the dominant control plane. This may include storing the compartment ID (e.g., within the customer tenant 130) of the Service B computing instance 132 indicated by the Service B control plane 122. Additionally, the Service A control plane 112 may identify what permitted operations have been agreed to and / or provided by the Service B control plane 122. In some embodiments, as part of the processing performed at S518, the Service A control plane 112 may perform ID wiring to enable the Service A computing instance 131 and the Service B computing instance 132 to communicate with each other. In some embodiments, as part of the processing performed at S518, the service A control plane 112 may configure the service A computing instance 131 and / or the service B computing instance 132 to indicate the connection.

[0134] At this point, both control planes agree to the connection and perform operations to complete the connection, such as storing information related to the connection and modifying certain permissions, ownership, and configurations. The Service B control plane 122 (i.e., the passive control plane) has granted control and ownership of the Service B computing instance 132 (i.e., the passive computing instance) to the Service A control plane 112 (i.e., the dominant control plane). As a result, the Service A control plane 112 (i.e., the dominant control plane) now has control and ownership of both the Service A computing instance 131 (i.e., the dominant computing instance) and the Service B computing instance 132 (i.e., the passive computing instance). Both the Service A computing instance 131 and the connected Service B computing instance 132 continue to exist within the customer tenant 130.

[0135] In S520, which may be the same as or similar to step S220 of Figure 2, the service A control plane workflow 114 can send a completion message indicating that the connection was successfully established (or if it failed) back to the service A control plane front end 113. Then, in S522, which may be the same as or similar to step S222 of Figure 2, the service A control plane front end 113 can send a completion message indicating that the connection was successfully established (or if it failed) back to the user 105 (e.g., via a user device such as the console 106).

[0136] As a result of the process shown in FIG. 5, two computing instances from two different services running on two different service tenants, which would normally be separate and independent and have no dependencies or connections, can be connected and able to communicate with each other as desired by user 105.

[0137] FIG. 6 shows a simplified swim chart 600 illustrating the process of connecting two computing instances within a customer tenant, according to one embodiment, where both computing instances do not yet exist and are created as part of the process. The process shown in FIG. 6 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device). The method shown in FIG. 6 and described below is intended to be exemplary and non-limiting. While FIG. 6 depicts various processing operations occurring in a particular sequence or order, this is not intended to be limiting. In an alternative embodiment, the process may be performed in some different order, or some steps may be performed in parallel.

[0138] Swim chart 600 illustrates the process of connecting two computing instances. The process illustrated in Figure 6 assumes that the dominant computing instance to be connected does not exist before receiving the connection request, and that the passive computing instance to be connected does not exist before receiving the connection request. For example, both the dominant computing instance and the passive computing instance to be connected have not been created before receiving the connection request.

[0139] 1, user 105 may not have sent an instruction to service A control plane front end 113 (e.g., via console 106) to create a first computing instance of service A, and thus service A computing instance 131 (e.g., an instance of the first service) may not yet exist within the user's customer tenant 130. Also, user 105 may not have sent an instruction to service B control plane 122 to create a second computing instance of service B, and thus service B computing instance 132 (e.g., an instance of the second service) may not yet exist within the user's customer tenant 130.

[0140] As shown in FIG. 6, the process may begin at S602 when a user 105 using a user device (e.g., console 106) sends a request to the Service A control plane 112 to connect a Service A computing instance 131 and a Service B computing instance 132 within the user's customer tenant 130, which may be the same as or similar to step S202 of FIG. 2.

[0141] After receiving the connection request, the dominant control plane may initiate a process to determine whether the connection request can be performed. For example, a process may be performed to determine whether the user requesting the connection is authorized for such a request. In some implementations, the identity management and authorization service 140 may perform the process for authorization. Thus, in S604, which may be the same as or similar to step S204 of FIG. 2, the dominant control plane (in this example, the Service A control plane 112) may send the identity management and authorization service 140 information related to the request received in S602. The identity management and authorization service 140 may then initiate the authorization process. If the authorization is successful (i.e., the user is allowed to request a connection between two computing instances), as part of S604, the identity management and authorization service 140 may send a response back to the dominant control plane (i.e., the Service A control plane 112) providing authorization to continue the connection process. In some embodiments, the response sent by the identity management and authorization service 140 to the Service A control plane 112 may include an On-Behalf-Of (OBO) token.

[0142] In implementations using asynchronous processing, in S606, which may be the same as or similar to step S206 of Figure 2, the Service A control plane front end 113 creates an asynchronous work request to perform the processing and provides a work request identifier to the user device (e.g., the console 106). The user device (e.g., the console 106) can request an update on the status of the connection processing by sending the work request ID.

[0143] 2, after the identity management and authorization processing of step S604 is completed, Service A control plane front end 113 instructs Service A control plane workflow 114 component to initiate a workflow to create the connection. In some embodiments, Service A control plane front end 113 can provide an OBO token to Service A control plane workflow 114 for use in communicating with Service B control plane 122 to create the connection.

[0144] At S609-A, the service A control plane workflow 114 determines that both the service A computing instance 131 (e.g., an instance of a first service) and the service B computing instance 132 (e.g., an instance of a second service) do not exist within the user's customer tenant 130. Therefore, it is determined to create the service A computing instance 131 and the service B computing instance 132 before the connection can be created.

[0145] At S609-B, the Service A control plane workflow 114 creates and configures a Service A computing instance 131 (e.g., an instance of a first service) within the user's customer tenant 130. The Service A control plane 112 can continue to control and manage the Service A computing instance 131.

[0146] At S609-C, the Service A control plane workflow 114 sends a request to the Service B control plane 122 (i.e., the passive control plane) to create a Service B computing instance 132 (e.g., an incarnation of a second service) within the user's customer tenant 130. The creation request includes a payload of any appropriate information related to the creation. For example, the creation request may include identity / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the computing instance. For example, the OBO token received by the Service A control plane 112 at S604 may be included in the request sent at S609C.

[0147] At S609-D, Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving the creation request. This may include creating and configuring Service B computing instance 132 (e.g., an incarnation of a second service) within the user's customer tenant 130. Service B control plane 122 may continue to control and manage Service B computing instance 132. Service B control plane 122 may then send a creation response to Service A control plane 112 indicating that the computing instance is created within the user's customer tenant 130. The response message may inform Service A control plane 112 of the instance identifier (e.g., OCID) of Service B computing instance 132 and any other appropriate information. After Service A computing instance 131 and Service B computing instance 132 are created, Service A control plane 112 may continue the process of connecting the two computing instances.

[0148] At S610, which may be the same as or similar to step S210 of FIG. 2, the Service A control plane workflow 114 (i.e., the dominant control plane) sends a connection request to the Service B control plane 122 (i.e., the passive control plane). The connection request notifies the Service B control plane 122 that a computing instance owned by the Service B control plane 122 is connected to another computing instance owned by the dominant control plane (i.e., the Service A control plane 122). The connection request message includes a payload of any appropriate information associated with the connection. For example, the connection request may include identity / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, the OBO token received by the Service A control plane 112 at S604 may be included in the request sent at S610. Additionally, the connection request may indicate the instances to be connected (e.g., the Service A computing instance 131 and the Service B computing instance 132). Compute instances can be identified using an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifier (OCID). Furthermore, connection requests can indicate the IDs of the dominant and passive control planes as well as the IDs of the corresponding dominant and passive control planes.

[0149] Further, in some embodiments, the connection imposes restrictions on the operations that (a) the customer and (b) the passive control plane can perform on the passive computing instance. In some implementations, the connection request sent at S610 may include information indicating these restrictions. For example, the request may identify, for each customer and passive control plane, a list of one or more operations that the connection allows or does not allow on the passive computing instance by the customer and / or the passive control plane. The request may identify a list of one or more operations that the connection allows or does not allow on the passive computing instance by the customer. In some implementations, a list of allowed operations is provided for each customer and passive service control plane. Operations not specifically specified in the list are not allowed while the connection exists. In some embodiments, the operation to delete the passive computing instance (e.g., service B computing instance 132) may no longer be included in the customer's new list of allowed operations. In some embodiments, the operation to delete the connection may be allowed only for the owner, not for the customer.

[0150] At S612, which may be the same as or similar to step S212 of FIG. 2, the Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving the connection request. This may include storing (also referred to as “posting”) details of the connection request received from the Service A control plane 112 (i.e., the dominant control plane) in a record to persist the connection information and modifying the ownership and permitted operations associated with the Service B computing instance 132 (i.e., the passive computing instance). In some embodiments, the Service B control plane 122 may verify that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, the Service B control plane 122 may verify the authenticity of the OBO token and / or the permissions associated with the OBO token. In some embodiments, as part of S612, the Service B control plane 122 may modify and configure the Service B computing instance 132 in the customer tenant 130 to indicate that the connection exists.

[0151] 2, the Service B control plane 122 sends a connection response to the Service A control plane 112 indicating that the connection will be handled by the Service B control plane 122. The connection response message may inform the Service A control plane 112 that the connection details will be confirmed and implemented according to the connection request message sent in step S610.

[0152] 2, the Service A control plane 112 (i.e., the dominant control plane) may send instructions to the Service B control plane 122 (i.e., the passive control plane) to configure and / or update the Service B computing instance 132 in the customer tenant 130. For example, depending on the type of computing instance, the Service A control plane 112 may install functionality (e.g., skills for a chatbot computing instance) in the Service B computing instance 132 that enables communication between the Service B computing instance 132 and the Service A computing instance 131.

[0153] At S618, which may be the same as or similar to step S218 of FIG. 2, the Service A control plane 112 (i.e., the dominant control plane) performs processing to connect the computing instances in response to receiving the connection response from the Service B control plane 122 (i.e., the passive control plane). For example, the Service A control plane 112 may store any appropriate information in a record to maintain the connection information in the dominant control plane. This may include storing the compartment ID (e.g., within the customer tenant 130) of the Service B computing instance 132 indicated by the Service B control plane 122. Additionally, the Service A control plane 112 may identify what permitted operations have been agreed to and / or provided by the Service B control plane 122. In some embodiments, as part of the processing performed at S618, the Service A control plane 112 may perform ID wiring to enable the Service A computing instance 131 and the Service B computing instance 132 to communicate with each other. In some embodiments, as part of the processing performed at S618, the service A control plane 112 may configure the service A computing instance 131 and / or the service B computing instance 132 to indicate the connection.

[0154] At this point, both control planes agree to the connection and perform operations to complete the connection, such as storing information related to the connection and modifying certain permissions, ownership, and configurations. The Service B control plane 122 (i.e., the passive control plane) has granted control and ownership of the Service B computing instance 132 (i.e., the passive computing instance) to the Service A control plane 112 (i.e., the dominant control plane). As a result, the Service A control plane 112 (i.e., the dominant control plane) now has control and ownership of both the Service A computing instance 131 (i.e., the dominant computing instance) and the Service B computing instance 132 (i.e., the passive computing instance). Both the Service A computing instance 131 and the connected Service B computing instance 132 continue to exist within the customer tenant 130.

[0155] 2, the service A control plane workflow 114 can send a completion message indicating that the connection was successfully established (or if it failed) back to the service A control plane front end 113. Then, in S622, which can be the same as or similar to step S222 of FIG. 2, the service A control plane front end 113 can send a completion message indicating that the connection was successfully established (or if it failed) back to the user 105 (e.g., via a user device such as the console 106).

[0156] As a result of the process shown in FIG. 6, two computing instances from two different services running on two different service tenants, which are typically separate and independent, can connect and communicate with each other as desired by user 105 without any dependency or connection.

[0157] In some embodiments, the embedded computing instances may be automatically connected without user instruction or involvement. For example, the process shown in FIG. 2 may be performed without step S202. In other words, the Service B computing instance 132 may automatically auto-connect to the Service A computing instance 131 without a specific user request. This auto-connect process may occur in embodiments in which the Service B control plane 122 and / or the Service B computing instance 132 are hidden from a user device (e.g., the console 106), such that the user device (e.g., the console 106) cannot view or access the Service B control plane 122 and / or the Service B computing instance 132. In this case, the Service B computing instance 132 may be created outside of the user's customer tenant 130, but instead may be created within the Service B control plane 122.

[0158] As mentioned above, in some embodiments, the connection places restrictions on the operations that can be performed on the passive computing instance.

[0159] FIG. 7 illustrates a process 700 for determining whether an operation is permitted, according to one embodiment. The process illustrated in FIG. 7 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems, using hardware, or a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device). The method illustrated in FIG. 7 and described below is intended to be exemplary and non-limiting. While FIG. 7 depicts various processing operations occurring in a particular sequence or order, this is not intended to be limiting. In an alternative embodiment, the process may be performed in some different order, or some steps may be performed in parallel. The process described in FIG. 7 assumes that Service A computing instance 131 is the dominant computing instance and that Service B computing instance 132, connected to Service A computing instance 131, is the passive computing instance. Therefore, Service A control plane 112 is the dominant control plane, and Service B control plane 122 is the passive control plane.

[0160] 1 , a user 105 outside of the dominant control plane may wish to perform an operation on a passive instance (e.g., service B computing instance 132) within customer tenant 130. As an example, user 105 may wish to delete a passive instance (e.g., service B computing instance 132) within customer tenant 130. Thus, a user device (e.g., console 106) may transmit a request to perform an operation (e.g., delete) on the passive instance (e.g., service B computing instance 132).

[0161] In some embodiments, this request is received by the service control plane that owns the passive instance (e.g., Service B computing instance 132). As described above, the connection allows the owner of the passive instance (e.g., Service B computing instance 132) to become the dominant control plane (e.g., Service A control plane 112).

[0162] 7 begins in step S705 when a dominant control plane (e.g., Service A control plane 112) receives a request to perform an operation on a passive instance (e.g., Service B computing instance 132) in customer tenant 130. By way of example, the request is a delete request to delete a passive instance (e.g., Service B computing instance 132) in customer tenant 130. After receiving the request, the dominant control plane (e.g., Service A control plane 112) calls IDMAS 140 to perform several checks to determine whether the operation is allowed.

[0163] The passive instance (e.g., Service B computing instance 132) is within customer tenant 130 and is also owned by a dominant tenant (e.g., Service A tenant 115) because the dominant control plane (e.g., Service A control plane 112) owns the connected passive instance. A first authorization check is performed to verify whether the requested operation on the passive instance (e.g., Service B computing instance 132) is allowed based on policies associated with the customer tenant 130. Thus, in step S710, the dominant control plane (e.g., Service A control plane 112) invokes IDMAS 140, which determines whether the requested operation (e.g., deleting the passive instance) is authorized based on policies and permissions associated with or configured for the customer compartment.

[0164] In one implementation, as part of the processing of S710, a customer tenant compartment identifier associated with a passive computing instance (e.g., Service B computing instance 132) is used to identify a particular customer tenant compartment and one or more policies associated with that compartment. The policies are then evaluated to determine whether the requested operation is authorized by the compartment policies. For example, a compartment in a user's customer tenant 130 may have associated with it one or more policies that identify a list of authorized operations that can be performed on computing instances in that compartment. If the requested operation is specified as a permitted operation in the list of authorized operations, the requested operation is considered authorized; otherwise, it is considered unauthorized.

[0165] In some embodiments, customer tenant 130 may include a hierarchy of nodes representing compartments, which may be represented by a hierarchical tree with a root compartment at the top of the tree. In some implementations, the hierarchy may represent a containment relationship. In such implementations, one or more policies may be associated with each compartment in the hierarchy. The processing performed by IDMAS 140 at S710 may include first identifying a particular compartment in the hierarchy that contains a passive instance (e.g., Service B computing instance 132) and identifying any policies associated with that compartment. Next, starting from the particular compartment that contains the passive instance (e.g., Service B computing instance 132), the hierarchical tree is walked up to the root compartment node. All policies associated with compartments included in the walk up to the root compartment are determined. As part of the processing of S710, one or more policies (if any) associated with the particular compartment containing the passive instance (e.g., Service B computing instance 132), as well as policies identified by walking / traversing the hierarchy tree from the particular compartment to the root compartment, are analyzed to determine whether the action requested in the request received in S705 is authorized.

[0166] This allows IDMAS 140 to determine whether the requested action (e.g., deleting a passive instance) is authorized or permitted and send a response to the dominant control plane (e.g., Service A control plane 112) with the result.

[0167] If the dominant control plane (e.g., Service A control plane 112) is informed that the requested operation (e.g., removing a passive instance) is authorized or permitted (i.e., the authorization check is passed), the dominant control plane (e.g., Service A control plane 112) may proceed to step S715 for further processing. If the dominant control plane (e.g., Service A control plane 112) is informed that the requested operation (e.g., removing a passive instance) is not permitted (i.e., the authorization check failed), then the dominant control plane (e.g., Service A control plane 112) may deny performance of the operation in step S712, and the process may end with the request to perform the operation being denied.

[0168] In step S715, the dominant control plane (e.g., Service A control plane 112) determines whether the passive instance (e.g., Service B computing instance 132) is connected to another computing instance. If so, additional authorization checks are performed.

[0169] Thus, if the dominant control plane (e.g., Service A control plane 112) determines in S715 that the passive instance (e.g., Service B computing instance 132) is part of a connection, i.e., connected to another computing instance, then processing proceeds to S720, where additional checks are performed. If the dominant control plane (e.g., Service A control plane 112) determines in S715 that no connection exists between the passive instance and another computing instance (i.e., the passive instance is not involved in a connection), then processing proceeds to S717, where the requested operation is allowed to be performed on the passive instance (e.g., Service B computing instance 132), and processing ends. For example, if the requested operation is to delete the passive instance, the passive instance is deleted.

[0170] Thus, in step S720, the dominant control plane (e.g., Service A control plane 112) determines whether the requested operation (e.g., delete a passive instance) is restricted based on a stored list of allowed customer operations associated with the connection. These allowed customer operations may be stored in the dominant control plane (e.g., Service A control plane 112) and / or the passive control plane (e.g., Service B control plane 122) associated with the connection. The allowed customer operation list may be referred to as a dual authorization list. This is because if an operation is included in the list, it is a restricted operation that requires dual authorization. If the operation is not included in the list, dual authorization is not required, and it is not a restricted operation, and the initial authorization (e.g., step S710) is deemed sufficient. To check the list, the dominant control plane (e.g., Service A control plane 112) calls the passive control plane (e.g., Service B control plane 122), which then checks the list of operations and returns the result to the dominant control plane (e.g., Service A control plane 112).

[0171] If the dominant control plane (e.g., Service A control plane 112) is notified by the passive control plane (e.g., Service B control plane 122) at S720 that the operation is included in the list and therefore is a restricted operation, then processing proceeds to S725, where additional checks are performed. If the dominant control plane (e.g., Service A control plane 112) is notified by the passive control plane (e.g., Service B control plane 122) at S720 that the operation is not included in the list and therefore is not a restricted operation, processing proceeds to S717, where the requested operation is permitted to be performed on the passive instance (e.g., Service B computing instance 132), and processing ends. For example, if the requested operation is to delete the passive instance, the passive instance is deleted.

[0172] As described above, a connected passive instance (e.g., Service B computing instance 132) that resides in both customer tenants 130 is also owned by the dominant tenant (e.g., Service A tenant 115). Processing is then performed to determine whether the requesting user is authorized to perform the requested operation on the passive instance (e.g., Service B computing instance 132) based on policies associated with the dominant tenant (e.g., Service A tenant 115).

[0173] Thus, in step S725, the dominant control plane (e.g., Service A control plane 112) invokes IDMAS 140, which determines whether the requested operation (e.g., deleting the passive instance) is permitted or authorized based on policies associated with the dominant tenant (e.g., Service A tenant 115) or based on connection-related metadata stored for the dominant tenant or control plane that identifies the authorized operations on the passive instance (e.g., Service B computing instance 132).

[0174] For example, as described above, when a connection is made, both the dominant control plane (e.g., Service A control plane 112) and the passive control plane (e.g., Service B control plane 122) maintain or store information about the connection (e.g., information about the connection between the dominant and passive instances). This stored information or record may include a list of operations that the customer is allowed to perform on the passive computing instance and a list of operations that the owner (e.g., the dominant control plane) is allowed to perform on the passive computing instance while the connection exists. If an operation is not included in this list, the operation is not allowed and cannot be performed by the requesting user. In one implementation, information identifying the allowed list of operations may be stored in the form of an access control list (ACL) that describes what access rights users have to resources.

[0175] As part of S725, IDMAS 140 checks whether the operation requested by the requesting user to be performed on the passive computing instance is included in a permission list of operations based on information stored by the dominant control plane. For example, in the embodiment shown in Figure 1, IDMAS 140 checks whether the operation requested by the requesting user on the passive instance (e.g., service B computing instance 132) is included in a permission list of operations that the owner (e.g., dominant control plane) can perform based on information stored by the dominant control plane (e.g., service A control plane 112).

[0176] IDMAS 140 may then perform a second authorization to determine whether the requested operation (e.g., deleting a passive instance) is authorized or permitted based on the policy associated with the dominant tenant (e.g., Service A tenant 115). IDMAS 140 may then send a response with the results of the second authorization to the dominant control plane (e.g., Service A control plane 112).

[0177] The dominant control plane (e.g., service A control plane 112) is notified that the requested operation (e.g., deleting the passive instance) is authorized based on the connection-related information stored by the dominant control plane and / or the list of authorized operations in the ACL, after which processing proceeds to S730, where the requested operation is permitted to execute on the passive instance (e.g., service B computing instance 132), and processing ends. For example, if the requested operation is to delete the passive instance, the passive instance is deleted.

[0178] If the dominant control plane (e.g., Service A control plane 112) is notified that the requested operation (e.g., deleting a passive instance) is not in the list of authorized operations indicated in the connection-related information stored by the dominant control plane and / or an ACL associated with the dominant control plane, then the dominant control plane (e.g., Service A control plane 112) may refuse to perform the operation in step S727, and the process may end with the request to perform the operation being denied.

[0179] In some embodiments, the steps of Figure 7 may be intentionally designed to prevent certain operations from occurring while a connection exists. For example, a connection may place a passive instance (e.g., Service B computing instance 132) under the ownership of a dominant control plane (e.g., Service A control plane 112), but it may be undesirable to allow the dominant control plane (e.g., Service A control plane 112) to perform one or more operations. One way to prevent the dominant control plane (e.g., Service A control plane 112) from performing certain operations on a passive instance (e.g., Service B computing instance 132) is to include a list of explicitly disallowed operations. However, current systems use lists of allowed operations (operations not listed are not allowed), and it is preferable to work with these existing frameworks. Therefore, a tiering policy may be utilized, as described above with respect to Figure 7. A first policy may allow the operation (e.g., the customer compartment policy in step S710), but if a connection exists, a second policy will be checked, and the second policy may not allow the operation (e.g., the owner compartment policy in step S725). The owner compartment policy can be designed to include a limited set of operations such that certain operation requests will fail (e.g., when checking the owner compartment policy in step S725). For example, it may be desirable to prohibit a delete operation, such that a request to delete a passive instance (e.g., Service B computing instance 132) would fail in step S725.

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

[0181] 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, and managing disaster recovery.

[0182] In most cases, the cloud computing model requires the participation of a cloud provider, which can be, but does not have to be, a third-party service that specializes in providing IaaS (e.g., providing, renting, selling). Enterprises can also choose to deploy private clouds and become their own infrastructure service providers.

[0183] In some examples, IaaS deployment is the process of placing a new application, or a new version of an application, onto a provisioned application server, etc. This 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., servers, storage, network hardware, and virtualization). Thus, the customer may be responsible for the processing (OS), middleware, and / or application deployment (e.g., self-service virtual machines (e.g., that can be spun up on demand)).

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

[0185] In some cases, IaaS provisioning presents two distinct challenges. First, there is the initial challenge of provisioning the initial set of infrastructure before anything can run. Second, there is the challenge of evolving the existing infrastructure after everything has been provisioned (e.g., adding new services, changing services, removing services, etc.). 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 resources and how they work together) can be described declaratively. In some cases, once the topology is defined, workflows can be generated to create and / or manage the various components described in the configuration files.

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

[0187] In some cases, continuous deployment techniques can be used to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques can enable infrastructure management within these environments. In some examples, a service team may write code that it is desirable to deploy to one or more, but often many, different production environments (e.g., across various different geographic locations, possibly spanning the entire world). However, in some examples, it is necessary to first set up the infrastructure onto which the code will be deployed. In some cases, provisioning can be done manually, and provisioning tools can be utilized to provision resources and / or deployment tools can be utilized to deploy the code after the infrastructure has been provisioned.

[0188] FIG. 8 is a block diagram 800 illustrating an example IaaS architecture pattern, according to at least one embodiment. A service operator 802 can be communicatively coupled to a secure host tenant 804, which can include a virtual cloud network (VCN) 806 and a secure host subnet 808. In some examples, the service operator 802 can employ one or more client computing devices, which can be portable handheld devices (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass® head-mounted display), running software such as Microsoft Windows Mobile®, and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and internet, email, short message service (SMS), Blackberry®, or other enabled communication protocols. Alternatively, the client computing devices can be general-purpose personal computers, including, for example, personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. The client computing device may be a workstation computer running any of a variety of commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS.Alternatively, or in addition, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox game console with or without a Kinect® gesture input device), and / or a personal messaging device capable of communicating over a network with access to VCN 806 and / or the Internet.

[0189] VCN 806 may include a local peering gateway (LPG) 810 that may be communicatively coupled to a secure shell (SSH) VCN 812 via an LPG 810 included in SSH VCN 812. SSH VCN 812 may include an SSH subnet 814, which may be communicatively coupled to a control plane VCN 816 via an LPG 810 included in the control plane VCN 816. SSH VCN 812 may also be communicatively coupled to a data plane VCN 818 via LPG 810. The control plane VCN 816 and the data plane VCN 818 may be included in a service tenant 819, which may be owned and / or operated by the IaaS provider.

[0190] The control plane VCN 816 may include a control plane demilitarized zone (DMZ) tier 820 that functions as a perimeter network (e.g., a portion of an enterprise network between the enterprise intranet and an external network). DMZ-based servers have limited responsibility and may help prevent breaches. Additionally, the DMZ tier 820 may include one or more load balancer (LB) subnets 822, a control plane app tier 824 that may include an app subnet 826, and a control plane data tier 828 that may include a database (DB) subnet 830 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 822 included in the control plane DMZ tier 820 may be communicatively coupled to the app subnet 826 included in the control plane app tier 824 and an Internet gateway 834 that may be included in the control plane VCN 816, and the app subnet 826 may be communicatively coupled to the DB subnet 830, a service gateway 836, and a network address translation (NAT) gateway 838 that are included in the control plane data tier 828. The control plane VCN 816 may include a service gateway 836 and a NAT gateway 838 .

[0191] The control plane VCN 816 can include a data plane mirrored app layer 840, which can include an app subnet 826. The app subnet 826 included in the data plane mirrored app layer 840 can include a virtual network interface controller (VNIC) 842 on which a compute instance 844 can run. The compute instance 844 can communicatively couple the app subnet 826 of the data plane mirrored app layer 840 to the app subnet 826, which can be included in the data plane app layer 846.

[0192] Data plane VCN 818 may include a data plane app layer 846, a data plane DMZ layer 848, and a data plane data layer 850. Data plane DMZ layer 848 may include a LB subnet 822, which may be communicatively coupled to an app subnet 826 of the data plane app layer 846 and an internet gateway 834 of the data plane VCN 818. App subnet 826 may be communicatively coupled to a service gateway 836 of the data plane VCN 818 and a NAT gateway 838 of the data plane VCN 818. Data plane data layer 850 may also include a DB subnet 830, which may be communicatively coupled to the app subnet 826 of the data plane app layer 846.

[0193] The internet gateways 834 of the control plane VCNs 816 and data plane VCNs 818 may be communicatively coupled to a metadata management service 852, which may be communicatively coupled to the public internet 854. The public internet 854 may be communicatively coupled to NAT gateways 838 of the control plane VCNs 816 and data plane VCNs 818. The service gateways 836 of the control plane VCNs 816 and data plane VCNs 818 may be communicatively coupled to cloud services 856.

[0194] In some examples, a service gateway 836 in a control plane VCN 816 or a data plane VCN 818 can make application programming interface (API) calls to a cloud service 856 without traversing the public internet 854. An API call from a service gateway 836 to a cloud service 856 can be one-way: the service gateway 836 can make an API call to the cloud service 856, and the cloud service 856 can send the requested data to the service gateway 836. However, the cloud service 856 may not initiate the API call to the service gateway 836.

[0195] In some examples, secure host tenant 804 can be directly connected to service tenant 819 or can be otherwise separate. Secure host subnet 808 can communicate with SSH subnet 814 through LPG 810, which can enable bidirectional communication through otherwise separate systems. Connecting secure host subnet 808 to SSH subnet 814 can give secure host subnet 808 access to other entities within service tenant 819.

[0196] The control plane VCN 816 can enable users of a service tenant 819 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 816 can be deployed or otherwise used in the data plane VCN 818. In some examples, the control plane VCN 816 can be separate from the data plane VCN 818, and the data plane mirror app layer 840 of the control plane VCN 816 can communicate with the data plane app layer 846 of the data plane VCN 818 via a VNIC 842, which can be included in the data plane mirror app layer 840 and the data plane app layer 846.

[0197] In some examples, a user or customer of the system may make a request, such as, for example, a create, read, update, or delete (CRUD) operation, over the public internet 854, which may communicate the request to a metadata management service 852. The metadata management service 852 may communicate the request to the control plane VCN 816 via an internet gateway 834. The request may be received by a LB subnet 822 included in the control plane DMZ tier 820. The LB subnet 822 may determine that the request is valid, and in response to this determination, the LB subnet 822 may send the request to an app subnet 826 included in the control plane app tier 824. If the request is validated and a call to the public internet 854 is required, the call to the public internet 854 may be sent to a NAT gateway 838, which may make the call to the public internet 854. Memory that may be desirable to store with the request may be stored in the DB subnet 830.

[0198] In some examples, the data plane mirror app layer 840 can facilitate direct communication between the control plane VCN 816 and the data plane VCN 818. For example, it may be desirable to apply configuration changes, updates, or other appropriate modifications to resources included in the data plane VCN 818. Via the VNIC 842, the control plane VCN 816 can communicate directly with the resources included in the data plane VCN 818, thereby enabling it to perform configuration changes, updates, or other appropriate modifications to the resources included in the data plane VCN 818.

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

[0200] In another embodiment, the LB subnet 822 included in the control plane VCN 816 may be configured to receive signals from the service gateway 836. In this embodiment, the control plane VCN 816 and the data plane VCN 818 may be configured to be called by the IaaS provider's customers without calling the public internet 854. Customers of the IaaS provider may desire this embodiment because databases used by the customers may be stored in the service tenant 819, which may be controlled by the IaaS provider and isolated from the public internet 854.

[0201] 9 is a block diagram 900 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 902 (e.g., service operator 802 in FIG. 8 ) can be communicatively coupled to a secure host tenant 904 (e.g., secure host tenant 804 in FIG. 8 ) and a secure host subnet 908 (e.g., secure host subnet 808 in FIG. 8 ), which can include a virtual cloud network (VCN) 906 (e.g., VCN 806 in FIG. 8 ). VCN 906 can include a local peering gateway (LPG) 910 (e.g., LPG 810 in FIG. 8 ), which can be communicatively coupled to a secure shell (SSH) VCN 912 (e.g., SSH VCN 812 in FIG. 8 ) via the LPG 810 included in SSH VCN 912. SSH VCN 912 can include an SSH subnet 914 (e.g., SSH subnet 814 in FIG. 8 ), which can be communicatively coupled to a control plane VCN 916 (e.g., control plane VCN 816 in FIG. 8 ) via an LPG 910 included in the control plane VCN 916. The control plane VCN 916 can be included in a service tenant 919 (e.g., service tenant 819 in FIG. 8 ), and the data plane VCN 918 (e.g., data plane VCN 818 in FIG. 8 ) can be included in a customer tenant 921, which can be owned or operated by a user or customer of the system.

[0202] The control plane VCN 916 may include a control plane DMZ layer 920 (e.g., the control plane DMZ layer 820 in FIG. 8 ) that may include a LB subnet 922 (e.g., the LB subnet 822 in FIG. 8 ), a control plane app layer 924 (e.g., the control plane app layer 824 in FIG. 8 ) that may include an app subnet 926 (e.g., the app subnet 826 in FIG. 8 ), and a control plane data layer 928 (e.g., the control plane data layer 828 in FIG. 8 ) that may include a database (DB) subnet 930 (e.g., similar to the DB subnet 830 in FIG. 8 ). The LB subnet 922 included in the control plane DMZ layer 920 can be communicatively coupled to an app subnet 926 included in the control plane app layer 924 and to an Internet gateway 934 (e.g., Internet gateway 834 in FIG. 8 ) that may be included in the control plane VCN 916, and the app subnet 926 can be communicatively coupled to a DB subnet 930 included in the control plane data layer 928, to a service gateway 936 (e.g., service gateway in FIG. 8 ), and to a network address translation (NAT) gateway 938 (e.g., NAT gateway 838 in FIG. 8 ). The control plane VCN 916 can include the service gateway 936 and the NAT gateway 938.

[0203] The control plane VCN 916 can include a data plane mirror app layer 940 (e.g., data plane mirror app layer 840 of FIG. 8 ), which can include an app subnet 926. The app subnet 926 included in the data plane mirror app layer 940 can include a virtual network interface controller (VNIC) 942 (e.g., VNIC 842) on which a computing instance 944 (e.g., similar to computing instance 844 of FIG. 8 ) can run. The computing instance 944 can facilitate communication between the app subnet 926 of the data plane mirror app layer 940 and the app subnet 926, which can be included in the data plane app layer 946 (e.g., data plane app layer 846 of FIG. 8 ), via the VNIC 942 included in the data plane mirror app layer 940 and the VNIC 942 included in the data plane app layer 946.

[0204] An internet gateway 934 included in the control plane VCN 916 can be communicatively coupled to a metadata management service 952 (e.g., metadata management service 852 in FIG. 8 ), which can be communicatively coupled to the public internet 954 (e.g., public internet 854 in FIG. 8 ). The public internet 954 can be communicatively coupled to a NAT gateway 938 included in the control plane VCN 916. A service gateway 936 included in the control plane VCN 916 can be communicatively coupled to cloud services 956 (e.g., cloud services 856 in FIG. 8 ).

[0205] In some examples, the data plane VCN 918 may be included in a customer tenant 921. In this case, the IaaS provider may provide a control plane VCN 916 for each customer, and the IaaS provider may set up a unique compute instance 944 for each customer that is included in the service tenant 919. Each compute instance 944 may enable communication between the control plane VCN 916 included in the service tenant 919 and the data plane VCN 918 included in the customer tenant 921. The compute instance 944 may enable resources provisioned in the control plane VCN 916 included in the service tenant 919 to be deployed or otherwise used in the data plane VCN 918 included in the customer tenant 921.

[0206] In another example, a customer of the IaaS provider may have a database that resides in customer tenant 921. In this example, control plane VCN 916 may include data plane mirror app tier 940, which may include app subnet 926. Data plane mirror app tier 940 may reside in data plane VCN 918, but data plane mirror app tier 940 may not reside in data plane VCN 918. That is, data plane mirror app tier 940 is accessible to customer tenant 921, but data plane mirror app tier 940 may not reside in data plane VCN 918 or be owned or operated by the IaaS provider's customer. Data plane mirror app tier 940 may be configured to make calls to data plane VCN 918, but may not be configured to make calls to any entities included in control plane VCN 916. A customer may desire to deploy or otherwise use resources in data plane VCN 918 that are provisioned in control plane VCN 916, and data plane mirror app tier 940 can facilitate the desired deployment or other use of the customer's resources.

[0207] In some embodiments, the IaaS provider's customer can apply filters to the data plane VCN 918. In this embodiment, the customer can determine what the data plane VCN 918 can access, and the customer can restrict access from the data plane VCN 918 to the public internet 954. The IaaS provider may not be able to apply filters or otherwise control the data plane VCN 918's access to any external networks or databases. Applying customer filters and controls to the data plane VCN 918 contained in the customer tenant 921 can help isolate the data plane VCN 918 from other customers and the public internet 954.

[0208] In some embodiments, cloud services 956 can be called by service gateway 936 to access services that may not reside on the public internet 954, on the control plane VCN 916, or on the data plane VCN 918. The connection between cloud services 956 and the control plane VCN 916 or the data plane VCN 918 may not exist or be continuous. Cloud services 956 may reside on a separate network owned or operated by the IaaS provider. Cloud services 956 may be configured to receive calls from service gateway 936 or may be configured not to receive calls from the public internet 954. Some cloud services 956 may be isolated from other cloud services 956, and control plane VCN 916 may be isolated from cloud services 956 that may not be in the same region as control plane VCN 916. For example, control plane VCN 916 may be located in “Region 1,” and cloud service “Deployment 8” may be located in Region 1 and “Region 2.” If a call to Deployment 8 is made by a service gateway 936 included in a control plane VCN 916 in Region 1, the call may be sent to Deployment 8 in Region 1. In this example, Control Plane VCN 916, and thus Deployment 8 in Region 1, may not be communicatively coupled to or otherwise in communication with Deployment 8 in Region 2.

[0209] 10 is a block diagram 1000 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1002 (e.g., service operator 802 in FIG. 8 ) can be communicatively coupled to a secure host tenant 1004 (e.g., secure host tenant 804 in FIG. 8 ) and a secure host subnet 1008 (e.g., secure host subnet 808 in FIG. 8 ), which can include a virtual cloud network (VCN) 1006 (e.g., VCN 806 in FIG. 8 ). VCN 1006 can include an LPG 1010 (e.g., LPG 810 in FIG. 8 ) that can be communicatively coupled to an SSH VCN 1012 (e.g., SSH VCN 812 in FIG. 8 ) via an LPG 1010 included in SSH VCN 1012. SSH VCN 1012 can include SSH subnet 1014 (e.g., SSH subnet 814 in FIG. 8 ), and SSH VCN 1012 can be communicatively coupled to control plane VCN 1016 (e.g., control plane VCN 816 in FIG. 8 ) via LPG 1010 included in control plane VCN 1016 and to data plane VCN 1018 (e.g., data plane 818 in FIG. 8 ) via LPG 1010 included in data plane VCN 1018. Control plane VCN 1016 and data plane VCN 1018 can be included in service tenant 1019 (e.g., service tenant 819 in FIG. 8 ).

[0210] The control plane VCN 1016 may include a control plane DMZ tier 1020 (e.g., control plane DMZ tier 820 of FIG. 8 ) that may include a load balancer (LB) subnet 1022 (e.g., LB subnet 822 of FIG. 8 ), a control plane app tier 1024 (e.g., control plane app tier 824 of FIG. 8 ) that may include an app subnet 1026 (e.g., similar to app subnet 826 of FIG. 8 ), and a control plane data tier 1028 (e.g., control plane data tier 828 of FIG. 8 ) that may include a DB subnet 1030. The LB subnet 1022 included in the control plane DMZ tier 1020 can be communicatively coupled to an app subnet 1026 included in the control plane app tier 1024 and an Internet gateway 1034 (e.g., Internet gateway 834 in FIG. 8 ) that can be included in the control plane VCN 1016, and the app subnet 1026 can be communicatively coupled to a DB subnet 1030 and a service gateway 1036 (e.g., service gateway in FIG. 8 ) and a network address translation (NAT) gateway 1038 (e.g., NAT gateway 838 in FIG. 8 ) included in the control plane data tier 1028. The control plane VCN 1016 can include the service gateway 1036 and the NAT gateway 1038.

[0211] The data plane VCN 1018 may include a data plane app layer 1046 (e.g., data plane app layer 846 in FIG. 8 ), a data plane DMZ layer 1048 (e.g., data plane DMZ layer 848 in FIG. 8 ), and a data plane data layer 1050 (e.g., data plane data layer 850 in FIG. 8 ). The data plane DMZ layer 1048 may include a LB subnet 1022, which may be communicatively coupled to a trusted app subnet 1060 and an untrusted app subnet 1062 of the data plane app layer 1046 and to an Internet gateway 1034 included in the data plane VCN 1018. The trusted app subnet 1060 may be communicatively coupled to a service gateway 1036 included in the data plane VCN 1018, a NAT gateway 1038 included in the data plane VCN 1018, and a DB subnet 1030 included in the data plane data layer 1050. The untrusted app subnet 1062 can be communicatively coupled to a service gateway 1036 included in the data plane VCN 1018 and a DB subnet 1030 included in the data plane data layer 1050. The data plane data layer 1050 can include a DB subnet 1030 that can be communicatively coupled to a service gateway 1036 included in the data plane VCN 1018.

[0212] The untrusted app subnet 1062 may include one or more primary VNICs 1064(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 1066(1)-(N). Each tenant VM 1066(1)-(N) may be communicatively coupled to a respective app subnet 1067(1)-(N) that may be included in a respective container egress VCN 1068(1)-(N) that may be included in a respective customer tenant 1070(1)-(N). Each secondary VNIC 1072(1)-(N) may facilitate communication between the untrusted app subnet 1062 included in the data plane VCN 1018 and the app subnet included in the container egress VCN 1068(1)-(N). Each container egress VCN 1068(1)-(N) may include a NAT gateway 1038 that may be communicatively coupled to the public internet 1054 (e.g., public internet 854 in FIG. 8 ).

[0213] An internet gateway 1034 included in the control plane VCN 1016 and included in the data plane VCN 1018 can be communicatively coupled to a metadata management service 1052 (e.g., metadata management system 852 of FIG. 8 ), which can be communicatively coupled to the public internet 1054. The public internet 1054 can be communicatively coupled to a NAT gateway 1038 included in the control plane VCN 1016 and included in the data plane VCN 1018. A service gateway 1036 included in the control plane VCN 1016 and included in the data plane VCN 1018 can be communicatively coupled to cloud services 1056.

[0214] In some embodiments, the data plane VCN 1018 can be integrated with a customer tenant 1070. This integration may be beneficial or desirable for the IaaS provider's customer, such as when support is needed for code execution. The customer may provide executable code that may be destructive, communicate with other customer resources, or cause other undesirable effects. In response, the IaaS provider can decide whether to run the code provided to the IaaS provider by the customer.

[0215] In some examples, a customer of an IaaS provider may grant the IaaS provider temporary network access and request a feature to be added to the data plane layer app 1046. The code to perform the feature may run in VMs 1066(1)-(N), and the code may not be configured to run elsewhere on the data plane VCN 1018. Each VM 1066(1)-(N) may be connected to one customer tenant 1070. Each container 1071(1)-(N) included in a VM 1066(1)-(N) may be configured to run code. In this case, double isolation may exist (e.g., a container 1071(1)-(N) running code, and the container 1071(1)-(N) may be included in at least one VM 1066(1)-(N) included in the untrusted app subnet 1062), which may help prevent erroneous or otherwise unwanted code from damaging the IaaS provider's network or damaging another customer's network. Containers 1071(1)-(N) may be communicatively coupled to customer tenants 1070 and may be configured to send or receive data from customer tenants 1070. Containers 1071(1)-(N) may not be configured to send or receive data from any other entities in data plane VCN 1018. Once code execution is complete, the IaaS provider can kill or otherwise discard containers 1071(1)-(N).

[0216] In some embodiments, trusted app subnet 1060 may execute code that may be owned or operated by the IaaS provider. In this embodiment, trusted app subnet 1060 may be communicatively coupled to DB subnet 1030 and configured to perform CRUD operations on DB subnet 1030. Untrusted app subnet 1062 may be communicatively coupled to DB subnet 1030, although in this embodiment, the untrusted app subnet may be configured to perform read operations on DB subnet 1030. Containers 1071(1)-(N) that may be included in each customer's VMs 1066(1)-(N) and that may execute code from the customer may not be communicatively coupled to DB subnet 1030.

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

[0218] 11 is a block diagram 1100 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1102 (e.g., service operator 802 in FIG. 8 ) can be communicatively coupled to a secure host tenant 1104 (e.g., secure host tenant 804 in FIG. 8 ) and a secure host subnet 1108 (e.g., secure host subnet 808 in FIG. 8 ), which can include a virtual cloud network (VCN) 1106 (e.g., VCN 806 in FIG. 8 ). VCN 1106 can include an LPG 1110 (e.g., LPG 810 in FIG. 8 ) that can be communicatively coupled to an SSH VCN 1112 (e.g., SSH VCN 812 in FIG. 8 ) via an LPG 1110 included in SSH VCN 1112. SSH VCN 1112 can include SSH subnet 1114 (e.g., SSH subnet 814 in FIG. 8 ), and SSH VCN 1112 can be communicatively coupled to control plane VCN 1116 (e.g., control plane VCN 816 in FIG. 8 ) via LPG 1110 included in control plane VCN 1116 and to data plane VCN 1118 (e.g., data plane 818 in FIG. 8 ) via LPG 1110 included in data plane VCN 1118. Control plane VCN 1116 and data plane VCN 1118 can be included in service tenant 1119 (e.g., service tenant 819 in FIG. 8 ).

[0219] The control plane VCN 1116 may include a control plane DMZ layer 1120 (e.g., control plane DMZ layer 820 of FIG. 8 ) that may include a LB subnet 1122 (e.g., LB subnet 822 of FIG. 8 ), a control plane app layer 1124 (e.g., control plane app layer 824 of FIG. 8 ) that may include an app subnet 1126 (e.g., app subnet 826 of FIG. 8 ), and a control plane data layer 1128 (e.g., control plane data layer 828 of FIG. 8 ) that may include a DB subnet 1130 (e.g., DB subnet 1030 of FIG. 10 ). The LB subnet 1122 included in the control plane DMZ tier 1120 can be communicatively coupled to an app subnet 1126 included in the control plane app tier 1124 and to an Internet gateway 1134 (e.g., Internet gateway 834 in FIG. 8 ), which can be included in the control plane VCN 1116, and the app subnet 1126 can be communicatively coupled to a DB subnet 1130 included in the control plane data tier 1128, as well as to a service gateway 1136 (e.g., service gateway in FIG. 8 ) and a network address translation (NAT) gateway 1138 (e.g., NAT gateway 838 in FIG. 8 ). The control plane VCN 1116 can include the service gateway 1136 and the NAT gateway 1138.

[0220] Data plane VCN 1118 may include a data plane app layer 1146 (e.g., data plane app layer 846 in FIG. 8 ), a data plane DMZ layer 1148 (e.g., data plane DMZ layer 848 in FIG. 8 ), and a data plane data layer 1150 (e.g., data plane data layer 850 in FIG. 8 ). Data plane DMZ layer 1148 may include a LB subnet 1122, which may be communicatively coupled to a trusted app subnet 1160 (e.g., trusted app subnet 1060 in FIG. 10 ) and an untrusted app subnet 1162 (e.g., untrusted app subnet 1062 in FIG. 10 ) of data plane app layer 1146 and Internet gateway 1134 included in data plane VCN 1118. Trusted app subnet 1160 may be communicatively coupled to a service gateway 1136 included in data plane VCN 1118, a NAT gateway 1138 included in data plane VCN 1118, and a DB subnet 1130 included in data plane data layer 1150. The untrusted app subnet 1162 can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118 and a DB subnet 1130 included in the data plane data layer 1150. The data plane data layer 1150 can include a DB subnet 1130 that can be communicatively coupled to a service gateway 1136 included in the data plane VCN 1118.

[0221] The untrusted app subnet 1162 may include primary VNICs 1164(1)-(N) that can be communicatively coupled to tenant virtual machines (VMs) 1166(1)-(N) residing within the untrusted app subnet 1162. Each tenant VM 1166(1)-(N) can execute code within a respective container 1167(1)-(N) and can be communicatively coupled to an app subnet 1126 that can be included in a data plane app layer 1146 that can be included in a container egress VCN 1168. Each secondary VNIC 1172(1)-(N) can facilitate communication between the untrusted app subnet 1162 included in the data plane VCN 1118 and the app subnet included in the container egress VCN 1168. The container egress VCN may include a NAT gateway 1138 that can be communicatively coupled to the public internet 1154 (e.g., public internet 854 in FIG. 8 ).

[0222] An internet gateway 1134 included in the control plane VCN 1116 and included in the data plane VCN 1118 can be communicatively coupled to a metadata management service 1152 (e.g., metadata management system 852 of FIG. 8 ), which can be communicatively coupled to the public internet 1154. The public internet 1154 can be communicatively coupled to a NAT gateway 1138 included in the control plane VCN 1116 and included in the data plane VCN 1118. A service gateway 1136 included in the control plane VCN 1116 and included in the data plane VCN 1118 can be communicatively coupled to cloud services 1156.

[0223] In some examples, the pattern illustrated by the architecture of block diagram 1100 in FIG. 11 may be considered an exception to the pattern illustrated by the architecture of block diagram 1000 in FIG. 10 and may be desirable for an IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in disconnected areas). Each container 1167(1)-(N) contained in each customer's VM 1166(1)-(N) can be accessed by the customer in real time. The containers 1167(1)-(N) can be configured to make calls to each secondary VNIC 1172(1)-(N) contained in the app subnet 1126 of the data plane app tier 1146, which can be included in the container egress VCN 1168. The secondary VNICs 1172(1)-(N) can send the calls to a NAT gateway 1138, which can send the calls to the public Internet 1154. In this example, containers 1167(1)-(N) that a customer can access in real time can be isolated from control plane VCN 1116 and isolated from other entities included in data plane VCN 1118. Containers 1167(1)-(N) can also be isolated from resources from other customers.

[0224] In another example, a customer can invoke cloud service 1156 using containers 1167(1)-(N). In this example, the customer can execute code within containers 1167(1)-(N) that requests a service from cloud service 1156. Containers 1167(1)-(N) can send this request to secondary VNICs 1172(1)-(N), which can send the request to a NAT gateway that can send the request to public internet 1154. The public internet 1154 can send the request to LB subnet 1122, which is included in control plane VCN 1116, via internet gateway 1134. In response to determining that the request is valid, the LB subnet can send the request to app subnet 1126, which can send the request to cloud service 1156 via service gateway 1136.

[0225] It should be understood that the IaaS architectures 800, 900, 1000, 1100 depicted in the figures may have components other than those shown. Additionally, the illustrated embodiments are only a few examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In other embodiments, the IaaS systems may have more or fewer components than those depicted in the figures, may combine two or more components, or may have a different configuration or arrangement of components.

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

[0227] 12 illustrates an exemplary computer system 1200 on which various embodiments may be implemented. System 1200 may be used to implement any of the computer systems described above. As shown, computer system 1200 includes a processing unit 1204 that communicates with a number of peripheral subsystems via a bus subsystem 1202. These peripheral subsystems may include a processing acceleration unit 1206, an I / O subsystem 1208, a storage subsystem 1218, and a communication subsystem 1224. Storage subsystem 1218 includes a tangible computer-readable storage medium 1222 and a system memory 1210.

[0228] Bus subsystem 1202 provides a mechanism that allows the various components and subsystems of computer system 1200 to communicate with each other as intended. While bus subsystem 1202 is shown schematically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1202 may be any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component InterConnect (PCI) bus. It may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0229] Processing unit 1204 may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers) and controls the operation of computer system 1200. One or more processors may be included in processing unit 1204. These processors may include single-core processors or multi-core processors. In an embodiment, processing unit 1204 may be implemented as one or more independent processing units 1232 and / or 1234, with a single processor or a multi-core processor included in each processing unit. In other embodiments, processing unit 1204 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0230] In various embodiments, processing unit 1204 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any time, some or all of the program code being executed may reside on processor 1204 and / or storage subsystem 1218. Through appropriate programming, processor 1204 may provide the various functions described above. Computer system 1200 may further include a processing acceleration unit 1206, which may include a digital signal processor (DSP), a special purpose processor, etc.

[0231] The I / O subsystem 1208 can include user interface input devices and user interface output devices. User interface input devices can include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touchscreen integrated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, a keypad, an audio input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices can include, for example, motion sensing and / or gesture recognition devices such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device through a natural user interface using gestures and voice commands, such as a Microsoft Xbox® 360 game controller. User interface input devices can also include eye gesture recognition devices, such as a Google Glass® blink detector that detects a user's eye activity (e.g., "blinking" when taking a photo and / or selecting a menu) 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 a user to interact with a voice recognition system (e.g., Siri® Navigator) through voice commands.

[0232] User interface input devices may also include three-dimensional (3D) mice, joysticks or pointing sticks, gamepads and graphics tablets, and audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode reader 3D scanners, 3D printers, laser range finders, eye-tracking devices, etc. Additionally, user interface input devices may include medical imaging input devices such as, for example, computed tomography, magnetic resonance imaging, positional emission tomography, and medical ultrasound devices. User interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, etc.

[0233] 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 1200 to a user or to another computer. For example, user interface output devices include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0234] Computer system 1200 may include a storage subsystem 1218 that comprises software elements shown as currently located in system memory 1210. System memory 1210 may store program instructions that are loadable and executable on processing unit 1204, as well as data generated during the execution of these programs.

[0235] Depending on the configuration and type of computer system 1200, system memory 1210 may be volatile (e.g., random access memory (RAM)) and / or non-volatile (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 1204. In some implementations, system memory 1210 may include several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, the basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within computer system 1200, such as during start-up, may typically be stored in ROM. By way of example and not limitation, system memory 1210 also illustrates application programs 1212, which may include client applications, web browsers, mid-tier applications, relational database management systems (RDBMS), etc., as well as program data 1214 and operating system 1216. By way of example, operating system 1216 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating 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® 12 OS, Palm® OS operating systems, etc.

[0236] The storage subsystem 1218 may also provide 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 the storage subsystem 1218. These software modules or instructions may be executed by the processing unit 1204. The storage subsystem 1218 may also provide a repository for storing data used in accordance with the present disclosure.

[0237] Storage subsystem 1200 may also include computer-readable storage medium reader 1220 that may further connect to computer-readable storage medium 1222. Computer-readable storage medium 1222, together with, and optionally in combination with, system memory 1210, may comprehensively represent remote, local, fixed, and / or removable storage devices and media that contain, store, transmit, and retrieve computer-readable information on a temporary and / or more permanent basis.

[0238] The computer-readable storage medium 1222 containing the code or portions of code may include any suitable medium known or used in the art, including, but not limited to, storage 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 may include tangible computer-readable storage media such as RAM, ROM, Electronically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, Digital Versatile Disk (DVD) or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage, or other magnetic storage device, or other tangible computer-readable medium. This may also include intangible computer-readable media such as a data signal, data transmission, or any other medium that can be used to transmit desired information and that can be accessed by computing system 1200.

[0239] By way of example, the computer-readable storage medium 1222 may include hard disk drives that read from or write to non-removable, non-volatile magnetic media, magnetic disk drives that read from or write to removable, non-volatile magnetic disks, and optical disk drives that read from or write to removable, non-volatile optical disks such as CD-ROMs, DVDs, and Blu-Ray® disks, or other optical media. The computer-readable storage medium 1222 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 1222 may also include solid-state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, solid-state ROMs, SSDs based on volatile memory such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 1200.

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

[0241] In some embodiments, the communications subsystem 1224 may also receive incoming communications in the form of structured and / or unstructured data feeds 1226, event streams 1228, event updates 1230, etc., on behalf of one or more users who may use the computer system 1200.

[0242] By way of example, the communications subsystem 1224 may be configured to receive data feeds 1226 in real time from users of social networks and / or other communications services, such as web feeds such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0243] Additionally, the communications subsystem 1224 may also be configured to receive data in the form of continuous data streams, which may include event streams 1228 of real-time events and / or event updates 1230, which may be continuous in nature or open-ended with no explicit 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.

[0244] Communications subsystem 1224 may be configured to output structured and / or unstructured data feeds 1226, event streams 1228, event updates 1230, etc. to one or more databases that may be in communication with one or more streaming data source computers coupled to computer system 1200.

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

[0246] Due to the ever-changing nature of computers and networks, the description of computer system 1200 shown in the figure is intended as a specific example only. Many other configurations are possible, having more or fewer components than the system shown in the figure. For example, customized hardware could also be used, and / or particular elements could be implemented in hardware, firmware, software (including applets), or a combination. Furthermore, connections to other computing devices, such as network input / output devices, could be used. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other manners and / or methods for implementing various embodiments.

[0247] While specific embodiments have been described, various modifications, variations, alternative constructions, 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 can freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a particular sequence of transactions and steps, it will be apparent to those skilled in the art that the scope of the present disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments can be used individually or in combination.

[0248] Furthermore, while embodiments have been described using particular combinations of hardware and software, it should be recognized that other combinations of hardware and software are within the scope of the present disclosure. Embodiments 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 any combination of different processors. Thus, when 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 (e.g., a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0249] 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 alterations may be made without departing from the broader spirit and scope of the appended claims. Accordingly, although certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are intended to be within the scope of the following claims.

[0250] Use of the terms “a,” “an,” “the,” and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims below) should be construed to cover both the singular and the plural unless otherwise indicated herein or clearly contradicted by context. The terms “comprising,” “having,” “including,” and “containing” should be construed as open-ended terms (i.e., meaning “including, but not limited to”) unless otherwise noted. The term “connected” should be construed as partially or wholly contained within, attached to, or joined to, 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 that range, unless otherwise indicated herein, and each separate value is incorporated herein as if it were individually set forth herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. Any examples provided herein, or the use of exemplary language (e.g., "such as"), are intended merely to better describe embodiments 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.

[0251] Unless specifically stated otherwise, disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood within the context in which it is generally used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). 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.

[0252] 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 foregoing description. Those skilled in the art will be able to adopt such variations as appropriate, and the present disclosure may be practiced in ways other 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. Furthermore, unless otherwise indicated herein, this disclosure encompasses any combination of the above-described elements in all possible variations thereof.

[0253] All references cited in this specification, including publications, patent applications, and patents, are herein 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.

[0254] In the foregoing specification, aspects of the disclosure have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure can be used individually or in combination. Moreover, embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.< / instanceid>

Claims

1. 1. A computer-implemented method for connecting computing instances from different tenants, comprising: a first control plane for a first service receiving a request to create a connection between a first computing instance of the first service and a second computing instance of a second service, the first computing instance being controlled by the first control plane and the second computing instance being controlled by a second control plane, the first computing instance being within a customer tenant and the second computing instance being within the customer tenant, the first computing instance being isolated from the second computing instance within the customer tenant; The method comprises: the first control plane performing a set of processing operations to create the connection between the first computing instance and the second computing instance; after executing the set of processing operations, the connection causes the first control plane to gain control of the second computing instance and enables communication between the first computing instance and the second computing instance.

2. Performing the set of processing operations includes: The method of claim 1 , including the first control plane obtaining a token indicating that the first control plane can communicate with the second control plane on behalf of a customer.

3. Performing the set of processing operations includes: The method of claim 1 or claim 2, further comprising the first control plane determining a set of permitted operations that can be performed on the second computing instance.

4. Performing the set of processing operations includes: the first control plane sending a connection request to the second control plane, the connection request including information identifying the first computing instance and the second computing instance, the second control plane storing information related to the connection; Performing the set of processing operations includes: The method of claim 1 or claim 2, wherein the first control plane includes storing information about the connection.

5. 3. The method of claim 1, wherein the first control plane is a dominant control plane, the second control plane is a passive control plane, the first computing instance is a dominant computing instance, and the second computing instance is a passive computing instance.

6. 3. The method of claim 1 or 2, further comprising: before performing the set of processing operations to create the connection, the first control plane creating the first computing instance of the first service in the customer tenant.

7. Performing the set of processing operations includes:

3. The method of claim 1, further comprising: the first control plane sending a request to the second control plane to create the second computing instance in the customer tenant; and the second control plane creating the second computing instance in the customer tenant in response to the request.

8. The method of claim 1 or 2, wherein the first service is an enterprise resource planning (ERP) service and the second service is a conversational artificial intelligence (AI) service.

9. 3. The method of claim 1, wherein after executing the set of processing operations, the connection restricts the second control plane from executing at least one operation on the second computing instance.

10. 1. A computer program comprising computer-executable instructions that, when executed, cause one or more processors of a computer system to perform a method, the method comprising: receiving a request to create a connection between a first computing instance of a first service and a second computing instance of a second service, wherein the first computing instance is controlled by a first control plane of the computer system and the second computing instance is controlled by a second control plane, the first computing instance is within a customer tenant, the second computing instance is within the customer tenant, and the first computing instance is isolated from the second computing instance within the customer tenant; The method comprises: performing a set of processing operations to create the connection between the first computing instance and the second computing instance; and after executing the set of processing operations, gaining control of the second computing instance through the connection and enabling communication between the first computing instance and the second computing instance.

11. Performing the set of processing operations includes: The computer program product of claim 10 , further comprising obtaining a token indicating that the computer system can communicate with the second control plane on behalf of a customer.

12. Performing the set of processing operations includes:

12. The computer program product of claim 10 or claim 11, further comprising determining a set of permitted operations that can be performed on the second computing instance.

13. Performing the set of processing operations includes: sending a connection request to the second control plane, the connection request including information identifying the first computing instance and the second computing instance, the second control plane storing information relating to the connection; Performing the set of processing operations includes:

12. A computer program according to claim 10 or claim 11, comprising storing information about said connection.

14. 12. The computer program product of claim 10 or claim 11, wherein the first control plane is a dominant control plane, the second control plane is a passive control plane, the first computing instance is a dominant computing instance, and the second computing instance is a passive computing instance.

15. 1. A computer system comprising: a processor; a memory configured to store a plurality of instructions executable by the processor, the instructions, when executed by the processor, causing a process to be performed, the process comprising: receiving a request to create a connection between a first computing instance of a first service and a second computing instance of a second service, wherein the first computing instance is controlled by a first control plane of the computer system and the second computing instance is controlled by a second control plane, the first computing instance is within a customer tenant, the second computing instance is within the customer tenant, and the first computing instance is isolated from the second computing instance within the customer tenant; The process comprises: performing a set of processing operations to create the connection between the first computing instance and the second computing instance; and after executing the set of processing operations, gaining control of the second computing instance through the connection and enabling communication between the first computing instance and the second computing instance.

16. Performing the set of processing operations includes:

16. The computer system of claim 15, further comprising obtaining a token indicating that the computer system can communicate with the second control plane on behalf of a customer.

17. Performing the set of processing operations includes:

17. The computer system of claim 15 or claim 16, further comprising determining a set of permitted operations that can be performed on the second computing instance.

18. Performing the set of processing operations includes: sending a connection request to the second control plane, the connection request including information identifying the first computing instance and the second computing instance, the second control plane storing information regarding the connection; Performing the set of processing operations includes:

17. A computer system according to claim 15 or claim 16, comprising storing information about said connections.

19. 17. The computer system of claim 15 or claim 16, wherein the first control plane is a dominant control plane, the second control plane is a passive control plane, the first computing instance is a dominant computing instance, and the second computing instance is a passive computing instance.

20. 16. The computer system of claim 15, further comprising creating the first computing instance of the first service in the customer tenant before performing the set of processing operations to create the connection.

Images