TECHNICAL FIELD

The present disclosure relates generally to the field of cloud computing; and more specifically, to a Function-as-a-Service (FaaS) controller configured to be used in a FaaS system, and a method for use in a FaaS system.

BACKGROUND

Generally, cloud computing refers to the on-demand availability of computer system resources, especially data storage (e.g., cloud storage) and computing power, without direct active management by a user. The availability of high-capacity networks, low-cost computers, and storage devices, as well as the widespread adoption of hardware virtualization, service-oriented architecture, and autonomic and utility computing, has led to growth in cloud computing. The cloud computing providers generally offer their “services” according to different models, such as Infrastructure-as-a-Service (laaS), Platform-as-a- Service (PaaS), and Software-as-a-Service (SaaS). Typically, Function-as-a-Service (FaaS) model has become a prevalent offering in cloud computing environments. The FaaS model is also referred to as serverless computing. The FaaS model or FaaS infrastructure is responsible for managing user-provided arbitrary small programs (i.e., functions) and invoke them on user-defined events. A typical function is invoked upon request coming from a network (or triggered by some timer/timeout). Further, the typical function is short-running, i.e., bound by seconds. Moreover, the typical function responds to requests or invokes other functions. For instance, when a request arrives, the FaaS infrastructure creates a worker (e.g., a container, a virtual machine, or a process) with an adequate runtime and user-provided code to service the request (and any other incoming requests of similar nature).

Conventionally, a cloud is used by different entities to achieve their own goals. In a typical public cloud, there are many different types of entities, such as organizations/tenants, projects (within a specific organization), users, teams (of several users), and infrastructurespecific entities (e.g., a function or a virtual machine). Further, a policy governs the relations and the access between different types of entities. For example, a policy may allow a function to access all other functions in the same project; alternatively, a different policy can allow a function access to all functions in the organization. Further, the same approach is applied to private clouds as well, where in a single organization, the access is restricted based on organizational units or otherwise. Thus, it is paramount to ensure that one function is not privy to information available to other functions in a secured manner.

In certain scenarios, a conventional serverless computing platform uses an open-source virtualization technology to run user code inside a sandbox (i.e., a testing environment that isolates untested code changes and outright experimentation from the production environment or repository). However, running the sandbox per entity or group of entities has a considerable cost and sandboxes introduce a lot of duplication because each one bundles the relevant runtime into itself. Moreover, the sandboxes are terminated only after they are idle for a defined period. Thus, there exists a technical problem of inefficiency and unreliability associated with conventional serverless computing platforms and how to isolate functions of different entities using same platform securely.

Therefore, in light of the foregoing discussion, there exists a need to overcome the aforementioned drawbacks associated with conventional serverless computing platforms.

SUMMARY

The present disclosure provides a Function-as-a-Service (FaaS) controller configured to be used in a FaaS system, and a method for use in a FaaS system. The present disclosure provides a solution to the existing problem of inefficiency and unreliability associated with conventional serverless computing platforms and how to isolate functions of different of different entities using same computing platform securely. An aim of the present disclosure is to provide a solution that overcomes at least partially the problems encountered in prior art, and provide an improved FaaS controller and method for FaaS system, which accepts only those functions that are safe. Additionally, a single FaaS worker can execute functions from multiple tenants and does not employ runtime instrumentation or sandboxing techniques, and runs the provided function as it is, which in turn improves the efficiency of computational resources (e.g., CPU cycles) utilization.

One or more objects of the present disclosure is achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims. According to an aspect, the present disclosure provides a FaaS controller configured to be used in a FaaS system. The FaaS controller is configured to receive computer instructions representing a function from an entity and determine a scope of the function. The FaaS controller is further configured to verify the function as safe based on the scope, and if the function is verified as safe, deploy the function to one or more worker processes.

The FaaS controller of the present disclosure provides an efficient and reliable serverless computing platform to isolate functions of different scopes. The FaaS controller ensures the safety of the function and accepts only those functions that are provably safe according to pre-determined criteria. Further, the FaaS controller eliminates the need for a sandbox for function execution, and thus, less software layers are used to execute the function. Moreover, since more functions can share the runtime, resources (e.g., CPU cycles for initialization) are efficiently utilized.

In an implementation form, the FaaS controller is further configured to verify the function as safe based on the scope by determining one or more accessed scopes of the function; determining that all accessed scopes are the same as the scope of the function based on a user-defined policy, and if so verifying that the function is safe.

In a further implementation form, the FaaS controller is further configured to determine at least one of the one or more accessed scopes by determining at least one function called by the function, and determining a scope of each of the at least one function called by the function as an accessed scope.

In a further implementation form, the FaaS controller is further configured to determine at least one of the one or more accessed scopes by determining at least one memory area accessed by the function; and determining a scope of each of the at least one memory area accessed by the function as an accessed scope.

Thus, functions of different scopes are isolated successfully, and the safety of the function is verified successfully, for several implementation forms.

