What is 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

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:

// 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 / Node.js — Back4app JS SDK
const params = { movie: 'Inception' };
const rating = await Parse.Cloud.run('averageStars', params);
console.log(`Average rating: ${rating}`);

// 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}');
}

// 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)
  }
}

// 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

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. 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

FaaS and BaaS: the two halves of serverless

“Serverless” covers two complementary models, a distinction Mike Roberts’ canonical article on martinfowler.com 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.

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

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: 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.