Remote Cloud Function Call Service

Abstract

The present disclosure relates to a framework that enables a serverless function to be executed in one cloud environment based on the occurrence of events / notifications from services in a completely different cloud environment. A target agent obtains a notification from a source agent, where the target agent is deployed in a target cloud environment and the source agent is deployed in a source cloud environment different from the target cloud environment. The target agent determines a function to call based on the notification. Once the target agent successfully verifies whether it is permitted to call a function deployed in the target customer tenancy of the target cloud environment, the target agent calls the function in the target customer tenancy of the target cloud environment.

Description

Technical Field

[0001] Cross - reference to Related Applications This application claims the benefit of the filing dates of U.S. Provisional Patent Application No. 63 / 339,753, filed May 9, 2022, and U.S. Patent Application No. 17 / 850,693, filed Jun. 27, 2022, each of which is hereby incorporated by reference in its entirety for all purposes.

[0002] Field The present disclosure relates to a framework that enables a serverless function to be executed in a cloud environment based on the occurrence of events / notifications from services of a completely different cloud environment.

Background Art

[0003] Background Cloud service providers (CSPs) provide a set of services to customers of cloud environments. One such service is what is referred to as function - as - a - service (FaaS). FaaS is a category of cloud computing services that provides a platform that enables customers to develop, execute, and manage application functions without incurring the complexity of building and maintaining the infrastructure normally associated with application development and launch. Building an application according to this model is one way to implement a “serverless” architecture and is commonly used when building microservices applications. Some cloud providers (e.g., Amazon Web Services (AWS), Google Cloud Platform (GCP) (registered trademark), and Oracle Cloud Infrastructure) offer versions of this service on the public cloud.

[0004] Typically, a CSP encourages the invocation of local functions by tightly integrating functions with other services provided by the CSP. In other words, as part of providing serverless functions, the CSP provides the function of integrating serverless functions with events / notifications from other native services supported in its cloud. For example, a customer can specify a serverless function that is invoked when an event occurs within the same cloud (e.g., when an object is added to a storage unit). However, currently, no CSP supports integrating serverless functions with events / notifications from services in different clouds in this way. Therefore, the current serverless function models of different CSPs restrict customers from leveraging cheaper resources (e.g., computing resources, storage resources, etc. in other cloud environments). The embodiments discussed in this specification address these and other problems both individually and collectively. Summary of the Invention Means for Solving the Problems

[0005] Overview The present disclosure generally relates to a framework that enables integrating serverless functions based on the occurrence of events / notifications from services in a completely different cloud environment in a certain cloud environment. In this specification, various embodiments are described, including methods, systems, non-transitory computer-readable storage media storing programs, code, or instructions executable by one or more processors, etc. These exemplary embodiments are not for limiting or defining the present disclosure, but are mentioned to provide examples to assist in understanding the present disclosure. Additional embodiments are discussed in the detailed description section, where further explanations are provided.

[0006] One aspect of the present disclosure provides a method. The method includes a target agent obtaining a notification from a source agent. The target agent is deployed in a target cloud environment, and the source agent is deployed in a source cloud environment different from the target cloud environment. The method further includes the target agent determining a function to be called based on the notification, verifying whether the target agent is permitted to call a function deployed in a target customer tenancy of the target cloud environment, and, in response to a successful verification, the target agent calling a function in the target customer tenancy of the target cloud environment.

[0007] Another aspect of the present disclosure provides a system. The system includes a processor and a memory that, when executed by the processor, cause the system to, at least, cause a target agent to obtain a notification from a source agent, where the target agent is deployed in a target cloud environment and the source agent is deployed in a source cloud environment different from the target cloud environment, cause the target agent to determine a function to be called based on the notification, verify whether the target agent is permitted to call a function deployed in a target customer tenancy of the target cloud environment, and, in response to a successful verification, cause the target agent to call a function in the target customer tenancy of the target cloud environment.

[0008] Another aspect of the present disclosure provides a non-transitory computer-readable medium storing specific computer-executable instructions that, when executed by a processor, cause a computer system to perform operations. The operations include the target agent obtaining a notification from the source agent. The target agent is deployed in a target cloud environment, and the source agent is deployed in a source cloud environment different from the target cloud environment. The operations further include the target agent determining a function to be called based on the notification, verifying whether the target agent is permitted to call a function deployed in the target customer tenancy of the target cloud environment, and, in response to a successful verification, the target agent calling a function in the target customer tenancy of the target cloud environment.

[0009] Another aspect of the present disclosure provides a computer program product including a computer program / instructions that, when executed by a processor, cause the processor to perform operations. The operations include the target agent obtaining a notification from the source agent. The target agent is deployed in a target cloud environment, and the source agent is deployed in a source cloud environment different from the target cloud environment. The operations further include the target agent determining a function to be called based on the notification, verifying whether the target agent is permitted to call a function deployed in the target customer tenancy of the target cloud environment, and, in response to a successful verification, the target agent calling a function in the target customer tenancy of the target cloud environment. Embodiments can be implemented by using a computer program product including a computer program / instructions that, when executed by a processor, cause the processor to perform any of the methods described in the present disclosure.

[0010] The above will become more apparent by reference to the following specification, claims, and accompanying drawings, together with other features and embodiments.

Brief Description of the Drawings

[0011]

Figure 1A

Figure 1B

Figure 2

Figure 3A

Figure 3B

Figure 4A

Figure 4B

Figure 5A

Figure 5B

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

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

[0013] Remote Function Invocation (RFI) is a framework of services and application programming interfaces (APIs) that enables users in a public cloud environment (e.g., a source cloud environment) to execute serverless workloads in a remote cloud environment (e.g., a target cloud environment) as a set of one or more functions as if such functions were being executed locally. In other words, a set of one or more functions appears as native functions of the source cloud environment.

[0014] The RFI framework provides a user with a programming structure for registering and invoking functions in response to notifications obtained from a service running in a different cloud environment in a certain remote cloud. For clarity, the cloud environment where notifications are generated is referred to herein as the "notification cloud environment", and the cloud environment where one or more functions are executed is referred to herein as the "execution cloud environment". It should be noted that the notification cloud environment is different from and independent of the execution cloud environment. Further, the RFI framework also provides a mechanism for polling (in the notification cloud environment) services that do not generate events to invoke functions in the execution cloud environment. In essence, with the RFI framework, cloud application developers can burst compute-sensitive workloads to other clouds in units of functions with simple application configuration changes. By doing so, the RFI framework enables users to utilize other cloud environments for higher availability and lower costs, or to obtain workload scalability.

[0015] It is understood that the delegation of functions to a remote cloud (i.e., the execution cloud environment) can be further complicated by the embedded nature in the application workflow. Functions can be triggered from many different services (i.e., in the notification cloud environment) and can call other functions or services. The disclosed RFI framework is a general framework of services and APIs that enables a user in one cloud environment to remotely call (and further execute) functions in another cloud environment. Further, it is noted that the RFI framework described herein can be easily extended to any number of public cloud environments that do not implicitly interoperate.

[0016] According to some embodiments, the RFI service framework provides a user interface and a command line interface (CLI) that provisions users of a cloud environment to configure RFI instances within a customer's tenancy included in the cloud environment. As described in detail herein, the RFI service framework has a notification forwarder component (referred to herein as a forwarder agent included in the notification cloud environment) that listens for events in the notification cloud environment and polls the service. The forwarder agent forwards such notifications to a remote cloud environment (i.e., the execution cloud environment), where the notifications are received by a receiver agent (referred to herein as a listener agent). The listener agent included in the execution cloud environment verifies the role and calls a function on behalf of the user. It is noted that the forwarder agent and the listener agent are located on either side of two cloud environments (i.e., the notification cloud environment and the execution cloud environment) connected by a secure inter-cloud notification bus. According to some embodiments, the notification bus is built on a highly reliable high-speed communication link (e.g., a FastConnect link) established between the two cloud environments.

[0017] According to some embodiments, the RFI service framework provides the user with the flexibility to define for any set of services in the notification cloud environment whether the user desires to receive notifications. Alternatively, the user can define for any service (within the notification cloud environment) whether the user desires to monitor the RFI instance (deployed in the notification cloud environment) polling and rules being triggered. An RFI instance in the notification cloud environment can convert a trigger into a notification. The notification is sent to the execution cloud environment where it triggers a function for the corresponding RFI instance (i.e., the RFI instance deployed in the execution cloud environment) to execute. It is understood that the user has already registered a specific function in the execution cloud environment (e.g., as FaaS).

