Remote cloud function call service

Abstract

The present disclosure relates to a framework that provides execution of server-less functions in a cloud environment based on the occurrence of events / notifications from services in completely different cloud environments. The target agent obtains a notification from the source agent, wherein 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 be invoked based on the notification. Upon successful verification of whether the target agent is allowed to invoke a function deployed in a target customer lease of the target cloud environment, the target agent invokes the function in the target customer lease of the target cloud environment.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of the filing dates of U.S. Provisional Application No. 63 / 339,753, filed on May 9, 2022, and U.S. Non-Provisional Application No. 17 / 850,693, filed on June 27, 2022, each of which is incorporated herein by reference in its entirety for all purposes. Technical Field

[0003] The present disclosure relates to a framework that provides execution of serverless functions in a cloud environment based on the occurrence of events / notifications from services in a completely different cloud environment. Background Art

[0004] Cloud service providers (CSPs) offer a set of services to customers of cloud environments. One such service is called Function as a Service (FaaS). FaaS is a category of cloud computing services that provides a platform that allows customers to develop, execute, and manage application functionality without incurring the complexity of building and maintaining the infrastructure typically associated with developing and launching applications. Building applications according to this model is a way to implement a "serverless" architecture and is commonly used when building microservices applications. Several cloud providers (e.g., Amazon Web Services (AWS), Google Cloud Platform (GCP), and Oracle Cloud Infrastructure) offer versions of this service on their public clouds.

[0005] Typically, CSPs implement local function calls by tightly integrating functions with other services provided by the CSP. In other words, as part of the serverless function offering, the CSP provides functionality to integrate serverless functions with events / notifications of other native services supported in the cloud. For example, a customer can specify a serverless function to be called when an event occurs in the same cloud (e.g., when an object is added to a storage unit). However, currently no CSP supports the integration of serverless functions with events / notifications from services in different clouds. Therefore, the serverless function models currently provided by different CSPs limit customers from taking full advantage of cheaper resources (e.g., computing resources, storage resources, etc. in other cloud environments). The embodiments discussed herein address these and other issues individually and collectively. Summary of the invention

[0006] The present disclosure generally relates to a framework that provides integration between serverless functions in a cloud environment based on the occurrence of events / notifications from services in completely different cloud environments. Various embodiments are described herein, including methods, systems, non-transitory computer-readable storage media storing programs, codes, or instructions executable by one or more processors, etc. These illustrative embodiments are not mentioned to limit or define the present disclosure, but to provide examples to aid in understanding the present disclosure. Additional embodiments are discussed in the detailed description section, and further description is provided therein.

[0007] One aspect of the present disclosure provides a method, which includes: obtaining, by a target agent, a notification from a source agent, the target agent being deployed in a target cloud environment and the source agent being deployed in a source cloud environment different from the target cloud environment; determining, by the target agent, a function to be called based on the notification; verifying whether the target agent is allowed to call a function deployed in a target customer lease of the target cloud environment; and in response to successful verification, calling, by the target agent, the function in the target customer lease of the target cloud environment.

[0008] Another aspect of the present disclosure provides a system, which includes: a processor; and a memory, the memory including instructions, which, when executed by the processor, causes the system to at least: obtain a notification from a source agent by a target agent, the target agent being deployed in a target cloud environment and the source agent being deployed in a source cloud environment different from the target cloud environment; determine, by the target agent, a function to be called based on the notification; verify whether the target agent is allowed to call a function deployed in a target customer lease of the target cloud environment; and, in response to successful verification, call, by the target agent, the function in the target customer lease of the target cloud environment.

[0009] Another aspect of the present disclosure provides a non-transitory computer-readable medium storing specific computer-executable instructions which, when executed by a processor, cause a computer system to perform operations, including: obtaining, by a target agent, a notification from a source agent, the target agent being deployed in a target cloud environment and the source agent being deployed in a source cloud environment different from the target cloud environment; determining, by the target agent, a function to be called based on the notification; verifying whether the target agent is allowed to call a function in a target customer lease deployed in the target cloud environment; and in response to successful verification, calling, by the target agent, the function in the target customer lease of the target cloud environment.

[0010] Another aspect of the present disclosure provides a computer program product, the computer program product including a computer program / instructions, which, when executed by a processor, causes the processor to perform operations, including: obtaining a notification from a source agent by a target agent, the target agent being deployed in a target cloud environment and the source agent being deployed in a source cloud environment different from the target cloud environment; determining, by the target agent, a function to be called based on the notification; verifying whether the target agent is allowed to call a function deployed in a target customer lease of the target cloud environment; and in response to successful verification, calling, by the target agent, the function in the target customer lease of the target cloud environment. Embodiments may be implemented using a computer program product including a computer program / instructions, which, when executed by a processor, causes the processor to perform any of the methods described in the present disclosure.

[0011] The foregoing and other features and embodiments will become more fully apparent with reference to the following description, claims and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1A Depicted is an exemplary architecture for a remote function invocation (RFI) service in accordance with various embodiments.

[0013] Figure 1B A simplified flow chart depicting steps performed by an RFI service according to certain embodiments is illustrated.

[0014] Figure 2 An exemplary detailed architecture of an RFI service according to various embodiments is depicted.

[0015] Figure 3A A swim diagram illustrating a process of registering a function call for notifications in accordance with some embodiments is depicted.

[0016] Figure 3B Another swim diagram illustrating the process of registering a function call for notifications in accordance with some embodiments is depicted.

[0017] Figure 4A A simplified flow chart depicting steps performed by a forwarder proxy according to certain embodiments is illustrated.

[0018] Figure 4B A simplified flow chart depicting steps performed by a listener agent according to certain embodiments is illustrated.

[0019] Figure 5A The diagram illustrates the process of completing the Figure 4A The registration process is handled by the swimming graph of the function call.

[0020] Figure 5B The diagram illustrates the process of completing the Figure 4BThe registration process is handled by the swimming graph of the function call.

[0021] Figure 6 is a block diagram illustrating one mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0022] Figure 7 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0023] Figure 8 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0024] Fig. 9 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0025] Fig.10 is a block diagram illustrating an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION

[0026] In the following description, for the purpose of explanation, specific details are set forth in order to provide a thorough understanding of certain embodiments. However, it is apparent that various embodiments can be implemented without these specific details. The drawings and descriptions are not intended to be limiting. The word "exemplary" as used herein means "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as superior or preferred over other embodiments or designs.

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

[0028] The RFI framework provides users with programming constructs to register and call functions on a remote cloud in response to notifications obtained from a service executing in another cloud environment. For clarity, the cloud environment that generates notifications is referred to as the "notification cloud environment" in this article, and the cloud environment that executes one or more functions is referred to as the "execution cloud environment" in this article. It should be noted that the notification cloud environment is different and independent from the execution cloud environment. In addition, the RFI framework also provides a mechanism to poll services (in the notification cloud environment) that do not generate events to call functions in the execution cloud environment. In essence, the RFI framework allows cloud application developers to burst compute-sensitive workloads to other clouds in units of functions through simple application configuration changes. By doing so, the RFI framework allows users to take full advantage of (one or more) other cloud environments to obtain higher availability, lower costs, or workload scalability.

[0029] It can be appreciated that delegating functions to a remote cloud (i.e., an execution cloud environment) is further complicated by the nature of being embedded in an application workflow. Functions can be triggered from many different services (i.e., in a notification cloud environment) and can call other functions or services. The RFI framework of the present disclosure is a general framework of services and APIs that allow users in a cloud environment to remotely call functions in another cloud environment (and execute them). In addition, 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.

[0030] According to some embodiments, the RFI service framework provides a user interface and a command line interface (CLI) that provide users of the cloud environment with RFI instances in the lease of a customer in the cloud environment. As will be 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 to events and polls services in the notification cloud environment. The forwarder agent forwards such notifications to a remote cloud environment (i.e., an execution cloud environment), where the notifications are received by a receiving 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. Note that the forwarder agent and the listener agent are deployed on both sides of the two cloud environments (i.e., the notification cloud environment and the execution cloud environment) and are connected via a secure inter-cloud notification bus. According to some embodiments, the notification bus is established on a trusted high-speed communication link (e.g., a FastConnect link) established between the two cloud environments.

