Connecting and separating compute instances owned by different tenants

Abstract

This provides a way to create and restrict the operation of connections between compute instances provisioned from two different tenants. [Solution] In order to create a connection between a first computing instance controlled by a first control plane and a second computing instance controlled by a second control plane, the first control plane executes a set of processing operations to create a connection between the first computing instance and the second computing instance. After executing the set of processing operations, the connection allows the second control plane to gain control of the second computing instance and enables communication between the second computing instance and the second computing instance. Consequently, the second control plane is restricted to performing at least one operation on the second computing instance.

Description

Technical Field

[0001] Related Applications This application is related to U.S. Non-Provisional Application No. 17 / 459,167, entitled "Restricted Operations by Connecting Computing Instances Owned by Different Tenants". The entire contents of the foregoing application are incorporated herein by reference for all purposes.

Background Art

[0002] Background When a customer signs up as a subscriber to an IaaS service provided by an IaaS cloud service provider (CSP), an account or tenant is created for that customer. In one implementation, the tenant created for the customer (also referred to as the 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 the resources placed within that customer's tenant. These resources can 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

Problems to be Solved by the Invention

[0003] For specific services where a customer subscribes and customer instances are provisioned to the customer, compute instances are typically created and served by a separate service infrastructure configured to provision and manage cloud resources associated with that particular service. For example, if a customer subscribes to both Service A and Service B, the Service A infrastructure, associated with its own tenant (called a service tenant), is configured to create and provision compute instance A to serve Service A to the customer. Similarly, the Service B infrastructure, associated with its own tenant, is configured to create and provision compute instance B to serve 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, because compute instances created by separate service infrastructures are provisioned by the infrastructures of two different tenants, they cannot communicate or interact with each other directly. However, while it may be possible for a customer to utilize resources received from two different service infrastructures (e.g., compute instance A and compute instance B in the above example) to interact and collaborate with each other, this becomes difficult because the compute instances are isolated based on the service tenant.

[0004] This disclosure describes a solution to the aforementioned problem. Brief Overview This disclosure generally relates to creating connectivity between computing instances. It describes the infrastructure and generalized methods for connecting (also called "wiring") two (or more) cloud resources (e.g., two computing instances) even though the computing resources are provisioned by two different services from different cloud tenants, as described herein. This describes the automated process performed to wire computing instances. The automated process can typically be applied to connect any two computing instances that provide two different services and are provisioned from two different service tenants.

[0005] For example, a customer can submit a request to the first service infrastructure to connect a first service computing instance with a second service computing instance. The request may be received and processed by the first service control plane of the first service infrastructure. Next, a workflow is executed to connect the two computing instances. This workflow includes processing performed by the first service control plane, the second service control plane, and the Identity Management and Authorization Service (IDMAS). [Means for solving the problem]

[0006] In one embodiment, the 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, wherein the first computing instance is controlled by the first control plane and the second computing instance is controlled by the second control plane, the first computing instance is located within a customer tenant, the second computing instance is located within a 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 a connection between the first computing instance and the second computing instance, and, after performing the set of processing operations, obtaining 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, the first control plane obtains a token indicating that the first control plane can communicate with the second control plane on behalf of the customer.

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

[0009] In yet another embodiment, executing a set of processing operations includes the first control plane sending a connection request to a second control plane, the connection request including information identifying a first computing instance and a second computing instance, the second control plane storing information about the connection, and executing a set of processing operations includes the first control plane storing information about 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 compute instance of the first service within the customer tenant before performing a set of processing operations to create a connection.

[0012] In yet another embodiment, executing a 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, and 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 a set of processing operations, the connection restricts the second control plane from performing at least one operation on the second computing instance.

[0015] In one embodiment, a non-temporary computer-readable storage medium is disclosed that stores computer-executable instructions, which, when executed, cause one or more processors of a computer system to execute 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, the first computing instance being controlled by a first control plane of a computer system, the second computing instance being controlled by a second control plane, the first computing instance being in a customer tenant, the second computing instance being in a customer tenant, the first computing instance being isolated from the second computing instance in the customer tenant, the method comprising executing a set of processing operations to create a connection between the first computing instance and the second computing instance, and, after executing the set of processing operations, obtaining control of the second computing instance by connection and enabling communication between the first computing instance and the second computing instance.

[0016] In one embodiment, a computer system is disclosed comprising a processor and a memory executable by the processor and configured to store a plurality of instructions which, when executed by the processor, cause processing to be performed, wherein the processing includes 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, the first computing instance being controlled by a first control plane of the computer system, the second computing instance being controlled by a second control plane, the first computing instance being in a customer tenant, the second computing instance being in a customer tenant, the first computing instance being isolated from the second computing instance in the customer tenant, and the processing includes performing a set of processing operations to create a connection between the first computing instance and the second computing instance, and, after performing the set of processing operations, obtaining control of the second computing instance by connection and enabling communication between the first computing instance and the second computing instance.

[0017] In one embodiment, a device for connecting computing instances is disclosed, which includes means for performing any step of the method according to the embodiments of this disclosure.

[0018] In one embodiment, a computer program product is disclosed which, when executed by a processor, includes computer instructions that implement any step of the method according to the embodiments of this disclosure.

[0019] The foregoing, along with other features and embodiments, is described below in the specification, claims, and This will become clearer by referring to the attached drawings. [Brief explanation of the drawing]

[0020] [Figure 1]A simplified block diagram of a distributed environment according to some embodiments. [Figure 2] A diagram showing a simplified swim chart illustrating the process of connecting two computing instances within a customer tenant according to an embodiment. [Figure 3] A diagram showing a simplified swim chart illustrating the process of separating two computing instances connected within a customer tenant according to an embodiment. [Figure 4] A diagram showing a simplified swim chart illustrating the process of connecting two computing instances within a customer tenant according to an embodiment, where the passive instance does not yet exist and is created as part of the process. [Figure 5] A diagram showing a simplified swim chart illustrating the process of connecting two computing instances within a customer tenant according to an embodiment, where the dominant instance does not yet exist and is created as part of the process. [Figure 6] A diagram showing a simplified swim chart illustrating the process of connecting two computing instances within a customer tenant according to an embodiment, where both computing instances do not yet exist but are created as part of the process. [Figure 7] A diagram showing the process of determining whether an operation is permitted according to an embodiment. [Figure 8] A block diagram showing one pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 9] A block diagram showing another pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 10] A block diagram showing another pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 11] This block diagram shows another pattern for implementing cloud infrastructure as a service system, with at least one embodiment. [Figure 12] A block diagram illustrating an exemplary computer system according to at least one embodiment. [Modes for carrying out the invention]

[0021] Detailed explanation In the following description, certain details are included to provide a complete understanding of a particular embodiment for illustrative purposes. However, it will be apparent that various embodiments can be carried out without these specific details. The figures and descriptions are not intended to be limiting. The term “exemplary” is used herein to mean “serving as an example, case, or illustration.” Any embodiment or design described herein as “exemplary” should not necessarily be construed as being preferable or advantageous over other embodiments or designs.

[0022] This disclosure generally relates to creating connections between computing instances. When a customer signs up as a subscriber to an IaaS service provided 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 called the 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 include, for example, one or more computing instances provisioned to the customer to provide one or more services to the customer. This may include instances.

[0023] For specific services where a customer subscribes and customer instances are provisioned to the customer, compute instances are typically created and served by a separate service infrastructure configured to provision and manage cloud resources associated with that particular service. For example, if a customer subscribes to both Service A and Service B, the Service A infrastructure, associated with its own tenant (called a service tenant), is configured to create and provision compute instance A to serve Service A to the customer. Similarly, the Service B infrastructure, associated with its own tenant, is configured to create and provision compute instance B to serve 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, because compute instances created by separate service infrastructures are provisioned by the infrastructures of two different tenants, they cannot communicate or interact with each other directly. However, while it may be possible for a customer to utilize resources received from two different service infrastructures (e.g., compute instance A and compute instance B in the above example) to interact and collaborate with each other, this becomes difficult because the compute instances are isolated based on the service tenant.

[0024] In this sense, customers may want to "connect" two computing instances to enable such cooperative functionality between them. Previously, such connections could only be achieved by making customized changes to the code implementing the two computing instances to be connected. However, such solutions are specific to those computing instances and are not typically applicable to other cloud resources that are being connected. Furthermore, the process is time-consuming because it requires applying specific code changes to the two computing instances to be connected, and it is specific to these computing instances and not applicable to other types of computing instances. As a result, customers could not request such connections on demand.

[0025] This disclosure describes a solution to the problem described above. It describes infrastructure and generalized methods for connecting (also called "wiring") two (or more) cloud resources (e.g., two computing instances) even though the computing resources are provisioned by two different services from different cloud tenants, as described herein. It describes automated processes performed to wire computing instances. These automated processes can typically be applied to connect any two computing instances that provide two different services and are provisioned from two different service tenants.

[0026] For example, a customer can submit a request to the first service infrastructure to connect a first service computing instance with a second service computing instance. The request may be received and processed by the first service control plane of the first service infrastructure. Next, a workflow is executed to connect the two computing instances. This workflow includes processing performed by the first service control plane, the second service control plane, and the Identity Management and Authorization Service (IDMAS). Details related to the processes to be performed are shown in Figures 2, 3, 4, 5, 6, and 7, and are explained below.

[0027] Figure 1 is a simplified block diagram of a distributed environment 100 according to several embodiments. The distributed environment 100 may comprise multiple computer systems that are connected to each other in a communicative manner via one or more communication links on one or more communication networks. The distributed environment 100 in Figure 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 operation console 106.

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

[0029] The various components shown in Figure 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 system can use the network resources to communicate with one or more other computer systems via one or more communication networks. Communication networks may include, for example, the internet, intranets, extranets, local area networks (LANs), wide area networks (WANs), and other networks that facilitate communication, as well as combinations thereof. Communication may be conducted via wired or wireless links using one or more wired or wireless communication protocols. In some implementations, the communication network may include a physical infrastructure 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 compute instances, to 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, allow multiple virtual machine compute instances to run on the same physical computer system (also called the host machine). Bare metal compute instances are hosted by a bare metal server or host machine without a hypervisor. Once 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 provided by an IaaS CSP Upon registration, an account called a customer tenant is created for the customer. For example, as shown in Figure 1, customer tenant 130 may be created for a subscriber 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 individual tenants can be created for individual, different customers. In a typical scenario, a customer can only access resources located within their own tenant. A customer can create additional compartments within their root tenant (root compartment) to further control access to resources located within those additional compartments. This is achieved by associating one or more access policies with the compartment to control access to the resources within that compartment. When cloud resources (e.g., compute instances, block volumes, cloud networks, etc.) are created for a customer, the customer can specify the particular compartment in which the resources will be located. In the simplest default scenario, the customer's cloud resources are located within the customer's root tenant. For example, in Figure 1, customer cloud resources such as service A compute instance 131 and service B compute instance 132 may be located within the 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 those offered under the Software-as-a-Service (SaaS) model, Platform-as-a-Service (PaaS) model, and other types of cloud services. The term "cloud service" is generally used to refer to services that are made available to users or customers on demand (e.g., through a subscription model) by a CSP using the systems and infrastructure (cloud infrastructure) provided by the CSP. 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 provided by a CSP without having to purchase hardware and software resources for the service separately. Cloud services are designed to provide subscribers with easy and scalable access to applications and computing resources without requiring them to invest in procuring the infrastructure used to deliver the service.

