Server
Serverless
Serverless is a way of running code where the platform starts it on demand and bills per invocation or per millisecond, so nothing sits running when nobody asks. You still have servers. You just do not manage or pay for the idle ones.
How it is measured
Look at the billing and runtime fields: invocations, duration in milliseconds, memory configured, and concurrency used. Cost is roughly invocations times duration times memory, which makes slow code directly more expensive.
Check limits too: maximum execution time (often 10 seconds to 15 minutes), payload size, and the number of concurrent executions the account allows.
Worked example
A form-handling endpoint for a brochure site receives about 400 submissions a month. On a 5 dollar VPS it would sit idle 99.9 percent of the time. As a serverless function it runs 400 times at 180 ms each and the bill rounds to under a cent.
A report-generation job on the same account runs 9 minutes and exceeds the platform's limit, so it moves to a queue with a long-running container. Serverless fit one job and not the other.
How it differs
Serverless starts compute when a request comes and may stop it afterwards. Always-on keeps a process resident and billed all day. Serverless excludes idle cost and carries a cold start risk. Always-on excludes boot delay and costs money at 3 a.m. The right answer depends on traffic shape, not on fashion.
Common errors
Assuming it is always cheaper when traffic is steady and heavy. Ignoring cold start on user-facing paths. Opening a database connection per invocation and exhausting the database. Hitting the time limit with a long task. Forgetting local state vanishes between calls.
In practice
Move bursty, short, stateless jobs to serverless first: webhooks, image resize, form handlers. Keep steady high-traffic or long-running parts on regular servers, and compare a month of both bills.