[0031] According to some embodiments, the RFI service framework provides the user with the flexibility to define which set of services the user expects to receive notifications for in the notification cloud environment. The user can alternatively define which services (in the notification cloud environment) the user wants the RFI instance (deployed in the notification cloud environment) to poll and monitor for rules to be triggered. The RFI instance in the notification cloud environment can convert the trigger into a notification. The notification is transmitted to the execution cloud environment, where the corresponding RFI instance (i.e., deployed in the execution cloud environment) triggers the function for execution. It can be recognized that the user has registered a specific function (e.g., as FaaS) with the execution cloud environment.

[0032] According to some embodiments, on the notification cloud environment side, the user grants the RFI service permission to receive notifications from (one or more) services used by cloud resources or poll (one or more) service instances through a standard role-based access control (RBAC) API. On the execution cloud environment side, the user grants permission to the RFI service instance to call functions on behalf of the customer. It can be appreciated that the RFI framework provides a multi-tenant, general, cloud and service-independent way to securely call remote functions on the selected cloud according to the user's expectations. In addition, the RFI service framework also provides functionality such as auditing, monitoring, logging, and metering capabilities.

[0033] Figure 1A An exemplary architecture of a remote function invocation (RFI) service according to various embodiments is depicted. The architecture 100 of the RFI service includes a source cloud environment (i.e., cloud environment I 101) referred to herein as a notification cloud environment and a target cloud environment (i.e., cloud environment II 111) referred to herein as an execution cloud environment. Each of the notification cloud environment 101 and the execution cloud environment 111 includes an instance of an RFI service lease. For example, Figure 1A As shown in , notification cloud environment 101 includes RFI service lease 105 referred to herein as notification side RFI service lease and execution cloud environment 111 includes RFI service lease 115 referred to herein as execution side RFI service lease. In addition, notification cloud environment 101 includes customer lease 102 and execution cloud environment includes customer lease 113.

[0034] The RFI service provides execution of a function 117 deployed in a customer lease 113 of an execution cloud environment 111 in response to a notification received from an RFI service lease 105 (i.e., a notification-side RFI service lease) in a notification cloud environment 101. The notification-side RFI service lease 105 is configured to receive notifications from a notification source 103 deployed in a customer lease 102 of the notification cloud environment 101. Specifically, according to one embodiment, the notification-side RFI service lease 105 registers itself with the cloud resource 104A to become a target for receiving notifications related to the occurrence of any event related to the cloud resource 104A or notifications generated by a service used by the cloud resource.

[0035] In some embodiments, the service used by the cloud resource 104A may not generate any notifications (e.g., a queuing service). In such cases, the notification-side RFI service lease 105 is configured to poll the service or message queue 104B or event bridge 104C to obtain notifications or determine the occurrence of an event. The occurrence of an event or notification is associated with a request to execute a function. As described above, the RFI framework allows users to take full advantage of (one or more) other cloud environments to obtain higher availability, lower costs, etc. Therefore, the (one or more) notifications obtained by the notification-side RFI service lease 105 are transmitted to the execution-side RFI service lease 115, and the execution-side RFI service lease 115 executes the requested function 117 deployed in the customer lease 113 of the execution-side cloud environment. In this way, the RFI service framework provides integration between functions executed in one cloud environment and events / notifications from services in a completely different cloud environment. Reference here Figure 2 Describe the detailed architecture of the RFI service.

[0036] Figure 1B Illustrated is a simplified flow chart 150 depicting steps performed by an RFI service according to certain embodiments. Figure 1B The processes depicted in the can be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the corresponding system, hardware, or a combination thereof. The software can be stored on a non-transitory storage medium (e.g., on a memory device). Figure 1B The methods presented in and described below are intended to be illustrative and non-limiting. Figure 1B Various processing steps are depicted as occurring in a particular order or sequence, but this is not intended to be limiting. In some alternative embodiments, the steps may be performed in a different order, or some steps may be performed in parallel.

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

[0038] In step 135, the source RFI service lease transmits a notification to a target RFI service lease (i.e., an execution-side RFI service lease) included in the target cloud environment (i.e., an execution-side environment). For example, the notification-side RFI service lease forwards the notification to the execution-side RFI service lease included in the execution cloud environment. Then, the process moves to step 140, where the target RFI service lease (i.e., the execution-side RFI service lease) calls a function to be executed in the target cloud environment. For example, referring to Figure 1A , the execution-side RFI service lease 115 calls the function 117 (deployed in the customer lease 113 of the execution cloud environment 111) to be executed.

[0039] Now turn to Figure 2 , Figure 2 Describes an exemplary detailed architecture of an RFI service according to various embodiments. Figure 2 As shown in FIG. 2 , the architecture 200 of the RFI service includes a source cloud environment (i.e., cloud environment I) referred to herein as a notification cloud environment 201, and a target cloud environment (i.e., cloud environment II) referred to herein as an execution cloud environment 231. As mentioned above, the RFI service of the present disclosure is intended to provide integration between a serverless function in one cloud environment (e.g., the execution cloud environment 231) and an event / notification from a service in a completely different cloud environment (e.g., the notification cloud environment 201).

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

[0041] According to some embodiments, in the execution cloud environment 231, the execution-side RFI service lease 233 includes a control plane 235 hosting 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 in which notifications received from resources in different clouds can be used to trigger calls to configured functions. The execution cloud environment 231 also includes a customer lease 243, an identity management service 239, and a serverless function service 241. The customer lease 243 includes one or more functions 242 deployed therein. The serverless function service 241 includes a service in which a server for executing the function is instantiated on demand in response to a call to invoke a function.

[0042] The notification cloud environment 201 is communicatively coupled to the execution cloud environment 231 via a secure transport channel. Specifically, according to one embodiment, the forwarder agent 205 included in the notification cloud environment 201 is communicatively coupled to the 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 a customer defines different groups of resources in one cloud environment (e.g., cloud resources 211 in the notification cloud environment 201), which provide notifications about specified events. In addition, 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), and for cost-saving purposes, the customer expects to use the service to offload its computing workload. In other words, the customer expects to have a serverless function in one cloud provider be triggered based on an event or notification generated by a resource in another cloud provider. According to some embodiments, in order to achieve the above functionality, a setup or registration phase is provided, in which the customer creates an instance of the RFI service (in both cloud environments) and enters necessary information about a notification source identifier and a notification target identifier. Reference will be made later to Figure 3A and Figure 3B Describes the details related to the registration phase.

[0043] According to some embodiments, forwarder proxy 205 included in notification-side RFI service lease 203 (included in notification cloud environment 201) registers itself with cloud resource 211 (deployed in customer lease 209 of notification cloud environment 201) as a target for receiving notifications from cloud resource 211. Specifically, forwarder proxy 205 registers an endpoint (e.g., an HTTP endpoint) via which it expects to receive notifications from cloud resource 211.

[0044] Upon receiving a request from the forwarder proxy 205 to register as a target for notifications, the cloud resource 211 (deployed in the customer tenancy 209 of the notification cloud environment 201) 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 performed based on the user-defined subscription policy 213. The subscription policy 213 defines whether the forwarder proxy 205 (i.e., in the RFI service account / tenancy 203) is allowed to subscribe to notifications from the cloud resource 211. Note that trust is established between the forwarder proxy 205 and the customer tenancy 209 in the notification cloud environment based on the user-defined subscription policy 213.

[0045] After successful authentication, the forwarder proxy 205 is registered as a target for cloud resources 211 to direct notifications related to different services occurring in the customer's tenancy. It will be appreciated that some services are capable of issuing / generating notifications. In such cases, the forwarder proxy 205 can be subscribed as a target for notifications, as described above. However, in some cases, a service may not be able to generate notifications, such as a queuing service. In such a case, the forwarder proxy 205 can be configured to poll the service for notifications. This is done by Figure 2 The dotted line 207 in FIG. Figure 3B Describes details about configuring forwarder proxy 205 to poll for services.

[0046] 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, a user can define certain types of notifications that the user is interested in. Such information can be maintained in a metadata database 215 associated with the forwarder agent 205. In this way, after receiving multiple notifications, the forwarder agent 205 can communicate with the metadata database 215 to determine, for each notification, whether the type of notification received is what the user expects. In other words, the forwarder agent performs filtering operations based on the information maintained in the metadata database 215.

