Serverless Glossary
Named pointer to a specific function version.
Managed service routing HTTP requests to functions.
Invocation where execution happens in the background.
Event delivery model where a function may run more than once.
Execution model where events are processed no more than once.
Verifying identity before invoking a function.
Enforcing permissions for function access.
Delay strategy applied between retries.
Slowing event ingestion to avoid system overload.
Smallest unit of time used for billing execution.
Deploying new versions without downtime.
Maximum rate at which new instances can be created.
Rapid scale-out in response to sudden traffic spikes.
Gradual rollout to a subset of traffic.
Excessive inter-function communication increasing cost and latency.
Persisted position in a stream used to resume processing without re-reading or skipping events.
Decentralized event-based interaction between functions.
Automated build and deployment pipelines.
Latency incurred when a function runs after being idle and must initialize.
Paying for initialization time during cold starts.
Delay caused by runtime startup and dependency loading.
Measurement of cold vs warm executions.
Number of function executions running simultaneously.
Maximum allowed concurrent executions for a function.
Visibility into parallel execution levels.
Provider-enforced restriction on parallel execution.
Cost spikes caused by high parallel execution.
Difficulty forecasting spend under variable traffic.
Difficulty attributing cost to individual functions.
Compute capacity implicitly tied to memory configuration.
Storage for failed events requiring manual inspection.
Managing external libraries used by functions.
Code and dependencies bundled for execution.
End-to-end visibility across services.
Configuration that controls how and when failed events from a Dead Letter Queue are reprocessed after fixes.
Designing functions to safely handle repeated events.
Serverless functions executed closer to end users.
Applying serverless at scale with governance and compliance.
Configuration values injected into runtime.
Temporary storage available during execution only.
Acceptable failure rate for serverless workloads.
Number of events delivered to a single function invocation when consuming from queues or streams; a key lever for cost and throughput.
Maximum time the platform waits to accumulate a batch of events before invoking a function, even if the batch is not full.
Guarantees defining how events are delivered to functions.
Function that decorates raw events with additional context (user, geo, config) before passing them downstream.
Server-side rules that drop or pass through only matching events to a function, reducing unnecessary invocations and cost.
Guarantees (or lack thereof) around the sequence of event delivery.
Buffer decoupling event producers and consumers.
Service or system that triggers function execution, such as HTTP, queues, or storage events.
Configuration that connects an event source to a function.
Design pattern where applications react to events rather than running continuously.
Consistency model common in serverless architectures.
Logical guarantee ensuring effects occur once, typically via idempotency.
Time taken by a function to complete execution.
Isolated runtime where a function executes.
Temporary credentials assumed during invocation.
Security boundary isolating function execution.
Maximum allowed duration for a function execution.
Pattern where one event triggers many parallel function invocations (fan-out) whose results are later aggregated (fan-in).
Paused execution state retained between warm invocations.
A stateless unit of code triggered by an event and executed on demand.
A serverless model where discrete functions execute in response to events and are billed per execution and duration.
Connecting multiple functions to execute sequentially.
Choosing appropriate function size and responsibility.
Maximum allowed size of deployment package.
Entry point invoked when a function runs.
Scaling by increasing concurrent function instances.
Mixing synchronous and asynchronous function calls.
Combining serverless with containers or VMs.
Identity defining permissions for function execution.
Stable identifier attached to a request/event that allows deduplication and safe replay across retries and at-least-once delivery.
Function implementation designed so repeated processing of the same event produces a single logical effect.
No cost incurred when functions are not running.
Maximum allowed time for runtime initialization.
A single execution of a serverless function.
Cost growth due to retries, fan-out, or chaining.
Metadata linking logs and traces across calls.
Granting only minimum required permissions.
Capturing execution details for debugging and auditing.
Unsuitability of serverless for extended executions.
Amount of memory assigned to a function, influencing CPU share.
Period during which an event is hidden while being processed.
Quantitative measures such as invocations and latency.
Lightweight virtual machine used for serverless isolation (e.g., Firecracker).
Continuous observation of health and performance.
Pattern where the same functions are deployed in multiple regions for lower latency, redundancy, or data residency needs.
Cost and latency impact of outbound traffic via NAT.
Restricting network access for functions.
Visibility into function behavior via metrics, logs, and traces.
Centralized control of function execution order and state.
Latency introduced by private networking or NAT.
Maximum allowed size of event/request or response payloads for a single function invocation.
External storage used to retain data across invocations.
Event that repeatedly fails processing.
Difficulty moving functions across platforms.
Traffic level where serverless becomes cost-inefficient.
Pricing based on execution time and allocated resources.
Pricing based on number of function executions.
Short-lived credentials scoped to a single execution.
Invoking functions via private network paths.
Pre-warmed function instances to reduce cold start latency.
Provider-wide safety cap on the total concurrent executions allowed in a region across all functions in an account.
Guaranteed slice of total concurrency allocated to a function, ensuring capacity for critical workloads and optionally throttling others.
Rules governing how failed executions are retried.
Automated remediation triggered by alerts.
Language environment used to execute a function.
Setup stage before handler execution that impacts cold starts.
Security exposure via language runtimes and dependencies.
Automatically scaling idle functions down to zero instances.
Automatic adjustment of function instances based on event volume.
Secure storage and retrieval of sensitive data.
Automatic rotation of credentials used by functions.
Use cases where serverless is inefficient or costly.
HTTP interface backed by serverless functions.
Cloud execution model where code runs without server management, and the platform handles provisioning, scaling, and availability.
Event-driven processing of data streams or files.
Using functions for lightweight inference workloads.
Uncontrolled growth of functions increasing complexity.
Coordinated execution of multiple serverless functions.
Native trigger from managed cloud services.
Provider-imposed limits specific to serverless (e.g., code size, environment variables, concurrent executions, payload size).
Moving state out of functions into external systems.
Long-running workflows with externalized state.
Execution model where functions do not retain state.
Integration where functions are invoked from ordered data streams (logs, Kafka/Kinesis-like systems) with checkpointing semantics.
Risk from third-party libraries in deployment packages.
Invocation where the caller waits for a response.
p95/p99 latency impact of cold starts and retries.
Tracking requests across distributed function calls.
Tight coupling to provider-specific services.
Maintaining multiple versions of a function.
Running functions within private networks.
Function execution using an already-initialized runtime.
Synthetic or scheduled invocation used to keep runtimes warm and reduce cold start frequency (separate from provisioned concurrency).
Service that manages state, retries, and orchestration.
No matching data found.