In a further implementation form, the FaaS controller is further configured to determine that at least one memory access comprises a runtime memory access that is determined during execution of the function, and in response thereto assign a default error scope as the accessed scope of the runtime memory access, the default error scope being different from the scope of the function.

By virtue of the runtime memory access, a default error scope, which is different from the scope of the function, is assigned as the accessed scope of the function.

In a further implementation form, the FaaS controller is further configured to determine that the function is unsafe and in response thereto refrain from verifying the function as safe, and provide details on the determination that the function is unsafe to the entity.

Thus, the unsafe function is sent back to the user for corrections along with the reason for being considered as an unsafe function. Hence, only those functions which are provably safe are stored in the FaaS system.

In a further implementation form, the FaaS controller is further configured to determine that the function is unsafe if the accessed scope of at least one of the at least one function called by the function is different from the scope of the function and in response thereto determine that the details on the determination that the function is unsafe includes the called function having a different scope.

Thus, the function is determined as unsafe if the scope of the function is not the same as the scopes of the functions called by the function and is sent back to the user for corrections.

In a further implementation form, the FaaS controller is further configured to determine that the function is unsafe if the accessed scope of at least one of the at least memory area accessed by the function is different from the scope of the function and in response thereto determine that the details on the determination that the function is unsafe includes the memory area access having a different scope.

Thus, the function is determined as unsafe if the scope of the function is not the same as the scopes of the memory area accessed by the function and is sent back to the user for corrections.

In a further implementation form, the FaaS controller is further configured to determine that the function comprises a runtime memory access, and in response thereto determine that the function is unsafe and that the details on the determination that the function is unsafe includes the runtime memory access. Thus, the function is determined as unsafe if the scope of the function is not the same as the accessed scope of the runtime memory access and is sent back to the user for corrections.

In a further implementation form, the FaaS controller is further configured to deploy the function to the one or more worker processes by storing the function; receiving a request for the function from an entity; and in response thereto cause the one or more worker processes to execute the function.

By virtue of the one or more worker processes, the FaaS worker is notified to load the function retrieved from the FaaS storage into the process memory for execution.

In a further implementation form, the FaaS controller is further configured to deploy the function to the one or more worker processes by furthermore generating and initiating the one or more worker processes and generating each a runtime environment for the function to be executed in by the one or more worker processes.

Thus, all of the functions in a single FaaS worker can run in a single worker process.

In a further implementation form, the FaaS controller comprises a front end, a function verifier, and a function manager. The front end is configured to receive the computer instructions representing the function from the entity. The function verifier is configured to determine the scope of the function and to verify the function as safe based on the scope. The function manager is configured to deploy the function to one or more worker processes.

By virtue of the front end, the function verifier, and the function manager, all the operations of the FaaS controller can be performed successfully.

In a further implementation form, the FaaS system comprises a first device and a second device. The first device is configured to execute at least one of the front end, the function verifier, and the function manager. The second device is configured to execute at least one of the front end, the function verifier, and the function manager.

By virtue of the first device and the second device, the FaaS controller may be spread on different servers. Thus, a single FaaS worker can execute functions from multiple tenants.

In another aspect, the present disclosure provides a method for use in a FaaS system. The method comprises: receiving computer instructions representing a function from an entity; determining a scope of the function; verifying the function as safe based on the scope, and if the function is verified as safe, deploying the function to one or more worker processes.

The method of the present disclosure provides an efficient and reliable serverless computing process to isolate functions of different scopes. The method ensures the safety of the function and accepts only those functions that are provably safe according to pre-determined criteria. Further, the method eliminates the need for a sandbox for function execution, and thus, less software layers are used to execute the function. Moreover, since more functions can share the runtime, resources (e.g., CPU cycles for initialization) are efficiently utilized.

In yet another aspect, the present disclosure provides a computer-readable media comprising instructions that when loaded into and executed by a FaaS controller enables the FaaS controller to execute the method of aforementioned aspect.

The computer-readable media achieves all the advantages and effects of the respective method of the present disclosure.

It has to be noted that all devices, elements, circuitry, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims.

Additional aspects, advantages, features and objects of the present disclosure would be made apparent from the drawings and the detailed description of the illustrative implementations construed in conjunction with the appended claims that follow.

BRIEF DESCRIPTION OF THE DRAWINGS The summary above, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and instrumentalities disclosed herein. Moreover, those in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.

Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

FIG. 1 is a diagram of a Function-as-a-Service (FaaS) system;

FIG. 2 is a flowchart for a method for use in a FaaS system;

FIG. 3 A is an exemplary illustration that depicts a conceptual architecture of FaaS workers under isolated runtime;

FIG. 3B is an exemplary illustration that depicts a conceptual architecture of a FaaS worker under shared runtime;

FIG. 4A is a flowchart for a process that depicts various operations of submit flow executed by a FaaS controller of a FaaS system;

