Patent Description:
The Function as a Service (FaaS) paradigm of cloud service offerings allows consumers (developers) to build and deploy applications without the need to manage the complexity of provisioning and maintaining the infrastructure, platform or software ecosystem. This model of developing and deploying services lends itself to a "Serverless" architecture. Developers may define individual functions that make up a service, and may deploy the individual functions on the cloud platform, which are then invoked when the service functionality is needed. Functions in a FaaS platform may be started within milliseconds to handle the task they are defined to perform. Consumers may only pay the cloud provider when the functions that they have deployed are invoked. The FaaS paradigm lends itself well to the microservices software development architecture.

The developer may decompose the functionalities of an application or microservice into a set of modular functions which may then be uploaded to the FaaS platform. Each of the uploaded functions may be capable of being invoked and executed independently. The functions may also be scaled independently. <FIG> illustrates an example of how a monolithic application may be broken down into a set of microservices that may be decomposed into a set of modular functions.

Functions may be invoked as a result of trigger predefined by the developer, or functions may be invoked manually. A set of functions may be chained together to achieve complex tasks in the service or microservice.

Some of the advantages of a FaaS platform include and not limited to, reduced developer logistics, higher development and deployment pace, scalability, fault tolerance and paying for only active time of the function and not when idle.

Disadvantages include harder tracking of numerous functions, harder debugging and minimal debug tooling and decreased transparence into the infrastructure. Most of the current leaders in cloud platform providers today provide FaaS capabilities, for example, AWS Lambda, Google cloud functions, and Azure Functions. Current FaaS frameworks also suffer from vendor lock-in.

<CIT> describes systems, methods, and computer-readable media for managing a distributed network of function execution environments.

<CIT> describes a service platform for routing intent-based API requests to the most relevant APIs.

According to some embodiments there is provided a method performed by a processing circuitry in a function as a service, FaaS, platform for enabling use of functions in a function as a service platform by third party developers. The method comprises storing in a function catalogue one or more function descriptions associated with one or more respective functions available for use by third party developers, wherein each function description comprises an intent and a function name of the respective function. The method also comprises receiving a function call from a first function developer comprising an indication of a first intent, preprocessing function source code of the function to search for a keyword indicating that the function is intending to call a third party function using intent invocation and selecting a first function description from the function catalog that matches the first intent. The storing further comprises receiving function source code of a second function from a second function developer, searching for a keyword in the function source code of the second function indicating that the second function is to be made available to other function developers and storing the associated function description in the function catalogue in response to the function source code of the second function comprising the keyword.

According to some embodiments there is provided a function as a service, FaaS, platform for enabling use of functions by third party developers. The FaaS platform comprises processing circuitry configured to store in a function catalogue one or more function descriptions associated with one or more respective functions available for use by third party developers, wherein each function description comprises an intent and a function name of the respective function and is also configured to receive a function call from a first function developer comprising an indication of a first intent, preprocess function source code of the function to search for a keyword indicating that the function is intending to call a third party function using intent invocation and select a first function description from the function catalog that matches the first intent. processing circuitry further configured to receive function source code of a second function from a second function developer; and search for a keyword in the function source code of the second function indicating that the second function is to be made available to other function developers.

For a better understanding of the embodiments of the present disclosure, and to show how it may be put into effect, reference will now be made, by way of example only, to the accompanying drawings, in which:.

Most current Function as a Service (FaaS) platforms provide functionality for developers to define their own functions which can then be deployed to offer a service or an application. Except for some standard functions all the functions that form a service need to be written/developed by the developer themselves. To realize a fairly complex service using FaaS would require developing, testing and validating a large number of functions which may require a considerable effort.

As of today, there is no intuitive and simple way in which developers can build a service using a mix of functions that are defined by themselves and functions that are developed by other third party developers. There are no systems for discovering and calling functions defined by other parties as part of the service deployed by the developer. This in a way limits the potential and pace of development in a FaaS environment.

The current FaaS platforms do not provide a transparent way for a developer to expose the functions that they have developed to other developers on the FaaS platform. There is also no transparent and dynamic way for developers to discover and invoke functions exposed by other developers to build their service.

