A few months back, I co-wrote a research paper titled An Analysis of Function-as-a-Service Infrastructures. Today I found out that the research paper has been accepted for publication in a leading international conference (EuroSPI 2020 in Dusseldorf, Germany), the current citation for which is as follows:
Grogan, J., Mulready, C., McDermott, J., Urbanavicius, M., Yilmaz, M., Abgaz, Y., McCarren, A., MacMahon, S.T., Garousi, V., Elger, P., Clarke, P.M.: A Multivocal Literature Review of Function-as-a-Service (FaaS) Infrastructures & Implications for Software Developers. To Appear In: Proceedings of the 27th European and Asian Conference on Systems, Software and Services Process Improvement (EuroSPI 2020), Springer CCIS Vol. 1251, 9-11 September 2020, Dusseldorf, Germany.
This is the first time I've had such academic success so it's really exciting. The research was conducted during my final year of my undergraduate studies in Dublin City University. Broadly speaking the aim of this paper was to provide an extensive analysis of Functions as a Service (FaaS) infrastructures, and how they compare to each other. I have for sometime been genuinely enthralled by the world of serverless so this was a great opportunity to learn more.
FaaS Infrastructures
FaaS infrastructures are important platforms that make up a category of cloud computing. This paradigm is representative of how writing and deploying applications has changed with time, moving from the heavyweight three-tier model of monolithic applications to the composable microservice oriented landscape of today. Instead, FaaS infrastructures are often associated with on-demand functionality, allowing clients to build applications without the overhead complexity associated with running and maintaining server infrastructures.
In this way, applications built alongside FaaS infrastructures are said to follow the “serverless” model. This is an execution model where a provider dynamically manages and allocates machine resources, simplifying the process of deploying code into a production environment.
This study provided an analysis of scalability, cost, execution times, integration support, and the constraints associated with FaaS services provided by AWS Lambda, Google Cloud Functions, and Azure Functions.
Findings
Hot and cold starts for differing runtimes are linked to the underlying architecture of the provide.
A reason for memory configuration having a greater impact on Google Cloud Functions than on AWS Lambda, suggests that Google allocates CPU proportionally to memory.
The biggest constraint of FaaS infrastructures is the amount of supported language runtimes.
Double billing in the serverless model breaks a core principle of the serverless model and that without intrinsic support from the FaaS vendor, it is impossible to avoid double billing.
Azure and AWS offers the cheapest access to a FaaS solution based on request invocations alone and also offers the best flat rate charge for duration of a functions execution - at $0.000016 per GB-second.
With respect to compute time, both AWS and Google Cloud round up to the nearest 100ms, whilst Azure only rounds to the nearest 1ms.
In regards to the integration capabilities of each solution, Google Cloud provides a more streamlined approach due to the absence of integrating the function with an API, whereas both AWS and Azure require the user to either deploy or have a pre-existing API.
The Final Publication
Unfortunately the final publication is not yet available as it is undergoing peer review and additional academic authors are working on the paper. Once I can make it freely available I will make sure to share it here on Dev!
What is your experience with FaaS and serverless computing? Let me know in the comments!
Top comments (3)
I've spent a lot of last year putting up some (simple) data science services on was lambda in both python and r. These services interface with our monolithic laravel PHP product.
I've been planning on writing up my experience more fully in a post. I've started a while back, but never got it to a publishable state. I'll try and get it done by the end of the month.
Generally, my experience was positive, and though I got both python and R services up in production, getting the R service up was a lot more of a faff. A key issue was database connection. For some still mysterious reason, it still doesn't work, so we send the data in the body of the API. It's good enough for now at least. Bakdata make a lovely R layer for Aws lambda that was key to the solution.
What do you mean by double billing? It's a term I haven't heard before.
Curious about what
Hey Dave!
So double billing would generally refer a vendor charging the customer for the same product twice. In the case of FaaS vendor’s double billing refers to the synchronous invocation of other functions. When a function makes a call to another service, you pay for the waiting time — even if the code is using async I/O. This means you wait for the result of each function called, and hence must pay for the wait time. This wait time is directly correlated to section.
So in all. this additional billing violates one of the serverless principles: pay for what you use, not idle time!
Without intrinsic support from the FaaS vendor, it is impossible to avoid double billing while still maintaining the core principle of the serverless computing model.
Got it. Cheers :)