[0047] After performing the filtering operation, for each notification that the forwarder agent 205 is to transmit to the listener agent 236 (in the execution cloud environment 231), the forwarder agent 205 can create a message (e.g., a notification message (i.e., simply referred to as a notification)). In one embodiment, the notification message can include metadata that identifies: the type of notification (i.e., the metadata includes a notification identifier) ​​and the cloud resource that generated the notification (i.e., the metadata includes a cloud resource identifier). The forwarder agent 205 also forwards the notification message to the listener agent 236 (via the secure transport channel 220) for further processing (e.g., calling a function (associated with the notification) to be executed in the execution cloud environment hosting the listener agent 236).

[0048] The notification transmitted by the forwarder agent 205 is received by the listener agent 236. It is noted that the listener agent 236 is deployed in the data plane of the RFI service in the execution side RFI service lease 233. According to one embodiment, the listener agent 236 performs a lookup operation after receiving the notification to identify the function to be called (and the corresponding customer lease hosting the function) based on the received notification. In one embodiment, the listener agent 236 communicates with the mapping database 237 to identify the function to be called. It can be appreciated that the mapping database 237 stores information related to the mapping of the notification and the corresponding function to be called. Context information related to the customer lease hosting the function can also be stored in the mapping database 237.

[0049] After identifying the function (and the corresponding customer tenancy in the execution cloud environment hosting the function), the listener agent 236 obtains credentials (e.g., a token) from the identity management service 239 of the execution cloud environment 231. In addition, the listener agent 236 forwards the token to the serverless function service 241 so as to call the function 242 in 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 privileges associated with the credentials, i.e., to determine whether the credentials have sufficient privileges 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 is obtained) is allowed to issue a query targeted to the customer tenancy hosting the function. Such a check can be performed based on information maintained in a user-defined execution policy 245. The execution policy 245 defines whether a service deployed in the execution-side service tenancy (e.g., the listener agent 236) is allowed to access (one or more) functions deployed in the customer tenancy 243 of the execution cloud environment 231. After the check is successfully executed, the serverless function service 241 starts the function 242 in the customer lease 243, that is, the serverless function service 241 calls the function 242 to be executed in the customer lease 243.

[0050] In this way, as described in the above embodiment, the RFI service enables a notification received in a source cloud environment (i.e., notification cloud environment 201) to call a function for execution in a target cloud environment (i.e., execution cloud environment 231) different from the source cloud environment. In addition, it can be appreciated that Figure 2 The above embodiments in no way limit the scope of the present disclosure. Rather, modifications to the architecture of the RFI service are entirely within the scope of the present disclosure. For example, Figure 2A single listener agent 236 deployed in the data plane of the execution-side RFI service lease and a single forwarder agent 205 deployed in the data plane of the notification-side RFI service lease are depicted. According to some embodiments, an alternative architecture for the RFI service may include a pool of listener agents in the execution-side RFI service lease and a pool of forwarder agents deployed in the notification-side RFI service lease. In such a setup, a pair of agents (i.e., a forwarder agent and a listener agent) may be dynamically selected based on certain conditions (e.g., the current traffic load in the system) to transmit notifications from the notification cloud environment 201 to the execution cloud environment 231.

[0051] Figure 3A A swimming diagram illustrating the process of registering a function call for notifications received from a service according to some embodiments is depicted. Figure 3A As shown in , the components of the swimming graph include a function as a service (FaaS) module 301, an RFI control plane module 303, a listener agent 305, a forwarder agent 307, and an SNS (Simple Notification Service) service module 309. It can be appreciated that the FaaS module 301, the RFI control plane module 303, and the listener agent 305 are deployed in the execution cloud environment 231, while the forwarder agent 307 and the SNS module are deployed in the notification cloud environment 201.

[0052] like Figure 3A As shown in , in step S1, user 302 deploys a function using FaaS module 301 in execution cloud environment 231. In step S2, user 302 registers a function call for notification in RFI control plane 303. Figure 3A In the example depicted in FIG, the service considered in the notification cloud environment 201 is considered as a simple notification service (i.e., SNS). It can be appreciated that a notification can correspond to an SNS topic. In addition, the registration of the function call can include an identifier (e.g., a resource identifier) ​​of a resource deployed in the notification cloud environment 201 and utilizing the service (i.e., SNS).

[0053] Once the function call request is registered with 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 for the notification (e.g., SNS topic) in the listener agent 305. In other words, the listener agent 305 stores the mapping between the notification and the corresponding function to be called (upon receipt of the notification) in a local database associated with the listener agent 305 (e.g., Figure 2 The mapping database 237). The mapping associates the notification with the function including the context information.

[0054] 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 with 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 in order to receive notifications from the service via the endpoint. In step S6, the service 309 transmits a confirmation back to the forwarder agent 307 (i.e., the service 309 confirms the subscription of the forwarder agent 307 to receive notifications (e.g., notifications about SNS topics)). After confirming the subscription, the forwarder agent 307 is configured to receive notifications on the registered endpoint (e.g., the HTTP endpoint from the service 309).

[0055] It can be appreciated that in some cases, a service executing in the notification cloud environment 201 may not be able to send out a notification. In this case, the forwarder agent is configured to poll the service for notifications. In this case, the service may communicate with the following: Figure 3B Corresponding to the Simple Queue Service (SQS) 311 shown in . Figure 3B Another swimming diagram illustrating the process of registering a function call for notification (via polling) according to some embodiments is depicted. Figure 3B In the step S11, S13 and S15, respectively Figure 3A Steps S1, S2 and S3 in are similar. Therefore, in order to avoid repetition, the description of these steps will not be repeated here.

[0056] In step S17, RFI control plane 303 submits a request to forwarder proxy 307. The request indicates to the forwarder proxy that the forwarder proxy can poll the service (SQS) (e.g., poll the queue associated with service 311 for new messages (i.e., notifications)). In step S19, forwarder proxy 307 is ready to poll the queue associated with service 311 after receiving the request from RFI control plane 303.

[0057] Steering Figure 4A , illustrates a simplified flow chart depicting steps performed by a forwarder proxy according to certain embodiments. Figure 4A The processing depicted in the can be implemented in software (e.g., code, instructions, program) executed by one or more processing units (e.g., processors, cores) of the corresponding system, hardware, or a combination thereof. The software can be stored on a non-transitory storage medium (e.g., on a memory device). Figure 4A The methods presented in and described below are intended to be illustrative and non-limiting. Figure 4AVarious processing steps are depicted as occurring in a particular order or sequence, but this is not intended to be limiting. In some alternative embodiments, the steps may be performed in a different order, or some steps may be performed in parallel.

[0058] Processing begins at step 401, where a forwarder agent deployed in a source RFI service lease in a source cloud environment receives a notification from a cloud resource (utilizing some service) to invoke a function deployed in a target cloud environment (i.e., different from the source cloud environment). Figure 2 , the forwarder agent 205 deployed in the notification-side RFI service lease 203 receives the notification to call the function from the cloud resource 211.

[0059] In step 403, according to some embodiments, the forwarder agent creates a message based on the received notification. In one embodiment, the created message may include metadata identifying the type of notification (i.e., the metadata may include a notification identifier) ​​and the ID of the cloud resource that issued the notification. The message created in step 403 is transmitted by the forwarder agent (e.g., as a notification message) to a listener agent deployed in a target RFI service lease in a target cloud environment. For example, referring to Figure 2 , the forwarder agent transmits the notification to the listener agent 236 deployed in the execution-side RFI service lease 233.

[0060] Now turn to Figure 4B , illustrates a simplified flow chart depicting steps performed by a listener agent according to certain embodiments. Figure 4B The processes depicted in the can be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the corresponding system, hardware, or a combination thereof. The software can be stored on a non-transitory storage medium (e.g., on a memory device). Figure 4B The methods presented in and described below are intended to be illustrative and non-limiting. Figure 4B Various processing steps are depicted as occurring in a particular order or sequence, but this is not intended to be limiting. In some alternative embodiments, the steps may be performed in a different order, or some steps may be performed in parallel.

[0061] Processing begins at step 410, where a listener agent receives a message (eg, a notification) from a forwarder agent. Figure 2, a listener agent 236 deployed in an execution-side RFI lease 233 included in an execution cloud environment receives a notification from a forwarder agent 205 in a notification-side RFI lease deployed in a notification cloud environment. In step 415, the listener agent determines a function to be called based on the received message and according to a function call mapping. For example, the listener agent 236 performs a lookup operation in a mapping database 237 associated with the listener agent 236. The mapping database maintains a plurality of mappings, each of which corresponds to a notification and an associated function to be called (including context information). It will be appreciated that the context information may include identifying a customer lease in the execution cloud environment that hosts the function (e.g., Figure 2 Information about customer leasing in 243).