Embodiments described herein therefore provide methods and apparatus for enabling use of functions in a function as a service platform by third party developers.

In particular, the methods and apparatuses described herein enable developers to expose their functions transparently for other developers to use in a FaaS platform. Furthermore the methods and apparatuses described herein enable the FaaS platform to catalog functions that are exposed based on the functionality that they provide. The cataloguing of the functions may be performed in a searchable manner. Embodiments described herein also enable developers to dynamically search and invoke functions exposed by other developers using intent based function invocation.

<FIG> illustrates an example of a FaaS platform according to some embodiments of the invention.

It will be appreciated that the functional blocks illustrated may be implemented by software code. In some circumstances a single piece of software may implement one or more of the functional blocks.

The FaaS Platform <NUM> supports the Function as a Service deployment paradigm. In particular the FaaS platform acts as a service deployment interface offered by the cloud platform provider to the consumers of to build services using FaaS.

The FaaS Platform <NUM> comprises a function development and execution environment <NUM>. The function development and execution environment <NUM> comprises a functional block capable of allowing developers to define and/or develop functions, specify triggers for function invocation (also chain functions together to achieve a service functionality), and where the functions may be executed inside the FaaS platform <NUM>. The function development and execution environment may also comprise a runtime environment needed to execute the functions.

In this example, the function development and execution environment <NUM> comprises functions 202a to <NUM>. The functions 202a to <NUM> may comprise individual pieces of code (or software) that a developer may write and deploy on the FaaS platform <NUM>. These functions <NUM> may be executed when a pre-set condition is triggered or when invoked explicitly.

Depending on the cloud platform provider, a FaaS platform may allow developers to define functions in multiple languages.

In this example, the function development and execution environment <NUM> further comprises a function invoker <NUM>. The Function Invoker <NUM> may comprise a functional block which may be responsible for invoking a function and executing it on the runtime environment required by the function. This function block may be instructed to invoke a function based on a predefined trigger or explicitly requested to invoke a function.

In this example, the function development and execution environment <NUM> further comprises a function compiler <NUM>. The function compiler <NUM> comprises a functional block which may be used to compile a function defined by the developer. The function compiler <NUM> may also link a function with other libraries into an executable form in which to be invoked by the function invoker <NUM>. The function compiler <NUM> may only be required when a function is defined in a language that needs to be compiled to be executed.

In this example, the function development and execution environment <NUM> further comprises a function preprocessor <NUM>. The function preprocessor comprises a functional block which may be configured to preprocess a function defined by the developer to look for intent based function invocation directives. The intent based function invocation directives may be in the form of a keyword that the developer uses to indicate an intent based function invocation. The directive may take different forms based on the programming language that the function is being written in, and may be designed to feel intuitive to the developer.

Once the function preprocessor <NUM> detects an intent based function invocation directive, the function preprocessor may call an Intent resolver <NUM> to perform further processing. The function preprocessor <NUM> may be configured to preprocesses a function after the developer has written the function, or may be configured to preprocess a function periodically while the developer is writing the function in real-time to process and analyze an intent based function invocation.

In this example, the FaaS platform <NUM> further comprises an intent resolver <NUM>. The intent resolver comprises a functional block that may be configured to resolve an intent indicated in a function call.

For example, the intent resolver <NUM> may determine a hierarchical search query that may be used to lookup available third-party functions that match the specified intent with in a function catalog.

In this example, the FaaS platform <NUM> further comprises an intent parser <NUM>. The intent parser <NUM> comprises a functional block configured to prepare the intent classification of a function. For example, when developers want to make a function available for other developers, they may one or more intents which, along with the function signature (Parameters and return types), may be used by the intent parser to prepare an intent classification. <FIG> presents a flow chart for the functionality of the module.

