## 5 Observable Long-Term Trends in Cloud Systems Engineering
### A Review of the Resource Utilization Evolution and Its Impact on Cloud Technology Architectures
#### 5.1.3 Function-as-a-Service  
Microservice architectures propose a solution to efficiently scale computing resources that are hardly realizable with monolithic architectures [45]. The allocated infrastructure can be better tailored to the microservices' needs due to the independent scaling of each one of them via standardized deployment units addressed in Section 5.1.2. However, microservice architectures face additional efforts like deploying every single microservice and scaling and operating them in cloud infrastructures. To address these concerns, container orchestrating platforms like Kubernetes [39], or Mesos/Marathon [47] emerged. However, this shifts the problem mainly to the operation of these platforms and these platforms are still always-on components. Thus, so-called Serverless architectures and Function-as-a-Service platforms have emerged in the cloud service ecosystem. The AWS lambda service might be the most prominent one, but there exist more like Google Cloud Functions, Azure Functions, OpenWhisk, Spring Cloud Functions to name just a few. However, all (commercial platforms) follow the same principle to provide very small and fine-grained services (just exposing one stateless function) that are billed on a runtime-consuming model (millisecond dimension). The problem with the term Serverless is that it occurs in two different notions. 1. _\"Serverless was first used to describe applications that significantly or fully incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state. These are typically \"rich client\" applications--think single-page web apps, or mobile apps--that use the vast ecosystem of cloud-accessible databases, authentication services, and so on. These types of services can be described as \"Backend as a Service (BaaS) [40]\"._
2. _\"Serverless can also mean applications where server-side logic is still written by the application developer, but, unlike traditional architectures, it is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a third party. One way to think of this is \"Functions as a Service\" or \"FaaS.\" AWS Lambda is one of the most popular implementations of a Functions-as-a-Service platform at present, but there are many others, too [40]\"._  
In this section, we use the term Serverless computing in the notion of FaaS, and we will mainly investigate the impact on resource utilization. The upcoming Section 5.2.2 will investigate Serverless more in architectural terms. FaaS was specifically designed for event-driven applications that require carrying out lightweight processing in response to an event [48]. FaaS is more fine-grained than microservices and facilitates the creation of functions. Therefore, these fine-grained functions are sometimes called _nanoservices_. These functions can be easily deployed and automatically scaled, and provide the potential to reduce infrastructure and operation costs. Others like the deployment unit approaches of Section 5.1.2--that are still always-on software components--functions are only processed if there are active requests. Thus, FaaS can be much more cost efficient than just containerized deployment approaches. According to a cost comparison of monolithic, microservice and FaaS architectures case study by [PERSON] et al. cost reductions up to 75% are possible [44]. On the other hand, there are still open problems like the Serverless trilemma identified by [PERSON] et al. The Serverless trilemma _\"captures the inherent tension between economics, performance, and synchronous composition\"_[42] of serverless functions. One obvious problem stressed by [PERSON] et al. is the \"double spending problem\" shown in Figure 6. This problem occurs when a serverless function \(f\) is calling another serverless function \(g\) synchronously. In this case, the consumer is billed for the execution of \(f\) and \(g\)--although only \(g\) is consuming resources because \(f\) is waiting for the result of \(g\).