[0062] Processing then moves to step 420, where the listener agent 236 obtains credentials (e.g., a token) from an identity management service included in the target cloud environment (i.e., the execution cloud environment). After obtaining the credentials, the listener agent 236 transmits the credentials to the serverless function service. Processing then moves to step 425, where the serverless function service communicates with the identity management service of the target cloud environment to verify the privileges associated with the credentials received from the listener agent. Specifically, by one embodiment, a check is performed to determine whether the listener agent (i.e., the entity from which the token was obtained) is allowed to issue a query targeted to the customer tenancy hosting the function. This may be based on a user-defined execution policy (e.g., Figure 2 This check is performed based on information maintained in the execution policy 245 of the execution cloud environment 231. The execution policy defines whether a service deployed in the execution-side service lease (eg, listener agent 236) is allowed to access function(s) deployed in the customer lease 243 of the execution cloud environment 231.

[0063] In response to a successful determination made in step 425, processing moves to step 430, where the serverless function service invokes the function to be executed in the customer's lease. Figure 4A and Figure 4B As described in the flowchart of , the RFI service of the present disclosure provides integration between serverless functions executed in one cloud environment based on events / notifications from services in completely different cloud environments.

[0064] Figure 5A The diagram illustrates the completion of the Figure 4A A swimming diagram of the function calls after the registration process. Figure 5AAs shown in , the components of the swimming graph include a function as a service (FaaS) module 301, an RFI control plane module 303, a listener agent 305, a forwarder agent 307, an SNS (Simple Notification Service) service module 309, and a publisher 501. It can be appreciated that the FaaS module 301, the RFI control plane module 303, and the listener agent 305 are deployed in the execution cloud environment 231, while the forwarder agent 307 and the SNS module are deployed in the notification cloud environment 201.

[0065] In step S21, publisher 501 publishes a message to SNS service 309. Publishing a message on SNS service 309 causes the SNS service to issue a notification which is transmitted to forwarder agent 307. Note that this occurs because the forwarder has registered with service 309 to receive notifications ( Figure 3A In step S27, the forwarder 307 verifies whether such a notification request exists and whether the request is valid. Specifically, the forwarder 307 may access Figure 2 The metadata database 215 in the , to determine whether the user is not filtering the notification. After a successful determination, the forwarder 307 forwards the notification to the listener agent 305.

[0066] According to some embodiments, the listener agent 305 accesses its local database (e.g., Figure 2 237 in the execution cloud environment 231) to determine the function to be called based on the received notification. According to some embodiments, it is noted that the listener agent 305 maintains multiple mappings in the mapping database, each mapping corresponding to a notification and an associated function to be called (including context information). It is noted that the context information may include information identifying a customer lease in the execution cloud environment that hosts the function. After determining the function to be called (and the customer lease that hosts the function), the listener agent 305 obtains a token to be used to call the function in the customer lease from the identity management service of the execution cloud environment 231. In addition, the listener agent 305 uses the serverless function service to call a specific function deployed in the customer lease (step S31). As previously described, it can be appreciated 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.

[0067] Figure 5B The diagram illustrates the completion of the Figure 4B The function after the registration process is called swimming graph. Specifically, Figure 5B The swimming graph of corresponds to a situation where the service is not configured to send notifications to forwarder proxy 307, and where forwarder proxy 307 polls a service (eg, an SQS service) for notifications.

[0068] In step S31, the forwarder agent 307 collects a queue (e.g., a queue associated with the SQS service 311) to check whether there is a new message in the queue. In step S33, since no new message has been published in 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 on 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 obtains the new message from the queue. In step S41, the forwarder agent continues to forward the notification to the listener agent 305. As previously described with reference to Figure 5A As described, the listener agent 305 may perform processing related to determining a function to be called based on the notification and obtaining a token to be used to call a function in the customer lease of the execution cloud environment (from the identity management service of the execution cloud environment 231). In addition, according to some embodiments, the listener agent 305 uses a serverless function service to call a specific function deployed in the customer lease of the execution cloud environment (step S43).

[0069] Example Infrastructure as a Service Architecture

[0070] As noted 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, IaaS providers can also provide various services to accompany these infrastructure components (e.g., billing, monitoring, logging, security, load balancing and clustering, etc.). Therefore, since these services may be policy-driven, IaaS users may be able to implement policies to drive load balancing to maintain application availability and performance.

[0071] 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 into that VM. Customers can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application problems, monitoring performance, managing disaster recovery, and more.

[0072] In most cases, the cloud computing model will require the involvement of a cloud provider. A cloud provider may, but need not, specialize in providing (e.g., provisioning, renting, selling) third-party IaaS services. An entity may also choose to deploy a private cloud, thereby becoming its own infrastructure service provider.

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

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

[0075] In some cases, there are two distinct problems with IaaS provisioning. First, there is the initial challenge of provisioning the initial set of infrastructure before anything is running. Second, once everything has been provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both of these challenges can be addressed by enabling configuration that defines the infrastructure in a declarative manner. In other words, the infrastructure (e.g., which components are required and how they interact) can be defined by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which resources, and how they work together) can be described in a declarative manner. In some cases, once the topology is defined, workflows can be generated to create and / or manage the different components described in the configuration files.

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

[0077] In some cases, continuous deployment techniques can be employed to enable deployment of infrastructure code across various virtual computing environments. In addition, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is expected to be deployed to one or more but typically many different production environments (e.g., across various different geographic locations, sometimes across the entire world). However, in some examples, the infrastructure on which the code will be deployed must first be set up. In some cases, provisioning can be done manually, resources can be provisioned using a provisioning tool, and / or code can be deployed using a deployment tool once the infrastructure is provisioned.

[0078] Figure 6 6 is a block diagram 600 illustrating an example mode of an IaaS architecture according to at least one embodiment. A service operator 602 may be communicatively coupled to a secure host lease 604 that may include a virtual cloud network (VCN) 606 and a secure host subnet 608. In some examples, the service operator 602 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, cell phones, iPad®, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass® head mounted displays), running software (such as Microsoft Windows Mobile®) and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.), and supporting Internet, email, short message service (SMS), Blackberry® or other communication protocols. Alternatively, the client computing device may be a general purpose personal computer, including, for example, a personal computer and / or laptop computer running various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems. The client computing device may be a workstation computer running any of a variety of commercially available UNIX® or UNIX-like operating systems, including but not limited to a variety of GNU / Linux operating systems (such as, for example, Google Chrome OS). Alternatively or additionally, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal messaging device capable of communicating over a network that has access to VCN 606 and / or the Internet.

[0079] VCN 606 may include a local peer gateway (LPG) 610, which may be communicatively coupled to a secure shell (SSH) VCN 612 via LPG 610 contained in SSH VCN 612. SSH VCN 612 may include an SSH subnet 614, and SSH VCN 612 may be communicatively coupled to a control plane VCN 616 via LPG 610 contained in control plane VCN 616. In addition, SSH VCN 612 may be communicatively coupled to a data plane VCN 618 via LPG 610. Control plane VCN 616 and data plane VCN 618 may be contained in a service lease 619, which may be owned and / or operated by an IaaS provider.

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

[0081] The control plane VCN 616 may include a data plane mirror application layer 640, which may include application subnet(s) 626. The application subnet(s) 626 included in the data plane mirror application layer 640 may include a virtual network interface controller (VNIC) 642 that may execute a compute instance 644. The compute instance 644 may communicatively couple the application subnet(s) 626 of the data plane mirror application layer 640 to the application subnet(s) 626 that may be included in the data plane application layer 646.

[0082] The data plane VCN 618 may 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 may include (one or more) LB subnets 622, which may be communicatively coupled to the (one or more) application subnets 626 of the data plane application layer 646 and the Internet gateway 634 of the data plane VCN 618. The (one or more) application subnets 626 may 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 may also include (one or more) DB subnets 630, which may be communicatively coupled to the (one or more) application subnets 626 of the data plane application layer 646.