[0018] According to some embodiments, on the notification cloud environment side, the user can receive notifications from services utilized by cloud resources or grant the RFI service permission to poll service instances through a standard role-based access control (RBAC) API. On the execution cloud environment side, the user gives the RFI service instance permission to call functions on behalf of the customer. It is understood that the RFI framework provides a multi-tenant, general-purpose, cloud and service-independent way to securely call remote functions on the optimal cloud according to the user's requirements. Further, the RFI service framework provides functions such as auditing, monitoring, logging, and metering capabilities.

[0019] Figure 1A shows an exemplary architecture of a Remote Function Invocation (RFI) service according to various embodiments. The architecture 100 of the RFI service includes a source cloud environment, herein referred to as the notification cloud environment (i.e., cloud environment I 101), and a target cloud environment, herein referred to as the execution cloud environment (i.e., cloud environment II 111). Each of the notification cloud environment 101 and the execution cloud environment 111 includes an instance of an RFI service tenancy. For example, as shown in Figure 1A, the notification cloud environment 101 includes an RFI service tenancy 105, herein referred to as the notification-side RFI service tenancy, and the execution cloud environment 111 includes an RFI service tenancy 115, herein referred to as the execution-side RFI service tenancy. Further, the notification cloud environment 101 includes a customer tenancy 102, and the execution cloud environment includes a customer tenancy 113.

[0020] The RFI service enables the execution of a function 117 deployed in the customer tenancy 113 of the execution cloud environment 111 in response to a notification received from the RFI service tenancy 105 (i.e., the notification-side RFI service tenancy) in the notification cloud environment 101. The notification-side RFI service tenancy 105 is configured to receive notifications from a notification source 103 deployed in the customer tenancy 102 of the notification cloud environment 101. Specifically, according to one embodiment, the notification-side RFI service tenancy 105 registers itself with a cloud resource 104A such that it is the target for receiving notifications regarding the occurrence of any event associated with the cloud resource 104A, or notifications generated by a service utilized by the cloud resource.

[0021] In some embodiments, the services utilized by the cloud resource 104A may not be able to generate any notifications (e.g., queuing services). In such cases, the notification-side RFI service tenancy 105 is configured to poll the service or message queue 104B or event bridge 104C to obtain notifications or determine the occurrence of events. The occurrence of an event or notification is associated with a request to execute a function. As described above, with the RFI framework, a user can utilize other cloud environments for higher availability, lower cost, etc. Thus, the notifications obtained by the notification-side RFI service tenancy 105 are sent to the execution-side RFI service tenancy 115, and the execution-side RFI service tenancy 115 executes the requested function 117 deployed in the customer tenancy 113 of the execution-side cloud environment. In this way, the RFI service framework enables the integration between a function executed in one cloud environment and an event / notification from a service in a completely different cloud environment. Details of the RFI service architecture are described with reference to FIG. 2 herein.

[0022] FIG. 1B shows a simplified flowchart 150 illustrating steps performed by an RFI service according to some embodiments. The processes shown in FIG. 1B can be executed by software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of respective systems, hardware, or combinations thereof. The software can be stored in a non-transitory storage medium (e.g., a memory device). The methods presented in FIG. 1B and described below are intended to be exemplary and non-limiting. FIG. 1B shows that various processing steps occur in a particular sequence or order, which is not intended to be limiting. In some alternative embodiments, the steps may be executed in some different order, or some steps may be executed in parallel.

[0023] The process starts at step 130, where a source RFI service tenancy (i.e., a notification-side RFI service tenancy) included in a source cloud environment (i.e., a notification cloud environment) receives a notification from a service utilized by cloud resources included in the source cloud environment. For example, a notification-side RFI tenancy 105 included in a notification cloud environment 101 receives a notification from a cloud resource (utilizing the service). In one embodiment, it is noted that the notification corresponds to a request to execute a function deployed in a target cloud environment (e.g., an execution cloud environment 111) different from the source cloud environment.

[0024] At step 135, the source RFI service tenancy sends the notification to a target RFI service tenancy (i.e., an execution-side RFI service tenancy) included in the target cloud environment (i.e., the execution-side environment). For example, the notification-side RFI service tenancy forwards the notification to an execution-side RFI service tenancy included in the execution cloud environment. Thereafter, the process moves to step 140, where the target RFI service tenancy (i.e., the execution-side RFI service tenancy) calls a function to be executed in the target cloud environment. For example, referring to FIG. 1A, an execution-side RFI service tenancy 115 calls a function 117 to be executed (deployed to a customer tenancy 113 of the execution cloud environment 111).

[0025] Referring now to FIG. 2, an exemplary detailed architecture of an RFI service according to various embodiments is shown. As shown in FIG. 2, an architecture 200 of the RFI service includes a source cloud environment (i.e., cloud environment I), herein referred to as a notification cloud environment 201, and a target cloud environment (i.e., cloud environment II), herein referred to as an execution cloud environment 231. As described above, the RFI service of the present disclosure aims to enable the integration of a serverless function in one cloud environment (e.g., the execution cloud environment 231) with an event / notification from a service in a completely different cloud environment (e.g., the notification cloud environment 201).

[0026] According to some embodiments, the RFI service tenancy is included in each of the notification cloud environment 201 and the execution cloud environment 231. For example, as shown in FIG. 2, the notification cloud environment 201 includes an RFI service tenancy 203 referred to herein as the notification-side RFI service tenancy, and the execution cloud environment 231 includes an RFI service tenancy 233 referred to herein as the execution-side RFI service tenancy. In the notification cloud environment 201, the notification-side RFI service tenancy 203 includes a forwarder agent 205 and a metadata database 215 associated with the forwarder agent 205. The notification cloud environment 201 further includes a customer tenancy 209 and an identity management service 216. The customer tenancy 209 includes one or more cloud resources 211 that utilize one or more services provided in the notification cloud environment 201.

[0027] According to some embodiments, in the execution cloud environment 231, the execution-side RFI service tenancy 233 includes a control plane 235 that hosts an RFI call service 234, a listener agent 236, and a mapping database 237 associated with the listener agent 236. The RFI call service 234 is a control plane component of a service that provides users with the flexibility to instantiate serverless function instances and can trigger the invocation of configured functions using notifications received from resources in different clouds. The execution cloud environment 231 further includes a customer tenancy 243, an identity management service 239, and a serverless function service 241. The customer tenancy 243 includes one or more functions 242 deployed therein. The serverless function service 241 includes a service in which a server used to execute a function is instantiated on demand in response to an invocation to call a certain function.

[0028] The notification cloud environment 201 is communicatively coupled to the execution cloud environment 231 via a secure transport channel. Specifically, in one embodiment, a forwarder agent 205 included in the notification cloud environment 201 is communicatively coupled to a listener agent 236 included in the execution cloud environment 231 via a secure communication channel 220 (e.g., a Fastconnect communication link). With respect to the RFI service, it is noted that the customer has a different set of resources (e.g., cloud resources 211 in the notification cloud environment 201) defined in a cloud environment that provides notifications regarding specified events. Further, the customer uses a serverless function service (e.g., serverless function service 241) deployed in a different cloud environment (e.g., the execution cloud environment 231) that the customer desires to use to offload the customer's compute workload for cost reduction purposes. In other words, the customer desires that a serverless function of the customer in one cloud provider be triggered based on events or notifications generated by resources in another cloud provider. According to some embodiments, to implement the functions described above, a setup or registration phase is provided, where the customer creates an instance of the RFI service (in the two cloud environments) and enters the necessary information regarding the notification source identifier and the notification target identifier. Details regarding the registration phase are described below with reference to FIGS. 3A and 3B.

[0029] According to some embodiments, a forwarder agent 205 included in the notification-side RFI service tenancy 203 (included in the notification cloud environment 201) registers itself with a cloud resource 211 (deployed in the customer tenancy 209 of the notification cloud environment 201) as a target to receive notifications from that cloud resource 211. Specifically, the forwarder agent 205 registers an endpoint (e.g., an HTTP endpoint) expected to receive notifications from the cloud resource 211.

[0030] (Deployed in the customer tenancy 209 of the notification cloud environment 201), when the cloud resource 211 receives a request to register as a target regarding a notification from the forwarder agent 205, it communicates with the identity management service 216 to verify the request from the forwarder 205. In one embodiment, when verifying the request, an authentication process is executed based on the subscription policy 213 defined by the user. The subscription policy 213 defines whether the forwarder agent 205 (i.e., within the RFI service account / tenancy 203) is permitted to subscribe to notifications from the cloud resource 211. It is noted that based on the subscription policy 213 defined by the user, trust is established between the forwarder agent 205 and the customer tenancy 209 in the notification cloud environment.