FIG. 4B is a flowchart for a process that depicts various operations of load flow executed by a FaaS controller of a FaaS system;

FIG. 5 A is a flowchart for a process that depicts various operations of submit flow executed by a FaaS controller of a FaaS system;

FIG. 5B is a flowchart for a process that depicts various operations of load flow executed by a FaaS controller of a FaaS system.

In the accompanying drawings, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the nonunderlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing. DETAILED DESCRIPTION OF EMBODIMENTS

The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practicing the present disclosure are also possible.

FIG. 1 is a diagram of a Function-as-a-Service (FaaS) system, in accordance with an embodiment of the present disclosure. With reference to FIG. 1, there is shown a network environment diagram 100 that includes a FaaS System 102 represented by a cloud representation (the cloud representation is used for illustration purpose only). The FaaS system 102 includes a FaaS controller 104 represented by a dashed box (the dashed box is used for illustration purpose only). In an implementation, the FaaS controller 104 includes a front end 104A, a function verifier 104B, and a function manager 104C. The FaaS system 102 further includes a FaaS storage 106 and FaaS workers 108. There is further shown a first entity 110 and a second entity 112.

The FaaS system 102 refers to a cloud computing model that enables users to develop applications and deploy functionalities and only be charged when the function executes. Alternatively stated, the FaaS system 102 provides users with the ability to run a single function, piece of logic, or part of an application and only be charged when the code executes. The FaaS system 102 may also be referred to as a serverless computing model. Unlike other cloud computing models that run on at least one server at all times, the FaaS system 102 only runs when a function is conducted and then shuts down. The FaaS system 102 includes suitable logic, circuitry, interfaces, and/or code that is configured to communicate among the FaaS controller 104, the FaaS storage 106, and the FaaS workers 108

The FaaS controller 104 refers to one or more processors executing a FaaS controlling process. The FaaS controller 104 may also be simply referred to as a controller. The FaaS controller 104 includes suitable logic, circuitry, interfaces, and/or code that is configured to communicate among the front end 104A, the function verifier 104B, and the function manager 104C. The front end 104A is a user-facing part of the FaaS system 102, which allows users to add new functions and manage the existing ones. The function verifier 104B is responsible forjudging, according to pre-determined criteria, whether a given function is safe or not. The function manager 104C is the internal part of the FaaS system 102, which is responsible for function lifecycle (such as persisting functions to FaaS storage 106, scheduling functions to FaaS workers 108). The FaaS controller 104 is configured to be used in the FaaS system 102, and is configured to receive computer instructions representing a function from an entity, determine a scope of the function, and verify the function as safe based on the scope, and if the function is verified as safe, deploy the function to one or more worker processes.

The FaaS storage 106 refers to a cloud storage element containing the function artifacts. Examples of FaaS storage 106 include, but are not limited to, disk-based object storage services, random memory access (RAM) based caching services, block storage services, and the like.

The FaaS workers 108 refers to elements that perform one or more worker processes. The one or more worker processes refers to processes executing a FaaS request in a runtime environment. The one or more worker processes retrieve functions from the FaaS storage 106 and execute functions as a result of an external trigger sent via the second entity 112.

The first entity 110 refers to a user who wants to add a new function or manage the existing functions in the FaaS system 102 via the front end 104A. The user performs its task with the help of a device, such as a smartphone, a laptop computer, an Intemet-of-Things (loT) device, a machine type communication (MTC) device, or any other portable or non-portable electronic device. Examples of the first entity 110 include, but are not limited to, a user, a team (group of several users), an organization/tenant, and the like.

The second entity 112 refers to a user who wants to execute or run a function stored in the FaaS storage 106 of the FaaS system 102. The user performs its task with the help of a device, such as a smartphone, a laptop computer, an Intemet-of-Things (loT) device, a machine type communication (MTC) device, or any other portable or non-portable electronic device. The second entity 112 sends a FaaS request to the FaaS workers 108, which externally triggers the execution of the FaaS request in the runtime environment. Examples of the second entity 112 include, but are not limited to, a user, a team (group of several users), an organization/tenant, and the like.

In operation, the FaaS controller 104 is configured to receive computer instructions representing a function from an entity. The computer instructions are sent via the entity, such as the first entity 110. The computer instructions are received via the front end 104A of the FaaS controller 104. The computer instructions correspond to instructions to submit a new function or manage the existing functions stored in the FaaS storage 106 of the FaaS system 102. The function refers to user-provided arbitrary small programs written in either compiler languages or interpreted languages.

The FaaS controller 104 is further configured to determine a scope of the function. The term scope refers to a specific group of entities that are allowed to share information among them. For example, a scope can be functions of the same project. The function verifier 104B determines the scope of the function submitted by the user. The function verifier 104B ensures that the functions of different scopes (e.g., tenant, project, etc.) are isolated so that one function is not privy to information available to other functions.