[0083] The internet gateway 634 of the control plane VCN 616 and the data plane VCN 618 may be communicatively coupled to the metadata management service 652, which may be communicatively coupled to the public Internet 654. The public Internet 654 may be communicatively coupled to the NAT gateway 638 of the control plane VCN 616 and the data plane VCN 618. The service gateway 636 of the control plane VCN 616 and the data plane VCN 618 may be communicatively coupled to the cloud service 656.

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

[0085] In some examples, secure host lease 604 can be directly connected to service lease 619, which can otherwise be isolated. Secure host subnet 608 can communicate with SSH subnet 614 through LPG 610, which can enable two-way communication on otherwise isolated systems. Connecting secure host subnet 608 to SSH subnet 614 can enable secure host subnet 608 to access other entities within service lease 619.

[0086] The control plane VCN 616 may allow a user of the service lease 619 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 616 may be deployed or otherwise used in the data plane VCN 618. In some examples, the control plane VCN 616 may be isolated from the data plane VCN 618, and the data plane mirror application layer 640 of the control plane VCN 616 may communicate with the data plane application layer 646 of the data plane VCN 618 via the VNIC 642, which may be included in the data plane mirror application layer 640 and the data plane application layer 646.

[0087] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, through the public internet 654, which may transmit the request to the metadata management service 652. The metadata management service 652 may transmit the request to the control plane VCN 616 through the internet gateway 634. The request may be received by the LB subnet(s) 622 contained in the control plane DMZ layer 620. The LB subnet(s) 622 may determine that the request is valid, and in response to the determination, the LB subnet(s) 622 may transmit the request to the application subnet(s) 626 contained in the control plane application layer 624. If the request is validated and a call to the public internet 654 is required, the call to the public internet 654 may be transmitted to the NAT gateway 638, which may make the call to the public internet 654. The storage that the request may desire to be stored may be stored in the DB subnet(s) 630.

[0088] In some examples, data plane mirror application layer 640 may facilitate direct communication between control plane VCN 616 and data plane VCN 618. For example, it may be desirable to apply changes, updates, or other appropriate modifications to the configuration to the resources contained in data plane VCN 618. Control plane VCN 616, via VNIC 642, may communicate directly with the resources contained in data plane VCN 618 and may thereby perform changes, updates, or other appropriate modifications to the configuration.

[0089] In some embodiments, control plane VCN 616 and data plane VCN 618 may be included in service lease 619. In this case, a user or customer of the system may not own or operate control plane VCN 616 or data plane VCN 618. Alternatively, an IaaS provider may own or operate control plane VCN 616 and data plane VCN 618, both of which may be included in service lease 619. This embodiment may enable isolation of networks that may prevent a user or customer from interacting with the resources of other users or other customers. In addition, this embodiment may allow a user or customer of the system to store databases privately without relying on the public Internet 654, which may not have the desired level of security, for storage.

[0090] In other embodiments, the LB subnet(s) 622 contained 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 called by customers of the IaaS provider without calling the public Internet 654. Customers of the IaaS provider may desire this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on the service lease 619, which may be isolated from the public Internet 654.

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

