Serverless versus server-based execution

01Servers still exist in both models

A thumbnail job reads an uploaded image, produces a smaller image and saves the result. Someone must arrange where the code runs.

1. Serverless execution: a provider starts or reuses execution environments when requests or events arrive, within configured limits. One run is an invocation. Your team supplies code and configuration rather than directly operating every machine.
2. Server-based fleet: your team chooses machine sizes, keeps worker processes running and controls their scheduling, replacement and scaling. Managed server platforms share these tasks in different ways.

Physical servers exist in both models. Serverless changes operating responsibilities; it does not remove the team's responsibility for permissions, saved jobs, retries, data protection and recovery. A server fleet can also scale automatically.

Compare the actual service limits and workload. “Serverless scales” does not establish that the database can handle the resulting connections, or that an interrupted job can recover.

02Elastic compute can expose fixed dependencies

Follow one thumbnail job in either model:

1. Save accepted work before running it. A durable queue or job table records the image reference, task and stable job identity so a worker crash does not erase the request.
2. Start a worker within configured capacity. A provider may prepare an environment; a fleet may assign an existing process. Initialization is a cold start and can occur after failure in either model.
3. Read the image and produce the thumbnail. Limit simultaneous database or storage work separately from the number of running jobs.
4. Save the result under that job's identity. Look up the job’s saved completion record. Reuse an output only when that record refers to a fully saved thumbnail for the same input image version and requested size; a partial file or a thumbnail from another edit is not completion.
5. Acknowledge completion only when the output is recoverable. A crash before acknowledgment can cause redelivery; the new worker must inspect the saved result.

Reusing parsed configuration or a connection in a warm environment is an optimization. Correctness must not depend on that environment surviving.

03Worked comparison: irregular image processing

Assume 200 thumbnail jobs/s and mean job duration 0.5 s under stable load.

1. Calculate concurrent work: 200 × 0.5 = 100 jobs on average.
2. The database slows and mean duration becomes 2 s. The same rate would require about 400 concurrent jobs, even without more arrivals.
3. The database safely supports 150 connections. Letting every job open its own connection can overwhelm it. Share a fixed connection pool or limit the number of jobs doing the database stage at once.
4. Keep excess jobs saved while they wait. Measure the oldest job's age. More compute environments do not supply more database capacity.
5. A worker saves a thumbnail and crashes before queue acknowledgment. A later attempt uses the same job identity to verify or return the saved thumbnail. It must not assume the first attempt did nothing.

For cost, assume 50,000 jobs/day at 0.5 s each: 25,000 useful execution-seconds/day, before startup and retries. This is workload, not a complete bill.

• A fleet bill depends on reserved machine hours and how much of them are used.
• A managed-execution bill depends on actual allocation and provider pricing dimensions.
• Both comparisons need transfer, storage, redundancy, startup, retries and team operating effort.

Measure these quantities rather than inserting a universal price or cold-start delay.

04Choose boundaries before a platform

Choose using the job's actual needs:

• Bursty bounded jobs can fit managed event execution and reduce idle machine management.
• Consistently busy jobs, special hardware or long-running processes may justify a fleet with more direct resource control.
• Mixed workloads can combine them, such as servers for live connections and managed background image jobs.
• Scale-down must stop new work and finish active jobs or leave them recoverable for redelivery. Never acknowledge the only result in memory and then terminate it.
• Monitoring should include startup time, job age, repeated attempts, worker saturation and dependency connections.

State arrival pattern, duration, completion target, simultaneous jobs and downstream capacity before choosing the platform. The successful design completes saved work reliably at acceptable total cost; fast compute expansion alone is not success.