Thoughts on Serverless Architecture

While reorganizing our team's deployment setup recently, I took another hard look at Serverless. This post records my understanding of the architecture: what problem it solves, how it works under the hood, and which scenarios it fits — and which ones call for caution.

Background

The trigger for this post was simple: we have a pile of low-frequency workloads — scheduled scripts, event callbacks, occasional file processing — each occupying a full or half server. The CPU sits idle most of the time, but the machine bills and the operations hours don't shrink one bit. This tension between "always-on resources, sparse workload" is exactly the problem Serverless sets out to solve.

Serverless has become a hot direction in cloud computing in recent years. Its core idea: developers don't need to worry about server deployment, operations, or scaling — they only focus on writing business logic.

To be clear, "serverless" doesn't mean there are no servers. It means the servers are invisible to the developer — they still exist, but the cloud vendor schedules and maintains them, and the abstraction the developer faces shifts from "machines" to "functions."

In a traditional architecture, launching a system usually means provisioning servers, setting up the environment, configuring networking, monitoring resources, and handling scaling — all of which cost extra operational effort. In a Serverless architecture, the cloud vendor manages all of that infrastructure; the developer just writes function code, deploys it, and it runs.

Serverless in the Cloud

Serverless is usually delivered as cloud functions (Function as a Service, FaaS) — for example Alibaba Cloud Function Compute (FC), AWS Lambda, or Tencent Cloud SCF. You upload your code, and when a request comes in, the platform runs the function automatically and bills you based on actual invocation count and execution time.

The execution model boils down to a single pipeline: event source triggers → platform schedules an instance → function executes → instance is reclaimed. The event source can be an HTTP request, a message queue, a file change in object storage, or a timer. When the platform receives an event, it loads and runs your function code in an isolated environment (typically a container or lightweight sandbox); after execution, the environment is kept warm for a short while for reuse, and reclaimed if it stays idle too long.

The biggest change this model brings: applications run on demand instead of permanently occupying server resources.

Billing changes accordingly. Traditional servers charge for "time held," traffic or not; FaaS charges for "actual execution," usually calculated from invocation count and execution time (multiplied by the allocated memory size). The sparser the workload, the bigger the cost advantage.

For example, in scenarios like:

• Scheduled task processing
• Webhook event handling
• Image processing
• Data transformation

None of these tasks need a continuously running server. With Serverless, a function spins up only when an event fires, saving substantial resource cost.

The Elasticity of Serverless

A key feature of Serverless is automatic scaling. When request volume suddenly spikes, the platform automatically launches more function instances to handle it; when traffic drops, resources are released. The whole process needs no human intervention and comes with distribution and fault tolerance built in.

The mechanism behind this elasticity is that the platform treats "one invocation" as the basic scheduling unit: each function instance typically handles only a limited number of requests at a time, and more requests mean more instances spun up horizontally, rather than piling pressure on a single instance. Because instances are stateless and can be created and destroyed at will, scaling and failover become routine platform-level operations that the application team no longer has to design.

This model is very friendly to small projects and startup teams. In the traditional model, even a low-traffic service requires a permanently maintained server; with Serverless's per-invocation billing, upfront deployment and operations costs drop dramatically. Alibaba Cloud Function Compute (FC), for instance, currently offers roughly 1 million free invocations per month, which is more than enough for many small applications.

That said, Serverless isn't perfect — there are trade-offs to weigh.

The most common one is vendor lock-in. In the Serverless model, functions tend to depend deeply on the cloud platform's services: OSS, RDS, message queues, logging systems, and so on. Once a system leans heavily on these capabilities, migrating to another cloud vendor usually means reworking the code to some degree. And the lock-in isn't just in code — trigger configuration, permission systems, and how logging and monitoring hook in all differ from vendor to vendor, so migration costs are more scattered than you'd expect.

Another classic issue is the cold start. Since Serverless functions usually run in containers or sandboxes, the platform reclaims resources when a function goes unused for a while. When a new request arrives, the runtime environment has to be spun up again, which introduces latency.

Cold start time is the sum of several stages: the platform scheduling and launching the runtime environment, loading the function code and its dependencies, and running the runtime and framework initialization. The heavier the runtime and the more dependencies, the slower this gets — which is why, for the same business logic, runtimes that need to boot a virtual machine like Java see noticeably worse cold starts than scripting languages.

In HTTP or event-triggered scenarios, the first invocation of a function can feel visibly slow. If your workload is highly latency-sensitive, you can buy reserved instances (pre-warmed resources) to reduce the cold-start impact — but that adds resource cost. Essentially you're trading "partial always-on" for latency, which puts you back on the traditional cost curve, so you need to run the numbers against your traffic pattern.

Overall, Serverless best fits:

• Event-driven applications
• Short-running tasks
• Services with erratic traffic
• Early-stage, small-scale projects

For systems that need to run continuously, demand high performance, or require heavily customized environments — large database services, long-running compute jobs — the traditional server architecture remains the better choice.

Pitfalls and Caveats

Building on the analysis above, if you're planning to move workloads to Serverless, think through a few things in advance:

1. Write functions to be stateless. Instances can be reclaimed at any time, so any state kept in local memory or on local disk is unreliable. Data that needs to persist should go into external storage or a cache service.

2. Mind the execution time limit. FaaS platforms generally cap the duration of a single execution. Long-running tasks either need to be split into a chain of functions or moved to a different compute model.

3. Assess how cold starts affect your call paths. Externally facing synchronous HTTP endpoints are latency-sensitive and feel cold starts the most; asynchronous and scheduled tasks barely notice them, so migrate those first.

4. Control how deep your cloud-service dependencies go. Avoiding cloud services entirely is unrealistic, but you can funnel calls to services like OSS and message queues through a dedicated adapter layer in your code, so the blast radius of a future migration is much smaller.

tip

A pragmatic approach: pick one or two non-critical asynchronous tasks (say, scheduled cleanup or image compression) as a pilot, get the full billing/logging/alerting loop working end to end, and only then decide whether to expand usage.

Wrapping Up

Serverless is not a full replacement for traditional architecture — it's a new compute model. Its core value: letting developers focus on the business itself rather than the infrastructure.

It turns "on-demand execution and automatic scaling" into platform capabilities, at the price of accepting cold starts, execution time limits, and some degree of vendor lock-in. Whether to adopt it depends on your traffic shape and latency requirements, not on how new or old the architecture is.

As cloud computing evolves, more and more platforms offer Serverless capabilities, and future system architectures may well converge toward a combined model of:

Serverless + microservices + containerization.