[0092] The control plane VCN 716 may include a control plane DMZ layer 720 (e.g., Figure 6 The control plane DMZ layer 620 may include (one or more) LB subnets 722 (e.g., Figure 6 (one or more) LB subnets 622), may include (one or more) application subnets 726 (e.g., Figure 6 The control plane application layer 724 (e.g., Figure 6 The control plane application layer 624 of FIG. 1 may include (one or more) database (DB) subnets 730 (e.g., similar to Figure 6 The control plane data layer 728 (e.g., Figure 6 The LB subnet(s) 722 contained in the control plane DMZ layer 720 may be communicatively coupled to the application subnet(s) 726 contained in the control plane application layer 724 and the Internet gateway 734 (e.g., Figure 6 634), and the application subnet(s) 726 may be communicatively coupled to the DB subnet(s) 730 and the service gateway 736 (e.g., Figure 6 Serving gateway) and network address translation (NAT) gateway 738 (e.g., Figure 6 The control plane VCN 716 may include a service gateway 736 and a NAT gateway 738.

[0093] The control plane VCN 716 may include: a data plane mirror application layer 740 (eg, Figure 6 The data plane image application layer 640). The application subnet(s) 726 included in the data plane image application layer 740 may include a computing instance 744 (e.g., similar to Figure 6The compute instance 744 may be configured to include a virtual network interface controller (VNIC) 742 (eg, VNIC 642) of the compute instance 644. The compute instance 744 may facilitate the application subnet(s) 726 of the data plane mirroring application layer 740 and the application subnets 726 that may be included in the data plane application layer 746 (eg, Figure 6 Communication between (one or more) application subnets 726 in the data plane application layer 646) via the VNIC 742 contained in the data plane mirror application layer 740 and the VNIC 742 contained in the data plane application layer 746.

[0094] The Internet gateway 734 included in the control plane VCN 716 can be communicatively coupled to the metadata management service 752 (e.g., Figure 6 ), which can be communicatively coupled to a public Internet 754 (e.g., Figure 6 The public Internet 754 can be communicatively coupled to a 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 cloud services 756 (e.g., Figure 6 Cloud services 656).

[0095] In some examples, the data plane VCN 718 may be contained in a customer lease 721. In this case, the IaaS provider may provide a control plane VCN 716 for each customer, and the IaaS provider may provision each customer with a unique compute instance 744 contained in a service lease 719. Each compute instance 744 may allow communication between a control plane VCN 716 contained in a service lease 719 and a data plane VCN 718 contained in a customer lease 721. The compute instance 744 may allow resources provisioned in a control plane VCN 716 contained in a service lease 719 to be deployed or otherwise used in a data plane VCN 718 contained in a customer lease 721.

[0096] In other examples, a customer of the IaaS provider may have a database that exists in the customer lease 721. In this example, the control plane VCN 716 may include a data plane mirror application layer 740, which may include (one or more) application subnets 726. The data plane mirror application layer 740 may reside in the data plane VCN 718, but the data plane mirror application layer 740 may not be in the data plane VCN 718. That is, the data plane mirror application layer 740 may access the customer lease 721, but the data plane mirror application layer 740 may not exist in the data plane VCN 718 or be owned or operated by the customer of the IaaS provider. The data plane mirror application layer 740 may be configured to make calls to the data plane VCN 718, but may not be configured to make calls to any entity contained in the control plane VCN 716. A customer may desire to deploy or otherwise use resources provisioned in control plane VCN 716 in data plane VCN 718, and data plane mirror application layer 740 may facilitate the customer's desired deployment or other use of resources.

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

[0098] In some embodiments, cloud services 756 may be called by service gateway 736 to access services that may not exist on public Internet 754, control plane VCN 716, or data plane VCN 718. The connection between cloud services 756 and control plane VCN 716 or data plane VCN 718 may not be real-time or continuous. Cloud services 756 may exist on different networks owned or operated by IaaS providers. Cloud services 756 may be configured to receive calls from service gateway 736 and may be configured not to receive calls from public Internet 754. Some cloud services 756 may be isolated from other cloud services 756, and control plane VCN 716 may be isolated from cloud services 756 that may not be in the same region as control plane VCN 716. For example, control plane VCN 716 may be located in "Region 1", and cloud service "Deployment 6" may be located in Region 1 and "Region 2". If a service gateway 736 contained in a control plane VCN 716 located in region 1 makes a call to deployment 6, the call may be transmitted to deployment 6 in region 1. In this example, control plane VCN 716 or deployment 6 in region 1 may not be communicatively coupled or otherwise in communication with deployment 6 in region 2.

[0099] Figure 8 8 is a block diagram 800 illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 802 (e.g., Figure 6 The service operator 602) may be communicatively coupled to the secure host lease 804 (e.g., Figure 6 The secure host lease 804 may include a virtual cloud network (VCN) 806 (e.g., Figure 6 VCN 606) and secure host subnet 808 (e.g., Figure 6 VCN 806 may include LPG 810 (e.g., Figure 6 810 ), which may be communicatively coupled to the SSH VCN 812 via the LPG 810 contained in the SSH VCN 812 (e.g., Figure 6 SSH VCN 812). SSH VCN 812 may include SSH subnet 814 (e.g., Figure 6 SSH subnet 614), and SSH VCN 812 may be communicatively coupled to control plane VCN 816 via LPG 810 contained in control plane VCN 816 (e.g., Figure 6 The control plane VCN 616 of the embodiment of the present invention is coupled to the data plane VCN 818 (eg, control plane VCN 616 of the embodiment of the present invention) and is coupled to the data plane VCN 818 (eg, control plane VCN 616 of the embodiment of the present invention) via the LPG 810 contained in the data plane VCN 818 Figure 6The control plane VCN 816 and the data plane VCN 818 may be included in a service lease 819 (e.g., Figure 6 of service lease 619).

[0100] The control plane VCN 816 may include: may include (one or more) load balancer (LB) subnet 822 (e.g., Figure 6 The control plane DMZ layer 820 (e.g., Figure 6 The control plane DMZ layer 620 may include (one or more) application subnets 826 (e.g., similar to Figure 6 The control plane application layer 824 (e.g., Figure 6 The control plane application layer 624 of the embodiment of the present invention may include a control plane data layer 828 (eg, Figure 6 The LB subnet(s) 822 contained in the control plane DMZ layer 820 may be communicatively coupled to the application subnet(s) 826 contained in the control plane application layer 824 and the internet gateway 834 (e.g., Figure 6 824 ), and the application subnet(s) 826 may be communicatively coupled to the DB subnet(s) 830 and the service gateway 836 (e.g., Figure 6 Serving gateway) and network address translation (NAT) gateway 838 (e.g., Figure 6 The control plane VCN 816 may include a service gateway 836 and a NAT gateway 838.

[0101] The data plane VCN 818 may include a data plane application layer 846 (e.g., Figure 6 Data plane application layer 646), data plane DMZ layer 848 (for example, Figure 6 Data plane DMZ layer 648), and data plane data layer 850 (e.g., Figure 6The data plane DMZ layer 848 may include the trusted application subnet(s) 860 and the untrusted application subnet(s) 862 that may be communicatively coupled to the data plane application layer 846 and the LB subnet(s) 822 of the Internet gateway 834 included in the data plane VCN 818. The trusted application subnet(s) 860 may be communicatively coupled to the service gateway 836 included in the data plane VCN 818, the NAT gateway 838 included in the data plane VCN 818, and the DB subnet(s) 830 included in the data plane data layer 850. The untrusted application subnet(s) 862 may be communicatively coupled to the service gateway 836 included in the data plane VCN 818 and the DB subnet(s) 830 included in the data plane data layer 850. The data plane data layer 850 may include the DB subnet(s) 830 that may be communicatively coupled to the service gateway 836 included in the data plane VCN 818.

[0102] The untrusted application subnet(s) 862 may include one or more primary VNICs 864(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 866(1)-(N). Each tenant VM 866(1)-(N) may be communicatively coupled to a respective application subnet 867(1)-(N) that may be contained in a respective container egress VCN 868(1)-(N), which may be contained in a respective customer tenancy 870(1)-(N). A respective secondary VNIC 872(1)-(N) may facilitate communications between the untrusted application subnet(s) 862 contained in the data plane VCN 818 and the application subnets contained in the container egress VCN 868(1)-(N). Each container egress VCN 868(1)-(N) may include a NAT gateway 838 that may be communicatively coupled to the public Internet 854 (e.g., Figure 6 of the public Internet 654).

[0103] An internet gateway 834 included in control plane VCN 816 and included in data plane VCN 818 may be communicatively coupled to a metadata management service 852 (e.g., Figure 6The metadata management service 852 may be communicatively coupled to the public Internet 854. The public Internet 854 may be communicatively coupled to a NAT gateway 838 included in the control plane VCN 816 and included in the data plane VCN 818. The service gateway 836 included in the control plane VCN 816 and included in the data plane VCN 818 may be communicatively coupled to the cloud service 856.

[0104] In some embodiments, the data plane VCN 818 can be integrated with the customer lease 870. In some cases, such integration may be useful or desirable for customers of the IaaS provider, such as where support may be desired when executing code. A customer may provide code to run that may be destructive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response to this, the IaaS provider may determine whether to run the code given to the IaaS provider by the customer.

[0105] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider and request functionality attached to a data plane layer application 846. Code running the functionality may be executed in a VM 866(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 818. Each VM 866(1)-(N) may be connected to a customer tenancy 870. The corresponding container 871(1)-(N) contained in the VM 866(1)-(N) may be configured to run the code. In this case, there may be double isolation (e.g., the container 871(1)-(N) runs the code, where the container 871(1)-(N) may be contained at least in the VM 866(1)-(N) contained in the (one or more) untrusted application subnets 862), which may help prevent incorrect or otherwise undesirable code from damaging the IaaS provider's network or damaging the network of a different customer. Containers 871(1)-(N) may be communicatively coupled to customer lease 870 and may be configured to transmit or receive data from customer lease 870. Containers 871(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 818. After running the code is complete, the IaaS provider may terminate or otherwise dispose of containers 871(1)-(N).

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

[0107] In other embodiments, the control plane VCN 816 and the data plane VCN 818 may not 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 may occur indirectly through at least one method. The LPG 810 may be established by an IaaS provider, which may 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 may call the cloud service 856 via the service gateway 836. For example, the call from the control plane VCN 816 to the cloud service 856 may include a request for a service that can communicate with the data plane VCN 818.

[0108] Fig. 9 900 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 902 (e.g., Figure 6 The service operator 602) may be communicatively coupled to the secure host lease 904 (e.g., Figure 6 The secure host lease 904 may include a virtual cloud network (VCN) 906 (eg, Figure 6 VCN 606) and secure host subnet 908 (e.g., Figure 6 VCN 906 may include LPG 910 (e.g., Figure 6 LPG 610), which LPG 910 can be included in the SSH VCN 912 (e.g., Figure 6 The LPG 910 in the SSH VCN 612 is communicatively coupled to the SSH VCN 912. The SSH VCN 912 may include an SSH subnet 914 (e.g., Figure 6SSH subnet 614), and SSH VCN 912 may be communicatively coupled to control plane VCN 916 via LPG 910 included in control plane VCN 916 (e.g., Figure 6 The control plane VCN 616 of the embodiment of the present invention is coupled to the data plane VCN 918 (eg, the control plane VCN 616 of the embodiment of the present invention) and is coupled to the data plane VCN 918 (eg, the control plane VCN 616 of the embodiment of the present invention) via the LPG 910 contained in the data plane VCN 918 Figure 6 The control plane VCN 916 and the data plane VCN 918 may be included in a service lease 919 (e.g., Figure 6 of service lease 619).

[0109] The control plane VCN 916 may include: may include (one or more) LB subnets 922 (e.g., Figure 6 The control plane DMZ layer 920 (e.g., Figure 6 The control plane DMZ layer 620 may include (one or more) application subnets 926 (e.g., Figure 6 The control plane application layer 924 (e.g., Figure 6 The control plane application layer 624 of FIG. 1 may include (one or more) DB subnets 930 (eg, Figure 8 The control plane data layer 928 (e.g., Figure 6 The LB subnet(s) 922 contained in the control plane DMZ layer 920 may be communicatively coupled to the application subnet(s) 926 contained in the control plane application layer 924 and the Internet gateway 934 (e.g., Figure 6 634), and the application subnet(s) 926 may be communicatively coupled to the DB subnet(s) 930 and the service gateway 936 (e.g., Figure 6 Serving gateway) and network address translation (NAT) gateway 938 (e.g., Figure 6 The control plane VCN 916 may include a service gateway 936 and a NAT gateway 938.

[0110] The data plane VCN 918 may include a data plane application layer 946 (e.g., Figure 6 Data plane application layer 646), data plane DMZ layer 948 (for example, Figure 6 Data plane DMZ layer 648), and data plane data layer 950 (e.g., Figure 6The data plane DMZ layer 948 may include (one or more) trusted application subnets 960 (e.g., Figure 8 (one or more) trusted application subnets 860) and (one or more) untrusted application subnets 962 (e.g., Figure 8 The trusted application subnet(s) 960 may be communicatively coupled to the service gateway 936 contained in the data plane VCN 918, the NAT gateway 938 contained in the data plane VCN 918, and the DB subnet(s) 930 contained in the data plane data layer 950. The untrusted application subnet(s) 962 may be communicatively coupled to the service gateway 936 contained in the data plane VCN 918 and the DB subnet(s) 930 contained in the data plane data layer 950. The data plane data layer 950 may include the DB subnet(s) 930 that may be communicatively coupled to the service gateway 936 contained in the data plane VCN 918.

[0111] The untrusted application subnet(s) 962 may include primary VNICs 964(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 966(1)-(N) residing within the untrusted application subnet(s) 962. Each tenant VM 966(1)-(N) may run code in a corresponding container 967(1)-(N) and may be communicatively coupled to application subnet 926 contained in a data plane application layer 946 contained in a container egress VCN 968. Corresponding secondary VNICs 972(1)-(N) may facilitate communications between the untrusted application subnet(s) 962 contained in the data plane VCN 918 and application subnets contained in the container egress VCN 968. The container egress VCN may include a primary VNIC 964(1)-(N) that may be communicatively coupled to a public Internet 954 (e.g., Figure 6 NAT gateway 938 of the public Internet 654).

[0112] The Internet gateways 934 included in the control plane VCN 916 and included in the data plane VCN 918 can be communicatively coupled to the metadata management service 952 (e.g., Figure 6The metadata management service 952 may be communicatively coupled to the public Internet 954. The public Internet 954 may be communicatively coupled to a NAT gateway 938 included in the control plane VCN 916 and included in the data plane VCN 918. A service gateway 936 included in the control plane VCN 916 and included in the data plane VCN 918 may be communicatively coupled to a cloud service 956.

[0113] In some examples, Fig. 9 The architecture model shown in block diagram 900 can be considered as Figure 8 800, and may be desirable to customers of the IaaS provider if the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected region). The customer may access in real time the corresponding container 967(1)-(N) contained in each customer's VM 966(1)-(N). The container 967(1)-(N) may be configured to make calls to the corresponding secondary VNIC 972(1)-(N) contained in the application subnet(s) 926 of the data plane application layer 946, which may be contained in the container egress VCN 968. The secondary VNIC 972(1)-(N) may transmit the call to the NAT gateway 938, which may transmit the call to the public Internet 954. In this example, the containers 967(1)-(N) that may be accessed in real time by the customer may be isolated from the control plane VCN 916 and may be isolated from other entities contained in the data plane VCN 918. Containers 967(1)-(N) may also be isolated from resources of other clients.

[0114] In other examples, a customer may use containers 967(1)-(N) to call cloud service 956. In this example, a customer may run code in container 967(1)-(N) to request a service from cloud service 956. Container 967(1)-(N) may transmit the request to secondary VNIC 972(1)-(N), which may transmit the request to a NAT gateway, which may transmit the request to public Internet 954. Public Internet 954 may transmit the request to LB subnet(s) 922 contained in control plane VCN 916 via Internet gateway 934. In response to determining that the request is valid, LB subnet(s) may transmit the request to application subnet(s) 926, which may transmit the request to cloud service 956 via service gateway 936.

[0115] It should be appreciated that the IaaS architectures 600, 700, 800, 900 depicted in the various figures may have other components in addition to those depicted. In addition, the embodiments shown in the various figures are merely some examples of cloud infrastructure systems that may be combined with embodiments of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the various figures, may combine two or more components, or may have a different configuration or component arrangement.

[0116] In certain embodiments, the IaaS system described herein may include application suites, middleware, and database service offerings delivered 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.

[0117] Fig.10 An example computer system 1000 is illustrated in which various embodiments may be implemented. System 1000 may be used to implement any of the computer systems described above. As shown, computer system 1000 includes a processing unit 1004 that communicates with multiple peripheral subsystems via a bus subsystem 1002. These peripheral subsystems may 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.

[0118] The bus subsystem 1002 provides a mechanism for allowing the various components and subsystems of the computer system 1000 to communicate with each other as intended. Although the bus subsystem 1002 is schematically shown as a single bus, an alternative embodiment of the bus subsystem can utilize multiple buses. The bus subsystem 1002 can be any of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, and a local bus using any of various bus architectures. For example, this architecture can include an industrial standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standard association (VESA) local bus, and a peripheral component interconnect (PCI) bus, which can be implemented as a Mezzanine bus manufactured by the IEEE P1386.1 standard.

[0119] The processing unit 1004, which may 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 may be included in the processing unit 1004. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 1004 may be implemented as one or more independent processing units 1032 and / or 1034, wherein a single-core or multi-core processor is included in each processing unit. In other embodiments, the processing unit 1004 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0120] In various embodiments, the processing unit 1004 can execute various programs in response to the program code and can maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed may reside in (one or more) processors 1004 and / or in the storage subsystem 1018. Through appropriate programming, (one or more) processors 1004 can provide the various functions described above. The computer system 1000 may additionally include a processing acceleration unit 1006, which may include a digital signal processor (DSP), a special processor, and the like.

[0121] I / O subsystem 1008 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as mice or trackballs, touch pads or touch screens incorporated into displays, scroll wheels, click wheels, dials, buttons, switches, keyboards, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices, such as Microsoft Kinect® motion sensors, which enable users to use gestures and voice commands to control input devices such as Microsoft Xbox® 360 game controllers through natural user interfaces and interact with them. User interface input devices may also include eye gesture recognition devices, such as Google Glass® blink detectors that detect eye activity from users (e.g., "blinking" when taking photos and / or making menu selections) and convert eye gestures into inputs in input devices (e.g., Google Glass®). In addition, user interface input devices may include voice recognition sensing devices that enable users to interact with voice recognition systems (e.g., Siri® navigators) through voice commands.

[0122] User interface input devices may also include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game panels and drawing tablets, and audio / video devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser rangefinders, and eye tracking devices. In addition, user interface input devices may include, for example, medical imaging input devices such as computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound equipment. User interface input devices may also include, for example, audio input devices such as MIDI keyboards, digital musical instruments, etc.

[0123] The user interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as using a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. 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 a user or other computers. For example, the user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0124] Computer system 1000 may include a storage subsystem 1018 containing software elements, shown currently located in system memory 1010. System memory 1010 may store program instructions that may be loaded and executed on processing unit 1004, as well as data generated during execution of these programs.

[0125] Depending on the configuration and type of computer system 1000, 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 to and / or currently being operated and executed by processing unit 1004. In some implementations, system memory 1010 may include a variety of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), such as one containing basic routines that help transfer information between elements of computer system 1000 during startup, may typically be stored in ROM. By way of example, but not limitation, system memory 1010 also illustrates application programs 1012, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 1014, and an operating system 1016. As examples, operating system 1016 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

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

[0127] The storage subsystem 1000 may also include a computer-readable storage media reader 1020, which may be further connected to a computer-readable storage medium 1022. Together with the system memory 1010 and, optionally, in conjunction therewith, the computer-readable storage medium 1022 may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

[0128] The computer-readable storage medium 1022 containing the code or portions of the code may also include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and / or transmission of information. This may include tangible computer-readable storage media, such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer-readable media. This may also include non-tangible computer-readable media, such as data signals, data transmissions, or any other media that can be used to send the desired information and can be accessed by the computing system 1000.

[0129] For example, the computer-readable storage medium 1022 may include a hard disk drive that reads or writes from a non-removable non-volatile magnetic medium, a magnetic disk drive that reads or writes from a removable non-volatile magnetic disk, and an optical disk drive that reads or writes from a removable non-volatile optical disk (such as a CD ROM, a DVD, and a Blu-Ray® disk or other optical media). The computer-readable storage medium 1022 may include, but is not limited to, a Zip® drive, a flash memory card, a universal serial bus (USB) flash drive, a secure digital (SD) card, a DVD disk, a digital audio tape, and the like. The computer-readable storage medium 1022 may also include a solid-state drive (SSD) based on non-volatile memory (such as an SSD based on flash memory, an enterprise flash drive, a solid-state ROM, etc.), an SSD based on volatile memory (such as solid-state RAM, dynamic RAM, static RAM), a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using a combination of SSDs based on DRAM and flash memory. The disk drives and their associated computer-readable media may provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer system 1000 .

[0130] The communication subsystem 1024 provides an interface to other computer systems and networks. The communication subsystem 1024 is used as an interface for receiving data from other systems and sending 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 may include a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular phone technology, advanced data network technology such as 3G, 4G or EDGE (Enhanced Data Rates for Global Evolution), Wi-Fi (IEEE 802.11 family of standards), or other mobile communication technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, as an addition or alternative to a wireless interface, the communication subsystem 1024 may provide a wired network connection (e.g., Ethernet).

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

[0132] For example, the communication subsystem 1024 can be configured to receive data feeds 1026 in real time from users of a social network and / or other communication service, such as Twitter® feeds, Facebook® updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0133] Additionally, the communication subsystem 1024 may also be configured to receive data in the form of a continuous data stream, which may include event streams 1028 and / or event updates 1030, which may be continuous or unbounded in nature, real-time events without explicit termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0134] 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 may be in computer communication with one or more streaming data source computers coupled to the computer system 1000 .

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

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

[0137] Although specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are also included within the scope of this disclosure. Embodiments are not limited to operating within certain specific data processing environments, but can be freely operated within multiple data processing environments. In addition, although embodiments have been described using a specific series of transactions and steps, it should be clear to those skilled in the art that the scope of this disclosure is not limited to the described series of transactions and steps. The various features and aspects of the above-described embodiments may be used alone or in combination.

[0138] In addition, although embodiments have been described using specific combinations of hardware and software, it should be appreciated 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 using a combination thereof. The various processes described herein may be implemented in any combination on the same processor or on different processors. Accordingly, where a component or module is described as being configured to perform certain operations, such configuration may be accomplished by, for example, designing an electronic circuit to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or any combination thereof. Processes may communicate using a variety of techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0139] Accordingly, the description and drawings are to be regarded as illustrative rather than restrictive. However, additions, subtractions, deletions and other modifications and changes may be made thereto without departing from the broader spirit and scope set forth in the claims. Therefore, although specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalent forms are within the scope of the following claims.

[0140] The use of the terms "a" and "an" and "the" and similar references in the context of describing the disclosed embodiments (especially in the context of the following claims) is to be interpreted as covering the singular and the plural, unless otherwise indicated herein or clearly contradicted by the context. Unless otherwise stated, the terms "include", "have", "include (including)" and "include (containing)" are to be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connected" should be interpreted as partially or completely contained in, attached to or connected together, even if there are something in the middle. Unless otherwise indicated herein, the enumeration of value ranges herein is intended only to be used as a shorthand method of individually referencing each individual value falling within the range, and each individual value is incorporated into the specification as if it were individually listed 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 and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate the embodiments and does not limit the scope of the present disclosure unless otherwise stated. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0141] Disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in the context generally used to indicate that an item, term, or the like, can be X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless expressly stated otherwise. Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require that at least one of X, at least one of Y, or at least one of Z each be present.

[0142] Preferred embodiments of the present disclosure are described herein, including the best mode known for implementing the present disclosure. Variations of those preferred embodiments will become apparent to those of ordinary skill in the art after reading the above description. Those of ordinary skill should be able to appropriately adopt such variations and may practice the present disclosure in a manner different from that specifically described herein. Accordingly, the present disclosure includes all modifications and equivalent forms of the subject matter recorded in the appended claims where permitted by applicable law. In addition, unless otherwise indicated herein, the present disclosure includes any combination of the above-mentioned elements in all possible variations thereof.

[0143] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference 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.

[0144] In the foregoing description, various aspects of the present disclosure are described with reference to their specific embodiments, but those skilled in the art will appreciate that the present disclosure is not limited thereto. Each feature and aspect disclosed above can be used alone or in combination. In addition, without departing from the broader spirit and scope of this specification, the embodiment can be used in any number of environments and applications other than those described herein. Accordingly, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

Claims

1. A method comprising: obtaining, by a target agent, a notification from a source agent, the target agent being deployed in a target cloud environment and the source agent being deployed in a source cloud environment different from the target cloud environment; The target agent determines the function to be called based on the notification; Verify that the target agent is allowed to call functions deployed in the target customer tenancy of the target cloud environment; as well as In response to successful verification, the function in the target customer tenancy of the target cloud environment is called by the target agent.

2. The method of claim 1, wherein the target agent is deployed in a target service lease in a target cloud environment, and the source agent is deployed in a source service lease in a source cloud environment, the target agent being communicatively coupled to the source agent via a secure communication channel.

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

4. The method of claim 1, 2 or 3, further comprising: obtaining, by the target agent, an identifier associated with the notification; as well as A mapping database is queried to obtain a function associated with the identifier, wherein the mapping database is preconfigured with a plurality of mappings, each mapping identifying a specific function to be called with respect to a specific identifier.

5. The method according to any one of the preceding claims, wherein the step of verifying further comprises: A determination is made whether the target proxy is permitted to access the target customer tenancy in the target cloud environment based on a policy associated with the target cloud environment.

6. The method of claim 5, further comprising: Responsive to a successful determination, obtaining, by the target agent, a token from an identity management service of the target cloud environment; as well as Forward the token to the serverless function service deployed in the target cloud environment.

7. The method of claim 6, further comprising: The serverless function service enables the function deployed in the target customer tenancy of the target cloud environment to be executed.

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

9. The method of any one of claims 2 to 8, wherein the target proxy is deployed in a data plane of a target service lease in a target cloud environment, and the source proxy is deployed in a corresponding data plane of a source service lease in a source cloud environment.

10. A non-transitory computer-readable medium storing specific computer-executable instructions, which, when executed by a processor, cause a computer system to perform operations including: obtaining, by a target agent, a notification from a source agent, the target agent being deployed in a target cloud environment and the source agent being deployed in a source cloud environment different from the target cloud environment; The target agent determines the function to be called based on the notification; Verify that the target agent is allowed to call functions deployed in the target customer tenancy in the target cloud environment; as well as In response to successful verification, the function in the target customer tenancy of the target cloud environment is called by the target agent.

11. The non-transitory computer-readable medium storing specific computer-executable instructions of claim 10, wherein the target agent is deployed in a target service lease in a target cloud environment, and the source agent is deployed in a source service lease in a source cloud environment, the target agent being communicatively coupled to the source agent via a secure communication channel.

12. A non-transitory computer-readable medium storing specific computer-executable instructions as described in claim 10 or 11, wherein the source agent: (i) registers with a cloud resource deployed in a source customer tenancy of a source cloud environment or polls a queue associated with the cloud resource to receive notifications, and (ii) forwards the notification to the target agent after receiving the notification from the cloud resource.

13. The non-transitory computer readable medium storing specific computer executable instructions as claimed in claim 10, 11 or 12, further comprising: obtaining, by the target agent, an identifier associated with the notification; as well as A mapping database is queried to obtain a function associated with the identifier, wherein the mapping database is preconfigured with a plurality of mappings, each mapping identifying a specific function to be called with respect to a specific identifier.

14. The non-transitory computer readable medium storing specific computer executable instructions according to any one of claims 10 to 13, wherein the step of verifying further comprises: A determination is made whether the target proxy is permitted to access the target customer tenancy in the target cloud environment based on a policy associated with the target cloud environment.

15. The non-transitory computer readable medium storing specific computer executable instructions as claimed in claim 14, further comprising: Responsive to a successful determination, obtaining, by the target agent, a token from an identity management service of the target cloud environment; as well as Forward the token to the serverless function service deployed in the target cloud environment.

16. The non-transitory computer readable medium storing specific computer executable instructions as claimed in claim 15, further comprising: The serverless function service enables the function deployed in the target customer tenancy of the target cloud environment to be executed.

17. A non-transitory computer-readable medium storing specific computer-executable instructions as described in claim 16, wherein the serverless function service communicates with an identity management service of a target cloud environment to determine a set of privileges associated with a token.

18. A non-transitory computer-readable medium storing specific computer-executable instructions as described in any one of claims 11 to 17, wherein the target agent is deployed in a data plane of a target service lease in a target cloud environment, and the source agent is deployed in a corresponding data plane of a source service lease in a source cloud environment.

19. A system comprising: processor; as well as A memory comprising instructions that, when executed by a processor, cause the system to at least: obtaining, by a target agent, a notification from a source agent, the target agent being deployed in a target cloud environment and the source agent being deployed in a source cloud environment different from the target cloud environment; The target agent determines the function to be called based on the notification; Verify that the target agent is allowed to call functions deployed in the target customer tenancy in the target cloud environment; as well as In response to successful verification, the function in the target customer tenancy of the target cloud environment is called by the target agent.

20. The system of claim 19, wherein the target agent is deployed in a target service lease in a target cloud environment and the source agent is deployed in a source service lease in a source cloud environment, the target agent being communicatively coupled to the source agent via a secure communication channel.

Images