The FaaS controller 104 is further configured to verify the function as safe based on the scope, and if the function is verified as safe, deploy the function to one or more worker processes. The verification of the function submitted by the user is done via the function verifier 104B of the FaaS controller 104. The safety of the function is judged by the resources the function accesses during run time. The function is allowed to use infrastructure-provided application programming interfaces and functions. The function is also allowed to access other safe functions of the same scope and global data of the same scope. Further, the function is not allowed to call functions of different scope, access variables of different scope, or access arbitrary memory addresses. For instance, while a first function can be part of a first proj ect scope and a second function can be part of a second proj ect scope, the access of the first function to the second function is not necessarily unsafe because the access to scope is subject to cloud (e.g., the FaaS System 102) and the user-defined policy. For example, a cloud would always forbid cross organization access, but an organization may choose to allow or forbid access across projects. The user-defined policy governs the relations and the access between different types of entities. Hence, one user-defined policy may allow a function to access all other functions in the same project; alternatively, another user-defined policy may allow a function access to all functions in the organization. If the function is verified successfully and deemed safe, it is deployed to the FaaS workers 108 (either proactively or on-demand). Optionally, the function verifier 104B produces a counterexample that can be provided to the user if the function is unsafe. In accordance with an embodiment, the FaaS controller 104 is further configured to verify the function as safe based on the scope by determining one or more accessed scopes of the function; determining that all accessed scopes are the same as the scope of the function based on a user-defined policy, and if so verifying that the function is safe. The one or more accessed scopes of the function correspond to the scopes that are required for the execution of the function. On the other hand, the scope of the function corresponds to the scope specified for the function by the function verifier 104B (i.e., the allowed scope of the function). The user-defined policy governs the accessed scopes between different types of entities. Hence, one user-defined policy may allow a function to access all other functions in the same project; alternatively, another user-defined policy may allow a function access to all functions in the organization. Further, the function verifier 104B considers the function to be safe only if all the accessed scopes of the function are the same as the scope of the function. For example, consider that the scope of a function is project 1, but the one or more accessed scopes of the function are from project 2 or project 3. In such a case, the accessed scopes of the function are not the same as the scope of the function. Hence, the function verifier 104B will not consider this function as safe. Thus, functions of different scopes are isolated successfully.

In accordance with an embodiment, the FaaS controller 104 is further configured to determine at least one of the one or more accessed scopes by determining at least one function called by the function, and determining a scope of each of the at least one function called by the function as an accessed scope. The one or more accessed scopes of the function correspond to the scopes that are required for the execution of the function. The one or more accessed scopes of the function are determined by determining the scope of each of the functions called by the function. Alternatively stated, a main function may include one or more function calls in it. If the scope of the one or more functions called is the same as the scope of the main function, then the main function is considered as a safe function. For example, consider that the scope of a function is project 1, and the scope of the one or more functions called by the function is project 2 and project 3. In such a case, the accessed scopes of the function are determined to be project 2 and project 3, which is not the same as the scope of the function. Hence, the function verifier 104B will not consider this function as safe. Thus, functions of different scopes are isolated successfully. In accordance with an embodiment, the FaaS controller 104 is further configured to determine at least one of the one or more accessed scopes by determining at least one memory area accessed by the function; and determining a scope of each of the at least one memory area accessed by the function as an accessed scope. The one or more accessed scopes of the function correspond to the scopes that are required for the execution of the function. The one or more accessed scopes of the function are determined by determining the scope of each of the memory areas accessed by the function. For example, consider that the scope of a function is memory area access 1 and the scope of the one or more memory areas accessed by the function is memory area access 2 and memory area access 3. In such a case, the accessed scopes of the function are determined to be memory area access 2 and memory area access 3, which is not the same as the scope of the function. Hence, the function verifier 104B will not consider this function as safe. Thus, functions of different scopes are isolated successfully.

In accordance with an embodiment, the FaaS controller 104 is further configured to determine that at least one memory access comprises a runtime memory access that is determined during execution of the function, and in response thereto assign a default error scope as the accessed scope of the runtime memory access, the default error scope being different from the scope of the function. The data is stored in variables, and variables are declared to have a specific scope (e.g., function). Accessing data at the memory address, rather than by referencing the variable, omits the relation between the data and the scope it was declared at. Hence, it is not possible to determine whether the memory access area is inside the scope or not before actually executing the function.

