Should You Actually Adopt Serverless for New Projects?

You’re starting a new project. Blank repo, clean architecture, no legacy baggage. Someone inevitably says, “Why not just go serverless?”

It sounds like the obvious modern choice. No infrastructure to manage, automatic scaling, pay only for what you use. In theory, it’s the closest thing we have to “infinite backend.”

But here’s the uncomfortable truth: serverless is not a default. It’s a tradeoff. And like most architectural decisions, it quietly shifts complexity rather than eliminating it.

Let’s break this down like practitioners, not marketers.

What Experts and Practitioners Are Actually Seeing

We spent time reviewing how teams at different stages are using serverless today, from startups to platform teams inside larger orgs. The consensus is not hype; it’s conditional.

Kelsey Hightower, former Google Cloud architect, has repeatedly emphasized that serverless shines when you focus on business logic, not infrastructure. His framing is simple: if managing servers is not your differentiator, stop doing it.

But Charity Majors, CTO at Honeycomb, has pushed back on blind adoption. She points out that serverless systems can become harder to debug and observe, especially when you have distributed event-driven flows with no clear request lifecycle.

Then there’s Werner Vogels, CTO at AWS, who often frames serverless as an evolution, not a replacement. His view is that the best systems mix paradigms, using serverless where it fits and not forcing it everywhere.

Synthesis: Serverless is powerful for reducing operational burden, but it introduces new complexity in observability, architecture, and cost predictability. It rewards teams that understand distributed systems, not teams trying to avoid them.

What “Serverless” Actually Means in Practice

At a high level, serverless means you don’t manage servers. But that definition hides the real shift.

You are trading:

• Infrastructure complexity → Application complexity
• Static systems → Event-driven systems
• Predictable costs → Usage-based variability

Instead of provisioning instances, you compose:

• Functions (AWS Lambda, Cloud Functions)
• Managed services (DynamoDB, Firebase, SQS)
• Event triggers (HTTP, queues, streams)

The result is a system where execution is ephemeral, state is externalized, and everything is loosely coupled.

This is powerful. It is also harder to reason about.

Where Serverless Actually Wins (And It’s Not Everywhere)

Serverless is not universally better. It’s disproportionately effective in a few specific scenarios.

1. Spiky or Unpredictable Traffic

If your workload goes from 0 to 10,000 requests in minutes, serverless handles it without pre-provisioning.

Example:

• A product launch landing page
• A webhook processor for external events

With EC2 or Kubernetes, you’d overprovision or risk latency. With serverless, scaling is automatic.

2. Event-Driven Workflows

Serverless excels when your system reacts to events rather than serving long-lived sessions.

Think:

• File uploads triggering processing pipelines
• Queue-based background jobs
• Data ingestion systems

This aligns naturally with function execution models.

3. Fast MVPs and Small Teams

If you have 2–5 engineers and need to ship quickly, serverless removes entire categories of work:

• No cluster management
• No autoscaling configs
• No patching infrastructure

You can focus entirely on business logic.

4. Low Baseline Traffic

Here’s a quick back-of-the-envelope example:

• Traditional server: $40/month minimum (always running)
• Serverless: $0.20 per million requests (Lambda pricing ballpark)

If you get 500k requests/month:

• Serverless costs $0.10
• Server cost = $40

That delta matters early.

Where Serverless Quietly Breaks Down

This is where most teams get surprised.

Cold Starts and Latency Sensitivity

Serverless functions are not always “warm.”

If your API requires sub-100ms latency, cold starts can hurt user experience, especially in languages like Java or .NET.

Observability Becomes Harder

In a monolith, a request flows through one system.

In serverless:

• One request might trigger 5 functions
• Logs are scattered
• Tracing requires additional tooling

Debugging becomes a distributed systems problem.

Vendor Lock-In Is Real

When you build deeply into AWS Lambda + DynamoDB + EventBridge, you are not just using cloud, you are coupling to a platform.

Rewriting later is expensive.

Cost Can Flip at Scale

That earlier example reverses quickly.

At scale:

• Millions of executions
• High memory allocations
• Long-running functions

Serverless can become more expensive than reserved infrastructure.

This is similar to SEO tradeoffs, where initial gains from tactics can plateau without deeper investment in fundamentals like authority and structure.

How to Decide (A Practical Framework)

Here’s how I’ve seen teams make good decisions in practice.

Step 1: Map Your Workload Shape

Ask:

• Is traffic predictable or bursty?
• Are tasks short-lived or long-running?

Serverless favors:

• Bursty traffic
• Short execution times (under a few seconds)

Step 2: Evaluate Team Maturity

Serverless reduces ops work but increases system design complexity.

If your team struggles with:

• Distributed tracing
• Event-driven design
• Debugging async flows

You may just be moving the pain.

Step 3: Identify Your Core Constraint

Be honest about what matters most:

• Speed to market → serverless wins
• Cost at scale → depends
• Control and flexibility → traditional infra wins

Step 4: Start Narrow, Not Global

Do not go “all serverless.”

Instead:

• Use serverless for background jobs
• Keep your core API stable (container or monolith)

This hybrid model is what most mature teams converge on.

A Realistic Architecture Pattern That Works

Here’s a pattern I’ve seen repeatedly succeed:

• Core API: containerized (ECS, Kubernetes)
• Async jobs: serverless functions
• Event processing: queues + functions
• Data layer: managed services

Why this works:

• You keep a predictable performance for user-facing requests
• You use serverless where elasticity matters

It mirrors how internal linking strengthens key pages while distributing support across related content in SEO systems. The core stays stable, the edges stay flexible.

FAQ

Is serverless good for startups?

Yes, especially early. It reduces operational overhead and lets you move fast. Just avoid deep lock-in until your architecture stabilizes.

Can serverless replace Kubernetes?

Not really. They solve different problems. Serverless is execution-focused; Kubernetes is infrastructure orchestration.

What about long-running tasks?

Serverless struggles here due to execution limits. You’ll need containers or batch systems.

Is serverless cheaper?

Sometimes. It’s cheaper at low usage, but can become more expensive at scale depending on execution patterns.

Honest Takeaway

Serverless is not a yes or no decision. It’s a placement decision.

Use it where elasticity, speed, and event-driven design matter. Avoid it where you need tight control, predictable performance, or long-running processes.

If you remember one thing, make it this: serverless does not remove complexity, it relocates it.

Teams that win with serverless are not avoiding distributed systems. They are embracing them, intentionally.

And if your team is not ready for that shift yet, forcing serverless will slow you down, not speed you up.

Kirstie Sands

Journalist at DevX

Kirstie a technology news reporter at DevX. She reports on emerging technologies and startups waiting to skyrocket.