In this example, the FaaS platform <NUM> further comprises a function catalog <NUM>. The function catalog <NUM> comprises a functional block which may be configured as a database of all functions that are made available by developers for invocation by other developers. The function catalog <NUM> may be configured to store the functions in a hierarchical fashion based on the intent classification made by the intent parser <NUM>. Additional metadata information about the function may also be stored by the function catalog <NUM> that may be used while searching for a function based on an intent indicated in a function call from a third-party developer.

In this example, the FaaS platform <NUM> further comprises a dynamic function mapper. The dynamic function mapper <NUM> comprises a functional block which may be configured to dynamically invoke a function from the function catalog <NUM> based on an intent specified by a calling function. The dynamic function mapper <NUM> may select from one or more candidate functions in the function catalog <NUM> that match the intent and fulfill the constraints specified by the calling function.

In this example, the FaaS platform <NUM> further comprises a function publisher <NUM>. The function publisher <NUM> comprises a functional block which may be configured to add a function to the function catalog <NUM>. The function publisher <NUM> may use an intent classification prepared by the intent parser <NUM> to publish a function in the function catalog <NUM> along with, for example, information pertaining to the pricing, access level and other metadata information (such as version, geo-availability etc.) related to the function.

<FIG> illustrates a method for enabling use of functions in a function as a service platform by third party developers according to some embodiments. The method illustrated in <FIG> may be performed by the FaaS platform illustrated in <FIG>.

In step <NUM>, the method comprises storing in a function catalog one or more function descriptions associated with one or more respective functions available for use by third party developers, wherein each function description comprises an intent and a function name of the respective function. For example, the function catalog may be the function catalog <NUM> illustrated in <FIG>.

A function description may comprise enough information to allow the FaaS platform <NUM> to call the function associated with the function description. For example, the function name in the function description may comprise an remote procedure call (RPC) stub.

An intent of a function may comprise an indication of what the function does. As an example, a first function may be envisaged that is configured to receive a list as an input, and to output a sorted version of the list as an output. The first function may, for example, be configured to use a quick sort method to sort the list.

The intent of the first function may therefore be condensed into a first level intent of "sort" and a second (more granular) level intent of "quick sort". In other words, in this example, the first function's intent is to sort, and more specifically to perform a quick sort.

In step <NUM>, the method comprises receiving a function call from a first function developer comprising an indication of a first intent.

In step <NUM>, the method comprises selecting a first function description from the function catalog that matches the first intent.

For example, step <NUM> may comprise finding one or more candidate function descriptions from the function catalog that match the first intent. A candidate function description may match the first intent if the intent in the candidate function description would provide the first intent when implemented. In other words, the first intent may be to "sort", and the input parameter may be a list. A stored function description which has an intent comprising two levels (e.g. "sort" and "quick sort" as described above), may be considered to match the first intent as the intent of "sort" is provided when the stored function is implemented.

In step <NUM>, the method comprises selecting the first function description from the one or more candidate function descriptions.

For example, in some cases there may be more than one stored function that has an intent that matches the first intent. For example, a first stored function which has the intent "sort" and "quick sort" and a second stored function which has then intent "sort" and "heapsort" may both be considered to match a first intent of "sort".

In cases where more than one candidate function description is found in step <NUM> therefore, the first function description may be selected from the one or more candidate function descriptions. The may be performed by the dynamic function mapper <NUM>, for example, as described with reference to <FIG> below.

In some examples, the step <NUM> may comprise receiving function source code of a second function from a second function developer, wherein the function source code comprises a second intent of the second function and a function name. The method may then further comprise extracting the second intent from the function source code; and storing a second function description comprising the second intent and the function name in the function catalog. In particular, the intent parser <NUM> illustrated in <FIG> may be configured to extract the second intent from the function source code, for example, as illustrated with reference to <FIG> below.

The function publisher <NUM> maybe be configured to store the second function description in the function catalog, for example, as illustrated with reference to <FIG> below.

<FIG> relate to the publication of a new function for discovery by third party developers using intent based calling.

<FIG> illustrates a method of extracting the second intent from the function source code. The method may be performed by the intent parser <NUM> illustrated in <FIG>.

In step <NUM>, the intent parser <NUM> receives the function source code of a second function.

