quickly, avoid boilerplate • Operational savings, someone else operates (a little more of the) infrastructure • Fine grained billing • Fits some use cases well, like cloud events People use FaaS for a few reasons:
application framework • Resource usage • Infra ownership and control, Portability, Open source • Fine-grained billing’s advantage is dependent on usage patterns From one point of view, FaaS is a pattern for designing and deploying apps; for example the idea of turning a function into a service is independent of how you pay for the resources used by the service. So there are some orthogonal ideas bundled together in serverless, and a FaaS framework teases them apart. Since FaaS gets idle functions to consume much lower cpu/memory, cluster resource usage becomes more proportional to real usage than deployment size. The next one is a big topic, but simply put, sometimes you want to own your infra. Maybe your workload is too business critical, maybe your business organization is not super comfortable adding dependencies to new cloud services. Maybe you want more visibility into development of the systems you use. Portability comes from using the only part of the cloud that’s completely commodified — VMs. Billing advantages depend, quite sensitively, on actual usage patterns. A function that runs for one second every 10 seconds is cheaper on lambda, but if it runs for 2 seconds every 10 sec it’s cheaper on EC2. You have to model your usage accurately and evaluate whether serverless saves you money.
short lived functions, long-lived and stateful services. • You don’t want to have separate clusters for FaaS • Kubernetes great for building on top of: powerful orthogonal primitives and good APIs • Kubernetes scheduler, service discovery, networking all required in a FaaS framework, avoid re-invention from a user point of view: apps need multiple types of components; any complex solution will use long lived services, short lived functions, and stateful services. Having all the options in one cluster lets you use the right tool for each job and still be able to easily integrate things together. separate clusters — both an operational and cost overhead