## 5 Observable Long-Term Trends in Cloud Systems Engineering
### A Review of the Architectural Evolution
#### 5.2.2 Serverless Architectures
This means that even service orchestration is not done anymore by the service provider itself but by the service consumer via provided applications. This end-user orchestration has two interesting effects: (1) the service consumer now provides resources needed for service orchestration; (2) because the service composition is done outside the scope of the FaaS platform, still unsolved FaaS function composition problems (like the double spending problem) are avoided. * Such client or edge devices are interfacing third party services directly. * Endpoints of very service specific functionality is provided via API gateways. Thus, HTTP- and REST-based/REST-like communication protocols are generally preferred. * Only very domain or service specific functions are provided on FaaS platforms. Mainly, when this functionality is security relevant and should be executed in a controlled runtime environment by the service provider, or the functionality is too processing or data-intensive to be executed on \begin{table}
\begin{tabular}{l l} \hline \hline
**Benefits** & **Drawbacks** \\ \hline
**RESOURCE EFFIENCY** (service side) & \\ - auto-scaling based on event stimulus & - maximum function runtime is limited \\ - reduced operational costs & - startup latencies of functions must be considered \\ - scale to zero capability (no always-on) & - function runtime variations \\  & - functions can not preserve a state across function calls \\  & - external state (cache, key/value stores, etc.) can \\  & compensate this but is a magnitude slower \\  & - double spending problems (FaaS functions call other \\  & FaaS functions) \\ \hline
**OPERATION** (service side) & \\ - simplified deployment & - increased attack surfaces \\ - simplified operation (see auto-scaling) & - each endpoint introduces possible vulnerabilities \\  & - missing protective barrier of a monolithic server \\  & application \\  & - parts of the application logic are shifted to the client-side \\  & (that is not under control of the service provider) \\  & - increased vendor lock-in (currently no FaaS standards \\  & for API gateways and FaaS runtime environments) \\ \hline
**DEVELOPMENT SPEED** (service side) & \\ - development speed & - increased client complexity \\ - simplified unit testing of stateless FaaS functions & - application logic is shifted to the client-side \\ - better time to market & - code replication on client side across client platforms \\  & - control of application workflow on client side to avoid \\  & double-sending problems of FaaS computing \\  & - increased integration testing complexity \\  & - missing integration test tool-suites \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Serverless architecture benefits and drawbacks (mainly compiled from [40]). consumer clients or edge devices, or the functionality is so domain-, problem-, or service-specific that simply no external third-party service exists. Finally, the reader might observe the trend in serverless architectures that this kind of architecture is more decentralized and distributed, makes more intentional use of independently provided services, and is therefore much more intangible (more cloudy) compared with microservice architectures.