[0031] Once successfully verified, the forwarder agent 205 registers the cloud resource 211 as a target for notifications generated in the customer tenancy regarding different services. It is understood that there are also services that can issue / generate notifications. In this case, the forwarder agent 205 can subscribe as a target for notifications as described above. However, in some cases, the service may not be able to generate notifications (e.g., a queuing service). In this case, the forwarder agent 205 can be configured to poll the service to obtain the notifications. This is represented by the dotted line 207 in Figure 2. Details regarding configuring the forwarder agent 205 to poll the service are described with reference to Figure 3B in this specification.

[0032] In some embodiments, the forwarder agent 205 can be configured to perform filtering operations on one or more notifications received from the cloud resources 211. Specifically, the user can define some types of notifications that are of interest to the user. Such information can be held in the metadata database 215 associated with the forwarder agent 205. In this way, when the forwarder agent 205 receives multiple notifications, it can communicate with the metadata database 215 to determine for each notification whether the type of the received notification is desired by the user. In other words, the forwarder agent performs filtering operations according to the information held in the metadata database 215.

[0033] Upon performing the filtering operation, the forwarder agent 205 can create a message (e.g., a notification message (i.e., simply referred to as a notification)) for each notification to be sent by the forwarder agent 205 to the listener agent 236 (in the execution cloud environment 231). In one embodiment, the notification message can include metadata identifying the type of the notification (i.e., the metadata includes a notification identifier) and metadata identifying the cloud resource that generated the notification (i.e., the metadata includes a cloud resource identifier). The forwarder agent 205 can further transfer the notification message (via the secure transport channel 220) to the listener agent 236 for further processing (e.g., to call a function (associated with the notification) to be executed in the execution cloud environment hosting the listener agent 236).

[0034] The notification sent by the forwarder agent 205 is received by the listener agent 236. It is noted that the listener agent 236 is disposed in the data plane of the RFI service within the executing RFI service tenancy 233. According to one embodiment, upon receiving a notification, the listener agent 236 performs a lookup operation to identify the function to be called (and the corresponding customer tenancy hosting the function) based on the received notification. In one implementation, the listener agent 236 communicates with the mapping database 237 to identify the function to be called. It is understood that the mapping database 237 stores information related to the mapping of notifications to the corresponding functions to be called. Context information related to the customer tenancy hosting the function can also be stored in the mapping database 237.

[0035] Once the function (and the corresponding customer tenancy in the execution cloud environment hosting the function) is identified, the listener agent 236 obtains credentials, such as a token, from the identity management service 239 of the execution cloud environment 231. Further, the listener agent 236 transfers the token to the serverless function service 241 to call the function 242 within the customer tenancy 243 using the serverless function service 241. In response to obtaining the credentials from the listener agent 236, the serverless function service 241 communicates with the identity management service 239 to determine the permissions associated with the credentials, that is, to determine whether the credentials have sufficient permissions to trigger the serverless function service 241. In other words, a check is performed to determine whether the listener agent (i.e., the entity from which the token was obtained) is permitted to issue a query targeting the customer tenancy hosting the function. Such a check can be performed based on the information held in the execution policy 245 defined by the user. The execution policy 245 defines whether a service, such as the listener agent 236 deployed in the execution-side service tenancy, is permitted to access a function deployed in the customer tenancy 243 of the execution cloud environment 231. When the check is successfully executed, the serverless function service 241 launches the function 242 in the customer tenancy 243, that is, the serverless function service 241 calls the function 242 to be executed in the customer tenancy 243.

[0036] As described above in the foregoing embodiments, the RFI service enables a function to be called for execution in a target cloud environment (i.e., the execution cloud environment 231) different from the source cloud environment by a notification received in the source cloud environment (i.e., the notification cloud environment 201). Further, it is understood that the above-described embodiments of FIG. 2 in no way limit the scope of the present disclosure. Rather, changes to the architecture of the RFI service are fully encompassed within the scope of the present disclosure. For example, FIG. 2 shows a single listener agent 236 deployed in the data plane of the execution-side RFI service tenancy and a single forwarder agent 205 deployed in the data plane of the notification-side RFI service tenancy. According to some embodiments, an alternative architecture of the RFI service can include a pool of listener agents in the execution-side RFI service tenancy and a pool of forwarder agents deployed in the notification-side RFI service tenancy. In such a configuration, a pair of agents (i.e., a forwarder agent and a listener agent) can be dynamically selected based on several conditions (e.g., the current traffic load within the system) to send a notification from the notification cloud environment 201 to the execution cloud environment 231.

[0037] FIG. 3A shows a swimlane diagram illustrating a process of registering a function call for a notification received from a service according to some embodiments. As shown in FIG. 3A, the components of the swimlane diagram include a function as a service (FaaS) module 301, an RFI control plane module 303, a listener agent 305, a forwarder agent 307, and a SNS (simple notification service) service module 309. It is understood that the FaaS module 301, the RFI control plane module 303, and the listener agent 305 are deployed in the execution cloud environment 231, and the forwarder agent 307 and the SNS module are deployed in the notification cloud environment 201.

[0038] As shown in FIG. 3A, in step S1, user 302 deploys a function using the FaaS module 301 in the execution cloud environment 231. In step S2, user 302 registers a function call regarding notifications in the RFI control plane 303. In the example shown in FIG. 3A, the service under consideration in the notification cloud environment 201 is considered to be the Simple Notification Service (i.e., SNS). It is understood that the notification can correspond to an SNS topic. Further, the registration of the function call can be deployed in the notification cloud environment 201 and can include an identifier of a resource (e.g., a resource identifier) that utilizes the service (i.e., SNS).

[0039] When a function call request is registered in the RFI control plane 303, the RFI control plane 303 synchronizes the request with the listener agent 305 and the forwarder agent 307. Specifically, in step S3, the RFI control plane 303 registers the function call request in the listener agent 305 for a notification (e.g., an SNS topic). In other words, the listener agent 305 stores the mapping between the notification and the corresponding function to be called (when the notification is received) in a local database associated with the listener agent 305 (e.g., the mapping database 237 in FIG. 2). The mapping associates the notification with a function that includes context information.

[0040] In step S4, the RFI control plane 303 submits a request to the forwarder agent 307 included in the notification cloud environment 201. According to some embodiments, the request notifies the forwarder agent 307 to register (i.e., subscribe) itself to the service 309 in order to receive notifications from the service 309. In step S5, the forwarder agent 307 registers with the service to receive notifications from the service. For example, in one embodiment, the forwarder agent 307 can register an endpoint (e.g., an HTTP endpoint) with the service 309 to receive notifications from the service via the endpoint. In step S6, the service 309 replies to the forwarder agent 307 with an acknowledgement response (i.e., the service 309 confirms the subscription of the forwarder agent 307 regarding the receipt of a notification (e.g., a notification regarding an SNS topic)). Upon confirming the subscription, the forwarder agent 307 is configured to receive notifications at the registered endpoint (e.g., the HTTP endpoint from the service 309).

[0041] It is understood that in some cases, the service running in the notification cloud environment 201 may not be able to issue notifications. In this case, the forwarder agent is configured to poll the service to obtain notifications. The service in this case can correspond to a simple queue service (SQS) 311 as shown in FIG. 3B. FIG. 3B shows another swimlane diagram illustrating the process of registering function calls for notifications (by polling) according to some embodiments. In FIG. 3B, steps S11, S13, and S15 are similar to steps S1, S2, and S3 in FIG. 3A, respectively. Therefore, to avoid repetition, the description of these steps will not be repeated here.

[0042] In step S17, the RFI control plane 303 submits a request to the forwarder agent 307. This request indicates to the forwarder agent that it can poll the service (SQS) (e.g., poll the queue associated with service 311 to obtain a new message (i.e., notification)). In step S19, the forwarder agent 307 that has received the request from the RFI control plane 303 is ready to poll the queue associated with service 311.

[0043] Referring to FIG. 4A, a simplified flowchart showing steps performed by a forwarder agent according to some embodiments is illustrated. The processes shown in FIG. 4A can be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of respective systems, hardware, or combinations thereof. The software can be stored in a non-transitory storage medium (e.g., a memory device). The methods presented in FIG. 4A and described below are intended to be exemplary and non-limiting. Although FIG. 4A shows that various processing steps occur in a particular sequence or order, this is not intended to be limiting. In some alternative embodiments, the steps may be executed in a different order or some steps may be executed in parallel.

[0044] The process starts at step 401, where a forwarder agent deployed to a source RFI service tenancy in a source cloud environment receives a notification from a cloud resource (utilizing some service) to call a function deployed to a target cloud environment (i.e., different from the source cloud environment). For example, referring to FIG. 2, the forwarder agent 205 deployed to the notification-side RFI service tenancy 203 receives a notification to call a function from the cloud resource 211.

