Every Trip Has a Maximum Length

Opening Scene

A taxi is well suited to getting across town, or even to a nearby city, but it’s genuinely the wrong choice for driving across an entire continent — at some point, a different kind of transportation becomes necessary. Serverless functions carry an equivalent, explicit boundary: a maximum execution time, beyond which the workload simply isn’t a fit for that particular service.

In Plain English

Most serverless function platforms impose a maximum execution time limit — commonly ranging from a few minutes to around fifteen minutes, depending on the provider — beyond which a running function is forcibly terminated. This isn’t an arbitrary restriction; it reflects the underlying design assumption that serverless functions are meant for short, bounded units of work, not long-running processes.

The Old Way

Before execution time limits were well understood as a deliberate design constraint, workloads were sometimes deployed to serverless functions without accounting for this boundary:

• Teams sometimes attempted to run genuinely long-running processes on serverless function platforms, without accounting for the maximum execution time limit.
• There wasn’t yet a well-established practice of decomposing longer workflows explicitly into shorter, chained function invocations that each respect the time limit.
• Execution time limits were sometimes discovered only when a workload was unexpectedly terminated in production, rather than accounted for during design.

Deploying long-running workloads without accounting for execution time limits, discovered only after unexpected termination, is what deliberate workload design against these limits directly addresses.

What’s Changing (and Why AI Is the Reason)

1. Practitioners increasingly design workloads explicitly around execution time limits from the start, either by choosing serverless containers for longer-running work or by decomposing work into shorter, chained steps.
2. This connects directly to the orchestration patterns covered in Article 16, which formally chain multiple shorter serverless steps into a longer overall workflow.
3. As AI inference calls, particularly for larger models, sometimes approach or exceed typical function time limits, this constraint has become an especially important design consideration for serverless AI serving specifically.

The Metaphor, Fully Extended

The Taxi Rider	Serverless Data Architecture Concept
A taxi well suited to getting across town, not across a continent	Serverless functions well suited to short work, not long-running processes
An explicit boundary on how far a single trip can reasonably go	An explicit maximum execution time limit on a single function invocation
Choosing a different mode of transport for a longer journey	Choosing serverless containers or chained functions for longer workloads
Not an arbitrary restriction, but a reflection of what the vehicle is for	Not an arbitrary restriction, but a reflection of what the service is designed for

Quick Recap

• Serverless functions impose maximum execution time limits, reflecting their design for short, bounded work.
• Workloads exceeding this limit need to be decomposed or moved to a different serverless service type.
• Designing around this constraint from the start avoids unexpected production failures.
• Larger AI model inference latency makes this constraint an especially important design consideration.

Where This Fits in the Series

Article 11 covered the execution time boundary serverless functions impose. Article 12 turns to a related constraint: where exactly your luggage goes between trips.