Function as a Service (FaaS) is a type of serverless cloud computing that allows you to open an application by calling a function when a certain event occurs, then stopping it immediately upon its termination, without the need to maintain a persistent infrastructure.
This allows users to develop and run their applications without having to create and configure the underlying computing infrastructure, thus concentrating on development, without devoting effort to the creation and configuration of infrastructure environments.
Typically, the elements underlying the FaaS model are “stateless” containers. The functions are thus executed in response to a certain event. FaaS allows you to obtain “ephemeral” but scalable runtime environments in a very simple way and in a very short time.
Function as a Service offers several advantages over the popular Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) models, as well as over traditional infrastructures (on-premises).
Scalability is inherent within the technology itself: scaling is managed in a totally transparent manner by the platform and, if using a cloud service provider, it is virtually infinite. This makes it possible, for example, to respond to changes in user load (such as marketing campaigns) without needing to do anything at your end.
FaaS adopts a “Pay per use” pricing model: the main calculation rationale is based on the number of calls made to the application. Thanks to this approach, we move away from the old paradigms such as memory or processors to be allocated, adopting concepts closer to the variability of business requirements instead.
The total absence of infrastructure means that the Total Cost of Ownership (TCO) of the solution is significantly reduced. In addition, FaaS technology is designed to be highly controllable through typical Software Development Life Cycle (SDLC) tools such as pipeline and Infrastructure as Code (IaC).
In Reply’s labs, we conducted an experiment to estimate the savings between the different cloud computing services on public cloud service providers.
An application was developed using the frameworks and a typical architecture of an Enterprise Intranet application, followed by a simulation of the real users’ traffic based on three different configurations: IaaS, PaaS and FaaS.
In the IaaS case, it was decided not to use automatisms, calculating the sizing “at peak”. In the PaaS case, it was decided to cage the user load, releasing resources when not used. The FaaS scenario did not require any resource allocation because the sizing coincided with the load curve. The results of the Reply study showed that, in conditions of high traffic variability, the savings compared to the IaaS model were 40% when using PaaS and 70% if using FaaS.
Reply has gained consolidated experience in the use of FaaS models, both in on-premise environments with OpenFaaS technologies, and in the cloud, by exploiting the various services that all major Cloud Service Providers make available. Experience has shown that every business has its own load curve, its seasonality and sometimes even periods of low or no activity. After analysing the applications managed by the Reply teams, the applications were grouped into 3 macro-categories:
Follow the Sun, or applications that serve a worldwide clientele 24x7
B2C applications, which generally show an M-curve with a reduction in traffic during the weekend
Working hours, with high traffic during working hours and for the most part zero traffic at other times of the day.
Since we are dealing with a “Pay per Use” cost model, the applications that maximise the result are the latter. The reason being that, compared to other environments that need to be “up and running” 24x7, with FaaS it is possible to eliminate costs when the applications are not in use. Thanks to its consolidated partnerships with all the leading cloud service providers, Reply can support companies in assessing the potential advantages of adopting a FaaS model for existing solutions, as well as for new applications during the design phase.