[0045] In step 403, according to some embodiments, the forwarder agent creates a message based on the received notification. In one embodiment, the created message can include metadata that identifies the type of the notification (i.e., the metadata can include a notification identifier), and the ID of the cloud resource that issued the notification. The message created in step 403 is sent by the forwarder agent (e.g., as a notification message) to the listener agent located in the target RFI service tenancy of the target cloud environment. For example, referring to FIG. 2, the forwarder agent sends a notification to the listener agent 236 located in the executor-side RFI service tenancy 233.

[0046] Referring now to FIG. 4B, a simplified flowchart showing the steps performed by a listener agent according to some embodiments is illustrated. The processes shown in FIG. 4B can be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of each system, hardware, or combinations thereof. The software can be stored in a non-transitory storage medium (e.g., a memory device). The methods presented in FIG. 4B and described below are intended to be exemplary and non-limiting. Although FIG. 4B shows that various processing steps occur in a particular sequence or order, this is not intended to be limiting. In some alternative embodiments, the steps may be performed in some different order, or some steps may be performed in parallel.

[0047] The process starts at step 410, where the listener agent receives a message (e.g., a notification) from the forwarder agent. For example, referring to FIG. 2, the listener agent 236 deployed to the execution-side RFI tenancy 233 included in the execution cloud environment receives a notification from the forwarder agent 205 deployed to the notification-side RFI tenancy included in the notification cloud environment. At step 415, the listener agent determines the function to be called based on the received message and according to the function call mapping. For example, the listener agent 236 performs a lookup operation in the mapping database 237 associated with the listener agent 236. The mapping database holds a plurality of mappings, each mapping corresponding to a notification and a related function to be called (including context information). It is understood that the context information can include information identifying the customer tenancy of the execution cloud environment hosting the function (e.g., the customer tenancy 243 in FIG. 2).

[0048] Next, the process moves to step 420 where the listener agent 236 obtains credentials, e.g., a token, from the identity management service included in the target cloud environment, i.e., the execution cloud environment. Once the credentials are obtained, the listener agent 236 sends those credentials to the serverless function service. Next, the process moves to step 425 where the serverless function service communicates with the identity management service of the target cloud environment to verify the permissions associated with the credentials received from the listener agent. Specifically, in one embodiment, a check is performed to determine whether the listener agent (i.e., the entity from which the token was obtained) is permitted to issue a query targeting the customer tenancy hosting the function. Such a check can be performed based on information held in an execution policy defined by the user (e.g., the execution policy 245 of FIG. 2). The execution policy defines whether a service deployed in the execution side service tenancy, e.g., the listener agent 236, is permitted to access a function deployed in the customer tenancy 243 of the execution cloud environment 231.

[0049] In response to a successful determination made at step 425, the process moves to step 430 where the serverless function service invokes the function in the customer tenancy to be executed. Thus, as described in the flowcharts of FIGS. 4A and 4B, the RFI service of the present disclosure enables integration of a serverless function executed in one cloud environment based on an event / notification from a service in a completely different cloud environment.

[0050] FIG. 5A shows a swimlane diagram illustrating function calls when the registration process of FIG. 4A is completed according to some embodiments. As shown in FIG. 5A, the components of the swimlane diagram include a Function as a Service (FaaS) module 301, an RFI control plane module 303, a listener agent 305, a forwarder agent 307, a Simple Notification Service (SNS) service module 309, and a publisher 501. It is understood that the FaaS module 301, the RFI control plane module 303, and the listener agent 305 are deployed in the execution cloud environment 231, and the forwarder agent 307 and the SNS module are deployed in the notification cloud environment 201.

[0051] In step S21, the publisher 501 publishes a message to the SNS service 309. By publishing the message to the SNS service 309, the SNS service issues a notification to be sent to the forwarder agent 307. It is noted that this occurs because the forwarder has registered itself with the service 309 to receive notifications (step S5 in FIG. 3A). In step S27, the forwarder 307 verifies whether there is a request for such a notification and whether it is valid. Specifically, the forwarder 307 can access the metadata database 215 of FIG. 2 to determine whether the user has not filtered the notification. If the determination is successful, the forwarder 307 forwards the notification to the listener agent 305.

[0052] According to some embodiments, the listener agent 305 accesses its local database (e.g., the mapping database 237 of FIG. 2) to determine the function to be called based on the received notification. According to some embodiments, it should be noted that the listener agent 305 holds a plurality of mappings in the mapping database, and each mapping corresponds to a notification and a related function to be called (including context information). It is noted that the context information can include information identifying the customer tenancy in the execution cloud environment hosting the function. Once the function to be called (and the customer tenancy hosting the function) is determined, the listener agent 305 obtains a token to be used to call the function in the customer tenancy from the identity management service of the execution cloud environment 231. Further, the listener agent 305 uses the serverless function service to call a specific function deployed in the customer tenancy (step S31). As described above, it is understood that the serverless function service in the execution cloud environment 231 can verify the token received from the listener agent 305 by communicating with the identity management service of the execution cloud environment 231.

[0053] FIG. 5B shows a swimlane diagram illustrating the function call when the registration process of FIG. 4B is completed according to some embodiments. Specifically, the swimlane diagram of FIG. 5B corresponds to the case where the service is not configured to send a notification to the forwarder agent 307 and the forwarder agent 307 polls the service (e.g., the SQS service) to obtain the notification.

[0054] In step S31, the forwarder agent 307 pools a queue (for example, the queue associated with the SQS service 311) and checks whether there is a new message in the queue. In step S33, since no new message is posted to the queue, the forwarder agent 307 receives an indication notifying it that there is no new message in the queue. In step S35, the publisher 501 publishes a new message to the queue. In step S37, the forwarder agent 307 polls the queue to determine whether there is a new message in the queue. In step S39, the forwarder agent 307 retrieves a new message from the queue. In step S41, the forwarder agent then transfers the notification to the listener agent 305. As described above with reference to FIG. 5A, the listener agent 305 can execute a process related to determining a function to be called based on the notification and obtaining a token to be used to call the function in the customer tenancy of the execution cloud environment (from the identity management service of the execution cloud environment 231). Further, according to some embodiments, the listener agent 305, in step S43, uses the serverless function service to call a specific function deployed in the customer tenancy of the execution cloud environment.

[0055] Example of infrastructure as a service architecture as a service As described above, infrastructure as a service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, an IaaS provider can also provide various services associated with those infrastructure components (e.g., billing, monitoring, logging, security, load balancing, and clustering, etc.). Therefore, since these services can potentially be policy-driven, an IaaS user may be able to implement a policy that promotes load balancing to maintain the availability and performance of an application.

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

[0057] In most cases, cloud computing models require the participation of a cloud provider. A cloud provider can be a third-party service that specializes in, but is not required to, provide (e.g., propose, rent, sell) IaaS. An entity can also choose to deploy a private cloud and become its own provider of infrastructure services.

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

[0059] In some examples, IaaS provisioning may refer to obtaining the computers or virtual hosts to be used and further installing the necessary libraries or services on those computers or virtual hosts. In most cases, deployment does not include provisioning, which needs to be done first.

[0060] In some cases, there are two different problems with IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before anything is running. Second, once everything is provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, deleting services, etc.). In some cases, these two problems can be addressed by enabling the infrastructure configuration to be defined declaratively. In other words, the infrastructure (e.g., what components are needed and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., what resources depend on what and how each coordinates) can be described declaratively. In some cases, once the topology is defined, a workflow can be generated to create and / or manage the different components described in the configuration files.

[0061] In some examples, the infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as a core network (e.g., a potential on-demand pool of configurable and / or shared computing resources). In some examples, there may also be one or more security group rules and one or more virtual machines (VMs) provisioned to define how network security is set up. Other infrastructure elements, such as load balancers, databases, etc., can also be provisioned. As more infrastructure elements are desired and / or added, the infrastructure can evolve incrementally.

[0062] In some cases, continuous deployment techniques can be employed to enable the deployment of infrastructure code across various virtual computing environments. Further, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across various different geographical locations, sometimes worldwide). However, in some examples, the infrastructure to which the code is deployed must first be set up. In some cases, provisioning can be done manually, provisioning tools can be utilized to provision resources, and / or once the infrastructure is provisioned, deployment tools can be utilized to deploy the code.

