Serverless: How it Changed Deployment (Forever)

There’s a before and after in the history of deployment. The line isn’t as sharp as a product launch, but if I had to point to a breaking point, I’d say around 2015 — when AWS Lambda became publicly available and changed the coordinates of the problem.

Before then, deploying an application meant managing the infrastructure that hosted it. After, it became a code problem.

The world before: servers, processes, and a lot of anxiety

Traditional deployment — whether on a VPS, bare metal server, or EC2 instance — required thinking about layers that had nothing to do with the application itself:

• How much RAM does the server have? Can it handle the traffic peak?
• Is the process still alive? Do I need a supervisor (pm2, systemd, supervisord)?
• How do I manage downtime during deployment?
• If it scales, how do I load balance?

The list was long. And even with Docker, which greatly simplified portability, the problem of where and how to run that container remained entirely yours.

A zero-downtime deployment on a single VPS required manual nginx configuration, a rolling process, health checks — stuff that took half a day and that you had to document so you wouldn’t forget it.

Serverless: The shift in perspective

The serverless model flips the question. There is no server to manage — there is a function to execute.

// A Lambda function in TypeScript
export const handler = async (event: APIGatewayProxyEvent) => {
  return {
    statusCode: 200,
    body: JSON.stringify({ message: "ok" }),
  };
};

This function:

• Has no process running 24/7
• Occupies no RAM when not called
• Automatically scales from 0 to thousands of parallel instances
• Costs exactly what is used (the famous pay-per-invocation)

Deploying this function is a single command:

# With SST (modern serverless framework for AWS)
npx sst deploy --stage production

Done. The infrastructure is built and managed by the cloud provider. The team doesn’t need a dedicated DevOps person to keep the servers up.

Real impact on the deployment process

1. Frequent deployments become normal

When you don’t have to deal with downtime, restarting processes, and syncing configurations, the psychological cost of a deployment drops drastically.

With Vercel, Netlify, or Cloudflare Workers, every push to main is a deployment. It’s not a complex pipeline — it’s the default. I’ve worked on projects where we deployed 10-15 times a day without thinking twice.

2. Preview environments for free

A paradigm shift that is often underestimated: every PR automatically gets a preview environment with its own URL.

PR #42 → https://pr-42.my-project.vercel.app

Before, testing a feature in a real environment required a dedicated staging server — infrastructure to pay for and maintain. Today, it’s included in the platform.

3. Rollback is just going back one commit

In traditional deployments, a rollback meant re-deploying the previous version, managing database migrations in reverse, and hoping everything went back to exactly as it was. A high-risk operation.

With serverless and immutable deployments, every deployment is a snapshot. Going back to the previous version is literally a click or a command away:

vercel rollback

4. Reduced attack surface

With persistent servers, a compromised process stays compromised until it’s restarted. Serverless functions are stateless by design: every invocation starts from scratch, no data persists in memory between one call and another.

It’s not perfect security, but the model structurally reduces certain classes of vulnerabilities.

The limits nobody mentions in tutorials

Serverless isn’t the answer to everything. There are real trade-offs.

Cold start. A function that hasn’t been invoked in a while takes a few hundred milliseconds to start up. For Lambda with heavy runtimes (Java, .NET) it can take seconds. Not suitable for everything.

State. No state in memory. Anything that must persist between invocations goes to an external database or key-value store. Architecturally cleaner, but adds latency and dependencies.

Local debugging. Emulating a serverless environment locally has improved a lot (SST, Serverless Framework, Wrangler for Workers), but it remains more complex than a normal npm run dev.

Vendor lock-in. A Lambda with 50 AWS services around it won’t be migrated in a week. Choosing serverless means choosing an ecosystem.

Where we are today

Serverless has won for most standard web use cases — APIs, webhooks, static sites with edge functions, background jobs. The operational complexity that used to require dedicated roles (sysadmin, DevOps) has been absorbed by cloud providers.

Today’s developer pushes code. Infrastructure is a configuration detail, not a full-time job.

It’s a shift in roles more than technology. And for those who have lived through both worlds, the difference is felt every day.