---
term: 'Serverless Architecture'
seoTitle: 'What is Serverless Architecture? Complete Guide'
headline: 'What is Serverless Architecture?'
slug: serverless-architecture
category: cloud-architecture
shortDefinition: 'Serverless architecture is a cloud execution model where the provider runs your code on demand, so you never provision or manage servers.'
relatedTerms:
  - baas-vs-custom-backend
  - cloud-code-serverless-functions
  - serverless-cold-starts
  - edge-computing-edge-functions
  - no-ops-development
contrastsWith:
  - microservices-vs-monolith
faq:
  - question: 'Does serverless mean there are no servers?'
    answer: 'No — servers still run your code. "Serverless" means the servers are invisible to you: the cloud provider owns, provisions, patches, and scales them. You deploy functions and the platform decides where and when they execute. From the developer''s perspective there is nothing to size, restart, or maintain.'
  - question: 'Is serverless cheaper than traditional servers?'
    answer: 'For spiky or low-volume workloads, usually yes: you pay per request and per GB-second of execution, and the bill drops to zero while nothing runs. For sustained high-volume traffic, an always-on container or reserved instance is often cheaper, because per-invocation pricing at millions of steady requests can exceed a flat server fee. Model your real traffic curve before choosing.'
  - question: 'What are the disadvantages of serverless architecture?'
    answer: 'The main trade-offs are cold starts (typically under 100 ms up to over 1 second on the first invocation of an idle function), execution time limits, harder local debugging and observability, and potential vendor lock-in if your functions use provider-specific APIs. Platforms built on open source, like Back4app Cloud Code, mitigate the lock-in risk because you can self-host the same stack.'
  - question: 'Should I use serverless or containers?'
    answer: 'Choose serverless over Docker containers for event-driven, spiky, or unpredictable workloads and for small teams that do not want to operate infrastructure. Choose containers for long-running processes, custom runtimes, or sustained high-volume services where always-on capacity is cheaper. Many production systems combine both: serverless for APIs and event handlers, containers for steady background workloads.'
  - question: 'Are cold starts still a problem?'
    answer: 'Far less than they used to be. In production, cold starts affect only a small fraction of invocations — a steadily invoked function reuses warm instances for hundreds of thousands of calls — and typically last from a few milliseconds up to about a second depending on runtime and code size. For latency-critical paths you can mitigate them with warm concurrency, lighter dependencies, or edge functions. For typical APIs and mobile backends they are rarely noticeable.'
  - question: 'What is the difference between FaaS and BaaS?'
    answer: 'FaaS (Functions-as-a-Service) runs the server-side code you still write — stateless, event-triggered functions like Back4app Cloud Code. BaaS (Backend-as-a-Service) goes further: the database, authentication, file storage, and APIs are consumed as ready-made services, so most backend code disappears entirely. They are complementary halves of the serverless model, and most real applications use both.'
  - question: 'When should you NOT use serverless?'
    answer: 'Avoid serverless for long-running jobs that exceed execution time limits, workloads needing specialized hardware or custom runtimes, latency-critical systems that cannot tolerate any cold start, and sustained high-volume traffic where always-on servers are cheaper. Regulatory requirements for full infrastructure control can also rule it out.'
  - question: 'What programming languages can serverless functions use?'
    answer: 'It depends on the runtimes your platform provides — JavaScript/Node.js is the most universally supported, and most platforms add options like Python, Go, or Java. On Back4app, Cloud Code functions are written in JavaScript on a managed Node.js runtime, so the same language your web frontend uses runs your backend logic. Whatever the platform, your clients are unaffected: they call functions by name over HTTPS or an SDK.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Serverless Architectures — Mike Roberts (martinfowler.com)'
    url: 'https://martinfowler.com/articles/serverless.html'
  - name: 'CNCF Serverless Whitepaper'
    url: 'https://github.com/cncf/wg-serverless/blob/master/whitepapers/serverless-overview/cncf_serverless_whitepaper_v1.0.pdf'
  - name: 'Serverless computing (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Serverless_computing'
  - name: 'Back4app Cloud Code documentation'
    url: 'https://www.back4app.com/docs/get-started/cloud-functions'
cta:
  title: 'Run serverless functions without assembling the platform first'
  text: 'Cloud Code on Back4app gives you serverless functions with the database, authentication, and APIs already provisioned — no gateway to configure, no IAM policies to write. Deploy your first function in minutes on the free tier.'
  linkText: 'Deploy Cloud Code for free'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-07-15'