[0063] FIG. 6 is a block diagram 600 showing an example pattern of an IaaS architecture according to at least one embodiment. A service operator 602 can be communicatively coupled to a secure host tenancy 604 that can include a virtual cloud network (VCN) 606 and a secure host subnet 608. In some examples, the service operator 602 may be using one or more client computing devices, and the one or more client computing devices may run software such as Microsoft Windows Mobile (registered trademark), and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and are portable handheld devices (e.g., iPhone (registered trademark), mobile phone, iPad (registered trademark), computing tablet, personal digital assistant (PDA)) or wearable devices (Google Glass (registered trademark) head-mounted display) that support the Internet, email, short message service (SMS), BlackBerry (registered trademark) or other communication protocols. Alternatively, the client computing device may be a general-purpose personal computer, including, by way of example, personal computers and / or laptop computers running various versions of the Microsoft Windows (registered trademark) operating system, Apple Macintosh (registered trademark) operating system, and / or Linux (registered trademark) operating system. The client computing device can be a workstation computer running any of various commercially available UNIX (registered trademark) or UNIX-like operating systems, including, without limitation, various GNU / Linux operating systems such as Google Chrome OS.Alternatively or in addition, the client computing device can communicate via a sync client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or any other electronic device such as a personal messaging device that can access the VCN606 and / or the Internet via a network.

[0064] The VCN606 can include a local peering gateway (LPG) 610, and the LPG 610 can be communicatively coupled to a secure shell (SSH) VCN612 via the LPG 610 included in the SSH VCN612. The SSH VCN612 can include an SSH subnet 614, and the SSH VCN612 can be communicatively coupled to a control plane VCN616 via the LPG 610 included in the control plane VCN616. Also, the SSH VCN612 can be communicatively coupled to a data plane VCN618 via the LPG 610. The control plane VCN616 and the data plane VCN618 can be included in a service tenancy 619 that can be owned and / or operated by an IaaS provider.

[0065] The control plane VCN 616 can include a control plane demilitarized zone (DMZ) layer 620 that acts as a border network (e.g., a portion of a corporate network between a corporate intranet and an external network). DMZ-based servers have limited responsibilities and can help suppress security breaches. Further, the DMZ layer 620 can include one or more load balancer (LB) subnets 622, a control plane application layer 624 that can include an app subnet 626, and a control plane data layer 628 that can include a database (DB) subnet 630 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 622 included in the control plane DMZ layer 620 can be communicatively coupled to the app subnet 626 included in the control plane application layer 624 and to an Internet gateway 634 that can be included in the control plane VCN 616. The app subnet 626 can be communicatively coupled to the DB subnet 630 included in the control plane data layer 628, a service gateway 636, and a network address translation (NAT) gateway 638. The control plane VCN 616 can include the service gateway 636 and the NAT gateway 638.

[0066] The control plane VCN 616 can include a data plane mirror app layer 640 that can include an app subnet 626. The app subnet 626 included in the data plane mirror app layer 640 can include a virtual network interface controller (VNIC) 642 that can execute a compute instance 644. The compute instance 644 can be communicatively coupled to the app subnet 626 of the data plane mirror app layer 640 to the app subnet 626 that can be included in the data plane app layer 646.

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

[0068] The Internet gateway 634 of the control plane VCN 616 and the Internet gateway 634 of the data plane VCN 618 can be communicatively coupled to a metadata management service 652 that can be communicatively coupled to the public Internet 654. The public Internet 654 can be communicatively coupled to the NAT gateway 638 of the control plane VCN 616 and the NAT gateway 638 of the data plane VCN 618. The service gateway 636 of the control plane VCN 616 and the service gateway 636 of the data plane VCN 618 can be communicatively coupled to a cloud service 656.

[0069] In some examples, the service gateway 636 of the control plane VCN 616 or the service gateway 636 of the data plane VCN 618 can make application programming interface (API) calls to cloud services 656 without going through the public Internet 654. API calls from the service gateway 636 to the cloud services 656 can be one-way. That is, the service gateway 636 can make API calls to the cloud services 656, and the cloud services 656 can send the requested data to the service gateway 636. However, the cloud services 656 cannot initiate API calls to the service gateway 636.

[0070] In some examples, the secure host tenancy 604 can connect directly to service tenancies 619 that might otherwise be isolated. The secure host subnet 608 can communicate with the SSH subnet 614 via an LPG 610 that can enable two-way communication in systems that were otherwise isolated. By connecting the secure host subnet 608 to the SSH subnet 614, the secure host subnet 608 can access other entities within the service tenancy 619.

[0071] The control plane VCN 616 can enable users of service tenancy 619 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 616 can be deployed or otherwise used in the data plane VCN 618. In some examples, the control plane VCN 616 can be isolated from the data plane VCN 618, and the data plane mirror app layer 640 of the control plane VCN 616 can communicate with the data plane app layer 646 of the data plane VCN 618 via a VNIC 642 that can be included in the data plane mirror app layer 640 and the data plane app layer 646.

[0072] In some examples, a user or customer of the system can make requests, such as requests for create, read, update, or delete (CRUD) operations, via the public internet 654, and the public internet 654 can communicate such requests to the metadata management service 652. The metadata management service 652 can communicate the requests to the control plane VCN 616 via the internet gateway 634. The requests can be received by an LB subnet 622 included in the control plane DMZ layer 620. The LB subnet 622 may determine that the requests are valid, and in response to this determination, the LB subnet 622 can send the requests to an app subnet 626 included in the control plane app layer 624. If the requests are verified and require a call to the public internet 654, the call to the public internet 654 can be sent to a NAT gateway 638 that can make the call to the public internet 654. Memory that may be desired to be stored by the requests can be stored in a DB subnet 630.

[0073] In some examples, the data plane mirror application layer 640 can facilitate direct communication between the control plane VCN 616 and the data plane VCN 618. For example, when it is desired to apply a change, update, or other suitable modification to the configuration for the resources included in the data plane VCN 618. The control plane VCN 616 can communicate directly with the resources included in the data plane VCN 618 via the VNIC 642, thereby enabling the execution of a change, update, or other appropriate modification to the configuration for the resources.

[0074] In some embodiments, the control plane VCN 616 and the data plane VCN 618 can be included in the service tenancy 619. In this case, the user or customer of the system does not need to own and operate either the control plane VCN 616 or the data plane VCN 618. Instead, the IaaS provider can own or operate the control plane VCN 616 and the data plane VCN 618, and both of these can be included in the service tenancy 619. This embodiment can enable network isolation, thereby preventing a user or customer from interacting with the resources of other users or other customers. Also, this embodiment can enable the system user or customer to store the database privately without relying on the public Internet 654, which may not have the desired level of security for storage.

[0075] In other embodiments, the LB subnet 622 included in the control plane VCN 616 can be configured to receive signals from the service gateway 636. In this embodiment, the control plane VCN 616 and the data plane VCN 618 can be configured to be invoked by the IaaS provider's customers without invoking the public Internet 654. Since the database used by the customer can be controlled by the IaaS provider and stored in the service tenancy 619 that can be isolated from the public Internet 654, the IaaS provider's customers may desire this embodiment.

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

[0077] The control plane VCN 716 can include a control plane DMZ layer 720 (e.g., the control plane DMZ layer 620 in FIG. 6) that can include an LB subnet 722 (e.g., the LB subnet 622 in FIG. 6), a control plane app layer 724 (e.g., the control plane app layer 624 in FIG. 6) that can include an app subnet 726, and a control plane data layer 728 (e.g., the control plane data layer 628 in FIG. 6) that can include a database (DB) subnet 730 (similar to the DB subnet 630 in FIG. 6 for example). The LB subnet 722 included in the control plane DMZ layer 720 can be communicatively coupled to the app subnet 726 included in the control plane app layer 724 and to an internet gateway 734 (e.g., the internet gateway 634 in FIG. 6) that can be included in the control plane VCN 716. The app subnet 726 can be communicatively coupled to the DB subnet 730 included in the control plane data layer 728, to a service gateway 736 (e.g., the service gateway in FIG. 6) and to a network address translation (NAT) gateway 738 (e.g., the NAT gateway 638 in FIG. 6). The control plane VCN 716 can include the service gateway 736 and the NAT gateway 738.

[0078] The control plane VCN 716 can include a data plane mirror app layer 740 (e.g., the data plane mirror app layer 640 of FIG. 6) that can include an app subnet 726. The app subnet 726 included in the data plane mirror app layer 740 can include a virtual network interface controller (VNIC) 742 (e.g., the VNIC 642) that can execute a compute instance 744 (similar to the compute instance 644 of FIG. 6). The compute instance 744 can facilitate communication between the app subnet 726 of the data plane mirror app layer 740 and the app subnet 726 that can be included in a data plane app layer 746 (e.g., the data plane app layer 646 of FIG. 6) via the VNIC 742 included in the data plane mirror app layer 740 and the VNIC 742 included in the data plane app layer 746.

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