In accordance with an embodiment, the FaaS controller 104 is further configured to determine that the function is unsafe and in response thereto refrain from verifying the function as safe, and provide details on the determination that the function is unsafe to the entity. The function verifier 104B notes the safety of the function and produces a counterexample that can be provided to the user if the function is unsafe. For example, consider that the function verifier 104B founds that the scope of the function is not the same as the one or more accessed scopes of the functions. Hence, the function verifier 104B will determine the function to be unsafe and send an acknowledgement to the user device (i.e. the user operating the user device) describing the reason for considering the function as unsafe and requesting the user to modify the function accordingly. In accordance with an embodiment, the FaaS controller 104 is further configured to determine that the function is unsafe if the accessed scope of at least one of the at least one function called by the function is different from the scope of the function and in response thereto determine that the details on the determination that the function is unsafe includes the called function having a different scope. The function verifier 104B notes the safety of the function and produces a counter-example that can be provided to the user if the function is unsafe. For example, consider that the function verifier 104B founds that the scope of the function is not the same as the scopes of the functions called by the function. Hence, the function verifier 104B will determine the function to be unsafe and send an acknowledgement to the user device (i.e. the user operating the user device) describing the reason for considering the function as unsafe and requesting the user to modify the function accordingly.

In accordance with an embodiment, the FaaS controller 104 is further configured to determine that the function is unsafe if the accessed scope of at least one of the at least memory area accessed by the function is different from the scope of the function and in response thereto determine that the details on the determination that the function is unsafe includes the memory area access having a different scope. The function verifier 104B notes the safety of the function and produces a counter-example that can be provided to the user if the function is unsafe. For example, consider that the function verifier 104B founds that the scope of the function is not the same as the scopes of the memory area accessed by the functions. Hence, the function verifier 104B will determine the function to be unsafe and send an acknowledgement to the user device (i.e. the user operating the user device) describing the reason for considering the function as unsafe and requesting the user to modify the function accordingly.

In accordance with an embodiment, the FaaS controller 104 is further configured to determine that the function comprises a runtime memory access, and in response thereto determine that the function is unsafe and that the details on the determination that the function is unsafe includes the runtime memory access. The function verifier 104B notes the safety of the function and produces a counter-example that can be provided to the user if the function is unsafe. For example, consider that the function verifier 104B founds that the scope of the function is not the same as the accessed scope of the runtime memory access. Hence, the function verifier 104B will determine the function to be unsafe and send an acknowledgement to the user device (i.e. the user operating the user device) describing the reason for considering the function as unsafe and requesting the user to modify the function accordingly.

In accordance with an embodiment, the FaaS controller 104 is further configured to deploy the function to the one or more worker processes by storing the function; receiving a request for the function from an entity; and in response thereto cause the one or more worker processes to execute the function. When the function is determined to be safe, it is either stored in the FaaS storage 106 or scheduled in the FaaS workers 108. The FaaS request to execute or run the function is sent by the entity, such as the second entity 112, which triggers the one or more worker processes either proactively or on-demand. By virtue of the one or more worker processes, the FaaS worker is notified to load the function retrieved from the FaaS storage 106 into the process memory for execution.

In accordance with an embodiment, the FaaS controller 104 is further configured to deploy the function to the one or more worker processes by furthermore generating and initiating the one or more worker processes and generating each a runtime environment for the function to be executed in by the one or more worker processes. Each FaaS worker of the FaaS workers 108 may include one or more worker processes. The one or more worker processes are initiated by the FaaS controller 104 to execute the function. The FaaS controller 104 further generates the runtime environment for each of the one or more worker processes. Thus, all of the functions in a single FaaS worker can run in a single worker process.

In accordance with an embodiment, the FaaS controller 104 comprises a front end 104A, a function verifier 104B, and a function manager 104C. The front end 104A is configured to receive the computer instructions representing the function from the entity. The function verifier 104B is configured to determine the scope of the function and to verify the function as safe based on the scope. The function manager 104C is configured to deploy the function to one or more worker processes. The front end 104A is a user-facing part of the FaaS controller 104, which allows users to add new functions and manage the existing ones. The function verifier 104B is responsible for judging, according to pre-determined criteria, whether a given function is safe or not. The function manager 104C is the internal part of the FaaS controller 104, which is responsible for function lifecycle (such as persisting functions to the FaaS storage 106 or scheduling functions to the FaaS workers 108). In accordance with an embodiment, the FaaS system 102 comprises a first device and a second device. The first device is configured to execute at least one of the front end 104A, the function verifier 104B, and the function manager 104C. The second device is configured to execute at least one of the front end 104A, the function verifier 104B, and the function manager 104C. The FaaS controller 104 may be spread on different servers. For example, one server (e.g., the first device) may include at least one of the front end 104A, the function verifier 104B, and the function manager 104C; while the other server (e.g., the second device) may include at least one of the front end 104A, the function verifier 104B, and the function manager 104C. Hence, one component of the FaaS controller 104 (e.g., front end 104A) may be present in two servers at once. Thus, a single FaaS worker can execute functions from multiple tenants.

Thus, the FaaS controller 104 provides an efficient and reliable serverless computing platform to isolate functions of different scopes. The FaaS controller 104 ensures the safety of the function and accepts only those functions that are provably safe according to predetermined criteria. Further, the FaaS controller 104 eliminates the need for a sandbox for function execution, and thus, less software layers are used to execute the function. Moreover, since more functions can share the runtime, resources (e.g., CPU cycles for initialization) are efficiently utilized.