[0033] For example, in the embodiment shown in Figure 1, a customer can subscribe to "Service A" provided by the CSP using Service A Infrastructure 110 and another "Service B" provided by the 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 subscriber customers. Service A Infrastructure 110 can operate within a Service A Tenant 115, which is created specifically for that service. A subscriber customer user 105 can use a console 106 to send a request to Service A Infrastructure 110 for a computing instance that provides Service A. In response, Service A Infrastructure 110 can provision a Service A computing instance 131 (e.g., a specific instance that provides Service A) to user 105. As shown in Figure 1, the provisioned Service A computing instance 131 can be stored within the customer tenant 130. Service A Infrastructure 110 is responsible for the lifecycle management and configuration of the Service A computing instance 131.

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

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

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

[0037] It should be noted 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 the cloud resources provisioned by Service B infrastructure 120. For example, Service A infrastructure 110 cannot access Service B computing instance 132. Similarly, Service B infrastructure 120 cannot access or control the cloud resources provisioned by Service A infrastructure 110. For example, Service B infrastructure 120 cannot access Service A computing instance 131.

[0038] Since Service A computing instance 131 and Service B computing instance 132 are provisioned and controlled by entities within two different tenants, for example, Service A tenant 115 and Service B tenant 125, the two computing instances cannot and will not interact with each other. However, a situation can be considered where a customer can use resources received from two different services to interact and collaborate with each other. For example, a customer with customer tenant 130 can use Service A computing instance 131 and Service B computing instance 132 to collaborate. In this sense, a customer may want to "connect" the two computing instances to enable such collaborative functionality of the computing instances. For example, suppose 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 customers. Furthermore, suppose Service B is a conversational artificial intelligence (AI) service (also called a digital assistant or chatbot service). The Service B infrastructure 120 is configured to create and train a chatbot service instance (e.g., Service B computing instance 132) for a customer, and the chatbot service instance is configured to respond in spoken and / or written language. A customer may want to interact with their ERP service via the chatbot. To achieve this, a customer may want to connect their chatbot service instance (e.g., Service B computing instance 132) to their ERP computing instance (e.g., Service A computing instance 131).

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

[0040] This disclosure describes a solution to the problem described above. It describes infrastructure and generalized methods for connecting (also called "wiring") two (or more) cloud resources (e.g., two computing instances) even though the computing resources are provisioned by two different services from different cloud tenants, as described herein. It describes automated processes performed to wire computing instances. These automated processes can typically be applied to connect any two computing instances that provide two different services and are provisioned from two different service tenants.

[0041] For example, in the embodiment shown in Figure 1, user 105 can send a request to the Service A infrastructure 110 via console 106 to connect Service A computing instance 131 and Service B computing instance 132. The request may be received and processed by the Service A control plane 112. Next, a workflow is executed to connect the two computing instances, and this workflow is performed by the Service A control plane 112, the Service B control plane 122, and the Identity Management and Authorization Service (IDMAS) 140. Processing is included. Details related to the processing performed as part of this workflow are shown in Figures 2, 3, 4, 5, 6, and 7 and are 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 aforementioned example concerning an ERP service computing instance and a chatbot computing instance, the user can request that the two computing instances be connected. Then, the process to perform the connection is executed. As a result of the connection, the user of the ERP computing instance will be able to interact with the ERP instance using a conversation with the chatbot instance.

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

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

[0045] Information associated with connection / isolation processing may be stored by the Service A infrastructure 110 as connection / isolation information 111. Similarly, information associated with connection / isolation processing may be stored by the Service B infrastructure 120 as connection / isolation 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 specific set of computing instances to be connected or disconnected. Authorization may be based on access control policies defined for the service instances to be connected or disconnected. For example, policies can be defined for the customer tenant 130 that control which instances can be connected / disconnected, and which users can request connection / disconnection. The identity management and authorization service 140 can evaluate such policies to determine whether the request can be authorized. The identity management and authorization service 140 can enable the service A infrastructure 110 and the service B infrastructure 120 to communicate with each other on behalf of user 105 during the connection process (or disconnection process).

[0047] Figure 2 shows a simplified swim chart 200 illustrating the process of connecting two computing instances within a customer tenant according to one embodiment. The processes shown in Figure 2 may be implemented using hardware or a combination thereof, in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each system. The software may be stored in a non-temporary storage medium (e.g., a memory device). The methods shown in Figure 2 and described below are intended to be illustrative and non-limiting. Figure 2 shows, but is not intended to limit, various processing operations occurring in a particular sequence or order. In some alternative embodiments, the operations may be executed in some different order, or some steps may be executed in parallel.

[0048] Swim chart 200 illustrates the process of connecting two computing instances. In the process shown in Figure 2, it is assumed that the two computing instances to be connected already exist before the connection request is received. For example, the two computing instances to be connected may have been created before the connection request was received. In one embodiment, when requests to connect two instances are received from two services, and the instances do not yet exist, as part of the process, the computing instances may be created by first interacting with their respective service infrastructures, and then the computing instances may be connected according to the process shown in Figure 2.

