The first time someone explained serverless computing to me, I interrupted them.

“So where does the code run?”

“On servers.”

This felt like a naming problem.

It still is, slightly. Serverless does not remove servers. It removes a particular relationship with them. You write a piece of application logic, deploy it to a cloud platform, and the provider handles much of the infrastructure required to run it.

No operating-system patching. No permanently running virtual machine for a tiny task. No guessing how many servers you will need before anyone uses the feature.

That can be wonderfully convenient.

It can also create a bill made of line items nobody remembers designing.

Paying for waiting is annoying

Consider a small internal tool that processes uploaded receipts.

Maybe people upload twenty files during the day. The actual processing takes a few seconds each time. Running a full virtual server twenty-four hours a day just to wait for those uploads feels wasteful.

A serverless function can wake when a file arrives, perform the work and stop.

You pay based more closely on actual execution rather than keeping a machine alive in case something happens.

This is where serverless makes immediate sense.

Event-driven work is everywhere: resize an image after upload, send a confirmation email, validate a form, process a queue message, generate a thumbnail.

The application reacts when something occurs.

Then it goes quiet.

Infrastructure does not disappear

The cloud provider handles a lot.

That is not the same as handling everything.

You still choose runtime settings, permissions, memory limits, network access and deployment configuration. The code still needs monitoring. Failures still happen. External services still time out.

Serverless removes some operational responsibility and moves other responsibility upward.

Instead of asking, “Is the server patched?” you may ask, “Why did this function retry six thousand times?”

Progress.

Software always finds a new way to keep people employed.

Scaling feels almost unfair when it works

A traditional application often requires capacity planning.

How much traffic will arrive? How many servers should run? What happens if a marketing campaign suddenly works much better than expected?

Serverless platforms can create more instances of a function as requests increase. For short, independent tasks, this can absorb traffic spikes without somebody manually provisioning machines.

That is incredibly useful for unpredictable workloads.

A side project can handle almost no traffic on Monday and a viral burst on Tuesday without the owner spending the weekend designing a scaling system.

The trade-off is that automatic scaling will happily scale bad behaviour too.

If a bug triggers the function repeatedly, the platform may execute the mistake very efficiently.

Set budgets and alerts.

Cloud automation does not know you are surprised.

Cold starts are real, but context matters

Serverless functions do not always stay running.

When a request arrives after inactivity, the platform may need to start a fresh execution environment. That delay is called a cold start.

For many background jobs, the extra delay barely matters. A thumbnail appearing half a second later is not a crisis.

For latency-sensitive APIs or interactive applications, it may matter a lot.

This is why “serverless is slow” and “cold starts do not matter” are both bad universal statements.

Architecture depends on the workload.

Some platforms offer ways to keep capacity warm or reduce startup delay, usually with cost attached. Again, every advantage sends an invoice.

Databases complicate the simple story

Functions are easy to scale because they are often stateless.

Databases are not.

If a function suddenly scales from ten instances to thousands, all of them may try to open database connections. A database that comfortably handled the old workload can collapse under the new connection storm.

This is one of the first moments where serverless stops feeling like a simple hosting trick and starts feeling like system design.

Developers use connection pools, managed data services, queues and other patterns to keep the backend stable.

The function may be serverless.

The application still has bottlenecks.

There is always a slowest thing somewhere.

Debugging becomes more distributed

A simple application on one server is easy to picture.

Request arrives. Code runs. Log appears on the machine.

Serverless systems can spread one business action across multiple functions, queues, storage events and managed services. When something fails, you may need to trace a request through several components.

This is manageable with good observability.

Without it, debugging feels like reconstructing a group chat after half the messages were deleted.

Use structured logs. Add request identifiers. Monitor failures and retries. Understand which events can occur more than once.

The cloud platform handles the servers.

It does not explain your own architecture back to you unless you build the visibility.

Vendor lock-in is not imaginary

Serverless platforms are convenient partly because they offer many proprietary services that fit together nicely.

Triggers, databases, identity systems, queues, monitoring, deployment tools.

The deeper you use those features, the harder moving elsewhere may become.

People sometimes respond by building elaborate abstraction layers from day one so the application can theoretically move between clouds without changes.

That can create more complexity than the lock-in it is avoiding.

I prefer being deliberate.

If the application is small and the platform saves months of work, some dependence may be a perfectly rational trade. If you are building critical infrastructure expected to live for ten years, portability deserves more thought.

Lock-in is a cost.

So is avoiding every useful platform feature because a future migration might happen.

Long-running work may belong somewhere else

Serverless functions are not ideal for every task.

Long video processing jobs, continuously running services, specialised networking or software requiring a particular operating environment may fit containers or virtual machines better.

The worst architecture is often the one built around ideology.

“We are serverless” should not be a company identity.

Use functions for the parts that benefit from event-driven scaling and managed execution. Use other computing models where they make more sense.

Modern systems can mix them happily.

No cloud police arrive.

The best server is sometimes one you never think about

Serverless became popular because infrastructure work can distract from product work.

A small team building an appointment system should not need to become expert operating-system administrators just to send reminder emails.

Let the platform handle the boring machinery where it can.

But keep enough understanding to know what you are delegating. Permissions, cost, failure modes and data still belong to you.

There are servers underneath.

The useful part is that, for a certain class of problem, you can spend remarkably little time caring which ones.