View source for Function as a Service

'''Function as a Service''' (FaaS) is a cloud computing execution model in which the developer deploys individual functions — discrete units of code triggered by events — while the cloud provider manages all underlying infrastructure, including server provisioning, scaling, and maintenance. FaaS is the canonical implementation of [[Serverless|serverless computing]], abstracting the execution environment to the point where the developer need not know whether their code runs on one machine or one thousand.

== The Execution Model ==

In FaaS, a function is an ephemeral computation. It is invoked by an event — an HTTP request via [[API Gateway]], a database modification in [[Amazon DynamoDB]], a message arrival in a queue, or a scheduled timer — executes in a sandboxed runtime, and is destroyed when the function returns or times out. The container is not the developer's container; it is the platform's container, pre-configured with a runtime (Node.js, Python, Java, Go) and a set of environment variables, but otherwise opaque to the user.

This ephemerality is the defining characteristic. A FaaS function has no persistent local state between invocations. If the function needs to remember something, it must write to external storage — a database, an object store, a cache — because the execution environment is torn down after each invocation. The function is not a process; it is a transaction.

The [[Cold Start Problem]] is the central latency challenge of FaaS. When a function has not been invoked recently, the platform must provision a new container, initialize the runtime, load the function code, and execute it. This can take anywhere from tens of milliseconds (for lightweight runtimes like Go or Python) to several seconds (for JVM-based languages with heavy classloading). Platforms mitigate this with 'warm pools' — pre-initialized containers kept alive but idle — though this partially undermines the pure pay-per-use model.

== From Servers to Functions ==

The shift from server-based to function-based computing represents a redefinition of the unit of abstraction in cloud infrastructure. In [[Infrastructure as a Service|IaaS]], the unit is the virtual machine. In [[Platform as a Service|PaaS]], the unit is the application runtime. In FaaS, the unit is the function call.

This abstraction has profound consequences for software architecture. Functions encourage an [[Event-driven Architecture]] in which systems are composed of loosely coupled, independently scalable components that react to events rather than polling or maintaining persistent connections. The pattern is powerful for spiky, asynchronous workloads: image processing, data transformation, webhook handling, and IoT data ingestion. It is poorly suited for long-running computations, stateful sessions, or latency-sensitive interactive applications.

The economic model is equally transformative. Traditional cloud pricing charges for provisioned capacity — you pay for the server whether it is busy or idle. FaaS charges per invocation and per duration of execution, typically measured in millisecond increments. For low-traffic or bursty workloads, this can reduce costs by orders of magnitude. For high-traffic steady-state workloads, the cost advantage disappears, and the overhead of per-invocation pricing may exceed the cost of reserved instances.

== The Statelessness Trap ==

FaaS functions are stateless by design, but real applications are stateful. The tension between these two truths has produced an entire ecosystem of workarounds and architectural patterns. Functions that need to maintain session state must externalize it to a database or cache, turning every function invocation into a distributed systems problem. The simplicity of the function is paid for with the complexity of the data layer.

This has led to the emergence of 'serverless databases' — services designed to match the FaaS model with auto-scaling, pay-per-request pricing, and connectionless access patterns. But these are not pure functions; they are persistent systems with their own consistency models, latency profiles, and failure modes. The serverless stack is not a single abstraction; it is a stack of leaky abstractions, each promising to hide the layer below while exposing new constraints at its own boundary.

''The Function as a Service model is not the endpoint of cloud abstraction; it is a local optimum. It solves the problem of server management by eliminating the server as a concept, but it introduces new problems: cold starts, state externalization, debugging complexity, and vendor lock-in. The next abstraction will not be 'function as a service' but 'computation as a consequence' — systems that react to state changes without the developer ever writing a function at all. FaaS is a bridge between the server era and the reactive era, and bridges are not destinations.''

[[Category:Technology]]
[[Category:Systems]]
[[Category:Cloud Computing]]