[0080] In some examples, the data plane VCN 718 can be included in the customer tenancy 721. In this case, the IaaS provider can provide a control plane VCN 716 for each customer, and the IaaS provider can set up a unique compute instance 744 included in the service tenancy 719 for each customer. Each compute instance 744 can enable communication between the control plane VCN 716 included in the service tenancy 719 and the data plane VCN 718 included in the customer tenancy 721. The compute instance 744 can enable resources provisioned in the control plane VCN 716 included in the service tenancy 719 to be deployed or otherwise used in the data plane VCN 718 included in the customer tenancy 721.

[0081] In other examples, a customer of an IaaS provider can have a database that resides in customer tenancy 721. In this example, control plane VCN 716 can include a data plane mirror app layer 740 that can include an app subnet 726. The data plane mirror app layer 740 can reside in data plane VCN 718, and the data plane mirror app layer 740 may not exist in data plane VCN 718. That is, the data plane mirror app layer 740 can access customer tenancy 721, but the data plane mirror app layer 740 may not exist in data plane VCN 718 or may not be owned and operated by the customer of the IaaS provider. The data plane mirror app layer 740 may be configured to make calls to data plane VCN 718, but may not be configured to make calls to any entity included in control plane VCN 716. A customer may desire to deploy or otherwise use resources within data plane VCN 718 that are provisioned in control plane VCN 716, and the data plane mirror app layer 740 can facilitate the desired deployment or other use of the customer's resources.

[0082] In some embodiments, a customer of an IaaS provider can apply a filter to data plane VCN 718. In this embodiment, the customer can determine what the data plane VCN 718 can access, and the customer can restrict access from data plane VCN 718 to the public Internet 754. The IaaS provider may not be able to apply a filter or otherwise control access from data plane VCN 718 to any external network or database. The customer applying filters and controls to data plane VCN 718 included in customer tenancy 721 can help isolate data plane VCN 718 from other customers and from the public Internet 754.

[0083] In some embodiments, the service gateway 736 can call the cloud service 756 to access services that may not be present on the public Internet 754, on the control plane VCN 716, or on the data plane VCN 718. The connection between the cloud service 756 and the control plane VCN 716 or the data plane VCN 718 may not be live or continuous. The cloud service 756 may be present on different networks owned or operated by an IaaS provider. The cloud service 756 may be configured to receive calls from the service gateway 736 and may be configured not to receive calls from the public Internet 754. Some cloud services 756 may be isolated from other cloud services 756, and the control plane VCN 716 may be isolated from cloud services 756 that may not be in the same region as the control plane VCN 716. For example, the control plane VCN 716 may be located in "Region 1", and the cloud service "Deployment 6" may be located in Region 1 and "Region 2". If a call to Deployment 6 is made by the service gateway 736 included in the control plane VCN 716 located in Region 1, this call can be sent to Deployment 6 within Region 1. In this example, the control plane VCN 716 or the Deployment 6 in Region 1 may not be communicatively coupled to or otherwise communicating with the Deployment 6 in Region 2.

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

[0085] The control plane VCN816 can include a control plane DMZ layer 820 (e.g., the control plane DMZ layer 620 in FIG. 6) that can include a load balancer (LB) subnet 822 (e.g., the LB subnet 622 in FIG. 6), a control plane application layer 824 (e.g., the control plane application layer 624 in FIG. 6) that can include an application subnet 826 (similar to the application subnet 626 in FIG. 6), and a control plane data layer 828 (e.g., the control plane data layer 628 in FIG. 6) that can include a DB subnet 830. 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 (e.g., the Internet gateway 634 in FIG. 6) that can be included in the control plane VCN816. The application subnet 826 can be communicatively coupled to the DB subnet 830 included in the control plane data layer 828, a service gateway 836 (e.g., the service gateway in FIG. 6), and a network address translation (NAT) gateway 838 (e.g., the NAT gateway 638 in FIG. 6). The control plane VCN816 can include the service gateway 836 and the NAT gateway 838.

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

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

[0088] The internet gateway 834 included in the control plane VCN 816 and the internet gateway 834 included in the data plane VCN 818 can be communicatively coupled to a metadata management service 852 (e.g., the metadata management system 652 of FIG. 6) that can be communicatively coupled to the public internet 854. The public internet 854 can be communicatively coupled to the NAT gateways 838 included in the control plane VCN 816 and the NAT gateways 838 included in the data plane VCN 818. The service gateways 836 included in the control plane VCN 816 and the service gateways 836 included in the data plane VCN 818 can be communicatively coupled to cloud services 856.

[0089] In some embodiments, the data plane VCN 818 can be integrated with the customer tenancy 870. This integration can be useful or desirable for customers of the IaaS provider in some cases, such as when they may desire support when running code. The customer may provide code that can be disruptive, may communicate with other customer resources, or may otherwise have undesirable effects. In response, the IaaS provider can determine whether to execute the code provided by the customer.

[0090] In some examples, the customer of the IaaS provider can permit the IaaS provider temporary network access and request a function to be attached to the data plane layer app 846. The code that executes the function can be run on the VMs 866(1) to (N), and the code need not be configured to run anywhere else on the data plane VCN 818. Each of the VMs 866(1) to (N) can be connected to one customer tenancy 870. Each of the containers 871(1) to (N) included in the VMs 866(1) to (N) can be configured to execute the code. In this case, there can be double isolation (e.g., the containers 871(1) to (N) execute the code, and the containers 871(1) to (N) can be included in the VMs 866(1) to (N) included in at least the untrusted app subnet 862). This can help prevent incorrect or otherwise undesirable code from damaging the IaaS provider's network or the networks of different customers. The containers 871(1) to (N) can be communicatively coupled to the customer tenancy 870 and configured to send or receive data from the customer tenancy 870. The containers 871(1) to (N) need not be configured to send or receive data from any other entity within the data plane VCN 818. When the execution of the code is complete, the IaaS provider can force stop or otherwise discard the containers 871(I) to (N).

[0091] In some embodiments, the trusted application subnet 860 can execute code that can be owned or operated by an IaaS provider. In this embodiment, the trusted application subnet 860 can be communicatively coupled to the DB subnet 830 and configured to perform CRUD operations in the DB subnet 830. The untrusted application subnet 862 can be communicatively coupled to the DB subnet 830, but in this embodiment, the untrusted application subnet can be configured to perform read operations within the DB subnet 830. The containers 871(1)-(N) that can be included in each customer's VMs 866(1)-(N) and execute code from the customer may not need to be communicatively coupled to the DB subnet 830.

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

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

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

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

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

[0097] The internet gateway 934 included in the control plane VCN 916 and the internet gateway 934 included in the data plane VCN 918 can communicatively connect to a metadata management service 952 (e.g., the metadata management system 652 of FIG. 6) that can communicatively connect to the public internet 954. The public internet 954 can communicatively connect to the NAT gateway 938 included in the control plane VCN 916 and the NAT gateway 938 included in the data plane VCN 918. The service gateway 936 included in the control plane VCN 916 and the service gateway 936 included in the data plane VCN 918 can communicatively connect to a cloud service 956.

[0098] In some examples, the pattern shown by the architecture of block diagram 900 of FIG. 9 may be considered an exception to the pattern shown by the architecture of block diagram 800 of FIG. 8 and may be desirable for customers of the IaaS provider when the IaaS provider cannot communicate directly with the customer (e.g., a non-connected region). The customer can access each of the containers 967(1)-(N) included in each customer's VMs 966(1)-(N) in real time. The containers 967(1)-(N) can be configured to call each of the secondary VNICs 972(1)-(N) included in the app subnet 926 of the data plane app layer 946 that can be included in the container egress VCN 968. The secondary VNICs 972(1)-(N) can send calls to a NAT gateway 938 that can send calls to the public internet 954. In this example, the containers 967(1)-(N) that the customer can access in real time can be isolated from the control plane VCN 916 and from other entities included in the data plane VCN 918. The containers 967(1)-(N) can also be isolated from the resources of other customers.

[0099] In other examples, a customer can call cloud service 956 using containers 967(1) to (N). In this example, the customer can execute code in containers 967(1) to (N) that requests a service from cloud service 956. Containers 967(1) to (N) can send this request to secondary VNICs 972(1) to (N), which can send the request to a NAT gateway that can send the request to public internet 954. Public internet 954 can send this request to LB subnet 922 included in control plane VCN 916 via internet gateway 934. In response to determining that the request is valid, the LB subnet can send this request to app subnet 926, which can send this request to cloud service 956 via service gateway 936.

[0100] It should be understood that the IaaS architectures 600, 700, 800, 900 shown in the figures may include components other than those shown. Further, the embodiments shown in the figures are merely examples of a part of a cloud infrastructure system that can incorporate embodiments of the present 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.