In step <NUM>, the intent parser <NUM> comprises parses the function source code.

An example function source code may comprise the following structure in a line of the source code:
<IMG>.

The intent parser performs step <NUM>. In step <NUM>, the intent parser searches for a keyword in the function source code indicating that the second function is to be made available to other function developers. In the example above, the keyword <KEY_WORD> may indicate that the second function is to be made available to other function developers.

In some examples, the following steps <NUM> and <NUM> may be performed in response to finding the keyword in the function source code.

In step <NUM>, the method comprises extracting the elements of the second intent from the function source code. In the example illustrated above, the second intent may comprise the parts:
<INTENT_LEVEL1_0>. <INTENT_LEVEL_1>. <INTENT_LEVEL_N> of the source code.

As previously described, an intent may be expressed according to one or more intent levels of increasingly fine granularity. In the example above, a first intent level <INTENT_LEVEL1_0> may indicate an intent of coarser granularity than a second intent level <INTENT_LEVEL_1>. The intent levels may then become increasingly fine in granularity until <INTENT_LEVEL_N>. For example <INTENT_LEVELl_0> may be "sort", <INTENT_LEVEL_1> may then be for example, "quick sort" "heapsort" or bubblesort" and so on.

The <THIRD_PARTY_ID> may indicate the identity of the developer providing the second function.

The <FunctionName> may indicate the name of the second function. The <FunctionName> may then be used to store the second function description for the second function, and later call the second function.

Step <NUM> may also comprise extracting an indication of one or more input parameter types for the second function and one or more output parameter types of the second function and any other metadata association with the second function.

In step <NUM>, the method comprises forwarding to the function publisher the second intent extracted in step <NUM>. Step <NUM> may also comprise forwarding the one or more input parameter types for the second function and one or more output parameter types of the second function and any other metadata.

<FIG> illustrates a method for storing a second function description in a function catalog. The method of <FIG> may be performed by the function publisher <NUM> illustrated in <FIG>.

In step <NUM>, the function publisher <NUM> receives the second intent from the intent parser. In step <NUM>, the function publisher may also receive the one or more input parameter types for the second function and the one or more output parameter types for the second function, and/or any other metadata associated with the second function.

In steps <NUM> and <NUM>, the function publisher <NUM> determines whether the function catalogue already comprises a third function description comprising the second intent.

For example, in step <NUM>, the function publisher prepares a hierarchical search query based on the second intent, and searches the function catalog for a catalog entry having the same intent.

In the example illustrated above therefore, the function publisher would search for a catalog entry having an intent matching the second intent:
<IMG>.

In step <NUM>, the function publisher <NUM> then determines if the search has been successful.

The function catalog may comprise a repository that stores the functions that can be called using an intent based function call.

<FIG> illustrates an example of a function catalog maintaining an intent hierarchy map.

In this example, the function catalog maintains an intent hierarchy map. Each catalog entry 601a to 601r, is stored associated with a branch of a hierarchy tree which is broken down by intent level.

For example, a branch of the hierarchy tree may be associated with intent level <NUM> = A. (where A is some intent function, for example "sort"). In some cases, the intent specified by a function source code may only comprise one level, and in those cases, the catalog entry for the function would be stored associated with this branch of the hierarchy tree. However, in this further intent levels are associated with the intent level <NUM> =A branch. For example, intent level <NUM> = B is also present, and intent level <NUM> = C etc..

In this example therefore, the catalog entries 601a t 601d comprise function descriptions which are associated with the intent level <NUM> = "A", the intent level <NUM> = "B", the intent level <NUM> = "C", and the intent level <NUM> = "D".

In a similar fashion, the catalog entries 601e to <NUM> are associated with intent level <NUM> = "E", intent level <NUM> = "F", intent level <NUM> = "G" and intent level <NUM> = "H". Where the levels "E" to "H" define the function intent with increasingly fine granularity.

The catalog entries 601i and 601j are associated with intent level <NUM> = "E", intent level <NUM> =""F", and intent level <NUM> = "G". The intents that were defined by these functions were therefore less granular than the catalog entries 601e to <NUM>.