modifiedDate: '2026-07-16'
translationKey: serverless-architecture
---

**Serverless architecture is a cloud execution model where the provider runs your code on demand, so you never provision or manage servers.** Servers still exist — you just stop renting, patching, and scaling them. You deploy functions; the platform allocates compute when an event arrives and bills you only for what runs.

## Key takeaways

| Question | Answer |
| --- | --- |
| What it is | Code that runs in provider-managed, on-demand compute — no server provisioning |
| Problem it solves | Capacity planning, idle-server costs, and infrastructure operations |
| Billing model | Per request + per GB-second of execution; scales to zero when idle |
| Watch out for | Cold starts, execution time limits, provider lock-in |
| Back4app equivalent | Cloud Code functions — deploy code, Back4app runs it |

## The problem it solves

With a traditional deployment you rent capacity ahead of demand: size the instance, configure autoscaling, pay for idle time, patch the OS. Get it wrong in one direction and you burn money; in the other, you drop requests at your traffic peak.

In a serverless model that entire loop disappears. You write a function, and scaling from zero to thousands of concurrent executions is the provider's job. This is all the backend code needed to compute a movie's average rating server-side:

```javascript
// cloud/main.js — a Back4app Cloud Code function
Parse.Cloud.define('averageStars', async (request) => {
  const query = new Parse.Query('Review');
  query.equalTo('movie', request.params.movie);
  const reviews = await query.find();
  const sum = reviews.reduce((acc, r) => acc + r.get('stars'), 0);
  return sum / reviews.length;
});
```

There is no Express app around it, no Dockerfile, no load balancer. The function is the unit of deployment.

## Calling it from any client

