Serverless Computing

Definition

Serverless computing is a cloud execution model in which the cloud provider dynamically allocates, scales, and manages the underlying compute infrastructure required to run application code. Despite the name, servers still exist — they are simply abstracted away from the development team, who deploy discrete units of logic (commonly called functions) that execute in response to triggers such as an API call, a file upload, or a scheduled event. The provider handles provisioning, patching, scaling up and down (including to zero when idle), and high availability, while billing is typically based on execution time and resource consumption rather than pre-allocated capacity. From an architecture standpoint, serverless is best understood as one point on a spectrum of compute abstraction — moving from physical servers, to virtual machines, to containers, to fully managed functions-as-a-service (FaaS) offerings such as AWS Lambda, Azure Functions, or Google Cloud Functions. It is frequently paired with managed backend services (databases, queues, authentication, storage) under the broader label "serverless architecture," which extends the same operational hands-off principle beyond compute alone. It is important to draw a boundary here: serverless is a technology delivery pattern, not a business capability or a business process. Business architects should not model "serverless" as a capability in a capability map; rather, it is an implementation option that shows up in the technology layer when cross-mapping capabilities to the application and technology architecture. Confusing the two — treating an infrastructure pattern as if it were a business function — is a common source of architecture model pollution.

Origin & Context

The term gained traction following Amazon Web Services' launch of AWS Lambda in 2014, which popularized event-driven, function-based execution as a distinct cloud service category. It builds on earlier platform-as-a-service (PaaS) concepts but pushes abstraction further by eliminating any developer awareness of server instances or runtime capacity planning. Within enterprise architecture frameworks such as TOGAF, serverless computing is typically addressed in the Technology Architecture domain, distinct from the Business Architecture domain where capabilities, value streams, and operating models live.

Why It Matters

CIOs and CTOs care because serverless can materially reduce infrastructure management overhead and shift cost from fixed capacity to variable, usage-based spend — a direct lever for IT cost optimization and technology rationalization initiatives. Enterprise architects care because it changes how applications are decomposed, deployed, and governed, affecting reference architectures, vendor lock-in exposure, and disaster recovery planning. Business architects care indirectly: when capability-to-application mappings show heavy reliance on serverless components, that has implications for cost allocation to capabilities, vendor risk exposure by business domain, and the feasibility of rapid scaling for volatile business capabilities like seasonal order processing or fraud detection.

Common Misconceptions

Myth: Serverless means there are no servers involved.

Reality: Servers still run the code; the term refers to the fact that the organization consuming the compute no longer provisions, patches, or manages those servers directly. The abstraction is operational, not physical.

Myth: Serverless is a business architecture concept and belongs in a capability map.

Reality: Serverless is a technology delivery pattern that lives in the technology and application architecture layers. It should appear in capability-to-application or capability-to-technology cross-mappings as an implementation detail, not as a capability itself.

Myth: Serverless is always cheaper than running your own infrastructure.

Reality: Serverless economics favor variable, bursty, or unpredictable workloads. For sustained, high-volume, predictable processing, reserved capacity or containerized approaches can be more cost-effective — a decision that should be evaluated capability by capability, not applied as a blanket standard.

Practical Example

An enterprise architect at a regional insurer is leading a technology rationalization initiative tied to the capability map. The Claims Intake capability shows unpredictable volume spikes after severe weather events, and the current architecture requires the infrastructure team to pre-provision servers for worst-case load, sitting mostly idle otherwise. Working with the solution architect, the team maps this capability to a redesigned application component built on serverless functions triggered by incoming claim submissions. The CIO signs off after the enterprise architect documents the tradeoff in the technology architecture roadmap: reduced idle infrastructure cost and faster scaling during surge events, weighed against increased dependency on a single cloud vendor's proprietary function runtime. The decision, and its capability linkage, is recorded in the architecture repository so future portfolio reviews can trace why this component departs from the organization's default containerization standard.

Industry Applications

Financial Services

Used for event-driven fraud scoring and payment validation functions that need to scale instantly during transaction spikes without maintaining always-on infrastructure.

Retail

Applied to seasonal and promotional workloads such as flash-sale order processing, where demand is highly variable and idle capacity during off-peak periods is a direct cost concern.

Healthcare

Used for asynchronous processing tasks like medical image ingestion or claims file transformation, where workloads arrive unevenly and strict data residency and compliance boundaries must be mapped explicitly to the technology components involved.

Related Terms

• Cloud Computing: Broader delivery model of which serverless is one specialized execution pattern
• Microservices: A related architectural style often implemented using serverless functions as the deployment unit
• Business Capability: The business-layer construct that must not be conflated with the technology pattern of serverless