## 3 Cloud-Agnostic Models
### FaaS Portability  
The usage of provider-specific function signatures, as well as libraries, can be considered as the two main causes for portability issues that limit a serverless function to only work on a single cloud provider. To counter these problems, we propose a model for the development of cloud-agnostic functions, that is, functions that can be reused in multiple cloud providers with no need to change a single line of code.  
Serverless functions have access to a wide variety of libraries offered by cloud providers. Cloud-agnostic libraries should provide uniform access to operations that are commonly found in most provider-specific libraries for a particular resource or event trigger, meaning that operations that are unique to a specific provider will probably be left out for the sake of providing a full cloud-agnostic usage. Additionally, if for some reason a certain cloud-agnostic operation cannot be implemented for a particular provider, the documentation should warn developers specifying that the operation is incompatible with that cloud provider.  
The entities and respective attributes that model a cloud-agnostic function definition are represented in Figure 4.  
Figure 3: FaaS deployment ERM.  
The _FUNCTION_ entity is the exact same entity as the one illustrated in Figure 3, and should not be confused with the _HOOKFUNC_ entity, which is the cloud-agnostic function defined by the developer (_definition_ attribute from _HOOKFUNC_ entity). Starting a new function instance involves loading the runtime environment (_RUNTIME_ entity), capable of running code from a certain programming language (_LANGUAGE_ entity). The developer has the option to specify a list of external dependencies (_dependencies_ attribute from _HOOKFUNC_ entity) to be downloaded from a remote repository if needed. These should follow the appropriate syntax when specified, that can vary depending on the chosen runtime (_dependsSyntax_ attribute from _RUNTIME_ entity). For instance, Maven dependencies for Java projects are specified in the POM file using XML, while Node.js dependencies are specified in the _package.json_ file using JSON.  
For every programming language, a cloud-agnostic function signature needs to be established (_signature_ attribute from _LANGUAGE_ entity). Defined below, in Listings 3 and 4, are two examples of cloud-agnostic function signature skeletons used for Java and JavaScript programming languages, respectively.  
```
1<packages>
2
3 publicclassMyFunctionClass{
4 publicvoidmyFunction(<parameters>){
5<definition>
6}
7}
8}
```  
Listing 3: Java cloud-agnostic signature.  
The words between the angle brackets represent the mutable parts of a function, thus, they can change from one deployment to another. Both the parameters and packages are established based on the trigger and programming language selected by the developer (_packages_ and _parameters_ attributes from the \(LANGUAGE\leftrightarrow TRIGER\) relation). These should be referencing the cloud-agnostic libraries for a specific event trigger. Both of them  
Figure 4: Function definition ERM.  
are defined using the appropriate language-specific syntax (_paramSyntax_ and _pkgSyntax_ attributes from _LANGUAGE_ entity).