[0049] For example, in the embodiment shown in Figure 1, user 105 can send a command to the service A control plane frontend 113 (for example, via console 106) to create a first computing instance of service A. In response to receiving the user command, the service A control plane workflow 114 can create and configure the service A computing instance 131 (for example, an entity of the 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. Similarly, user 105 can send a command to the service B control plane 122 (for example, via console 106) to create a second computing instance of service B. In response to receiving the user command, the service B control plane 122 can create and configure the service B computing instance 132 (for example, an entity of the second service) within the user's customer tenant 130. The service B control plane 122 can continue to control and manage the service B computing instance 132.

[0050] Both Service A computing instance 131 and Service B computing instance 132 may exist within the customer tenant 130, but they can be created independently and are initially isolated from each other within the customer tenant 130. Typically, the Service A control plane 112 owns Service A computing instance 131, and as a result, only the Service A control plane 112 can access and configure Service A computing instance 131. Similarly, typically, the Service B control plane 122 owns Service B computing instance 132, and as a result, only the 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 with each other or share information.

[0051] The process shown in Figure 2 and described below can connect Service A computing instance 131 and Service B computing instance 132 based on user commands. As a result of the connection, Service A computing instance 131 and Service B computing instance 132 can communicate and exchange information. Furthermore, 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 Figure 2, processing may begin in 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 service A computing instance 131 and service B computing instance 132.

[0053] For the purposes of this disclosure, the control plane that receives connection requests from users 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 includes the functions and APIs necessary to initiate the connection process and execute the connection. For example, in Figure 2, the service A control plane 112 receives the connection request in S202 and is therefore the dominant control plane, while the service B control plane 122 is the passive control plane.

[0054] In the example shown in Figure 2, the command is received by the Service A control plane frontend 113. Since two separate computing instances created by two separate service control planes are connected, in one embodiment a connection request may be sent to either 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. User 105 can decide which service to send the command to via the user device (e.g., console 106). For example, user 105 can select Service A from a list displayed in the user interface via the user device (e.g., console 106).

[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, 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, not service B control plane 122. In such implementations, only one of the control planes (e.g., service A control plane 112) can 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 can be the dominant control plane.

[0056] In one embodiment, after the connection process is complete, the connection gives the dominant control plane control and ownership of the passive control plane's compute instance (within the customer tenant). As a result, certain actions that the passive control plane could perform on the compute instance (e.g., deleting the compute instance) are no longer permitted as long as the connection persists. Instead, in such embodiments, the passive control plane receives and complies with connection messages and commands from the dominant control plane, and the dominant control plane takes control of the passive control plane's compute instance. To enable control of the instance.

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

[0058] In some embodiments, responses sent by the ID 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 commands to the Service B control plane 122 on behalf of a user device (e.g., console 106). In some implementations, 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 a dominant control plane to a passive control plane).

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

[0060] The process of executing the connection may be performed synchronously or asynchronously. In some implementations, an asynchronous implementation is preferred because the requesting user does not need to wait (or is not locked) until the entire process is complete. Therefore, in implementations that use asynchronous processing, in S206, the service A control plane frontend 113 creates an asynchronous work request to execute the process and provides a work request identifier to the user device (e.g., console 106). The user device (e.g., console 106) can request an update regarding the status of the connection process by sending the work request ID.

[0061] In S208, after completing the ID management and authorization process in step S204, the Service A control plane frontend 113 instructs the Service A control plane workflow 114 components to start the workflow for creating a connection. In some embodiments, the Service A control plane frontend 113 may provide the Service A control plane workflow 114 with an OBO token for use in communication with the Service B control plane 122 to create a connection.

[0062] In 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 compute instance owned by the Service B control plane 122 is connected to another compute instance owned by the dominant control plane (i.e., the Service A control plane 122). The connection request message contains a payload of any appropriate information associated with the connection. For example, the connection request may include ID / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, an OBO token received by the Service A control plane 112 in S204 may be included in the request sent in S210. Furthermore, the connection request may specify the instances being connected (e.g., Service A compute instance 131 and Service B compute instance 132). Computing instances can be identified using an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifier (OCID).

[0063] Furthermore, connection requests can indicate the IDs of the dominant and passive control planes. For example, in the example in Figure 2, the dominant control plane is the Service A control plane 112, and the passive control plane is the Service B control plane 122. This also identifies the dominant and passive computing instances. Since the Service A control plane 112 is the dominant control plane, the Service A computing instance 131 is called the dominant computing instance. Similarly, since the Service B control plane 122 is the passive control plane, the connection refers to the Service B computing instance 132 as the passive computing instance.

[0064] Furthermore, in some embodiments, the connection imposes restrictions on the actions that (a) the customer and (b) the passive control plane can perform on the passive computing instance. In some implementations, the connection request sent in 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 actions that the connection allows or disallows on the passive computing instance by the customer and / or the passive control plane. The request may identify, for each customer and passive control plane, a list of one or more actions that the connection allows or disallows on the passive computing instance by the customer. In some implementations, a list of allowed actions is provided for each customer and passive service control plane. While the connection exists, actions not specifically specified in the list are not allowed. In some embodiments, the action of deleting a passive computing instance (e.g., service B computing instance 132) may no longer be included in the new list of allowed actions by the customer. In some embodiments, the action of deleting a connection may be allowed only to the owner, and not the customer.

[0065] The following is an example of a connection request that may be called a 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"], / / The Service Provider name of ServiceACP. This is a list to support multiple Service Provider names for the same service. / / Any * means that it controls all permissions for this resource. "allowedOwnerOperations": / / list of actions the owner should be able to perform. "allowedCustomerOperations": / / List of control plane permission strings allowed for all other callers } }

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

[0067] It should be noted that neither the customer (e.g., the 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 the connection exists. Therefore, 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 is active.

[0068] In S212, the Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving a connection request. This may include persisting the connection information by recording (also called "posting") the details of the connection request received from the Service A control plane 112 (i.e., the dominant control plane), and changing the ownership and authorized actions associated with the Service B computing instance 132 (i.e., the passive computing instance). Cut.

[0069] For example, the Service B control plane 122 may create and store a record within the customer tenant 130 indicating that the Service B computing instance 132 (identified, for example, by its associated OCID) is currently connected to the Service A computing instance 131 (identified, for example, by its associated OCID). This record may indicate that the Service B computing instance 132 is a passive computing instance and the Service A computing instance 131 is a dominant computing instance. Furthermore, the record may indicate the associated control planes and their respective roles. For example, the dominant control plane could be the Service A control plane 112, and the passive control plane could be the 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). Furthermore, the record may indicate that the Service A control plane 112 is currently the owner of the Service B computing instance 132 (i.e., since the Service A control plane 112 is the dominant control plane in this example). This allows the Service B control plane 122 to grant the Service A control plane 112 control and ownership of the Service B computing instance 132. The record may also indicate what actions are permitted on the Service B computing instance 132 while the connection exists, and these actions may be modifications of previously permitted actions. Actions may include customer-permitted actions and owner-permitted actions on the Service B computing instance 132 (e.g., actions that the dominant control plane can perform). For example, a delete action may not be permitted while the connection exists because it is not a customer-permitted action.

[0070] In some embodiments, the Service B control plane 122 can 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 can verify the trustworthiness of the OBO token and / or the authorization 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 within the customer tenant 130 to indicate that a connection exists.

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

[0073] Therefore, in S214, the Service B control plane 122 sends a connection response to the Service A control plane 112 indicating that the connection will be processed by the Service B control plane 122. The connection response message is a connection request message sent in step S210. Therefore, the service A control plane 112 can be notified that the connection details have been confirmed and implemented.

[0074] An example of a connection response message sent from a passive control plane (e.g., service B control plane 122) to a dominant control plane (e.g., 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 for this instance or connection" "attachmentType":"ServiceA" "ownerMetadata":{ "attachmentType":"ServiceA" / / Polymorphic identifier "ownerService":["ServiceA-control-plane"] / / Additional custom fields per service provider. For example, the 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 actions the owner can perform. "" } "LifecycleState":"ATTACHIMG" }

[0075] As indicated in the above request, "id" provides the identifier for the connection. "instanceID" is the passive co currently connected to the dominant computing instance. Provides the identifier of the computing instance (e.g., OCID). "attachToId" provides the 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 (for example, the compartment within customer tenant 130 where 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" shows the following additional data fields: "ownerService" identifies the name of the service provider associated with the dominant control plane. In the example above, the name is "ServiceA-control-plane". Additional data fields can be included that are configured for specific services and control planes. For example, "allowedCustomerOperations" recognizes the actions that are permitted by the customer when a connection exists. To separate. For example, a customer may be allowed to perform GET, LIST, UPDATE, and ATTACH operations on a passive computing instance. "allowedOwnerOperations" is, Identify the actions permitted 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 11) 2) Perform GET, LIST, and UPDATE operations on a passive computing instance. It may be permitted to execute. "lifecycleState" indicates what action is currently being performed on the connection. In the example above, the connection is being established, so "lifecycleState" is "attaching".

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

[0077] In S218, the Service A control plane 112 (i.e., the dominant control plane) performs processing to connect the computing instance in response to receiving a 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 its records to hold the connection information for the dominant control plane. This may include storing the compartment ID of the Service B computing instance 132 (e.g., within customer tenant 130) as indicated by the Service B control plane 122. Furthermore, the Service A control plane 112 may identify what permitted actions are agreed upon and / or provided by the Service B control plane 122.

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

[0079] In some embodiments, as part of the processing performed in 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 connectivity.

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

[0081] The connection and the temporary ownership of the Service B compute instance 132 of the Service A control plane remain valid until the connection is deleted by a subsequent isolation API call. In some embodiments, the Service B compute instance 132 cannot be deleted while the connection exists. To delete the Service B compute instance 132, the compute instance must first be isolated, and only then can the Service B compute instance 132 be deleted. If a user device (e.g., console 106) attempts to delete the Service B compute instance 132 via the Service B control plane 122, which no longer owns the Service B compute instance 132, the deletion attempt is rejected because the connection exists. If a user device (e.g., console 106) attempts to delete the Service B compute instance 132 via the Service A control plane 112, which currently owns it, the user device (e.g., console 106) is notified that the connection exists, and therefore cannot delete the Service B compute instance 132 until the compute instance is isolated.

[0082] In S220, the Service A control plane workflow 114 may send a completion message back to the Service A control plane frontend 113 indicating that the connection was successfully established (or failed). Then, in S222, the Service A control plane frontend 113 may send a completion message back to the user 105 (for example, via a user device such as the console 106) indicating that the connection was successfully established (or failed).

[0083] As a result of the process shown in Figure 2, two computing instances from two different services operating in two different service tenants, which are normally separate and independent, can communicate with each other and cooperate (e.g., via API calls) at the user 105's request, without dependencies or connections. The embodiment allows interaction or communication between the two computing instances to be unidirectional or bidirectional.

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

[0085] User 105 may want to connect a fusion computing instance and an ODA computing instance so that the two instances can interact and share information. Normally, the two instances cannot interact, and information sharing between the two instances is done manually by a human user. However, by connecting them using the process described above, information can be shared automatically without the need for a human user. For example, the ODA computing instance can interact with a customer and receive customer purchase orders, the ODA computing instance can provide purchase order information to the connected fusion computing instance, and the fusion computing instance can fulfill the purchase orders.

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

[0087] The process described above illustrates connecting one computing instance to another, 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] Figure 3 shows a simplified swim chart 300 illustrating a process for isolating two computing instances connected within a customer tenant according to one embodiment. The process shown in Figure 3 can be implemented using hardware or a combination thereof, in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each system. The software may be stored in a non-temporary storage medium (e.g., a memory device). The methods shown in Figure 3 and described below are illustrative and not intended to be limiting. Figure 3 shows various processing operations occurring in a particular sequence or order, but is not intended to be limiting. In some alternative embodiments, the operations may be performed in some different order, or some steps may be performed in parallel.

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

[0090] As shown in Figure 3, the process may be initiated in S302 when a user 105 using a user device (e.g., console 106) sends a request to the service A control plane 112 to isolate 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, in S304, the Service A control plane frontend 113 creates an asynchronous work request to execute the processing and provides a work request identifier to the user device (e.g., console 106). The user device (e.g., console 106) can request an update regarding the status of the connection processing by sending the work request ID.

[0092] In S306, the Service A control plane front end 113 is the Service A control plane The workflow 114 components are instructed to initiate a workflow for isolating the two computing instances. In some embodiments, the service A control plane frontend 113 may provide the service A control plane workflow 114 with an OBO token for use in communication with the service B control plane 122 to isolate the two computing instances.

[0093] In S308, the Service A control plane workflow 114 (i.e., the dominant control plane) sends a separation request to the Service B control plane 122 (i.e., the passive control plane). The separation request notifies the Service B control plane 122 that the computing instance associated with the Service B control plane 122 is being separated from another computing instance associated with the dominant control plane (i.e., the Service A control plane 122), thereby restoring the configuration of the previous computing instance. The separation request message contains a payload of any appropriate information related to connectivity and separation. For example, the separation request may include ID / authorization information indicating that the Service A control plane 112 is authorized to initiate separation. For example, an OBO token received by the Service A control plane 112 (e.g., S204 in Figure 2) may be included in the request sent in S308. Furthermore, the connectivity request may indicate the instances being separated (e.g., Service A computing instance 131 and Service B computing instance 132). Compute instances can be identified using an identifier that uniquely identifies the instance, such as their respective Oracle Cloud Identifier (OCID). Furthermore, isolation The request can specify not only the IDs of the dominant and passive control planes, but also the IDs of the corresponding dominant and passive control planes. The isolation request may also include the identifier of the connection.

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

[0095] In S310, the Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving an isolation request. This may include removing connection details from the posted record and modifying the ownership and authorized behavior associated with the Service B compute instance 132 (i.e., the passive compute 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 authorization 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 compute instance 132 in the customer tenant 130 to indicate that the previous connection no longer exists.

[0096] In S312, the Service B control plane 122 sends a separation response to the Service A control plane 112 indicating that separation is being processed in the Service B control plane 122. The separation response message informs the Service A control plane 112 that the previous connection details have been removed. It can notify the system that this will happen and calculate the instance configuration to be restored according to the isolation request message sent in step S308.

[0097] In S314, the Service A control plane 112 (i.e., the dominant control plane) performs the process of isolating the computing instances in response to receiving an isolation response from the Service B control plane 122 (i.e., the passive control plane). For example, the Service A control plane 112 may remove stored information about previous connections in the dominant control plane, restore the previous set of permitted actions, remove ID wiring, and / or configure the Service A computing instance 131 and / or Service B computing instance 132 so that they no longer indicate a connection.

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

[0099] In S316, the Service A control plane workflow 114 may send a completion message back to the Service A control plane frontend 113 indicating that the isolation was completed successfully (or failed). Then, in S318, the Service A control plane frontend 113 may send a completion message back to the user 105 (for example, via a user device such as the console 106) indicating that the connection was removed successfully (or failed).

[0100] Figure 4 shows a simplified swim chart 400 illustrating the process of connecting two computing instances within a customer tenant according to one embodiment, where the passive instance does not yet exist and is created as part of the process. The processes shown in Figure 4 can be implemented using hardware or a combination thereof, in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each system, using hardware. The software may be stored in a non-temporary storage medium (e.g., a memory device). The methods shown in Figure 4 and described below are illustrative and not intended to be limiting. Figure 4 illustrates, but is not intended to limit, various processing operations occurring in a particular sequence or order. In some alternative embodiments, the operations may be executed in some different order, or some steps may be executed in parallel.

[0101] Swim chart 400 illustrates the process of connecting two computing instances. In the process shown in Figure 4, it is assumed that the dominant instance to be connected already exists before the connection request is received, and the passive instance to be connected does not yet exist before the connection request is received. For example, the dominant computing instance to be connected may be created before the connection request is received, but the passive computing instance to be connected may not have been created before the connection request is received.

[0102] For example, in the embodiment shown in Figure 1, user 105 can send a command to the service A control plane frontend 113 (e.g., via console 106) to create a first computing instance of service A. In response to receiving the user command, the service A control plane workflow 114 can create and configure the service A computing instance 131 (e.g., an entity of the 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. However, user 105 may not have sent a command to the service B control plane 122 to create a second computing instance of service B, and therefore, the computing instance 132 of service B (e.g., an entity of the second service) may not yet exist within the user's customer tenant 130.

[0103] As shown in Figure 4, the process can be initiated in 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 service A computing instance 131 and service B computing instance 132 within the user's customer tenant 130, which may be identical or similar to step S202 in Figure 2.

[0104] After receiving a connection request, the dominant control plane can begin processing to determine whether it can execute the connection request. For example, it may perform processing to determine whether the user requesting the connection should authorize such a request. In some implementations, the identity management and authorization service 140 can perform processing for authorization. Thus, in S404, which may be identical or similar to step S204 in Figure 2, the dominant control plane (in this example, the Service A control plane 112) can send information related to the request received in S402 to the identity management and authorization service 140. The identity management and authorization service 140 can then begin the authorization process. If 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 can send back a response to the dominant control plane (i.e., the Service A control plane 112) providing authorization to proceed with the connection processing. 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, step S406 may be identical or similar to step S206 in Figure 2, where the service A control plane frontend 113 creates an asynchronous work request to execute the processing and provides a work request identifier to the user device (e.g., console 106). The user device (e.g., console 106) can request an update regarding the status of the connection processing by sending the work request ID.

[0106] In step S408, which may be identical or similar to step S208 in Figure 2, after the ID management and authorization process in step S404 is completed, the Service A control plane frontend 113 instructs the Service A control plane workflow 114 components to start a workflow for creating a connection. In some embodiments, the Service A control plane frontend 113 may provide the Service A control plane workflow 114 with an OBO token for use in communication with the Service B control plane 122 to create a connection.

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

[0108] In 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 compute instance 132 (e.g., an entity of the 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 ID / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the compute instance. For example, an OBO token received by the Service A control plane 112 in S404 may be included in the request sent in S409B.

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

[0110] In S410, which may be identical or similar to step S210 in Figure 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 compute instance owned by the Service B control plane 122 is connected to another compute instance owned by the dominant control plane (i.e., the Service A control plane 122). The connection request message contains a payload of any appropriate information associated with the connection. For example, the connection request may include ID / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, an OBO token received by the Service A control plane 112 in S404 may be included in the request sent in S410. Furthermore, the connection request may specify the instances to be connected (e.g., Service A compute instance 131 and Service B compute instance 132). The compute instances have an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifier (OCID). They can be identified using ). Furthermore, the connection request can also indicate not only the IDs of the dominant and passive control planes, but also the IDs of the corresponding dominant and passive control planes.

[0111] 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 in 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, 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. In some implementations, the connection may include information indicating these restrictions. For each of the passive service control planes, a list of permitted actions is provided. While a connection exists, actions not specifically specified in the list are not permitted. In some embodiments, the action of deleting a passive computing instance (e.g., service B computing instance 132) may no longer be included in the new list of permitted actions for the customer. In some embodiments, the action of deleting a connection may be permitted only to the owner, and not to the customer.

[0112] In S412, which may be identical or similar to step S212 in Figure 2, the Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving a connection request. This may include persisting the connection information by recording (also called "posting") the details of the connection request received from the Service A control plane 112 (i.e., the dominant control plane), and modifying the ownership and authorized behavior associated with the Service B compute instance 132 (i.e., the passive compute 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 trustworthiness of the OBO token and / or the authorization 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 compute instance 132 in the customer tenant 130 to indicate that a connection exists.

[0113] In step S414, which may be identical or similar to step S214 in Figure 2, the service B control plane 122 sends a connection response to the service A control plane 112 indicating that the connection will be processed by the service B control plane 122. The connection response message can also notify the service A control plane 112 that the connection details will be confirmed and implemented in accordance with the connection request message sent in step S410.

[0114] Optionally, in S416, which may be identical or similar to step S216 in Figure 2, the Service A control plane 112 (i.e., the dominant control plane) may send commands to the Service B control plane 122 (i.e., the passive control plane) to configure and / or update the Service B computing instance 132 within the customer tenant 130. For example, depending on the type of computing instance, the Service A control plane 112 may install a function (e.g., a chatbot computing instance skill) 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] In S418, which may be identical or similar to step S218 in Figure 2, the Service A control plane 112 (i.e., the dominant control plane) performs processing to connect the computing instance in response to receiving a 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 its records to hold the connection information in the dominant control plane. This may include storing the compartment ID of the Service B computing instance 132 (e.g., within customer tenant 130) as indicated by the Service B control plane 122. Furthermore, the Service A control plane 112 may identify what permitted actions have been agreed upon and / or provided by the Service B control plane 122. In some embodiments, as part of the processing performed in S418, the Service A control plane 112 may perform ID wiring so that the Service A computing instance 131 and the Service B computing instance 132 can communicate with each other. In this state, as part of the processing performed in S418, the service A control plane 112 can 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 agree to the connection and perform the necessary actions to complete the connection, including storing information associated with the connection and making certain permissions, ownership, and configuration changes. Service B control plane 122 (i.e., the passive control plane) grants Service A control plane 112 (i.e., the dominant control plane) control and ownership of Service B compute instance 132 (i.e., the passive compute instance). As a result, Service A control plane 112 (the dominant control plane) now has control and ownership of both Service A compute instance 131 (i.e., the dominant compute instance) and Service B compute instance 132 (i.e., the passive compute instance). Both Service A compute instance 131 and the connected Service B compute instance 132 continue to exist within customer tenant 130.

[0117] In S420, which may be identical or similar to step S220 in Figure 2, the Service A control plane workflow 114 can send a completion message back to the Service A control plane frontend 113 indicating that the connection was successfully established (or failed). Next, in S422, which may be identical or similar to step S222 in Figure 2, the Service A control plane frontend 113 can send a completion message back to the user 105 (for example, via a user device such as a console 106) indicating that the connection was successfully established (or failed).

[0118] As a result of the process shown in Figure 4, two computing instances from two different services operating in two different service tenants are normally separate and independent, with no dependencies or connections, but can be connected and communicate with each other at the user 105's request.

[0119] Figure 5 shows a simplified swim chart 500 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. The processes shown in Figure 5 can be implemented using hardware or a combination thereof, in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each system. The software may be stored in a non-temporary storage medium (e.g., a memory device). The methods shown in Figure 5 and described below are illustrative and not intended to be limiting. Figure 5 shows various processing operations occurring in a particular sequence or order, but is not intended to be limiting. In some alternative embodiments, the processes may be executed in some different order, or some steps may be executed in parallel.

[0120] Swimchart 500 illustrates the process of connecting two computing instances. In the process shown in Figure 5, it is assumed that the passive instance to be connected already exists before the connection request is received, and the dominant instance to be connected does not yet exist before the connection request is received. For example, the passive computing instance to be connected may have been created before the connection request was received, but the dominant computing instance to be connected has not been created before the connection request was received.

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

[0122] As shown in Figure 5, the process can begin in 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 service A computing instance 131 and service B computing instance 132 within the user's customer tenant 130, which may be identical or similar to step S202 in Figure 2.

[0123] After receiving a connection request, the dominant control plane can begin processing to determine whether it can execute the connection request. For example, it may perform processing to determine whether the user requesting the connection is authorized to make such a request. In one implementation, the identity management and authorization service 140 can perform processing for authorization. Thus, in S504, which may be identical or similar to step S204 in Figure 2, the dominant control plane (in this example, the service A control plane 112) can send identity management and authorization service 140 information related to the request received in S502. The identity management and authorization service 140 can then begin the authorization process. If authorization is successful (i.e., the user is able to request a connection between two computing instances), then, as part of S504, the identity management and authorization service 140 can send back a response to the dominant control plane (i.e., the service A control plane 112) providing authorization to proceed with the connection processing. In some embodiments, the response sent by the ID 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 step S506, which may be identical or similar to step S206 in Figure 2, the service A control plane frontend 113 creates an asynchronous work request to execute the processing and provides a work request identifier to the user device (e.g., console 106). The user device (e.g., console 106) can request an update regarding the status of the connection processing by sending the work request ID.

[0125] In step S508, which may be identical or similar to step S208 in Figure 2, after completing the ID management and authorization process of step S504, the Service A control plane frontend 113 instructs the Service A control plane workflow 114 components to start a workflow for creating a connection. In some embodiments, the Service A control plane frontend 113 may provide the Service A control plane workflow 114 with an OBO token for use in communication with the Service B control plane 122 to create a connection.

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

[0127] In S509-B, the Service A control plane workflow 114 creates and configures a Service A computing instance 131 (e.g., an entity of the 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 proceed with the process of connecting the two computing instances.

[0128] In S510, which may be identical or similar to step S210 in Figure 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 compute instance owned by the Service B control plane 122 is connected to another compute instance owned by the dominant control plane (i.e., the Service A control plane 122). The connection request message contains a payload of any appropriate information associated with the connection. For example, the connection request may include ID / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, an OBO token received by the Service A control plane 112 in S504 may be included in the request sent in S510. Furthermore, the connection request may specify the instances to be connected (e.g., Service A compute instance 131 and Service B compute instance 132). The compute instances have an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifier (OC They can be identified using their IDs. Furthermore, connection requests can also specify not only the IDs of the dominant and passive control planes, but also the IDs of the corresponding dominant and passive control planes.

[0129] Furthermore, in some embodiments, the connection imposes restrictions on the actions that (a) the customer and (b) the passive control plane can perform on the passive computing instance. In some implementations, the connection request sent in 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 actions that the connection allows or disallows on the passive computing instance by the customer and / or the passive control plane. The request may identify, by the connection, a list of one or more actions that the customer allows or disallows on the passive computing instance. In some implementations, a list of allowed actions is provided for each customer and passive service control plane. While the connection exists, actions not specifically designated in the list are not allowed. In some embodiments, the action of deleting a passive computing instance (e.g., service B computing instance 132) may no longer be included in the new list of actions allowed by the customer. In some embodiments, the action of deleting a connection may be allowed only to the owner, and not to the customer.

[0130] Step S512 may be identical or similar to step S212 in Figure 2, in which the Service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving a connection request. This may include persisting the connection information by recording (also called "posting") the details of the connection request received from the Service A control plane 112 (i.e., the dominant control plane), and changing the ownership and authorized behavior 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 This allows for the verification of the trustworthiness of the OBO token and / or the authorization 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 compute instance 132 in the customer tenant 130 to indicate that a connection exists.

[0131] In step S514, which may be identical or similar to step S214 in Figure 2, the service B control plane 122 sends a connection response to the service A control plane 112 indicating that the connection will be processed by the service B control plane 122. The connection response message can also notify the service A control plane 112 that the connection details have been confirmed and will be implemented in accordance with the connection request message sent in step S510.

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

[0133] In S518, which may be identical or similar to step S218 in Figure 2, the Service A control plane 112 (i.e., the dominant control plane) performs processing to connect the computing instance in response to receiving a 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 its records to hold the connection information in the dominant control plane. This may include storing the compartment ID of the Service B computing instance 132 (e.g., within customer tenant 130) as indicated by the Service B control plane 122. Furthermore, the Service A control plane 112 may identify what permitted actions have been agreed upon and / or provided by the Service B control plane 122. In some embodiments, as part of the processing performed in S518, the Service A control plane 112 may perform ID wiring so that the Service A computing instance 131 and the Service B computing instance 132 can communicate with each other. In some embodiments, as part of the processing performed in 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 connectivity.

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

[0135] In S520, which may be identical or similar to step S220 in Figure 2, the Service A control plane workflow 114 can send a completion message back to the Service A control plane frontend 113 indicating that the connection was successfully established (or failed). Next, in S522, which may be identical or similar to step S222 in Figure 2, the Service A control plane frontend 113 can send a completion message back to the user 105 (for example, via a user device such as a console 106) indicating that the connection was successfully established (or failed).

[0136] As a result of the process shown in Figure 5, two computing instances from two different services operating in two different service tenants are normally separate and independent, with no dependencies or connections, but can be connected and communicate with each other at the user 105's request.

[0137] Figure 6 shows a simplified swim chart 600 illustrating the process of connecting two computing instances within a customer tenant according to one embodiment, where neither of the two computing instances yet exists and will be created as part of the process. The processes shown in Figure 6 may be implemented using hardware or a combination thereof, in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each system. The software may be stored in a non-temporary storage medium (e.g., a memory device). The methods shown in Figure 6 and described below are illustrative and not intended to be limiting. Figure 6 illustrates, but is not intended to be limiting, various processing operations occurring in a particular sequence or order. In some alternative embodiments, the operations 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. In the process shown in Figure 6, it is assumed that the dominant instance to be connected does not exist before the connection request is received, and neither does the passive instance to be connected before the connection request is received. For example, neither the dominant computing instance nor the passive computing instance to be connected has been created before the connection request is received.

[0139] For example, in the embodiment shown in Figure 1, user 105 may not have sent a command to the service A control plane frontend 113 (e.g., via console 106) to create a first computing instance of service A, and therefore the service A computing instance 131 (e.g., the entity of the first service) may not yet exist within the user's customer tenant 130. Similarly, user 105 may not have sent a command to the service B control plane 122 to create a second computing instance of service B, and therefore the service B computing instance 132 (e.g., the entity of the second service) may not yet exist within the user's customer tenant 130.

[0140] As shown in Figure 6, the process can begin in 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 service A computing instance 131 and service B computing instance 132 within the user's customer tenant 130, which may be identical or similar to step S202 in Figure 2.

[0141] After receiving a connection request, the dominant control plane determines whether it can execute the connection request. A decision-making process can be initiated. For example, a process may be performed to determine whether a user requesting a connection is authorized to make such a request. In some implementations, the Identity Management and Authorization Service 140 can perform an authorization process. Thus, in S604, which may be identical or similar to step S204 in Figure 2, the dominant control plane (in this example, the Service A control plane 112) can transmit Identity Management and Authorization Service 140 information related to the request received in S602. The Identity Management and Authorization Service 140 can then initiate the authorization process. If authorization is successful (i.e., the user is authorized to request a connection between two computing instances), as part of S604, the Identity Management and Authorization Service 140 can send back a response to the dominant control plane (i.e., the Service A control plane 112) providing authorization to proceed with 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 step S606, which may be identical or similar to step S206 in Figure 2, the service A control plane frontend 113 creates an asynchronous work request to execute the processing and provides a work request identifier to the user device (e.g., console 106). The user device (e.g., console 106) can request an update regarding the status of the connection processing by sending the work request ID.

[0143] In step S608, which may be identical or similar to step S208 in Figure 2, after the ID management and authorization process of step S604 is completed, the Service A control plane frontend 113 instructs the Service A control plane workflow 114 components to start a workflow for creating a connection. In some embodiments, the Service A control plane frontend 113 may provide the Service A control plane workflow 114 with an OBO token for use in communication with the Service B control plane 122 to create a connection.

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

[0145] In S609-B, the Service A control plane workflow 114 creates and configures a Service A computing instance 131 (e.g., an entity of the 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] In 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 entity of the 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 ID / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the computing instance. For example, an OBO token received by the Service A control plane 112 in S604 may be included in the request sent in S609C.

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

[0148] In S610, which may be identical or similar to step S210 in Figure 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 compute instance owned by the Service B control plane 122 is connected to another compute instance owned by the dominant control plane (i.e., the Service A control plane 122). The connection request message contains a payload of any appropriate information associated with the connection. For example, the connection request may include ID / authorization information indicating that the Service A control plane 112 is authorized to initiate the creation of the connection. For example, an OBO token received by the Service A control plane 112 in S604 may be included in the request sent in S610. Furthermore, the connection request may specify the instances to be connected (e.g., Service A compute instance 131 and Service B compute instance 132). The compute instances have an identifier that uniquely identifies the instance, for example, their respective Oracle Cloud Identifier (OC They can be identified using their IDs. Furthermore, connection requests can also specify not only the IDs of the dominant and passive control planes, but also the IDs of the corresponding dominant and passive control planes.

[0149] Furthermore, in some embodiments, the connection imposes restrictions on the actions that (a) the customer and (b) the passive control plane can perform on the passive computing instance. In some implementations, the connection request sent in 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 actions that the connection allows or disallows on the passive computing instance by the customer and / or the passive control plane. The request may identify, by the connection, a list of one or more actions that the customer allows or disallows on the passive computing instance. In some implementations, a list of allowed actions is provided for each customer and passive service control plane. While the connection exists, actions not specifically specified in the list are not allowed. In some embodiments, the action of deleting a passive computing instance (e.g., service B computing instance 132) may no longer be included in the new list of actions allowed by the customer. In some embodiments, the action of deleting a connection may be allowed only to the owner, and not the customer.

[0150] In step S612, which may be identical or similar to step S212 in Figure 2, the service B control plane 122 (i.e., the passive control plane) performs processing in response to receiving a connection request. This includes recording (also called "posting") the details of the connection request received from the service A control plane 112 (i.e., the dominant control plane). This may include persisting connection information and modifying ownership and authorized behavior associated with the Service B computing instance 132 (i.e., a 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 trustworthiness of the OBO token and / or the authorization 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 a connection exists.

[0151] In step S614, which may be identical or similar to step S214 in Figure 2, the service B control plane 122 sends a connection response to the service A control plane 112 indicating that the connection will be processed by the service B control plane 122. The connection response message can also notify the service A control plane 112 that the connection details have been confirmed and will be implemented in accordance with the connection request message sent in step S610.

[0152] Optionally, in S616, which may be identical or similar to step S216 in Figure 2, the Service A control plane 112 (i.e., the dominant control plane) may send commands to the Service B control plane 122 (i.e., the passive control plane) to configure and / or update the Service B computing instance 132 within the customer tenant 130. For example, depending on the type of computing instance, the Service A control plane 112 may install a function (e.g., a chatbot computing instance skill) 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] In S618, which may be identical or similar to step S218 in Figure 2, the Service A control plane 112 (i.e., the dominant control plane) performs processing to connect the computing instance in response to receiving a 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 its records to hold the connection information in the dominant control plane. This may include storing the compartment ID of the Service B computing instance 132 (e.g., within customer tenant 130) as indicated by the Service B control plane 122. Furthermore, the Service A control plane 112 may identify what permitted actions have been agreed upon and / or provided by the Service B control plane 122. In some embodiments, as part of the processing performed in S618, the Service A control plane 112 may perform ID wiring so that the Service A computing instance 131 and the Service B computing instance 132 can communicate with each other. In some embodiments, as part of the processing performed in 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 connectivity.

[0154] At this point, both control planes agree to the connection and perform the necessary actions to complete the connection, such as storing information related to the connection and making certain permissions, ownership, and configuration changes. Service B control plane 122 (i.e., passive control plane) grants control and ownership of Service B computing instance 132 (i.e., passive computing instance) to Service A control plane 112 (i.e., dominant control plane). As a result, Service A control plane 112 (dominant control plane) now has control over Service A computing instance 131 (i.e., dominant computing instance). It has control and ownership of both the service A computing instance (131) 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] In S620, which may be identical or similar to step S220 in Figure 2, the Service A control plane workflow 114 can send a completion message back to the Service A control plane frontend 113 indicating that the connection was successfully established (or failed). Next, in S622, which may be identical or similar to step S222 in Figure 2, the Service A control plane frontend 113 can send a completion message back to the user 105 (for example, via a user device such as a console 106) indicating that the connection was successfully established (or failed).

[0156] As a result of the process shown in Figure 6, two computing instances from two different services operating in two different service tenants are normally separate and independent, and can connect and communicate with each other at the user 105's request, without dependencies or connections.

[0157] In some embodiments, embedded computing instances may connect automatically without user instruction or user involvement. For example, the process shown in Figure 2 can be executed without step S202. In other words, service B computing instance 132 can automatically connect to service A computing instance 131 without any specific user request. This automatic connection process may be carried out in embodiments where the service B control plane 122 and / or service B computing instance 132 are hidden from the user device (e.g., console 106), so that the user device (e.g., console 106) cannot view or access the service B control plane 122 and / or service B computing instance 132. In this case, service B computing instance 132 may be created outside the user's customer tenant 130, or it may be created within the service B control plane 122 instead.

[0158] As described above, in some embodiments, the connection imposes limitations on the operations that can be performed on the passive computing instance.

[0159] Figure 7 shows a process 700 for determining whether an operation is permitted, according to one embodiment. The process shown in Figure 7 may be implemented using hardware, or a combination thereof, in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each system, using hardware. The software may be stored in a non-temporary storage medium (e.g., a memory device). The methods shown in Figure 7 and described below are illustrative and not intended to be limiting. Figure 7 shows various processing operations that occur in a particular sequence or order, but is not intended to be limiting thereto. In some alternative embodiments, the processes may be executed in some different order, or some steps may be executed in parallel. In the process described in Figure 7, it is assumed that the service A computing instance 131 is a dominant computing instance, and the service B computing instance 132 connected to the service A computing instance 131 is a passive computing instance. Thus, the service A control plane 112 is a dominant control plane, and the service B control plane 122 is a passive control plane.

[0160] For example, referring to Figure 1, a user 105 other than the dominant control plane may want to perform an action on a passive instance (e.g., Service B computing instance 132) within the customer tenant 130. For instance, user 105 may want to delete a passive instance (e.g., Service B computing instance 132) within the customer tenant 130. Therefore, a user device (e.g., console 106) can send a request to perform an action (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 be the dominant control plane (e.g., service A control plane 112).

[0162] Therefore, the process in Figure 7 is initiated in step S705 when the 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) within the customer tenant 130. For example, this request is a delete request to delete the passive instance (e.g., Service B computing instance 132) within the 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 permitted.

[0163] A passive instance (e.g., Service B compute instance 132) resides 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 passive instance after it has been connected. A first authorization check is performed to determine whether the requested action on the passive instance (e.g., Service B compute instance 132) is permitted based on the policies associated with customer tenant 130. Thus, in step S710, the dominant control plane (e.g., Service A control plane 112) calls IDMAS 140, which determines whether the requested action (e.g., deleting the passive instance) is authorized based on the policies and permissions associated with or configured for the customer compartment.

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

[0165] In some embodiments, the customer tenant 130 may have a hierarchy of nodes representing compartments, where the root compartment is located at the top of the tree. This can be represented by a hierarchical tree. In some implementations, the hierarchy can represent an inclusion relationship. In such implementations, one or more policies can be associated with individual compartments within the hierarchy. The processing performed by IDMAS140 in S710 may first include identifying a specific 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 specific compartment containing 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 the compartment are determined as a result of the walk-up to the root compartment. As part of the processing in S710, the one or more policies (if any) associated with the specific compartment containing the passive instance (e.g., service B computing instance 132), and the policies identified by walking / traversing the hierarchical tree from the specific compartment to the root compartment are analyzed to determine whether the requested action in the request received in S705 is authorized.

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

[0167] If the dominant control plane (e.g., Service A control plane 112) is informed that the requested action (e.g., deletion of a passive instance) is authorized or permitted (i.e., the authorization check has passed), the dominant control plane (e.g., Service A control plane 112) may proceed to step S715 for additional processing. If the dominant control plane (e.g., Service A control plane 112) is informed that the requested action (e.g., deletion of a passive instance) is not permitted (i.e., the authorization check has failed), the dominant control plane (e.g., Service A control plane 112) may then refuse to perform the action in step S712, and the process may terminate with the request for the action to be performed rejected.

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

[0169] Therefore, 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, the process then proceeds to S720 where additional checks are performed. If the dominant control plane (e.g., Service A control plane 112) determines in S715 that there is no connection between the passive instance and the other computing instance (i.e., the passive instance is not involved in the connection), the process then proceeds to S717 where the requested action is permitted to be performed on the passive instance (e.g., Service B computing instance 132), and the process terminates. For example, if the requested action is to delete the passive instance, the passive instance is deleted.

[0170] Therefore, in step S720, the dominant control plane (e.g., service A control plane 112) determines whether the requested action (e.g., deletion of a passive instance) is restricted based on a stored list of permitted customer actions associated with the connection. The decision is made as to whether to allow a customer action. These allowed customer actions may be stored in the dominant control plane (e.g., Service A control plane 112) and / or passive control plane (e.g., Service B control plane 122) associated with the connection. The list of allowed customer actions may be called a dual authorization list. This is because if an action is included in the list, it is a restricted action that requires dual authorization. If an action is not included in the list, it is considered that dual authorization is not required, it is not a restricted action, and the first authorization (e.g., step S710) is 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 that action 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 in S720 by the passive control plane (e.g., service B control plane 122) that its operation is included in the list and therefore restricted, the process then proceeds to S725 where an additional check is performed. If the dominant control plane (e.g., service A control plane 112) is notified in S720 by the passive control plane (e.g., service B control plane 122) that its operation is not included in the list and therefore not restricted, the process proceeds to S717 where the requested operation is permitted to be performed on the passive instance (e.g., service B computing instance 132), and the process terminates. For example, if the requested operation is to delete the passive instance, the passive instance is deleted.

[0172] As described above, the connected passive instance (e.g., Service B compute instance 132) that exists in both customer tenants 130 is also owned by the dominant tenant (e.g., Service A tenant 115). Next, the requesting user performs a process to determine whether they are permitted to perform the requested action on the passive instance (e.g., Service B compute instance 132) based on the policies associated with the dominant tenant (e.g., Service A tenant 115).

[0173] Therefore, in step S725, the dominant control plane (e.g., Service A control plane 112) calls IDMAS 140, which determines whether the requested action (e.g., deletion of a passive instance) is permitted or authorized based on the 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 action to be authorized on the passive instance (e.g., Service B computing instance 132).

[0174] For example, as described above, when a connection is established, 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 actions that a customer can perform on the passive computing instance and a list of actions that the owner (e.g., the dominant control plane) can perform on the passive computing instance while the connection exists. If an action is not included in this list, that action is not permitted and cannot be performed by the requesting user. In some implementations, information identifying the permitted list of actions can be stored in the form of an access control list (ACL) that describes what access rights a user has to a resource.

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

[0176] This allows IDMAS140 to perform a second authorization to determine whether the requested action (e.g., deleting a passive instance) is authorized or permitted based on the policies associated with the dominant tenant (e.g., service A tenant 115). IDMAS140 can then send a response with the result 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 action (e.g., deletion of a passive instance) is authorized based on the connection-related information and / or the list of authorized actions in the ACL stored by the dominant control plane, and processing then proceeds to S730, where the requested action is permitted to be performed on the passive instance (e.g., Service B computing instance 132), and processing terminates. For example, if the requested action is to delete a passive instance, the passive instance is deleted.

[0178] If a dominant control plane (e.g., service A control plane 112) is notified that the requested action (e.g., deletion of a passive instance) is not on the list of authorized actions indicated in the connection-related information stored by the dominant control plane and / or ACL associated with the dominant control plane, then the dominant control plane (e.g., service A control plane 112) may refuse to perform the action in step S727, and the process may terminate with the request for the action to be performed rejected.

[0179] In some embodiments, the steps in Figure 7 can be intentionally designed to prevent certain actions 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 actions. One way to prevent the dominant control plane (e.g., Service A control plane 112) from performing certain actions on the passive instance (e.g., Service B computing instance 132) is to include a list of actions that are explicitly not allowed. However, current systems use a list of allowed actions (actions not listed are not allowed), and it is preferable to work with these existing frameworks. Therefore, a tiered policy can be utilized, as described above with respect to Figure 7. The first policy may permit an action (e.g., the customer compartment policy in step S710), but if a connection exists, the second policy will be checked, which may not permit the action (e.g., the owner compartment policy in step S725). The owner compartment policy can be designed to include a limited set of actions so that certain action requests fail (e.g., when checking the owner compartment policy in step S725). For example, it may be desirable to prohibit delete actions, so a request to delete a passive instance (e.g., service B computing instance 132) will 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 computing resources that are virtualized over a public network (e.g., the internet). In the IaaS model, the cloud computing provider can host the infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, the IaaS provider can also supply various services that accompany these infrastructure components (e.g., billing, monitoring, logging, load balancing, clustering, etc.). Therefore, since these services can be policy-driven, IaaS users may be able to implement policies that promote 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 install the rest of their application stack using the cloud provider's services. For example, a user might 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 install enterprise software on those 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. This cloud provider does not have to be a third-party service specializing in IaaS provision (e.g., providing, renting, or selling). Companies can also choose to deploy a private cloud and become their own infrastructure service provider.

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

[0184] In some examples, IaaS provisioning can even refer to acquiring the computers or virtual hosts to be used and installing the necessary libraries or services on them. In most cases, provisioning is not included in the deployment, so you may need to perform provisioning first.

[0185] In some cases, IaaS provisioning presents two distinct challenges. First, there's the initial challenge of provisioning an initial set of infrastructure before doing anything. Second, there's the challenge of evolving existing infrastructure after everything has been provisioned (e.g., adding new services, changing services, removing services). In some cases, these two challenges can be addressed by allowing the infrastructure configuration to be defined declaratively. In other words, infrastructure provisioning The "kucha" (for example, which components are needed and how they interact) can be defined by one or more configuration files. Therefore, the overall topology of the infrastructure (for example, which resources depend on which others and how they interact) 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, infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as core networks (e.g., a potentially on-demand pool of configurable and / or shared computing resources). In some examples, there may also be one or more inbound / outbound traffic group rules and one or more virtual machines (VMs) provisioned to define how inbound and / or outbound network traffic is set up. Other infrastructure elements such as load balancers and databases can also be provisioned. Infrastructure can evolve incrementally as more infrastructure elements are desired and / or added.

[0187] In some cases, continuous deployment techniques can be used to enable the deployment of infrastructure code across various virtual computing environments. Furthermore, the techniques described can enable infrastructure management within these environments. In some examples, a service team may write code that they want to deploy to one or more, but often many, different production environments (e.g., across various different geographical locations, and possibly worldwide). However, in some examples, the infrastructure to which the code will be deployed must first be set up. In some cases, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or code can be deployed using deployment tools after the infrastructure has been provisioned.

[0188] Figure 8 is a block diagram 800 showing an example pattern of an IaaS architecture according to at least one embodiment. A service operator 802 can be communicatively coupled to a secure host tenant 804 which may include a virtual cloud network (VCN) 806 and a secure host subnet 808. In some examples, the service operator 802 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, mobile phones, iPad®, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass® head-mounted displays), running software such as Microsoft Windows Mobile®, and / or various mobile operating systems such as iOS®, Windows Phone, Android, BlackBerry 8, Palm OS, and the Internet, email, short message service (SMS), Blackberry®, or other valid communication protocols. Alternatively, the client computing device may be a general-purpose personal computer, including, for example, personal computers and / or laptop computers running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux® operating systems. Client computing devices can be workstation computers running any of the various 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 that can communicate via a network that has access to the VCN806 and / or the Internet.

[0189] VCN806 may include a local peering gateway (LPG) 810 that can communicately connect to Secure Shell (SSH) VCN812 via LPG810 contained within SSH VCN812. SSH VCN812 may include an SSH subnet 814, and SSH VCN812 may communicately connect to control plane VCN816 via LPG810 contained within control plane VCN816. Furthermore, SSH VCN812 may communicately connect to data plane VCN818 via LPG810. Control plane VCN816 and data plane VCN818 may be contained within a service tenant 819, which may be owned and / or operated by an IaaS provider.

[0190] The control plane VCN 816 may include a control plane demilitarized zone (DMZ) layer 820 that functions as a perimeter network (e.g., part of the corporate network between the corporate intranet and the external network). DMZ-based servers have limited liability and can help deter breaches. Furthermore, the DMZ layer 820 may include a control plane application layer 824 that may include one or more load balancer (LB) subnets 822, an application subnet 826, and a control plane data layer 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 layer 820 can be communicatively coupled to the application subnet 826 included in the control plane application layer 824 and an internet gateway 834 that may be included in the control plane VCN 816, and the application subnet 826 can be communicatively coupled to the DB subnet 830, a service gateway 836, and a network address translation (NAT) gateway 838 included in the control plane data layer 828. The control plane VCN816 may include a service gateway 836 and a NAT gateway 838.

[0191] The control plane VCN 816 may include a data plane mirror application layer 840 which may include an application subnet 826. The application subnet 826 included in the data plane mirror application layer 840 may include a virtual network interface controller (VNIC) 842 which can run a compute instance 844. The compute instance 844 may communicatively combine the application subnet 826 of the data plane mirror application layer 840 with the application subnet 826 which may be included in the data plane application layer 846.

[0192] The data plane VCN818 may include a data plane application layer 846, a data plane DMZ layer 848, and a data plane data layer 850. The data plane DMZ layer 848 may include an LB subnet 822 that can be communicatively coupled to the application subnet 826 of the data plane application layer 846 and the internet gateway 834 of the data plane VCN818. The application subnet 826 may be communicatively coupled to the service gateway 836 of the data plane VCN818 and the NAT gateway 838 of the data plane VCN818. The data plane data layer 850 may also include a DB subnet 830 that can be communicatively coupled to the application subnet 826 of the data plane application layer 846.

[0193] The Internet gateway 834 of the control plane VCN816 and data plane VCN818 can be communicatively connected to a metadata management service 852, which can be communicatively connected to the public internet 854. The public internet 854 can be communicatively connected to the NAT gateway 838 of the control plane VCN816 and data plane VCN818. The service gateway 836 of the control plane VCN816 and data plane VCN818 can be communicatively connected to a cloud service 856.

[0194] In some cases, a service gateway 836 on the control plane VCN816 or data plane VCN818 can make application programming interface (API) calls to a cloud service 856 without going through the public internet 854. API calls from the service gateway 836 to the 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 an API call to the service gateway 836.

[0195] In some examples, a secure host tenant 804 can connect directly to a service tenant 819, which may otherwise be isolated. A secure host subnet 808 can communicate with an SSH subnet 814 via an LPG 810, which can enable bidirectional communication through systems that would otherwise be isolated. Connecting the secure host subnet 808 to the SSH subnet 814 allows the secure host subnet 808 to access other entities within the service tenant 819.

[0196] The control plane VCN816 can enable users of service tenant 819 to set up or otherwise provision desired resources. Desired resources provisioned within the control plane VCN816 can be deployed or otherwise used within the data plane VCN818. In some examples, the control plane VCN816 can be separated from the data plane VCN818, and the data plane mirror application layer 840 of the control plane VCN816 can communicate with the data plane application layer 846 of the data plane VCN818 via a VNIC 842 which may be included in the data plane mirror application layer 840 and the data plane application layer 846.

[0197] In some examples, a system user or customer may make requests, such as create, read, update, or delete (CRUD) operations, via the public internet 854, which can communicate the requests to the metadata management service 852. The metadata management service 852 can communicate the requests to the control plane VCN 816 via the internet gateway 834. This request may be received by the LB subnet 822, which is included in the control plane DMZ layer 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 the application subnet 826, which is included in the control plane application layer 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 the NAT gateway 838, which can make calls to the public internet 854. Memory that may be desirable to be stored by the request can be stored in the DB subnet 830.

[0198] In some examples, the data plane mirror application layer 840 can facilitate direct communication between the control plane VCN816 and the data plane VCN818. For example, changes, updates, or other appropriate modifications to the configuration can be included in the data plane VCN818. It may be desirable to apply this to the resources. Through VNIC842, the control plane VCN816 can communicate directly with the resources included in the data plane VCN818, thereby enabling configuration changes, updates, or other appropriate modifications to the resources included in the data plane VCN818.

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

[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 invoked by the IaaS provider's customers without calling the public internet 854. The IaaS provider's customers may prefer this embodiment because the database used by the customer may be controlled by the IaaS provider and stored in a service tenant 819 which can be isolated from the public internet 854.

[0201] Figure 9 is a block diagram 900 illustrating another pattern example of an IaaS architecture according to at least one embodiment. A service operator 902 (e.g., service operator 802 in Figure 8) can be communicatively coupled to a secure host tenant 904 (e.g., secure host tenant 804 in Figure 8) and a secure host subnet 908 (e.g., secure host subnet 808 in Figure 8), which may include a virtual cloud network (VCN) 906 (e.g., VCN806 in Figure 8). The VCN906 may include a local peering gateway (LPG) 910 (e.g., LPG810 in Figure 8), which can be communicatively coupled to an SSH VCN912 (e.g., SSH VCN812 in Figure 8) via the LPG810 contained within the Secure Shell (SSH) VCN912. SSH VCN912 may include SSH subnet 914 (e.g., SSH subnet 814 in Figure 8), and SSH VCN912 may be communicably coupled to control plane VCN916 (e.g., control plane VCN816 in Figure 8) via LPG910 included in control plane VCN916. Control plane VCN916 may include service tenant 919 (e.g., service tenant 819 in Figure 8), and data plane VCN918 (e.g., data plane VCN818 in Figure 8) may include customer tenant 921, which may be owned or operated by a user or customer of the system.

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

[0203] The control plane VCN916 may include a data plane mirror application layer 940 (e.g., data plane mirror application layer 840 in Figure 8) which may include an application subnet 926. The application subnet 926 included in the data plane mirror application layer 940 may include a virtual network interface controller (VNIC) 942 (e.g., VNIC 842) which can run a compute instance 944 (e.g., similar to compute instance 844 in Figure 8). Compute instance 944 can facilitate communication between the application subnet 926 of the data plane mirror application layer 940 and the application subnet 926 that can be included in the data plane application layer 946 (e.g., data plane application layer 846 in Figure 8) via the VNIC 942 included in the data plane mirror application layer 940 and the VNIC 942 included in the data plane application layer 946.

[0204] The Internet gateway 934 included in the control plane VCN916 can be communicatively connected to the metadata management service 952 (for example, the metadata management service 852 in Figure 8), and the metadata management service 952 can be communicatively connected to the public internet 954 (for example, the public internet 854 in Figure 8). The public internet 954 can be communicatively connected to the NAT gateway 938 included in the control plane VCN916. The service gateway 936 included in the control plane VCN916 can be communicatively connected to the cloud service 956 (for example, the cloud service 856 in Figure 8).

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

[0206] In another example, an IaaS provider's customer might have a database residing within customer tenant 921. In this example, control plane VCN916 could include a data plane mirror app layer 940 that could include app subnet 926. The data plane mirror app layer 940 could reside within data plane VCN918, but it does not have to reside within data plane VCN918. That is, the data plane mirror app layer 940 can access customer tenant 921, but it may not reside in data plane VCN918, or it may not be owned or operated by the IaaS provider's customer. The data plane mirror app layer 940 makes calls to data plane VCN918. It may be configured to do so, but does not have to be configured to make calls to any entities included in the control plane VCN916. The customer may want to deploy or otherwise use resources in the data plane VCN918 provisioned within the control plane VCN916, and the data plane mirror app layer 940 can facilitate the customer's desired deployment or other use of resources.

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

[0208] In some embodiments, the cloud service 956 can be invoked by the service gateway 936 to access services that may not exist on the public internet 954, the control plane VCN 916, or the data plane VCN 918. The connection between the cloud service 956 and the control plane VCN 916 or the data plane VCN 918 may not exist or may not be continuous. The cloud service 956 may reside on another network owned or operated by the IaaS provider. The cloud service 956 may be configured to receive calls from the service gateway 936, or it 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 the control plane VCN 916 may be isolated from cloud services 956 that do not have to be in the same region as the control plane VCN 916. For example, the control plane VCN 916 may be located in "region 1", and the cloud service "deployment 8" may be located in regions 1 and "region 2". If a call to deployment 8 is made by a service gateway 936 included in the control plane VCN916 in region 1, that call may be sent to deployment 8 in region 1. In this example, the control plane VCN916, i.e., deployment 8 in region 1, may not be communicatively coupled to, or otherwise not communicating with, deployment 8 in region 2.

[0209] Figure 10 is a block diagram 1000 illustrating another pattern example of an IaaS architecture according to at least one embodiment. A service operator 1002 (e.g., service operator 802 in Figure 8) can be communicatively coupled to a secure host tenant 1004 (e.g., secure host tenant 804 in Figure 8) and a secure host subnet 1008 (e.g., secure host subnet 808 in Figure 8), which may include a virtual cloud network (VCN) 1006 (e.g., VCN806 in Figure 8). VCN 1006 may include an LPG 1010 (e.g., LPG810 in Figure 8) which can be communicatively coupled to SSH VCN 1012 (e.g., SSH VCN812 in Figure 8) via an LPG 1010 contained in SSH VCN 1012. SSH VCN1012 may include SSH subnet 1014 (e.g., SSH subnet 814 in Figure 8), and SSH VCN1012 may be communicably coupled to control plane VCN1016 (e.g., control plane VCN816 in Figure 8) via LPG1010 included in control plane VCN1016, and to data plane VCN1018 (e.g., data plane 818 in Figure 8) via LPG1010 included in data plane VCN1018. Control plane VCN1016 and data plane VCN1018 may be included in service tenant 1019 (e.g., service tenant 819 in Figure 8).

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

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

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

[0213] The Internet gateway 1034, which is included in the control plane VCN1016 and the data plane VCN1018, can communicate with a metadata management service 1052 (for example, the metadata management system 852 in Figure 8), which can communicate with the public internet 1054. The public internet 1054 is the control plane The lane VCN1016 is included in the NAT gateway 1038, which is included in the data plane VCN1018, and can be communicated to. The service gateway 1036, which is included in the control plane VCN1016 and is included in the data plane VCN1018, can be communicated to the cloud service 1056.

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

[0215] In some examples, an IaaS provider's customer may request the IaaS provider to grant temporary network access and a function to be added to a dataplane tier application 1046. The code to perform the function may run on VMs 1066(1)-(N), and the code may not be configured to run elsewhere on the dataplane VCN 1018. Each VM 1066(1)-(N) may be connected to one customer tenant 1070. Each container 1071(1)-(N) contained within VM 1066(1)-(N) may be configured to run the code. In this case, a double isolation may exist (for example, container 1071(1)-(N) running the code, and container 1071(1)-(N) may be contained within at least VM 1066(1)-(N) in an untrusted application subnet 1062), which may help prevent incorrect or otherwise undesirable code from damaging the IaaS provider's network or another customer's network. Containers 1071(1)-(N) may be communicatively coupled to customer tenant 1070 and may be configured to send or receive data from customer tenant 1070. Containers 1071(1)-(N) may not be configured to send or receive data from any other entities in the data plane VCN1018. Once code execution is complete, the IaaS provider may terminate or otherwise dispose of containers 1071(1)-(N).

[0216] In some embodiments, a trusted application subnet 1060 may execute code that may be owned or operated by the IaaS provider. In this embodiment, the trusted application subnet 1060 may be communicatively coupled to a DB subnet 1030 and configured to perform CRUD operations in the DB subnet 1030. An untrusted application subnet 1062 may be communicatively coupled to a DB subnet 1030, but in this embodiment, the untrusted application subnet may be configured to perform read operations in the DB subnet 1030. Containers 1071(1)~(N), which may be included in each customer's VM 1066(1)~(N) and may execute code from the customer, do not need to be communicatively coupled to the DB subnet 1030.

[0217] In other embodiments, the control plane VCN1016 and the data plane VCN1018 do not have to be directly communicatively coupled. In this embodiment, there is no direct communication between the control plane VCN1016 and the data plane VCN1018. However, communication can be performed indirectly through at least one method. The LPG1010 may be established by an IaaS provider that can facilitate communication between the control plane VCN1016 and the data plane VCN1018. In another example, the control plane VCN1016 or the data plane VCN1018 can make a call to the cloud service 1056 via the service gateway 1036. For example, control plane VCN1 A call from 016 to cloud service 1056 may include a request for a service that can communicate with data plane VCN1018.

[0218] Figure 11 is a block diagram 1100 illustrating another pattern example of an IaaS architecture according to at least one embodiment. A service operator 1102 (e.g., service operator 802 in Figure 8) can be communicatively coupled to a secure host tenant 1104 (e.g., secure host tenant 804 in Figure 8) and a secure host subnet 1108 (e.g., secure host subnet 808 in Figure 8), which may include a virtual cloud network (VCN) 1106 (e.g., VCN806 in Figure 8). VCN 1106 may include an LPG 1110 (e.g., LPG810 in Figure 8) which can be communicatively coupled to SSH VCN 1112 (e.g., SSH VCN812 in Figure 8) via an LPG 1110 contained in SSH VCN 1112. SSH VCN1112 may include SSH subnet 1114 (e.g., SSH subnet 814 in Figure 8), and SSH VCN1112 may be communicably coupled to control plane VCN1116 (e.g., control plane VCN816 in Figure 8) via LPG1110 included in control plane VCN1116, and to data plane VCN1118 (e.g., data plane 818 in Figure 8) via LPG1110 included in data plane VCN1118. Control plane VCN1116 and data plane VCN1118 may be included in service tenant 1119 (e.g., service tenant 819 in Figure 8).

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

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

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

[0222] The Internet gateway 1134, included in the control plane VCN1116 and data plane VCN1118, can communicate with a metadata management service 1152 (for example, the metadata management system 852 in Figure 8), which can communicate with the public internet 1154. The public internet 1154 can communicate with a NAT gateway 1138, included in the control plane VCN1116 and data plane VCN1118. The service gateway 1136, included in the control plane VCN1116 and data plane VCN1118, can communicate with a cloud service 1156.

[0223] In some examples, the pattern shown by the architecture in block diagram 1100 of Figure 11 may be considered an exception to the pattern shown by the architecture in block diagram 1000 of Figure 10, which may be desirable for the IaaS provider's customers when the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected area). Each container 1167(1)~(N) contained within each customer's VM 1166(1)~(N) is accessible by the customer in real time. Each container 1167(1)~(N) may be configured to make calls to each secondary VNIC 1172(1)~(N) contained within the application subnet 1126 of the data plane application layer 1146, which can be included in the container exit VCN 1168. The secondary VNICs 1172(1)~(N) can send calls to a NAT gateway 1138, which can send calls to the public internet 1154. In this example, the containers 1167(1)-(N), which customers can access in real time, can be isolated from the control plane VCN1116 and from other entities included in the data plane VCN1118. The containers 1167(1)-(N) may also be isolated from resources from other customers.

[0224] In another example, a customer can use containers 1167(1)-(N) to invoke cloud service 1156. In this example, the customer can execute code within containers 1167(1)-(N) to request 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 the 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, the LB subnet can send requests to the application subnet 1126, which can then send requests to the cloud service 1156 via the service gateway 1136.

[0225] It should be understood that the IaaS architectures 800, 900, 1000, and 1100 shown in the figures may have components other than those shown. Furthermore, the embodiments shown in the figures are only some examples of cloud infrastructure systems that may incorporate embodiments of this disclosure. In some other embodiments, the IaaS system may have more or fewer components than those shown in the figures, may combine two or more components, or may have different configurations or arrangements of components.

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

[0227] Figure 12 shows an exemplary computer system 1200 in which various embodiments can be implemented. System 1200 can be used to implement any of the computer systems described above. As shown in the figure, computer system 1200 includes a processing unit 1204 that communicates with several 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. The storage subsystem 1218 includes a tangible computer-readable storage medium 1222 and system memory 1210.

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

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

[0230] In various embodiments, the processing unit 1204 can execute various programs in response to program code and can maintain multiple concurrently running programs or processes. At any given time, some or all of the program code being executed may be This can be mounted on the processor 1204 and / or the memory subsystem 1218. Through appropriate programming, the processor 1204 can provide the various functions described above. The computer system 1200 may further include a processing acceleration unit 1206 which may include a digital signal processor (DSP), a dedicated processor, etc.

[0231] The I / O subsystem 1208 may include user interface input devices and user interface output devices. User interface input devices may include pointing devices such as keyboards, mice or trackballs, touchpads or touchscreens integrated into displays, scroll wheels, click wheels, dials, buttons, switches, keypads, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, a user accessing a Microsoft Xbox (registered Microsoft Kinect® motion sensors and other motion sensors enable control and interaction with input devices via a natural user interface using gestures and voice commands, such as the 360 ​​game controller. This may include eye and / or gesture recognition devices. User interface input devices may also include eye gesture recognition devices, such as Google Glass (registered trademark). The blinking detector detects the user's eye activity (e.g., blinking when taking a photo and / or selecting a menu) and translates the eye gestures into input to an input device (e.g., Google Glass®). The interface input device may include a voice recognition sensing device that enables the user to interact with a voice recognition system (e.g., Siri® Navigator) through voice commands.

[0232] User interface input devices may also include 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 readers, 3D scanners, 3D printers, laser rangefinders, and eye-tracking devices. Furthermore, user interface input devices may also include medical imaging input devices such as computed tomography, magnetic resonance imaging, situated radiography, and medical ultrasound devices. User interface input devices may also include audio input devices such as MIDI keyboards and digital musical instruments.

[0233] User interface output devices may include non-visual displays such as display subsystems, indicator lights, or audio output devices. Display subsystems may include flat panel devices such as those using cathode ray tubes (CRTs), liquid crystal displays (LCDs), or plasma displays, projection devices, touchscreens, etc. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1200 to a user or 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, audio output devices, and modems.

[0234] The computer system 1200 may include a storage subsystem 1218 having software elements that are shown to be currently located in the system memory 1210. The system memory 1210 is loadable and executable on the processing unit 1204. It can store program instructions, as well as data generated during the execution of these programs.

[0235] Depending on the configuration and type of the computer system 1200, the 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 the processing unit 1204 and / or currently operating and executing by the processing unit 1204. In some implementations, the system memory 1210 may contain several different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS) containing basic routines that help transfer information between elements within the computer system 1200, such as during startup, may typically be stored in ROM. As an example, but not an limitation, the system memory 1210 also represents application programs 1212, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), and also represents program data 1214 and operating systems 1216. For example, operating systems 1216 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 iOS, Windows This may include mobile operating systems such as (registered trademark)Phone, Android® OS, BlackBerry® 12 OS, and Palm® OS.

[0236] The storage subsystem 1218 may also provide a tangible, computer-readable storage medium for storing basic programming and data structures that provide the functionality of several embodiments. When executed by the processor, software (programs, code modules, instructions) that provides the aforementioned functionality 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 this disclosure.

[0237] The storage subsystem 1200 may also include a computer-readable storage medium reader 1220 which can be further connected to the computer-readable storage medium 1222. The computer-readable storage medium 1222, together with the system memory 1210, and optionally in combination with the system memory 1210, may comprehensively represent remote, local, fixed, and / or removable storage devices and storage media for temporary and / or more permanent storage, storage, transmission, and retrieval of computer-readable information.

[0238] Computer-readable storage media 1222 containing code or a portion of code may also include any suitable media known or used in the art, including, but not limited to, storage and communication media such as volatile and non-volatile, removable and non-removable media implemented in any way or technique 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 technologies, CD-ROM, digital versatile disk (DVD) or other optical storage devices, magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices, or other tangible computer-readable media. This may also include any other media that can be used to transmit data signals, data transmissions, or desired information and are accessible by the computing system 1200. This could include any intangible computer-readable medium.

[0239] For example, the computer-readable storage medium 1222 may include hard disk drives that read or write to non-removable non-volatile magnetic media, magnetic disk drives that read or write to removable non-volatile magnetic disks, and optical disk drives that read or write to removable non-volatile optical disks such as CD-ROMs, DVDs, and Blu-ray® discs, or other optical media. The computer-readable storage medium 1222 may also include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD discs, and digital videotapes. 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. Disk drives and associated computer-readable media can provide computer-readable instructions, data structures, program modules, and other non-volatile storage devices for computer system 1200.

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

[0241] In some embodiments, the communication subsystem 1224 may also receive input 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 can use the computer system 1200.

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

[0243] Furthermore, the communication subsystem 1224 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 1228 of real-time events and / or event updates 1230, which may be inherently continuous or unrestricted without explicit termination. Examples of applications may include, for instance, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, and automotive traffic monitoring.

[0244] The communication 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 communicating with one or more streaming data source computers connected to the computer system 1200.

[0245] The computer system 1200 can be one of several types, including handheld portable devices (e.g., iPhone® mobile phone, iPad® computing tablet, PDA), wearable devices (e.g., Google Glass), and (Registered trademark) Head-Mounted Display, including PCs, workstations, mainframes, kiosks, server racks, or any other data processing systems.

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

[0247] While specific embodiments have been described, various modifications, changes, alternative structures, and equivalents are also included within the scope of this disclosure. The embodiments are not limited to operation within a particular data processing environment, but can freely operate within multiple data processing environments. Furthermore, while the embodiments have been described using a specific set of transactions and steps, it will be apparent to those skilled in the art that the scope of this disclosure is not limited to the described set of transactions and steps. The various features and aspects of the embodiments described above can be used individually or in combination.

[0248] Furthermore, while embodiments have been described using specific combinations of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of this disclosure. Embodiments can be implemented using hardware alone, software alone, or a combination thereof. The various processes described herein can be implemented on the same processor or on any combination of different processors. Thus, where a component or module is described as being configured to perform a certain operation, such configuration can be achieved, for example, by designing an electronic circuit that performs the operation, by programming a programmable electronic circuit (e.g., a microprocessor) to perform the operation, or by any combination thereof. Processes can communicate using a variety of techniques, including but not limited to conventional techniques for inter-process communication, different pairs of processes can use different techniques, or the same pair of processes can use different techniques at different times.

[0249] Therefore, the specification and drawings should be considered illustrative rather than restrictive. However, additions, subtractions, deletions, and other modifications and changes may be made without departing from the broader intent and scope set forth in the claims. This is clear. Therefore, although specific embodiments of disclosure have been described, they are not intended to be limiting. Various modifications and equivalents are included in the following claims.

[0250] In the context describing the embodiments disclosed (particularly in the context of the following claims), the use of the terms “a,” “an,” “the,” and similar reference subjects should be interpreted as covering both singular and plural forms unless otherwise indicated herein or otherwise clearly inconsistent with the context. The terms “comprising,” “having,” “including,” and “containing” should be interpreted as unrestricted terms (i.e., “including but not limited to”) unless otherwise specified. The term “connected” should be interpreted as being partially or entirely contained, attached, or combined within, even if something is intervening. The descriptions of ranges of values ​​herein are merely intended to serve as a simplified way of individually referring to each individual value within that range unless otherwise indicated herein, and each individual value is incorporated herein as if it were individually described herein. All methods described herein may be performed in any appropriate order unless otherwise indicated herein or otherwise clearly inconsistent with the context. Any use of any examples or exemplary language provided herein (e.g., "etc.") is intended solely to better illustrate embodiments and, unless otherwise requested, does not impose any limitation on the scope of this disclosure. Nothing in this specification should be construed as indicating that any unclaimed element is essential for the practice of this disclosure.

[0251] Unless otherwise specified, disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood within the context of its general use to indicate that an item, term, etc., can be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Therefore, such disjunctive language is not, and should not, be intended to mean that a particular embodiment requires the presence of at least one X, at least one Y, or at least one Z, respectively.

[0252] Preferred embodiments of the Disclosure, including the best known modes for carrying out the Disclosure, are described herein. Variations of these preferred embodiments may become apparent to those skilled in the art by reading the foregoing description. Those skilled in the art should be able to adopt such variations as needed, and the Disclosure may also be carried out in ways other than those specifically described herein. Accordingly, the Disclosure includes all modifications and equivalents of the subject matter described in the claims appended herein, as permitted by applicable law. Furthermore, unless otherwise indicated herein, any combination of the elements described above in all possible variations thereof is incorporated herein.

[0253] All references cited herein, including publications, patent applications, and patents, are incorporated herein by reference to the same extent as they are incorporated herein in whole, provided that each reference is individually and specifically indicated as being incorporated herein by reference.

[0254] While aspects of the disclosure are described in the aforementioned specification with reference to specific embodiments, those skilled in the art will recognize that the disclosure is not limited thereto. The various features and aspects of the disclosure described above can be used individually or in combination. Furthermore, embodiments can be used in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. Accordingly, this specification and the drawings should be considered illustrative, not restrictive.< / instanceid>

Claims

1. A method performed on a computer to connect computing instances from different tenants, A first control plane for a first service includes 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, wherein the first computing instance is controlled by the first control plane, the second computing instance is controlled by the second control plane, the first computing instance resides within a customer tenant, the second computing instance resides within the customer tenant, and the first computing instance is isolated from the second computing instance within the customer tenant. The aforementioned method, The first control plane performs a set of processing operations to create the connection between the first computing instance and the second computing instance, A method further comprising, after executing the set of processing operations, the connection thereby allowing the first control plane to gain control of the second computing instance and enabling communication between the first computing instance and the second computing instance.

2. Executing the aforementioned set of processing operations means The method according to claim 1, wherein the first control plane obtains a token indicating that the first control plane can communicate with the second control plane on behalf of the customer.

3. Executing the aforementioned set of processing operations means The method according to claim 1 or 2, wherein the first control plane determines a set of permitted operations that can be performed on the second computing instance.

4. Executing the aforementioned set of processing operations means The first control plane includes transmitting a connection request to the second control plane, the connection request including information identifying the first computing instance and the second computing instance, and the second control plane stores information regarding the connection. Executing the aforementioned set of processing operations means The method according to claim 1, claim 2, or claim 3, wherein the first control plane includes storing information relating to the connection.

5. The method according to any one of the preceding claims, 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. The method according to any one of the preceding claims, further comprising the first control plane creating the first computing instance of the first service within the customer tenant before performing the set of processing operations for creating the connection.

7. Executing the aforementioned set of processing operations means The method according to any one of the preceding claims, comprising the first control plane sending a request to the second control plane to create the 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.

8. The method according to any one of the preceding claims, wherein the first service is an enterprise resource planning (ERP) service and the second service is a conversational artificial intelligence (AI) service.

9. The method according to any one of the preceding claims, wherein, after performing the set of processing operations, the connection restricts the second control plane from performing at least one operation on the second computing instance.

10. A non-temporary computer-readable storage medium for storing computer-executable instructions, wherein, when the computer-executable instructions are executed, they cause one or more processors of a computer system to execute a method, and the method is The system includes 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, the second computing instance is controlled by a second control plane, the first computing instance resides within a customer tenant, the second computing instance resides within the customer tenant, and the first computing instance is isolated from the second computing instance within the customer tenant. The aforementioned method, Executing a set of processing operations to create the connection between the first computing instance and the second computing instance, A non-temporary computer-readable storage medium that causes a method to be performed, which includes, after performing the set of processing operations, obtaining control of the second computing instance by the connection, and enabling communication between the first computing instance and the second computing instance.

11. Executing the aforementioned set of processing operations means The non-temporary computer-readable storage medium according to claim 10, comprising obtaining a token indicating that the computer system can communicate with the second control plane on behalf of the customer.

12. Executing the aforementioned set of processing operations means A non-temporary computer-readable storage medium according to claim 10 or 11, comprising determining a set of permitted operations that can be performed on the second computing instance.

13. Executing the aforementioned set of processing operations means This 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, and the second control plane storing information regarding the connection. Executing the aforementioned set of processing operations means A non-temporary computer-readable storage medium according to claim 10, claim 11, or claim 12, comprising storing information relating to the aforementioned connection.

14. A non-temporary computer-readable storage medium according to any one of claims 10 to 13, 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. A computer system, Processor and The process includes a memory that is executable by the processor and is configured to store a plurality of instructions that cause the processor to perform processing when executed, and the processing is The system includes 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, the second computing instance is controlled by a second control plane, the first computing instance resides within a customer tenant, the second computing instance resides within the customer tenant, and the first computing instance is isolated from the second computing instance within the customer tenant. The aforementioned process is, Executing a set of processing operations to create the connection between the first computing instance and the second computing instance, A computer system comprising: executing the set of processing operations; obtaining control of the second computing instance through the connection; and enabling communication between the first computing instance and the second computing instance.

16. Executing the aforementioned set of processing operations means The computer system according to claim 15, further comprising obtaining a token indicating that the computer system can communicate with the second control plane on behalf of the customer.

17. Executing the aforementioned set of processing operations means The computer system according to claim 15 or 16, comprising determining a set of permitted operations that can be performed on the second computing instance.

18. Executing the aforementioned set of processing operations means This 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, and the second control plane storing information regarding the connection. Executing the aforementioned set of processing operations means A computer system according to claim 15, claim 16, or claim 17, comprising storing information relating to the aforementioned connection.

19. The computer system according to any one of claims 15 to 18, 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. Before executing the set of processing operations for creating the connection, within the customer tenant The computer system according to claim 15, further comprising creating the first computing instance of the first service.

21. A device for connecting computing instances, comprising means for performing steps of the method according to any one of claims 1 to 9.

22. A computer program product that, when executed by a processor, includes computer instructions that implement the steps of the method described in any one of claims 1 to 9.

Images