FIG. 2 is a flowchart for a method for use in a FaaS system, in accordance with an embodiment of the present disclosure. FIG. 2 is described in conjunction with elements of FIG. 1. With reference to FIG. 2, there is shown a method 200. The method 200 is for use in the FaaS system 102 described, for example, in FIG. 1. The method 200 includes steps 202 to 206.

In another aspect, the present disclosure provides a method 200 for use in a FaaS system 102. The method 200 comprises: receiving computer instructions representing a function from an entity; determining a scope of the function; verifying the function as safe based on the scope, and if the function is verified as safe, deploying the function to one or more worker processes.

At step 202, the method 200 comprises receiving computer instructions representing a function from an entity. The function refers to user-provided arbitrary small programs written in either compiler languages or interpreted languages. The computer instructions are sent via the entity, such as the first entity 110. The computer instructions are received via the front end 104A of the FaaS controller 104. The computer instructions correspond to instructions to submit a new function or manage the existing functions stored in the FaaS storage 106 of the FaaS system 102.

At step 204, the method 200 further comprises determining a scope of the function. The term scope refers to a specific group of entities that are allowed to share information among them. For example, a scope can be functions of the same project. The function verifier 104B determines the scope of the function submitted by the user. The function verifier 104B ensures that the functions of different scopes (e.g., tenant, project, etc.) are isolated so that one function is not privy to information available to other functions.

At step 206, the method 200 further comprises verifying the function as safe based on the scope, and if the function is verified as safe, deploying the function to one or more worker processes. The verification of the function submitted by the user is done via the function verifier 104B of the FaaS controller 104. The safety of the function is judged by the resources the function accesses during run time. The function is allowed to use infrastructure-provided application programming interfaces and functions. The function is also allowed to access other safe functions of the same scope and global data of the same scope. Further, the function is not allowed to call functions of different scope, access variables of different scope, or access arbitrary memory addresses. For instance, while a first function can be part of a first proj ect scope and a second function can be part of a second proj ect scope, the access of the first function to the second function is not necessarily unsafe because the access to scope is subject to cloud (e.g., the FaaS System 102) and the user-defined policy. For example, a cloud would always forbid cross organization access, but an organization may choose to allow or forbid access across projects. The user-defined policy governs the relations and the access between different types of entities. Hence, one user-defined policy may allow a function to access all other functions in the same project; alternatively, another user-defined policy may allow a function access to all functions in the organization. If the function is verified successfully and deemed safe, it is deployed to the FaaS workers 108 (either proactively or on-demand). Optionally, the function verifier 104B produces a counterexample that can be provided to the user if the function is unsafe. The steps 202 to 206 are only illustrative, and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

The method 200 uses the FaaS controller 104 to provide an efficient and reliable serverless computing process to isolate functions of different scopes. The method 200 ensures the safety of the function and accepts only those functions that are provably safe according to pre-determined criteria. Further, the method 200 eliminates the need for a sandbox for function execution, and thus, less software layers are used to execute the function. Moreover, since more functions can share the runtime, resources (e.g., CPU cycles for initialization) are efficiently utilized.

In yet another aspect, the present disclosure provides a computer-readable media comprising instructions that when loaded into and executed by a FaaS controller 104 enables the FaaS controller 104 to execute the method 200. The computer-readable media refers to a non- transitory computer-readable storage medium. Examples of implementation of the computer-readable media include, but is not limited to, Electrically Erasable Programmable Read-Only Memory (EEPROM), Random Access Memory (RAM), Read Only Memory (ROM), Hard Disk Drive (HDD), Flash memory, a Secure Digital (SD) card, Solid-State Drive (SSD), a computer-readable storage medium, and/or CPU cache memory.

FIG. 3 A is an exemplary illustration that depicts a conceptual architecture of FaaS workers under isolated runtime, in accordance with an embodiment of the present disclosure. FIG. 3A is described in conjunction with elements of FIG. 1 and FIG. 2. With reference to FIG. 3 A, there is shown an exemplary illustration 300A that depicts a conceptual architecture of the FaaS workers 108 under isolated runtime. There are further shown a user function 302 and a runtime overhead 304. The user function 302 (also represented by braces) denotes the overhead of having a single function loaded in the runtime. The runtime overhead 304 (also represented by cylic arrows) denotes the overhead of a single runtime. The isolated runtime corresponds to the runtime when each one of the FaaS workers 108 executes a single function separately as denoted by the an association of each user function 302 with each corresponding runtime overhead 304. According to the exemplary illustration 300A, the isolated runtime shows that each function entails runtime overhead. It is observed that the isolated runtime consumes more resources while serving less functions. FIG. 3B is an exemplary illustration that depicts a conceptual architecture of a FaaS worker under shared runtime, in accordance with an embodiment of the present disclosure. FIG. 3B is described in conjunction with elements of FIG. 1 and FIG. 2. With reference to FIG. 3B, there is shown an exemplary illustration 300B that depicts a conceptual architecture of a FaaS worker under shared runtime. There are further shown the user function 302 and the runtime overhead 304. In this case, the shared runtime corresponds to the runtime when a single FaaS worker executes all the functions deployed to it at once. According to the exemplary illustration 300B, the shared runtime shows that many functions require only one runtime denoted by just one runtime overhead 304 associated with multiple user functions, such as the user function 302. Thus, the shared runtime consumes significantly less resources while serving more functions as compared to the isolated runtime described in FIG. 3A.