The remaining catalog entries <NUM> to 601r are similarly associated with intent levels in the hierarchy tree.

Storing the catalog entries in this way may save memory in the function catalog as the information relating to the intent of a function does not have to be repeated for each catalog entry.

Along with the function database, the function catalog also stores the RPC stubs for the functions in different languages, which may be required for calling a function from another function defined in a different language but using intent based call.

The function catalog may also store metadata associated with each of the function that may be used to decide while dynamically mapping an intent based call to a function. The Metadata information can include information related to pricing, geo-availability, runtime statistics and any other relevant information.

Returning to <FIG> responsive to determining that the function catalog comprises a third function description comprising the second intent (for example, responsive to determining that the search is successful in step <NUM>), the method passes to step <NUM> in which the function publisher <NUM> stores the second function description alongside the third function description associated with the second intent.

For example, referring to <FIG>, if the second intent was equal to intent level <NUM> = "E", intent level <NUM> = "F" and intent level <NUM> = "G", then the second function description would be stored alongside the catalog entries 601i and 601j.

Alternatively, responsive to determining that the function catalogue does not comprise a third function description comprising the second intent, the method passes to step <NUM> in which the function publisher <NUM> stores the second function description associated with the second intent. For example, if the second intent is intent level <NUM> = "E" and intent level <NUM> = "F" but not specifically that intent level <NUM> = "G", then the second function description may be stored associated with the intent level <NUM> = "F".

In some examples, the second intent may comprise an intent level that is not yet stored in the function catalog. In these examples a new branch of the function catalog tree may be created.

For example, the second intent may be equal to intent level <NUM> = "E", intent level <NUM> = "F" and intent level <NUM>= "O". In this example, a new branch may be created off intent level <NUM> = "F", in which intent level <NUM> = "O".

In step <NUM>, the function publisher may add any metadata associated with the second function to the second function description before it is then stored in the function catalog.

In step <NUM>, the function publisher <NUM> may create one or more RPC stubs for the second function in different languages and may store the RPC stubs in the second function description.

In step <NUM>, the function publisher inserts the second function description into the function catalog appropriately.

<FIG> relate to the intent based calling of a published function.

<FIG> illustrates a method of preprocessing function source code defined by a first function developer. The method of <FIG> may be performed by the function preprocessor <NUM> illustrated in <FIG>.

The method illustrated in <FIG> may be performed after a developer has written a function, or it may be run periodically while the developer is writing the function in real-time to process and analyse whether an intent based function invocation is being written into the function.

In particular, step <NUM> of <FIG> may comprise the features of step <NUM> below.

In step <NUM>, the function preprocessor <NUM> parses the source code of the function written or being written by the first function developer. The source code of the function may comprise the function call from the first function developer comprising the indication of the first intent. The function call in the source code of the function may therefore be calling a third part for use within the function that the first function developer has written or is writing.

In step <NUM>, the function preprocessor <NUM> searches for a keyword in the source code of the function. The keyword indicates that the function is intending to call a third party function using intent invocation. The keyword may take different forms depending on the language being used by the first function developer to write the function. In particular, the keyword may be designed to be intuitive to the first function developer.

In step <NUM>, the function preprocessor <NUM> may extract elements of the intent from the function call.

The function call may be structures as follows:
<IMG>.

Here the <KEY_WORD> indicates that the function is intending to call a third part function using intent invocation. The <THIRD_PARTY_ID> is an optional parameter that indicates the identity of the third party developer whose function the call is intending to invocate. The parameters <LEVEL_0_INTENT>, <LEVEL_1_INTENT> and <LEVEL_N_INTENT> indicate the first intent of a function that the developer wants to call. The first intent comprises intent levels, as described above.

