Serverless computing was sold on a simple idea: developers should be able to deploy code without thinking about machines. Instead of provisioning virtual servers or planning capacity, a developer can upload a function and let the platform decide where and when it runs.
That abstraction is real. But the infrastructure work did not disappear. It moved down the stack.
A 2026 review in Machine Learning with Applications describes serverless as abstracting resource provisioning, configuration, and auto-scaling while executing applications as event-driven functions on managed infrastructure. The same review identifies cold-start overhead, throughput and cost-effectiveness as persistent performance concerns.
That tension defines serverless today: the developer sees less infrastructure while the platform manages more of it automatically.
Cold starts reveal what the abstraction is hiding
When a function has no warm execution environment available, the platform may need to allocate resources, initialize a runtime, load dependencies, configure networking and start user code before the request can run.
A September 2026 systematic review of 80 high-quality studies says serverless platforms still face cold start latency, workload diversity, and complex resource scheduling. Across 149 performance-metric mentions, latency accounted for 31%, followed by cost at 24% and execution time at 15%.
Those numbers matter because short-lived functions can spend a meaningful share of total response time simply becoming ready.
Production research shows the problem is not solved. A 2025 USENIX OSDI study of Ant Group’s serverless platform found that, even after prior optimization techniques were incorporated, cold starts still ranged from hundreds of milliseconds to several seconds. Researchers traced delays to control-path interactions, resource contention under concurrency and user-code initialization.
Their AFaaS system reduced startup latency to the millisecond level, but that required deeper changes to runtime and resource management. The function became easier to invoke because the engineering underneath it became more sophisticated.
Autoscaling is a scheduling problem in disguise
Serverless platforms are often described as automatically scaling from zero to demand. That phrase hides a difficult forecasting and placement problem.
A provider must decide when to keep environments warm, when to reclaim them, where functions should run and how many resources to reserve. Too many warm instances waste capacity. Too few create cold starts.
Microsoft researchers studying the entire Azure Functions production workload found that most functions were invoked very infrequently while invocation frequency varied across eight orders of magnitude. They described FaaS as shifting allocation and provisioning complexity to the cloud provider, which must create the “illusion of always-available resources” while controlling resource cost.
That is not the elimination of capacity planning. It is capacity planning automated by the platform at enormous scale.
The September 2026 review makes the trade-off broader by evaluating latency, execution time, throughput, resource utilization, energy consumption and cost-performance together. Serverless scheduling is therefore multi-objective: improving one metric can worsen another.
State makes simple functions complicated again
Function-as-a-Service works most naturally when functions are short-lived and stateless. Real applications rarely remain that simple.
They depend on databases, queues, caches, authentication state and other services. Once state enters the system, the platform must coordinate data movement and consistency while preserving elasticity.
The June 2026 review identifies stateful serverless execution as an underexplored research gap. A September 2026 review of serverless functions across cloud-edge environments describes state management, workflow coordination, placement, migration, trust and data locality as interacting orchestration problems.
Putting a function close to a user does not guarantee low latency if every invocation still depends on distant state.
Serverless therefore does not remove distributed-systems reasoning. It moves parts of that work into managed platforms while leaving architects responsible for understanding where data lives, what happens during failures and how many network boundaries a workflow crosses.
Efficiency has more than one definition
Serverless is attractive partly because customers can pay for execution instead of permanently provisioned capacity. Yet customer cost efficiency does not automatically mean infrastructure efficiency.
The 2026 cloud-edge review notes that warm pools, repeated image distribution, inefficient data transfer and redundant replicas can create hidden sustainability costs. It also finds that aggressive pre-warming can reduce cold starts while increasing energy consumed by idle resources.
The lowest-latency configuration may therefore not be the lowest-cost or lowest-energy configuration.
The September systematic review similarly finds optimization work spanning dynamic scaling, heuristic and greedy algorithms, cost-aware provisioning and AI-driven approaches because serverless workloads are heterogeneous and rapidly changing.
A platform must optimize a moving set of service-level objectives rather than one number.
Operating systems are still doing the hard work
The clearest evidence that serverless did not eliminate infrastructure is how much systems research continues underneath it.
A 2026 USENIX OSDI paper says many serverless invocations still experience cold-start delays of tens to hundreds of milliseconds, sometimes exceeding the function’s actual execution time. Its Spice system redesigned process-snapshot restoration and operating-system support.
For representative Java, Python and Node.js functions, Spice reduced end-to-end latency by 7.5× over process-based systems and 9.5× over VM-based systems.
That is deep operating-systems engineering performed so the application developer experiences something simple.
Serverless transfers responsibility rather than eliminating it
The lesson for founders and engineers is not that serverless failed. Its value comes from transferring responsibility.
Developers give up direct control over machines in exchange for elasticity, managed scheduling and usage-based execution. The provider absorbs much of the operational complexity, but applications still inherit the platform’s latency, pricing, limits, data model and architectural trade-offs.
That makes architecture selection important. Serverless can be an excellent fit for event-driven workloads, variable traffic and teams that value operational simplicity. It can be less comfortable when predictable tail latency, complex state, specialized infrastructure or tightly controlled costs dominate the design.
The useful question is not whether serverless removes infrastructure.
It is whether the infrastructure problems it hides are the ones a team wants someone else to solve.
Serverless succeeded because it made servers less visible. The engineering underneath them only became more important.
