Azure Functions are often introduced as the simplest way to run code in Azure.

You write a function. Azure handles the rest.

For a while, that is true.

Then, at some point, Functions stop feeling serverless. They start feeling like infrastructure.

The Early Days Feel Magical

Early on, Azure Functions are hard to beat.

  • No servers to manage
  • Easy triggers
  • Automatic scaling
  • Minimal deployment overhead

They are especially attractive for:

  • background processing
  • event-driven workflows
  • small integrations
  • glue code between systems

In those early stages, the abstraction holds. You focus on behavior, not hosting.

That phase does not last forever.

The First Cracks Appear Quietly

The shift does not happen all at once.

It usually starts with small questions:

  • Why is this function cold starting so often?
  • Why did this spike in traffic slow everything down?
  • Why does this deployment behave differently in prod?
  • Where exactly is this running?

None of these are deal-breakers by themselves.

But together, they signal something important. You are starting to care about the platform again.

Cold Starts Were Not the Real Issue

Cold starts get blamed a lot, but they were not our biggest problem.

The real friction came from predictability.

We started caring about:

  • execution duration
  • concurrency behavior
  • retry semantics
  • timeout limits
  • dependency warmup
  • outbound networking behavior

At that point, Functions stopped being “just code.”

They became a runtime we had to understand.

Serverless Still Has Servers

Azure Functions are serverless in the ownership sense, not the behavior sense.

There are still:

  • workers
  • scaling thresholds
  • memory limits
  • execution constraints
  • regional behavior differences

You just do not see them until you need to.

And when you do need to see them, the abstraction can get in the way.

The Consumption plan makes this especially clear. You don’t pay for idle time, but you also don’t control when instances warm up or cool down. That’s fine for event-driven spikes. It’s painful for workloads that expect consistent response times.

The Moment Ownership Shifts

There is a clear moment when Functions stop feeling lightweight.

It is when someone asks: “Who owns this function in production?”

Now you need:

  • runbooks
  • alerts
  • scaling decisions
  • performance expectations
  • cost awareness

At that point, Functions are no longer just a developer convenience. They are part of your platform surface area.

When Functions Still Make Sense

None of this means Azure Functions are bad.

They worked very well for us when:

  • execution time was short
  • traffic was bursty but bounded
  • failure could be retried safely
  • latency was not critical
  • the logic was truly event-driven

In those cases, the abstraction held.

The problems showed up when we pushed Functions into long-running, stateful, or latency-sensitive roles.

We had one function that processed webhook events from third-party services. It ran for 200ms, handled retries gracefully, and scaled from 0 to 50 instances without issue. That’s exactly what Functions are designed for.

We had another that tried to orchestrate complex workflows with multiple downstream API calls. It hit timeout limits, struggled with cold starts, and became harder to reason about than a simple background job would have been.

The Quiet Tradeoff

Functions trade control for convenience.

That tradeoff is reasonable early on. It becomes expensive later if you do not recognize it.

The danger is not using Functions. The danger is assuming they stay simple forever.

Knowing When to Move On

The right question is not: “Are Azure Functions good or bad?”

The better question is: “Is this workload still benefiting from the abstraction?”

When the answer becomes no, that is not failure. It is maturity.

Sometimes the best decision is to move the workload to:

Not because Functions failed. Because your needs changed.

Final Thought

Serverless is not a destination. It is a phase.

Azure Functions feel serverless when they remove decisions. They stop feeling serverless when those decisions come back.

Recognizing that moment early is a platform skill. Ignoring it is how simple systems become fragile ones.

Using Azure Functions in production? The abstraction is great until it isn’t. Know when to hold, know when to fold.