The type of input parameters of the function that the first function developer wants to call are listed as ([Param1 , Param2 ,. , ParamN]; and the expected output parameter types of the function that the first function developer wants to call as listed as [ReturnParam1, ReturnParam2,. , ReturnParamN].

The function call may also comprise one or more additional constraints indicated by the first function developer relating to the function to be called. For example, the additional constraint may relate to, for example, the cost of utilizing the called function, the location of the called function, the speed of operation of the called function, or any other metadata that may be associated with the called function.

An example of an intent based call that follows the format described above would be:
<IMG>.

The intent here is to find a sort algorithm from any vendor and any sort method (quick, heap, bubble), with the constrain that it has to run in SE and it should be cheap to invoke.

Another example of an intent based function call is provided below:
<IMG>.

Here the developer is trying to invoke a hash function that uses the sha-<NUM> standard with <NUM> bit digest; the developer also passes the message to be hashed and length of the message as input parameters and expects a Digest as a return value. The developer has also specified that the function selected to be invoked should be the fasted available implementation; also in the above example the developer has used a wildcard '*' for the <THIRD_PARTY_ID> to specify that the FaaS platform can choose a function from any available third party developers.

In step <NUM>, the function preprocessor invokes the intent resolver <NUM> to retrieve candidate third party functions that match the first intent. For example, the function preprocessor may transmit the first intent to the intent resolver. The function preprocessor may also transmit the other parameters indicated in the function call.

In step <NUM>, responsive to the intent resolver <NUM> finding one or more candidate functions, the function preprocessor may indicate to the first function developer that potential third party functions are available to implement the function call in the source code of the function that the first function developer has written or is writing.

<FIG> illustrates a method of finding one or more candidate function descriptions from the function catalogue that match the first intent. The method illustrated in <FIG> may be performed by the intent resolver <NUM> illustrated in <FIG>.

In step <NUM>, the intent resolver <NUM> prepares a search query based on the first intent. For example, where the function catalog comprise a hierarchy map as illustrated in <FIG>, the search query may comprise a hierarchy search query based on an order of granularity of intent levels in the first intent.

In step <NUM>, the intent resolver <NUM> searches the function catalog for <NUM> for candidate function descriptions that match the first intent. For the example in which a hierarchy map is used as the function catalog, the intent resolver may locate the first intent in the hierarchy map, and any catalog entries stored associated with the first intent may be selected as candidate functions that match the first intent.

For example, say the first intent specified intent level <NUM> = "E" intent level <NUM> = "F", intent level <NUM> = "G". In this example, from the hierarchy map illustrated in <FIG>, the intent resolver may determine that the catalog entries 601i and 601j match the first intent. The intent resolver may also determine that the catalog entries 601e to <NUM> also match the first intent as they also provide the same first three intent levels.

In some examples, the intent resolver may only search for function descriptions that were provided by a third party developer that is indicated in the function call.

In step <NUM>, the intent resolver <NUM> may optionally test the one or more candidate function descriptions to check for expected functionality of the one or more candidate function descriptions. For example, the intent resolver may input the input parameters indicated in the function call into the one or more candidate functions, and may check that the outputs returned by the one or more candidate functions of an expected type of output.

In step <NUM>, the intent resolver <NUM> may filter the one or more candidate functions that we found in step <NUM>. For example, the intent resolver may filter the candidate functions based on one or more additional constraints indicated in the function call. For example, if the function call included an additional constraint that the function be as cheap as possible, the intent resolver may only select the cheapest candidate functions.

In step <NUM> the intent resolver <NUM> transmits the remaining list of candidate functions to the dynamic function mapper <NUM>. In some examples, the intent resolver <NUM> may also transmit any metadata associated with the candidate functions that was stored in the function catalog.

<FIG> illustrates method of calling the first function. The method illustrated in <FIG> may be performed by the dynamic function mapper <NUM> illustrated in <FIG>.

In step <NUM>, the dynamic function mapper <NUM> receives the list of candidate functions from the intent resolver <NUM>.

In step <NUM>, the dynamic function mapper selects the first function description from the one or more candidate functions. In some examples, the selection of the first function description from the one or more candidate function descriptions may be based on the additional constraints included in the function call.

In step <NUM> the dynamic function mapper may ensure that the first function can be invoked. If the first function cannot be invoked, the dynamic function mapper may either undergo procedures to ensure that the first function can be invoked, or may select a different function from one or more the candidate functions.

In step <NUM>, the dynamic function mapper <NUM> calls the first function using a first function name in the first function description and one or more input parameters indicated in the function call. For example, the dynamic function mapper may marshall the input parameters from the function call onto an RPC call to the first function.

In step <NUM>, the dynamic function mapper <NUM> waits for the invocation of the first function and receives the one or more outputs of the first function from the first function.

In step <NUM>, the dynamic function mapper <NUM> unmarshalls the one or more outputs of the first function.

In step <NUM>, the dynamic function mapper <NUM> transmits the one or more outputs to the first function developer. For example, the dynamic function mapper may populate the one or more outputs into the return variables of the function call.

<FIG> illustrates a Function as a Service (FaaS) Platform <NUM> comprising processing circuitry (or logic) <NUM>. It will be appreciated that the FaaS platform <NUM> may comprise one or more virtual machines running different software and/or processes. The FaaS platform <NUM> may therefore comprise one or more servers, switches and/or storage devices and/or may comprise cloud computing infrastructure that runs the software and/or processes.

The FaaS platform <NUM> may comprise the FaaS platform <NUM> as described above. The processing circuitry <NUM> controls the operation of the FaaS platform <NUM> and can implement the method described herein in relation to an FaaS platform <NUM>. The processing circuitry <NUM> can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the FaaS platform <NUM> in the manner described herein. In particular implementations, the processing circuitry <NUM> can comprise a plurality of software and/or hardware modules that are each configured to perform, or are for performing, individual or multiple steps of the method described herein in relation to the FaaS platform <NUM> or FaaS platform <NUM>.

Briefly, the processing circuitry <NUM> of the FaaS platform <NUM> is configured to: store in a function catalogue one or more function descriptions associated with one or more respective functions available for use by third party developers, wherein each function description comprises an intent and a function name of the respective function; receive a function call from a first function developer comprising an indication of a first intent; and select a first function description from the function catalog that matches the first intent.

In some embodiments, the FaaS platform <NUM> may optionally comprise a communications interface <NUM>. The communications interface <NUM> of the FaaS platform <NUM> can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface <NUM> of the FaaS platform <NUM> can be configured to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar. The processing circuitry <NUM> of FaaS platform <NUM> may be configured to control the communications interface <NUM> of the FaaS platform <NUM> to transmit to and/or receive from other nodes or network functions requests, resources, information, data, signals, or similar.

Optionally, the FaaS platform <NUM> may comprise a memory <NUM>. In some embodiments, the memory <NUM> of the FaaS platform <NUM> can be configured to store program code that can be executed by the processing circuitry <NUM> of the FaaS platform <NUM> to perform the method described herein in relation to the FaaS platform <NUM> or the FaaS platform <NUM>. Alternatively or in addition, the memory <NUM> of the FaaS platform <NUM>, can be configured to store any requests, resources, information, data, signals, or similar that are described herein. The processing circuitry <NUM> of the FaaS platform <NUM> may be configured to control the memory <NUM> of the FaaS platform <NUM> to store any requests, resources, information, data, signals, or similar that are described herein.

Claim 1:
A method performed by a processing circuitry in a function as a service, FaaS, platform for enabling use of functions in a function as a service platform by third party developers, the method comprising:
storing (<NUM>) in a function catalogue one or more function descriptions associated with one or more respective functions available for use by third party developers, wherein each function description comprises an intent and a function name of the respective function;
receiving (<NUM>) a function call from a first function developer comprising an indication of a first intent;
preprocessing (<NUM>) function source code of the function to search (<NUM>) for a keyword indicating that the function is intending to call a third party function using intent invocation; and
selecting (<NUM>, <NUM>) a first function description from the function catalogue that matches the indicated first intent;
wherein the storing comprises
receiving (<NUM>) function source code of a second function from a second function developer;
searching (<NUM>) for a keyword in the function source code of the second function indicating that the second function is to be made available to other function developers; and
storing the associated function description in the function catalogue in response to the function source code of the second function comprising the keyword.