Every client SDK invokes the same function by name — the transport, auth, and scaling are handled by the platform:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
const params = { movie: 'Inception' };
const rating = await Parse.Cloud.run('averageStars', params);
console.log(`Average rating: ${rating}`);
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('averageStars');
final params = <String, dynamic>{'movie': 'Inception'};
final response = await function.execute(parameters: params);
if (response.success) {
  print('Average rating: ${response.result}');
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("averageStars",
                        parameters: ["movie": "Inception"]) { result in
  switch result {
  case .success(let rating):
    print("Average rating: \(rating)")
  case .failure(let error):
    print(error.localizedDescription)
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
val params = hashMapOf("movie" to "Inception")
ParseCloud.callFunctionInBackground<Float>("averageStars", params) { rating, e ->
  if (e == null) {
    Log.d("Cloud", "Average rating: $rating")
  }
}
```

## How a serverless request flows

```mermaid
flowchart LR
  accTitle: Serverless request flow
  accDescr: A client calls a managed endpoint; the platform runs the function on a warm instance or provisions one in a cold start, reads the managed database, returns the response, and scales to zero after idle.
  A[Client app] --> B[Managed HTTPS endpoint]
  B --> C{Warm instance<br/>available?}
  C -- yes --> D[Execute function]
  C -- no --> E[Cold start:<br/>provision runtime] --> D
  D --> F[(Managed database)]
  D --> G[Response to client]
  D -. after idle period .-> H[Scale to zero<br/>cost: $0]
```

The branch to watch is the cold start. When no warm instance exists, the platform must provision a runtime before executing your code — anywhere from [a few milliseconds to several seconds depending on language, code size, and dependencies](https://martinfowler.com/articles/serverless.html). In production it affects only a small fraction of requests, since a steadily invoked function keeps reusing warm instances — negligible for most APIs, but real for latency-critical paths, and a reason edge functions and warm-up strategies exist.

## Serverless vs. containers vs. traditional servers

| Dimension | Serverless | Containers (Kubernetes) | Traditional VMs |
| --- | --- | --- | --- |
| Unit you deploy | Function | Container image | Machine image |
| Scaling | Automatic, per request, to zero | Automatic, but you configure and pay for the cluster | Manual or autoscaling groups |
| Idle cost | $0 | Cluster keeps running | Instance keeps running |
| Cold starts | Yes (ms–seconds) | No (pods stay warm) | No |
| Long-running processes | Limited by execution timeouts | Yes | Yes |
| Ops burden | None | Significant (cluster, upgrades, capacity) | Highest (OS, patching, HA) |
| Best for | Event-driven, spiky, or unpredictable load | Sustained load, custom runtimes | Legacy systems, full control |

## FaaS and BaaS: the two halves of serverless

"Serverless" covers two complementary models, a distinction [Mike Roberts' canonical article on martinfowler.com](https://martinfowler.com/articles/serverless.html) formalized. The split has a birthday: commercial event-triggered compute launched in 2014, and within two years serverless went from research idea to production default for event-driven work — which is why the vocabulary still feels newer than the ideas underneath it. **FaaS (Functions-as-a-Service)** means you still write server-side logic, but it runs in stateless, event-triggered, fully managed compute — the "cloud functions" model. **BaaS (Backend-as-a-Service)** goes further: the database, authentication, file storage, and APIs are themselves consumed as managed services, so most backend code you would have written disappears entirely.

Most real applications need both — functions for custom logic, managed services for everything else. That combination is exactly what a BaaS platform packages. For a deep dive into that half of the model, read our [complete guide to Backend as a Service](https://www.back4app.com/backend-as-a-service-baas).

## Common serverless use cases

- **APIs and mobile backends.** The dominant case: request-driven traffic that idles at night and spikes at launch — exactly the shape pay-per-execution pricing rewards.
- **Event and data processing.** Resize an image on upload, validate a record on save, sync a change to a third-party system — short-lived reactions to events.
- **Scheduled jobs.** Nightly reports, cleanup tasks, and recurring syncs run as cron-triggered functions with no server waiting around between runs.
- **Real-time features.** Chat, notifications, and live dashboards pair serverless functions with managed real-time infrastructure instead of hand-rolled WebSocket servers.
- **MVPs and prototypes.** When validating an idea, spending zero time on infrastructure is the entire point — deploy a function, get a URL, ship.
- **AI agents and webhooks.** Glue code between LLMs, payment providers, and SaaS APIs is naturally event-driven and short-lived — a perfect serverless fit.

## Should you go serverless? A decision matrix

| Choose serverless when… | Choose always-on servers when… |
| --- | --- |
| Traffic is spiky, unpredictable, or low-volume | Traffic is sustained and high-volume (always-on is cheaper) |
| You need to launch fast with a small team | You run long-lived processes that exceed function timeouts |
| Standard building blocks (auth, CRUD, storage) cover most needs | You need custom runtimes, GPUs, or specialized hardware |
| You have no dedicated DevOps resources | Regulations require full control of the infrastructure |
| Cost should track usage, starting at $0 | Sub-10-ms tail latency is non-negotiable on every request |

On cost, concrete anchors help: serverless platforms bill per request plus compute time consumed (GB-seconds), with no upfront commitment — and Back4app's free tier includes 25,000 API requests per month, enough to run a real MVP at $0 before any scaling decision is needed.

## Limitations and trade-offs

- **Cold starts.** The first invocation of an idle function pays a provisioning penalty (sub-100 ms to over a second). Mitigations: warm concurrency, smaller bundles, edge runtimes.
- **Execution time limits.** Functions are built for short work; video encoding or hour-long batch jobs belong in containers or background job systems.
- **Harder debugging and observability.** There is no server to SSH into. You depend on the platform's logs, metrics, and tracing — evaluate them before committing.
- **Vendor lock-in.** Functions written against proprietary APIs are expensive to move. Prefer platforms built on open source — Back4app's Cloud Code runs on an open-source foundation you can self-host anytime.
- **Cost at sustained scale.** Pay-per-execution is unbeatable at low and spiky volume but can exceed flat server pricing under constant heavy load. Re-run the math as traffic stabilizes.
- **Statelessness.** Functions keep no memory between invocations; session and application state must live in a database or cache, which is a design constraint if you're porting stateful code.

## How Back4app implements serverless

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. It gives you both halves in one platform. The FaaS half is **[Cloud Code](https://www.back4app.com/docs/get-started/cloud-functions)**: JavaScript functions like `averageStars` above that you deploy from the dashboard or CLI, plus database triggers and scheduled jobs — no gateway, IAM policies, or infrastructure to configure. The BaaS half comes provisioned with every Back4app app: the database, user authentication, file storage, and auto-generated REST and GraphQL APIs. And because Back4app builds on an open-source foundation, the functions you write are portable — you can self-host the same stack later, which removes the lock-in objection that hangs over provider-specific serverless platforms.