Is serverless the same as functions as a service?

Functions are one important form, but the broader ecosystem includes other managed capabilities.

Is it always cheaper?

No. Cost depends on the workload, pricing model, and connected services, so it needs measurement and current estimates.

Does the provider secure everything?

No. The provider manages specified infrastructure responsibilities, while customers still manage their application, permissions, data use, and relevant configuration.

AI Glossary / Data engineering and architecture / Intermediate

Serverless computing

Definition

Serverless computing is a service model in which a provider manages the underlying server infrastructure while users deploy application code or use managed capabilities through service interfaces. Servers still exist; the customer is relieved of some direct provisioning and maintenance work. The term includes more than functions alone and can cover managed databases, messaging, and other services. Responsibilities and operating limits depend on the specific offering.

What it means

A team can arrange for code to run when an event occurs without maintaining a dedicated server for that function. This can simplify some operational tasks, especially for variable or event-driven workloads. It does not remove application design, monitoring, access management, or cost control. Pricing and scaling behavior also vary: “serverless” should not be interpreted as a promise that every service is free when idle or scales without limits.

How it works

The application combines provider-managed services with its own code and configuration. Events or requests trigger work, and the platform allocates execution resources according to the service's rules. Persistent state usually belongs in an appropriate durable service rather than relying on a particular execution environment remaining alive. Developers define permissions, failure handling, and observability. For event-driven functions, delivery and retry behavior must be checked because some workflows can present the same event more than once.

Three practical examples

File processing: a new upload triggers a function that extracts metadata and records the result, with safeguards for duplicate notifications.
Website backends: an API invokes managed compute for short operations while a separate database stores durable application state.
AI orchestration: an event-driven workflow validates a document, invokes an appropriate model service, and stores the result, while respecting model limits and handling long-running steps through a suitable design.

Think of it this way

Think of using a professionally managed event venue instead of owning the building. You still plan the event, control admission, and pay for the services you use, but someone else maintains the building. The analogy is limited because cloud services have technical quotas, execution models, and billing units. Delegating infrastructure does not delegate responsibility for what the application does with data or credentials.

Worked example

A fictional image workflow receives 100 upload events. Each should create one thumbnail record. Suppose five events are delivered twice, producing 105 function invocations. If each invocation blindly inserts a new record, the result can contain 105 records for only 100 uploads. A design using a stable upload identifier and an appropriate atomic uniqueness or idempotency mechanism can recognize repeated work and preserve the intended one-result-per-upload behavior. This does not mean every serverless event source has identical delivery guarantees. The team must inspect the actual trigger and failure semantics, then test concurrent duplicates as well as sequential retries.

Illustrative case study

Fictional example: Alder Notes processes occasional document uploads. Its developers choose managed event-driven components and avoid maintaining an always-running worker for the trial. During testing, they find that one document type takes longer than the chosen function's execution allowance. They split the workflow and use an appropriate longer-running service for that step. This invented scenario illustrates workload fit; it claims neither lower costs nor better performance than every server-based alternative.

Common misconceptions and mistakes

Do not read “serverless” as “no servers” or “no operations.” Do not assume local process memory is durable application storage. Avoid relying on exactly-once processing unless the complete workflow actually guarantees the required effect. Cold starts, service limits, dependency failures, and debugging across components can matter, but their importance varies by workload. Also do not equate automatic scaling with unlimited capacity in downstream databases, external APIs, or model services.

Business use

Evaluate serverless against the workload rather than the label. Consider event frequency, latency needs, execution duration, dependencies, data movement, and observability. Estimate total cost across compute, storage, requests, and connected services using current provider information. Define clear ownership for application security and failure recovery. For AI products, orchestration may suit serverless components even when model execution requires a different environment. The architecture should make retries, state transitions, and user-visible outcomes understandable.

Check your understanding

A function completes its database write but the caller never receives confirmation. Is retrying automatically harmless because the function is serverless?

Answer: No. The retry can repeat a side effect unless the workflow handles duplicates correctly. Infrastructure management does not replace application-level idempotency design.

Related terms

Cold start (recommender systems)
Infrastructure as code
Functions as a service
event-driven architecture
managed service
idempotency
cold start
shared responsibility
both matter independently

Learn next

sketch one event-driven workflow and mark its durable state, retry boundaries, permissions, and failure notifications. Estimate the effect of a duplicate event and a slow dependency before selecting a deployment service. Compare the design with a simple worker-based alternative using the same requirements.

Sources

Primary sources consulted: AWS, What Is Serverless Computing?, https://aws.amazon.com/what-is/serverless-computing/; Lambda Best Practices, https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html; Designing Lambda Applications, https://docs.aws.amazon.com/lambda/latest/dg/concepts-application-design.html — search excerpts consulted. AWS examples illustrate provider-specific behavior, not universal limits or prices. All scenarios are original; full editorial review remains pending.

Previous: Seriousness check Next: Service principal