[0101] In some embodiments, the IaaS systems described herein can include a set of application, middleware, and database service offerings that are provided to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is Oracle Cloud Infrastructure (OCI) provided by the present assignee.

[0102] Figure 10 shows a computer system example 1000 that can execute various embodiments. System 1000 can be used to execute any of the computer systems described above. As shown in the figure, computer system 1000 includes a processing unit 1004 that communicates with a plurality of peripheral subsystems via a bus subsystem 1002. These peripheral subsystems can include a processing acceleration unit 1006, an I / O subsystem 1008, a storage subsystem 1018, and a communication subsystem 1024. Storage subsystem 1018 includes a tangible computer-readable storage medium 1022 and a system memory 1010.

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

[0104] The processing unit 1004, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), controls the operation of the computer system 1000. One or more processors can be included in the processing unit 1004. These processors can include single-core processors or multi-core processors. In some embodiments, the processing unit 1004 can be implemented as one or more independent processing units 1032 and / or 1034 each having a single-core or multi-core processor included in each processing unit. In other embodiments, the processing unit 1004 may be implemented as a quad-core processing unit formed by integrating two dual-core processors on a single chip.

[0105] In various embodiments, the processing unit 1004 can execute various programs according to program code and can maintain multiple simultaneously executing programs or processes. At any given point in time, some or all of the program code to be executed can be present in the processor 1004 and / or the storage subsystem 1018. Through suitable programming, the processor 1004 can provide the various functions described above. The computer system 1000 can further include a processing acceleration unit 1006, which can include a digital signal processor (DSP), a dedicated processor, and the like.

[0106] The I / O subsystem 1008 can include user interface input devices and user interface output devices. User interface input devices can include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen incorporated in a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice input device having a voice command recognition system, a microphone, and other types of input devices. The user interface input devices can include, for example, a motion sensing and / or gesture recognition device such as a Microsoft Kinect (registered trademark) that enables a user to control and interact with an input device such as a Microsoft Xbox (registered trademark) 360 game controller through a natural user interface that uses gestures and spoken commands. The user interface input devices can also include an eye gesture recognition device such as a Google Glass (registered trademark) blink detector that detects a user's eye activity (e.g., a "blink" during photo taking and / or menu selection) and converts the eye gesture into an input to the input device (e.g., Google Glass (registered trademark)). Additionally, the user interface input devices may include a voice recognition sensing device that enables a user to interact with a voice recognition system (e.g., a Siri (registered trademark) navigator) via voice commands.

[0107] The user interface input device may also include, but is not limited to, a three-dimensional (3D) mouse, a joystick or a pointing stick, a game pad and a graphic tablet, and audio / visual devices such as a speaker, a digital camera, a digital video camera, a portable media player, a web camera, an image scanner, a fingerprint scanner, a barcode reader, a 3D scanner, a 3D printer, a laser rangefinder, and a gaze tracking device. Further, the user interface input device may include, for example, a medical image input device such as a computed tomography device, a magnetic resonance imaging device, a positron emission tomography device, and a medical ultrasonic inspection device. The user interface input device may also include, for example, a voice input device such as a MIDI keyboard and a digital musical instrument.

[0108] The user interface output device may include a non-visual display such as a display subsystem, an indicator light, or an audio output device. The display subsystem may be, for example, a flat panel device using a cathode ray tube (CRT), a liquid crystal display (LCD), or a plasma display, a projection device, a touch screen, or the like. In general, 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 1000 to the user or another computer. For example, the user interface output device may include, but is not limited to, a monitor, a printer, a speaker, headphones, an in-vehicle navigation system, a plotter, an audio output device, and a modem, and various display devices for visually conveying text, graphics, and audio / video information.

[0109] The computer system 1000 can include a storage subsystem 1018 that includes software elements shown as being currently located within system memory 1010. The system memory 1010 can store program instructions loadable into and executable by the processing unit 1004 and data generated during the execution of these programs.

[0110] Depending on the configuration and type of the computer system 1000, the system memory 1010 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible and / or currently being operated on and executed by the processing unit 1004. In some embodiments, the system memory 1010 can include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some embodiments, the ROM can typically store a basic input / output system (BIOS) that includes basic routines useful for transferring information between elements within the computer system 1000, such as during startup. By way of non-limiting example, the system memory 1010 also shows an application program 1012 that can include a client application, a web browser, a middle-tier application, a relational database management system (RDBMS), etc., program data 1014, and an operating system 1016. By way of example, the operating system 1016 can include various versions of Microsoft Windows (registered trademark), Apple Macintosh (registered trademark), and / or Linux operating systems, various commercially available UNIX (registered trademark) or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome (registered trademark) OS, etc.), and / or mobile operating systems such as iOS, Windows (registered trademark) Phone, Android (registered trademark) OS, BlackBerry (registered trademark) 10 OS, and Palm (registered trademark) OS operating systems.

[0111] The storage subsystem 1018 can also provide a tangible computer-readable storage medium for storing the basic programming and data structures that provide the functionality of some embodiments. The storage subsystem 1018 can store software (programs, code modules, instructions) that, when executed by a processor, provide the functionality described above. These software modules or instructions can be executed by the processing unit 1004. The storage subsystem 1018 can also provide a repository for storing data used in accordance with the present disclosure.

[0112] The storage subsystem 1000 can also include a computer-readable storage medium reader 1020 that can be further connected to a computer-readable storage medium 1022. Together with the system memory 1010, optionally in combination, the computer-readable storage medium 1022 can comprehensively represent, by adding storage media to remote, local, fixed, and / or removable storage devices, for temporarily and / or more permanently accommodating, storing, transmitting, and obtaining computer-readable information.

[0113] A computer-readable storage medium 1022 that includes code, or a portion of code, can include any suitable medium known in or used in the art, including, but not limited to, storage and / or transmission media such as volatile and non-volatile, removable and non-removable media implemented in any method or technology for the storage and / or transmission of information. This can 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 disks (DVD) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or other tangible computer-readable media. This can also include non-tangible computer-readable media such as data signals, data transmissions, or any other medium that can be used to transmit desired information and that can be accessed by computing system 1000.

[0114] As an example, the computer-readable storage medium 1022 can include a hard disk drive that reads from or writes to a non-removable non-volatile magnetic medium, a magnetic disk drive that reads from or writes to a removable non-volatile magnetic disk, and an optical disk drive that reads from or writes to a removable non-volatile optical disk such as a CD ROM, a DVD, and a Blu-Ray (registered trademark) disk, or other optical media. Examples of the computer-readable storage medium 1022 include, but are not limited to, a Zip (registered trademark) drive, a flash memory card, a Universal Serial Bus (USB) flash drive, a Secure Digital (SD) card, a DVD disk, a digital video tape, etc. The computer-readable storage medium 1022 can also include a solid state drive (SSD) based on non-volatile memory such as a flash memory-based SSD, an enterprise flash drive, a solid state ROM, an SSD based on volatile memory such as a solid state RAM, a dynamic RAM, a static RAM, a DRAM-based SSD, a magnetic resistance RAM (MRAM) SSD, and a hybrid SSD that uses a combination of DRAM and a flash memory-based SSD. Disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1000.

[0115] The communication subsystem 1024 provides an interface to other computer systems and networks. The communication subsystem 1024 functions as an interface for receiving data from the computer system 1000 and transmitting data from the computer system 1000 to other systems. For example, the communication subsystem 1024 can enable the computer system 1000 to connect to one or more devices via the Internet. In some embodiments, the communication subsystem 1024 can include radio frequency (RF) transceiver components, a global positioning system (GPS) receiver component, and / or other components for accessing wireless voice and / or data networks (e.g., using cellular phone technology, advanced data network technologies such as 3G, 4G, or EDGE (enhanced data rates for global evolution), Wi-Fi (IEEE 802.11 family standards, or other mobile communication technologies, or any combination thereof). In some embodiments, the communication subsystem 1024 can provide wired network connectivity (e.g., Ethernet (registered trademark)) in addition to or instead of a wireless interface.

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

[0117] As an example, the communication subsystem 1024 may be configured to receive in real time a data feed 1026 from users of social networks and / or other communication services, such as Twitter (registered trademark) feeds, Facebook (registered trademark) updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0118] Furthermore, the communication subsystem 1024 may be configured to receive data in the form of a continuous data stream, including an event stream 1028 and / or event updates 1030 of real-time events that may be inherently continuous or infinite with no clear end. Examples of applications that generate continuous data include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

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

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

