Skip to main content

My Current Views on Serverless

1. Does Serverless Have a Future?​

Yes, but not much.​

Many cloud vendors attract new users and startups with the promise that Serverless dramatically reduces costs. But once your traffic increases even slightly, prices skyrocket - often higher than traditional VPS or ECS. Moreover, services built on Serverless can't be replicated on other cloud providers or locally, effectively locking users into that specific vendor.

So the entire Serverless cloud vendor business model is: attract users with low prices, let them build their Serverless services, then harvest them when traffic increases - unless users invest significant effort to migrate away from Serverless

Honestly, Serverless is only viable within cloud vendors. The inability to self-host stems from the lack of unified standards across vendors. While I know about knative and others, each vendor's Serverless implementation differs significantly. Almost all software depends on complete underlying hardware or virtual machine environments - how do you mount data directories in Serverless? You can only rely on the vendor's object storage, right? Great, another way to charge you. Plus, logging, monitoring, etc. all depend on the cloud vendor - if they don't provide it, you're stuck, or you have to export data via APIs. Unless Serverless first develops a runtime like Docker that can be installed anywhere, leveraging open-source ecosystems for mature solutions in certain areas, then we can discuss cost reduction.

Furthermore, Serverless isn't cheap.​

Cloud vendors package CPU-seconds, memory GB-seconds, and other metrics as pay-as-you-go pricing, but function cold start initialization time is billed separately, concurrent requests trigger multiple instances billed as independent containers, and when traffic spikes, your bill takes off. You can't prevent competitors from hitting your endpoints, and you can't prevent real users from suddenly surging before you've implemented a monetization strategy.

Cases like this are common:

2. Think Those Are the Only Drawbacks? Here's More:​

  • Log querying, distributed tracing, and other basic ops features are split into add-on services - choose between ops blindness or skyrocketing costs
  • Vendors claim you don't need to worry about servers, but memory-CPU bundling means adjusting memory configuration forces proportional CPU quota changes - upgrading means buying redundant memory
  • They attract users with S3 file upload triggers, DynamoDB stream changes, etc., but this deeply couples business logic with specific cloud services
  • IAM permission systems are welded to vendor account systems - migration requires complete permission reconfiguration
  • No vendor clearly documents container warm-up strategies or keep-alive mechanisms - they just say "under 100ms" or "7-8 seconds" - how do you know if your next function call will respond in 100ms or cold start in 10 seconds?
  • Your local environment differs from production Serverless, meaning some production issues can never be reproduced locally - how do you debug? OK, you say you'll set up knative locally - but then you need professional ops to maintain that k8s cluster, right?
  • Serverless requires making your services stateless, then using Redis and DB to simulate sessions. Wow! What a genius invention.
  • 15-minute execution limits (surprise! there's a CPU execution time limit too) - you must break complete logic into function pipelines, trading distributed transaction complexity for basic functionality
  • Files over 512MB require cloud storage connections, turning simple file I/O into network I/O - are you sure this won't increase latency?

3. After the Drawbacks, Let's Talk Advantages​

A PPT fundraising weapon - write "Full Serverless Architecture" in your BP and instantly boost your tech cred. Investors can't see the cost black hole behind it - technical debt is the next round's problem anyway.

4. Afterword​

I stumbled upon my old notes with Serverless-related content. You can click this link to read the original:

Serverless Computing: One Step Forward, Two Steps Back

Main Content of the Paper:​

This paper "Serverless Computing: One Step Forward, Two Steps Back" by Hellerstein et al. from UC Berkeley, published at CIDR 2019, systematically criticizes the limitations of mainstream Serverless platforms (mainly FaaS like AWS Lambda). It points out that while Serverless brings "one step forward" advantages, it also causes "two steps back" problems.

One Step Forward: Autoscaling​

Serverless (especially FaaS) simplifies cloud application deployment - developers just upload function code, and the platform runs it automatically when requests arrive.

  • Advantages:
    • Pay-per-use, no wasted idle resources
    • No manual server management
    • Suitable for simple parallel tasks and event-triggered workloads

Two Steps Back:​

    1. Low Data Processing Efficiency
    • FaaS is "bring data to code," not "send code to where data lives"
    • Each function execution must pull data from external sources, severely wasting I/O bandwidth and time
    • Network bandwidth is shared - worse with concurrent instances (e.g., 20 Lambdas average only 28Mbps bandwidth)
    1. Distributed Computing Hindered
    • Lambdas can't communicate directly - only through slow, expensive intermediate storage (like S3, DynamoDB) for state or message passing
    • Can't build effective distributed protocols (consensus, transactions, leader election, etc.) - only "embarrassingly parallel" workloads
    • Functions are stateless with short lifespans (e.g., AWS 15-minute limit) - can't cache state or maintain connections, severely limiting computation patterns

The authors believe: Current Serverless is more like a "lightweight shell that locks in developers," better suited for calling cloud vendors' own services rather than driving third-party software innovation.

Case Studies​

The paper demonstrates severity through three major cases:

  • Model Training
    • Training a simple neural network with Lambda is 21x slower and 7x more expensive than EC2
    • Reason: Each iteration must pull data from S3, and compute power is limited
  • Online Inference Service
    • Using Lambda + SQS for text "profanity" filtering
    • Even optimized, latency is 27-127x that of EC2, and costs are higher
  • Distributed Leader Election Protocol
    • Implementing Bully Leader Election with Lambda + DynamoDB
    • Each election round takes 16.7 seconds, supporting 1000 nodes costs $450/hour just for communication

The Paper's Core Conclusion:​

While Serverless (especially FaaS) simplifies cloud application development, its current design actually limits complex data processing, distributed system construction, and open-source innovation - contradicting cloud computing's original promise of "unlimited resources, unlimited innovation."

If you only want Serverless to run small amounts of business logic calling certain cloud services, it's sufficient. But if you want to build data-intensive, performance-sensitive, or novel computing model services, it falls far short.