FIG. 4A is a flowchart for a process that depicts various operations of submit flow executed by a FaaS controller of a FaaS system, in accordance with another embodiment of the present disclosure. FIG. 4A is described in conjunction with elements of FIG. 1, and FIG. 2. With reference to FIG. 4A, there is shown a process 400A. The process 400A depicts various operations of submit flow for compiled languages. The process 400A includes operations 402 to 410. The operations 402 to 410 are performed by the FaaS controller 104 of the FaaS system 102 (of FIG. 1). The process 400A may correspond to or maybe a part of the method 200 (of FIG. 2).

At operation 402, a user submits a function to the FaaS controller 104. In other words, a function is submitted from a user device, being operated by a user, to the FaaS controller 104. The user submits function written in a compiled language (e.g., C++, C, JAVA) to the front end 104A of the FaaS controller 104. The compiled languages are the programming languages whose implementations are typically compilers, i.e., the source codes are directly translated into machine codes after writing the complete source code.

At operation 404, the FaaS controller 104 compiles the function. The FaaS controller 104 compiles the language to an intermediate representation, e.g., low-level virtual machine intermediate representation (LLVM IR). LLVM refers to a compiling technology called the LLVM project, which is a collection of modular and reusable compiler and toolchain technologies. Optionally, the intermediate representation (IR) is submitted by the user rather than the function. At operation 406, the FaaS controller 104 analyzes the function. The FaaS controller 104 analyzes the function for desired properties using known methods, such as symbolic execution, bounded model checking, and abstract interpretation. Symbolic execution refers to a means of analyzing a program to determine what inputs cause each part of a program to execute. Bounded model checking refers to a method for checking whether a finite-state model of a system meets a given specification (also known as correctness). Abstract interpretation refers to a theory of sound approximation of the semantics of computer programs based on monotonic functions over ordered sets, especially lattices.

If the result of operation 404 and operation 406 is a success, then the control moves directly to operation 410; otherwise, the control moves to operation 408.

At operation 408, the user corrects the function. After the FaaS controller 104 compiles and analyzes the function and determines that the function is not safe, then it sends an acknowledgement to the user device (i.e. the user operating the user device) stating the reason for determining the function as unsafe and requesting corrections accordingly. The user then corrects the errors and submits the function again to the FaaS controller 104.

At operation 410, the function is stored in the FaaS storage 106. If verification passes, the compiled function is submitted into the FaaS storage 106. The FaaS worker is assumed to perform a just-in-time (JIT) compilation of the function from the IR. Alternatively, the function is compiled ahead of time to all needed variations of the function for direct execution by the FaaS workers 108 (e.g., different operating systems, CPU architectures/features).

The operations 402 to 410 are only illustrative, and other alternatives can also be provided where one or more operations are added, one or more operations are removed, or one or more operations are provided in a different sequence without departing from the scope of the claims herein.

FIG. 4B is a flowchart for a process that depicts various operations of load flow executed by a FaaS controller of a FaaS system, in accordance with another embodiment of the present disclosure. FIG. 4B is described in conjunction with elements of FIG. 1 and FIG. 2. With reference to FIG. 4B, there is shown a process 400B. The process 400B depicts various operations of load flow for compiled languages. The process 400B includes operations 412 to 416. The operations 412 to 416 are performed by the FaaS controller 104 of the FaaS system 102 (of FIG. 1). The process 400B may correspond to or maybe a part of the method 200 (of FIG. 2).

At operation 412, the FaaS workers 108 are notified to load a function. The FaaS workers 108 are notified by the FaaS request that a specific function needs to be loaded either as a result of an external trigger for a specific function or proactively by a cloud policy.

At operation 414, the FaaS workers 108 retrieve function from the FaaS storage 106. The FaaS storage 106 stores all the functions of the FaaS system 102. When the FaaS request is received, the specific function requested is loaded from the FaaS storage 106 by the FaaS workers 108.

At operation 416, the FaaS workers 108 loads loaded function into the memory. The FaaS workers 108 load the function from artifacts into process memory and thus executes or run the function.

Thus, the FaaS workers 108 are implemented in a classic reactor pattern: the incoming requests are picked up by the FaaS workers 108; a function relevant to the request is looked up (and loaded if not present), and the function call servicing the request is dispatched to one of the threads.

