What is serverless computing?
A plain-English guide — with a real engine you can poke
no jargon · one worked example · 8 minute read
The core idea
Traditional hosting means you run a server: pick a machine, install a runtime, patch it at 3am, pay for it while it sleeps. If your app suddenly gets popular, you scramble to add capacity. If nobody uses it, you still pay.
Serverless flips the responsibilities. You write what should happen; someone else runs the thing that makes it happen. The name is misleading — there are absolutely servers — but they are not your problem:
No servers to provision or manage. Code runs when events happen. You pay per use, not per idle hour. Scaling is someone else's job.
That's it. Everything else about serverless follows from those three properties.
The three pillars
Instead of a program that's always on, you define reactions: when this happens, do that. An HTTP request arrives → run this function. A database row changes → send a notification. A schedule fires → generate a report. Between events, nothing runs and nothing costs anything.
Your functions need somewhere to put data. Serverless platforms give you managed building blocks — databases, file storage, authentication, queues — consumed over APIs. You never see the machines running them.
Cost tracks usage: number of requests, execution time, bytes stored. A hobby project with 40 visitors can cost literally zero; the same code handles a traffic spike without you touching anything.
What people actually mean by "serverless"
| Flavor | You write | Examples |
|---|---|---|
| FaaS (functions) | Single functions triggered by events | AWS Lambda, Cloudflare Workers |
| BaaS (backend-as-a-service) | A frontend; the platform IS your backend | Firebase, Supabase |
| Containers/serverless hosts | A whole app image | Cloud Run, Fly.io |
Most real projects mix all three. The pain shows up in the gaps: gluing a Lambda to a database to auth to storage means configuring four services, IAM policies, CORS… for what is often a tiny app.
A worked example: one engine that does all of it
The PilserLabs serverless engine is a compact demonstration of every pillar above — with a twist we'll get to. It's a single Rust process that gives each application (board) a complete backend over HTTP:
# create an app ("board") — that's the whole deploy step
curl -X POST $ENGINE/mcp -d '{"method":"tools/call","params":{
"name":"apps.create","arguments":{"title":"My App"}}}'
# → {"result":{"board":"b_7z5lr8zaurkd0000"}} ← this ID *is* your app
# a validated database table, on demand
curl -X POST $ENGINE/api/srv/$B/tables/todos \
-d '{"schema":{"type":"object","required":["title"]}}'
# insert data (validated server-side)
curl -X POST $ENGINE/api/srv/$B/tables/todos/submit \
-d '{"payload":{"title":"learn serverless"}}'No provisioning step. No connection strings. No migrations. Each board is an isolated tenant — its own tables, users, files, automations — inside one process. One engine hosts many apps the way one apartment building hosts many homes.
The pillar checklist
| Pillar | Classic serverless | This engine |
|---|---|---|
| Event-driven | Lambda triggers | recipes + webhooks + cron: "on record created, call this URL" |
| Managed state | DynamoDB / Firestore / … | document store, full-text search, aggregates, files, auth — per board |
| Per-use scaling | platform-managed fleet | single portable binary; scales by hosting more boards per process, or embedding the library in your own service |
The twist: your backend engineer is an AI agent
The unusual property of this engine: every operation is also exposed as an MCP tool — a standard protocol AI coding agents speak natively. That changes who can build software:
apps.create,
tables.create, records.bulk, auth.signup,
recipes.add — wiring schema, permissions, automation.This matters most for people without years of backend experience: validation rules, role-based access, email flows, scheduled jobs — the parts that usually require an engineer — become tool calls. The platform enforces correctness (server-side schema validation, scoped API keys, signed webhooks) so the agent can move fast without creating security holes.
The same engine is also a Rust library crate (serverless-engine-rs):
if your product needs "database + auth + files + automations" embedded inside a bigger
application, it's a dependency, not a vendor relationship.
Honest tradeoffs
- Cold starts / warm paths: managed FaaS has per-invocation latency; self-hosted engines keep a warm process but you operate it.
- Vendor gravity: FaaS+BaaS stacks tie you to one cloud's proprietary services. Portable engines (like the one here — swap the storage layer by config) reduce that lock-in.
- Not for everything: long-running compute, GPU workloads, and stateful protocols still belong on classic infrastructure.
Try it right now
The engine behind pilserlabs.com serves this page. Explore the live handbook built on it — architecture notes, internals, and a 15-minute build guide:
Part of the PilserLabs lab — see also Agent Orchestration and Distributed Storage.