Serverless Computing: Managed Execution Without Managing Servers

The term serverless sounds physically impossible. Code always runs on computers.

The name describes the customer's operating model, not the absence of hardware.

Serverless computing lets customers run code or use managed capabilities without provisioning and maintaining individual servers.

The provider schedules work, manages the host fleet, replaces failed machines, and adjusts execution capacity. Customers still own code, data, permissions, configuration, architecture, and cost.

A concrete example: processing an uploaded image

A user uploads a photograph to object storage.

The upload emits an event. A serverless function:

1. Receives the event.
2. Downloads the image.
3. Creates thumbnail sizes.
4. Stores the outputs.
5. Records status.
6. Finishes.

No customer-managed server waits continuously for uploads.

The provider starts execution when work arrives and can run several instances when many images arrive.

Functions as a Service

Functions as a Service, or FaaS, is a common serverless model.

Developers deploy a function plus configuration:

export async function handle(event) {
  const image = await loadImage(event.objectKey);
  const thumbnail = await resize(image, 320);
  await saveThumbnail(event.objectKey, thumbnail);
}

The platform decides which machine runs it and manages execution environments.

Functions typically have limits on duration, memory, temporary storage, package size, and concurrent executions.

Work that exceeds those constraints may fit a container service, batch platform, or long-running server better.

Serverless includes managed services

Serverless architecture is broader than functions.

It may use:

• Managed databases with automatic capacity
• Object storage
• Event buses
• Queues
• Workflow engines
• Authentication services
• API gateways
• Analytics services

The shared idea is that customers consume a capability while the provider manages most server lifecycle.

Every managed service still exposes quotas, data models, failure behavior, and pricing that architecture must respect.

Event-driven execution

Serverless functions are often triggered by:

• HTTP requests
• File uploads
• Queue messages
• Database changes
• Scheduled timers
• Monitoring alerts
• Event-bus messages

Events decouple the producer from the consumer. The uploader does not need to know which machine processes the image.

However, delivery may be delayed, duplicated, or retried. Consumers need clear contracts and idempotent behavior.

Stateless execution

Execution environments can disappear at any time. Local memory and temporary files should not be the only copy of important state.

Durable state belongs in external services such as:

• Databases
• Object storage
• Queues
• Durable workflow systems

An environment may be reused, allowing cached connections or data to improve performance, but code cannot assume reuse.

Treat each invocation as able to start in a fresh environment.

Cold starts

When no ready execution environment exists, the platform must prepare one and initialize the application. This extra delay is a cold start.

Cold-start time depends on:

• Runtime
• Package size
• Initialization code
• Network setup
• Memory allocation
• Platform behavior

Warm invocations reuse an existing environment and are faster.

Latency-sensitive services may keep provisioned capacity, reduce startup work, use lighter packages, or choose another compute model.

Automatic scaling has consequences

A platform can start many function instances rapidly.

This helps absorb parallel events, but can overwhelm:

• Database connection limits
• Legacy services
• Third-party APIs
• Downstream rate quotas
• Shared storage

Concurrency controls and queues protect dependencies.

Serverless scaling moves the capacity question from "How many servers?" to "How much concurrency can the whole workflow safely support?"

At-least-once delivery and idempotency

Many event systems provide at-least-once delivery. A function may receive the same event more than once.

If processing a payment event twice charges a customer twice, the consumer is unsafe.

Idempotent handling may use:

• A unique event ID
• A database uniqueness constraint
• A conditional write
• An idempotency record
• A destination key derived from the source event

Retries are normal recovery behavior, so duplicate handling belongs in the initial design.

Timeouts and retries

Functions have execution timeouts. Trigger services may retry failed invocations.

Architects need to know:

• Which failures trigger retries
• Retry schedule and maximum attempts
• Whether events remain ordered
• Where permanently failing events go
• How partial side effects are handled

A dead-letter queue can preserve failed events for investigation.

Retries without backoff or limits can amplify an outage and increase cost.

Workflows coordinate multiple steps

A business process may need several functions:

1. Validate an order.
2. Reserve inventory.
3. Request payment.
4. Arrange shipment.
5. Notify the customer.

Chaining functions directly can hide state and recovery behavior.

A managed workflow engine records progress, waits, retries, branches, and applies compensating actions.

Durable orchestration is useful when the process outlives one invocation or must resume after failure.

Security and permissions

Each function should receive only the permissions it needs.

An image-resize function may read one upload location and write one thumbnail location. It does not need permission to delete every storage bucket.

Serverless security includes:

• Identity roles
• Secret management
• Dependency security
• Input validation
• Network access
• Event-source policy
• Log privacy

Short-lived execution does not make vulnerable code harmless.

Observability in distributed executions

There may be no stable server to inspect.

Useful observability includes:

• Invocation count
• Duration
• Cold starts
• Errors and retries
• Throttling
• Concurrency
• Queue age
• Cost
• Trace identifiers across events

Logs from hundreds of short executions must be centralized and correlated.

Monitoring only function errors misses delayed queues, duplicate outcomes, and failed downstream effects.

Cost characteristics

FaaS pricing often measures:

• Number of invocations
• Execution duration
• Allocated memory or CPU
• Network transfer
• Attached service usage

It can be economical for intermittent or bursty work because idle functions do not consume active compute charges.

For steady high-volume workloads, dedicated containers or VMs may cost less.

Hidden cost can come from logs, API gateways, databases, retries, and data transfer. Compare the complete workflow.

Vendor constraints and portability

Function code may use standard languages, but the surrounding system depends on provider-specific:

• Event formats
• Identity policies
• Deployment tools
• Limits
• Managed databases
• Workflow services

Abstraction can improve testability, but forcing every provider into the lowest common denominator may discard valuable capabilities.

Choose portability based on realistic migration risk and value, not an imaginary zero-dependency architecture.

When serverless fits

Good candidates include:

• Event processing
• Scheduled automation
• Webhooks
• Lightweight APIs
• File transformation
• Irregular workloads
• Workflow coordination

Less suitable cases may include:

• Long-running processes
• Consistently high utilization
• Very low predictable latency
• Specialized host access
• Large local state

Serverless is one operating model among several, not the destination of every application.

Knowledge check

1. Why does serverless not mean there are no servers?
2. Why must durable state live outside a function's local environment?
3. What causes a cold start?
4. How can automatic function scaling harm a database?
5. Why should event consumers be idempotent?

The one idea to remember

Serverless removes individual server provisioning and maintenance from the customer. It replaces those tasks with event, concurrency, limit, retry, permission, observability, and cost decisions that still require deliberate engineering.