The operations 412 to 416 are only illustrative, and other alternatives can also be provided where one or more operations are added, one or more operations are removed, or one or more operations are provided in a different sequence without departing from the scope of the claims herein.

FIG. 5 A is a flowchart for a process that depicts various operations of submit flow executed by a FaaS controller of a FaaS system, in accordance with yet another embodiment of the present disclosure. FIG. 5 A is described in conjunction with elements of FIG. 1 and FIG. 2. With reference to FIG. 5 A, there is shown a process 500A that depicts various operations 502 to 508 of submit flow for interpreted languages. The operations 502 to 508 are performed by the FaaS controller 104 of the FaaS system 102 (of FIG. 1). The process 500A may correspond to or maybe a part of the method 200 (of FIG. 2).

At operation 502, a user submits a function to the FaaS controller 104. The user submits a function written in an interpreted language (e.g., Python, Perl, JavaScript, Ruby) via a user device to the front end 104A of the FaaS controller 104. The interpreted languages are the programming languages whose implementations are typically interpreters, i.e., the source codes are translated into machine codes line-by-line.

At operation 504, the FaaS controller 104 analyzes the function. The FaaS controller 104 analyzes the function for desired properties using known methods, such as symbolic execution, bounded model checking, and abstract interpretation. Symbolic execution refers to a means of analyzing a program to determine what inputs cause each part of a program to execute. Bounded model checking refers to a method for checking whether a finite-state model of a system meets a given specification (also known as correctness). Abstract interpretation refers to a theory of sound approximation of the semantics of computer programs based on monotonic functions over ordered sets, especially lattices.

If the result of operation 504 is a success, then the control moves directly to operation 508; otherwise, the control moves to operation 506.

At operation 506, the user corrects the function. After the FaaS controller 104 analyzes the function and determines that the function is not safe, then it sends an acknowledgement to the user device (i.e. the user operating the user device) stating the reason for determining the function as unsafe and requesting corrections accordingly. The user then corrects the errors and submits the function again to the FaaS controller 104.

At operation 508, the function is stored in the FaaS storage 106. If verification passes, the compiled function is submitted into the FaaS storage 106. The FaaS storage 106 contains all the functions stored in the FaaS system 102.

The operations 502 to 508 are only illustrative, and other alternatives can also be provided where one or more operations are added, one or more operations are removed, or one or more operations are provided in a different sequence without departing from the scope of the claims herein.

FIG. 5B is a flowchart for a process that depicts various operations of load flow executed by a FaaS controller of a FaaS system, in accordance with yet another embodiment of the present disclosure. FIG. 5B is described in conjunction with elements of FIG. 1 and FIG. 2. With reference to FIG. 5B, there is shown a process 500B that depicts various operations of load flow for interpreted languages. The process 500B includes operations 510 to 514 performed by the FaaS controller 104 of the FaaS system 102 (of FIG. 1). The process 500B may correspond to or may be a part the method 200 (of FIG. 2).

At operation 510, the FaaS workers 108 are notified to load a function. The FaaS workers 108 are notified by the FaaS request that a specific function needs to be loaded either as a result of an external trigger for a specific function or proactively by cloud policy.

At operation 512, the FaaS workers 108 retrieve function from the FaaS storage 106. The FaaS storage 106 stores all the functions of the FaaS system 102. When the FaaS request is received, the specific function requested is loaded from the FaaS storage 106 by the FaaS workers 108.

At operation 514, the FaaS workers 108 loads loaded function into the memory. The FaaS workers 108 load the function from artifacts into process memory and thus executes or run the function.

Thus, the FaaS workers 108 are implemented in a classic reactor pattern: the incoming requests are picked up by the FaaS workers 108; a function relevant to the request is looked up (and loaded if not present), and the function call servicing the request is dispatched to one of the threads.

The operations 510 to 514 are only illustrative, and other alternatives can also be provided where one or more operations are added, one or more operations are removed, or one or more operations are provided in a different sequence without departing from the scope of the claims herein.

The FaaS controller 104 and the method 200 of the present disclodure has many practical applications, such as may be useful in video streaming platforms, file hosting services, secure storage of personal data, chatbots, and backup solutions for systems, sites, and software. In one practical application, the FaaS controller 104 may be used in on-demand functionality and beneficially, enables the powering down feature of any infrastructure leading to cut down cost and optimization of resources in a secured manner. In another practical application, the FaaS controller 104 may be used for simplified developer logistics, which leads to faster development, faster updates, and response to users.

Modifications to embodiments of the present disclosure described in the foregoing are possible without departing from the scope of the present disclosure as defined by the accompanying claims. Expressions such as “including”, “comprising”, “incorporating”, “have”, “is” used to describe and claim the present disclosure are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural. The word “exemplary” is used herein to mean “serving as an example, instance or illustration”. Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and/or to exclude the incorporation of features from other embodiments. The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. It is appreciated that certain features of the present disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the present disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable combination or as suitable in any other described embodiment of the disclosure.