[0121] Because the nature of computers and networks is constantly changing, the description of the computer system 1000 shown in the figures is merely intended as a specific example. Many other configurations are possible that have more or fewer components than the system shown in the figures. For example, customized hardware may be used and / or certain elements may be implemented in hardware, firmware, software (including applets), or combinations thereof. Additionally, connections to other computing devices such as network input / output devices may be employed. Based on the disclosure and teachings provided herein, those of ordinary skill in the art will understand other manners and / or methods for implementing various embodiments.

[0122] Although specific embodiments have been described, various changes, modifications, alternative structures, and equivalents are also included within the scope of the present disclosure. Embodiments are not limited to operating within a certain specific data processing environment and can operate freely within multiple data processing environments. Further, although embodiments have been described using a specific set of transactions and steps, it should be apparent to those of ordinary skill in the art that the scope of the present disclosure is not limited to the set of transactions and steps described. The various features and aspects of the embodiments described above may be used individually or jointly.

[0123] Furthermore, although 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 the present disclosure. Embodiments may be implemented using only hardware, or only software, or a combination thereof. The various processes described herein may be executed on the same processor or on any combination of different processors. Thus, when a component or module is described as being configured to perform some operations, such a configuration can be realized, for example, by designing an electronic circuit to perform the operations, by programming a programmable electronic circuit (such as a microprocessor) to perform the operations, or by any combination thereof. The processes can communicate using various techniques including, but not limited to, conventional techniques for inter-process communication, and different pairs of processes can use different techniques, or the same pair of processes can use different techniques at different times.

[0124] Accordingly, the specification and drawings are to be considered in an illustrative rather than a restrictive sense. However, it will be apparent that additions, subtractions, deletions, and other modifications and changes may be made without departing from the broader spirit and scope as set forth in the claims. Thus, while specific embodiments of the disclosure have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0125] In the context of describing the disclosed embodiments (especially in the context of the following claims), the use of the terms "a," "an," and "the" and similar referents should be interpreted to include both the singular and the plural, unless otherwise indicated herein or clearly contradicted by the context. The terms "comprising," "having," "including," and "containing" should be interpreted as open-ended terms (i.e., meaning "including but not limited to") unless specifically stated otherwise. The term "connected" should be interpreted as being either internally contained within, attached to, or joined to one another, in whole or in part, even if there are intervening elements. The recitation of a range of values herein is merely intended to serve as a shorthand way of referring individually to each separate value within that range, unless otherwise indicated herein, and each separate value is incorporated herein as if it were individually recited herein. Unless otherwise indicated herein or clearly contradicted by the context, all methods described herein can be performed in any suitable order. The use of any examples, or exemplary language (e.g., "such as") provided herein is merely intended to make the embodiments clearer and is not intended to limit the scope of the disclosure unless otherwise claimed. No language in this specification should be interpreted as indicating that any non-claimed element is essential for the practice of the disclosure.

[0126] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is generally intended to be understood within the context as being used to indicate that items, terms, etc. may be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically provided otherwise. Thus, such disjunctive language is not generally intended to, and should not be taken to, mean that some embodiments require the presence of at least one of each of at least one of X, at least one of Y, or at least one of Z.

[0127] This specification describes preferred embodiments of the present disclosure, including the best mode known to the applicant for practicing the disclosure. Variations of these preferred embodiments will be apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art should be able to appropriately adopt such variations, and the present disclosure may be practiced in other ways than those specifically described herein. Accordingly, the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Further, any combination of the above-described elements in all possible variations thereof is included in the present disclosure unless otherwise indicated herein.

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

[0129] In the foregoing specification, embodiments of the present disclosure have been described with reference to specific embodiments, but those skilled in the art will recognize that the present disclosure is not limited thereto. The various features and aspects of the disclosure described above can be used individually or in combination. Further, the embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of this specification. Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive.

Claims

1. 1. A method comprising: the target agent receiving the notification from the source agent; The target agent is deployed to a target cloud environment, and the source agent is deployed to a source cloud environment that is different from the target cloud environment; The method comprises: the target agent determining a function to call based on the notification; verifying whether the target agent is authorized to invoke the function deployed in a target customer tenancy in the target cloud environment; In response to successful validation, the target agent invokes the function in the target customer tenancy of the target cloud environment.

2. 10. The method of claim 1, wherein the target agent is deployed in a target service tenancy in the target cloud environment, the source agent is deployed in a source service tenancy in the source cloud environment, and the target agent is communicatively coupled with the source agent by a secure communication channel.

3. 3. The method of claim 1 or 2, wherein the source agent (i) subscribes to or polls a queue associated with a cloud resource deployed in a source customer tenancy of the source cloud environment to receive the notification, and (ii) upon receiving the notification from the cloud resource, forwards the notification to the target agent.

4. The method comprises: the target agent obtaining an identifier associated with the notification; and querying a mapping database to obtain the function associated with the identifier; 3. The method of claim 1, wherein the mapping database is pre-configured with a plurality of mappings, each mapping specifying a particular function to invoke for a particular identifier.

5. 3. The method of claim 1 or 2, wherein the verifying further comprises determining whether the target agent is authorized to access the target customer tenancy in the target cloud environment according to a policy associated with the target cloud environment.

6. In response to a successful determination, the target agent obtains a token from an identity management service of the target cloud environment; and and forwarding the token to a serverless function service deployed in the target cloud environment.

7. 7. The method of claim 6, further comprising: causing the serverless function service to execute the functions deployed to the target customer tenancy in the target cloud environment.

8. 7. The method of claim 6, wherein the serverless function service communicates with the identity management service of the target cloud environment to determine a set of permissions associated with the token.

9. 3. The method of claim 2, wherein the target agent is deployed in a data plane of the target service tenancy in the target cloud environment, and the source agent is deployed in a corresponding data plane of the source service tenancy in the source cloud environment.

10. A computer-readable program storing specific computer-executable instructions that, when executed by a processor, cause a computer system to perform operations, said operations including: receiving, by the target agent, a notification from the source agent; The target agent is deployed to a target cloud environment, and the source agent is deployed to a source cloud environment that is different from the target cloud environment; The operation is determining, by the target agent, a function to call based on the notification; verifying whether the target agent is authorized to invoke the function deployed in a target customer tenancy in the target cloud environment; and in response to successful validation, invoking, by the target agent, the function in the target customer tenancy of the target cloud environment.

11. 11. The computer-readable program of claim 10, wherein the target agent is deployed in a target service tenancy in the target cloud environment, the source agent is deployed in a source service tenancy in the source cloud environment, and the target agent is communicatively coupled with the source agent by a secure communication channel.

12. 12. The computer-readable program of claim 10 or 11, wherein the source agent (i) subscribes to cloud resources deployed in a source customer tenancy of the source cloud environment to receive the notification, and (ii) upon receiving the notification from the cloud resources, forwards the notification to the target agent.

13. obtaining, by the target agent, an identifier associated with the notification; and querying a mapping database to obtain the function associated with the identifier; 12. The computer readable program of claim 10 or 11, wherein the mapping database is pre-configured with a plurality of mappings, each mapping specifying a particular function to invoke for a particular identifier.

14. 12. The computer-readable program of claim 10 or 11, wherein the verifying further comprises determining whether the target agent is authorized to access the target customer tenancy in the target cloud environment according to a policy associated with the target cloud environment.

15. In response to a successful determination, obtaining, by the target agent, a token from an identity management service of the target cloud environment; and forwarding the token to a serverless function service deployed in the target cloud environment.

16. 16. The computer-readable program of claim 15, further comprising causing the serverless function service to execute the functions deployed to the target customer tenancy in the target cloud environment.

17. 17. The computer-readable program of claim 16, wherein the serverless function service communicates with the identity management service of the target cloud environment to determine a set of permissions associated with the token.

18. 12. The computer-readable program of claim 11, wherein the target agent is deployed to a data plane of the target service tenancy in the target cloud environment, and the source agent is deployed to a corresponding data plane of the source service tenancy in the source cloud environment.

19. 1. A system comprising: a processor; a memory containing instructions; The instructions, when executed by the processor, cause the system to at least obtain, by a target agent, a notification from a source agent; The target agent is deployed in a target cloud environment, and the source agent is deployed in a source cloud environment that is different from the target cloud environment, and the instructions include instructions to the system to at least: causing the target agent to determine a function to call based on the notification; verifying, by the target agent, whether the target agent is authorized to invoke the function deployed in the target customer tenancy in the target cloud environment; In response to successful validation, the system causes the target agent to invoke the function in the target customer tenancy of the target cloud environment.

20. 20. The system of claim 19, wherein the target agent is deployed in a target service tenancy in the target cloud environment, the source agent is deployed in a source service tenancy in the source cloud environment, and the target agent is communicatively coupled with the source agent by a secure communication channel.

Images