Serverless computing, also known as Functions-as-a-Service, is a recent paradigm aimed at simplifying the programming of cloud applications. The idea is that developers design applications in terms of functions, which are then deployed on a cloud infrastructure. The infrastructure takes care of executing the functions whenever requested by remote clients, dealing automatically with distribution and scaling with respect to inbound traffic. While vendors already support a variety of programming languages for serverless computing (e.g. Go, Java, Javascript, Python), as far as we know there is no reference model yet to formally reason on this paradigm. In this paper, we propose the first core formal programming model for serverless computing, which combines ideas from both the λ-calculus (for functions) and the π-calculus (for communication). To illustrate our proposal, we model a real-world serverless system. Thanks to our model, we capture the limitations of current vendors and formalise possible amendments. Maurizio Gabbrielli, Saverio Giallorenzo, Ivan Lanese, Fabrizio Montesi, Marco Peressotti, & Stefano Pio Zingaro. (2019). No More, No Less - A Formal Model for Serverless Computing. In H. R. Nielson & E. Tuosto (Eds.), Coordination Models and Languages - 21st IFIP WG 6.1 International Conference, COORDINATION 2019, Held as Part of the 14th International Federated Conference on Distributed Computing Techniques, DisCoTec 2019, Kongens Lyngby, Denmark, June 17-21, 2019, Proceedings (Vol. 11533, pp. 148–157). Springer. [https://doi.org/10.1007/978-3-030-22397-7_9]

1. No More, No Less
A Formal Model for Serverless Computing
Maurizio Gabbrielli, Ivan Lanese, Stefano Pio Zingaro
INRIA, France / Università di Bologna, Italy
Coordination 2019
Saverio Giallorenzo, Fabrizio Montesi, Marco Peressotti
University of Southern Denmark, Denmark

2. A gentle introduction to “serverless”...
...
Adapted from “Serverless Architecture Patterns” by Abby Fuller, AWS
Event Source Function Cloud Architecture

3. A gentle introduction to “serverless”...
Monolith Microservices Serverless
provisioned,
pay-per-deployment
on-demand,
pay-per-execution

4. A gentle introduction to “serverless”...
Monolith Microservices Serverless

5. A gentle introduction to “serverless”...
Monolith Microservices Serverless
?!
Still rough
around theedges

6. A gentle introduction to “serverless”...
https://aws.amazon.com/serverless/
Tailor

7. A gentle introduction to “serverless”...
https://github.com/alanwill/aws-tailor
Tailor
an excerpt

8. … and its current limitations (non-exhaustive)
● Currently ~15’ execution timeout;
● No function-to-function invocation. Functions need an in-between
stateful service to call each other;
● Sparse coordination logic.

9. … and its current limitations (non-exhaustive)
● Traffic-dependent scaling of
functions implies:
○ complex cost model;
○ complex system load
estimations.
● Poor performance for
standard communication
patterns
Jonas, Eric, et al. "Cloud Programming Simplified: A Berkeley View on Serverless Computing."
Block
Storage
Object
Storage
File
System
Elastic
Database
Memory
Store
Function access
Transparent
Provisioning
Availability and
persistence
Latency
Costs

10. … and its current limitations (non-exhaustive)
Lock-in due to absence of standards on:
● function support/execution environments;
● function call semantics;
● semantics of stateful services.

11. Direction
● We want to study S.C. avoiding any vendor/technology specifics
● We need a formal model for Serverless Computing that
○ Captures current incarnations of S.C.
(e.g. event-based, storage-mediated as in AWS)
○ Supports proposed approaches/features
(e.g. function-to-function invocation, updatable function definitions)

12. Serverless Kernel Calculus (SKC)
● Systems: ⟨S,𝒟⟩
● Function definitions: f↦M
● Running functions: c◂M
Repository of function definitionsNetwork of running functions
λ-termFunction name
λ-termPromise

13. Serverless Kernel Calculus (SKC)
● Systems: ⟨S,𝒟⟩
● Function definitions: f↦M
● Running functions: c◂M
Repository of function definitionsNetwork of running functions
λ-termFunction name
λ-termPromise

14. Serverless Kernel Calculus (SKC)
● Systems: ⟨S,𝒟⟩
● Function definitions: f↦M
● Running functions: c◂M
Repository of function definitionsNetwork of running functions
λ-termFunction name
λ-termPromise

15. Serverless Kernel Calculus (SKC)
● Systems: ⟨S,𝒟⟩
● Function definitions: f↦M
● Running functions: c◂M
Repository of function definitionsNetwork of running functions
λ-termFunction name
λ-termPromise

16. SKC function terms
M ::= M M' ∣ V
∣ f
∣ async M
∣ set f M
∣ take f
V ::= x ∣ λx.M
∣ c
⟨ℰ[async M],𝒟⟩ ⟶ ⟨ℰ[c] ∣ c◂M,𝒟⟩
⟨ℰ[set f M],𝒟⟩ ⟶ ⟨ℰ[f],𝒟[f↦M]⟩
⟨ℰ[take f],𝒟[f↦M]⟩ ⟶ ⟨ℰ[M],𝒟∖f⟩
Function invocation
Asynchronous eval
Function Repository
Updates
⟨ℰ[f],𝒟[f↦M]⟩ ⟶ ⟨ℰ[M],𝒟⟩
Futures ⟨c◂V ∣ S,𝒟⟩ ⟶ ⟨S[V/c],𝒟⟩

17. SKC function terms
M ::= M M' ∣ V
∣ f
∣ async M
∣ set f M
∣ take f
V ::= x ∣ λx.M
∣ c
⟨ℰ[async M],𝒟⟩ ⟶ ⟨ℰ[c] ∣ c◂M,𝒟⟩
⟨ℰ[set f M],𝒟⟩ ⟶ ⟨ℰ[f],𝒟[f↦M]⟩
⟨ℰ[take f],𝒟[f↦M]⟩ ⟶ ⟨ℰ[M],𝒟∖f⟩
Function invocation
Asynchronous eval
Function Repository
Updates
⟨ℰ[f],𝒟[f↦M]⟩ ⟶ ⟨ℰ[M],𝒟⟩
Futures ⟨c◂V ∣ S,𝒟⟩ ⟶ ⟨S[V/c],𝒟⟩

18. SKC function terms
M ::= M M' ∣ V
∣ f
∣ async M
∣ set f M
∣ take f
V ::= x ∣ λx.M
∣ c
⟨ℰ[async M],𝒟⟩ ⟶ ⟨ℰ[c] ∣ c◂M,𝒟⟩
⟨ℰ[set f M],𝒟⟩ ⟶ ⟨ℰ[f],𝒟[f↦M]⟩
⟨ℰ[take f],𝒟[f↦M]⟩ ⟶ ⟨ℰ[M],𝒟∖f⟩
Function invocation
Asynchronous eval
Function Repository
Updates
Futures ⟨c◂V ∣ S,𝒟⟩ ⟶ ⟨S[V/c],𝒟⟩

19. SKC function terms
M ::= M M' ∣ V
∣ f
∣ async M
∣ set f M
∣ take f
V ::= x ∣ λx.M
∣ c
⟨ℰ[set f M],𝒟⟩ ⟶ ⟨ℰ[f],𝒟[f↦M]⟩
⟨ℰ[take f],𝒟[f↦M]⟩ ⟶ ⟨ℰ[M],𝒟∖f⟩
Function invocation
Asynchronous eval
Function Repository
Updates
Futures

20. SKC function terms
M ::= M M' ∣ V
∣ f
∣ async M
∣ set f M
∣ take f
V ::= x ∣ λx.M
∣ c
⟨ℰ[async M],𝒟⟩ ⟶ ⟨ℰ[c] ∣ c◂M,𝒟⟩
⟨ℰ[set f M],𝒟⟩ ⟶ ⟨ℰ[f],𝒟[f↦M]⟩
⟨ℰ[take f],𝒟[f↦M]⟩ ⟶ ⟨ℰ[M],𝒟∖f⟩
Function invocation
Asynchronous eval
Function Repository
Updates
⟨ℰ[f],𝒟[f↦M]⟩ ⟶ ⟨ℰ[M],𝒟⟩
Futures ⟨c◂V ∣ S,𝒟⟩ ⟶ ⟨S[V/c],𝒟⟩
λ + Futures + Function Repository

21. Programmable events in SKC
● Store handlers for event e in the definition repository 𝒟:
install_handler ↦ λe.λhandler.
let old_handler = take e
let new_handler = λv.do async (handler v)
(current_handler v)
set e new_handler
● Raise event e (with v) by invoking its handlers in 𝒟:
e v
● ( See the paper for Tailor in SKC )

22. Programmable events in SKC
● Store handlers for event e in the definition repository 𝒟:
install_handler ↦ λe.λhandler.
let old_handler = take e
let new_handler = λv.do async (handler v)
(current_handler v)
set e new_handler
● Raise event e (with v) by invoking its handlers in 𝒟:
e v
● ( See the paper for Tailor in SKC )
Updatable function
definitions

23. Programmable events in SKC
● Store handlers for event e in the definition repository 𝒟:
install_handler ↦ λe.λhandler.
let old_handler = take e
let new_handler = λv.do async (handler v)
(current_handler v)
set e new_handler
● Raise event e (with v) by invoking its handlers in 𝒟:
e v
● ( See the paper for Tailor in SKC )
Updatable function
definitions
Function-to-function
invocation

24. Conclusions and future work
We introduced SKC a Kernel Calculus for Serverless Computing:
● Build on established models (λ-calculus + futures + function repository)
● captures current programming models
● supports next-gen features e.g. function-to-function invocation
Serverless: current challenges SKC: research direction
The coordination logic is spare and
loosely-consistent
Choreographic Programming
targeting SKC.
Estimation of performance and
costs is complex
Quantitative SKC

25. No More, No Less
λ + Futures + Function Repository
=
A formal model for Serverless Computing
Thanks for your attention