Serverless Cloud Functions vs. Custom Microservices

A serverless cloud function is a single deployable unit of backend logic; a microservice is a whole independently operated service. That one sentence is the entire comparison in miniature — everything else (ops burden, cost curves, cold starts, state) follows from what the unit of deployment is: a function you hand to a platform, or a service you run yourself.

Key takeaways

The unit of deployment, in code

Here is the entire deployable for a checkout operation — one function, no repo-per-service, no container image, no pipeline:

// JavaScript / Node.js — the function is the whole deployable
// cloud/main.js — runs on the platform; there is no service to operate
Parse.Cloud.define('checkout', async (request) => {
  const cart = await new Parse.Query('Cart').get(request.params.cartId, {
    sessionToken: request.user.getSessionToken(),
  });
  // …price the cart, reserve stock, write the order…
  return { orderId: cart.id, status: 'confirmed' };
});

// Any client calls it by name — no gateway, container, or pipeline
const result = await Parse.Cloud.run('checkout', { cartId });

// Flutter / Dart — Back4app Flutter SDK
// Calling the function: one named endpoint, no service discovery
final checkout = ParseCloudFunction('checkout');
final response = await checkout.execute(
  parameters: {'cartId': cartId},
);
if (response.success) {
  print(response.result['status']); // confirmed
} else {
  print(response.error?.message);
}

// iOS / Swift — Back4app Swift SDK
// Calling the function: one named endpoint, no service discovery
struct Checkout: ParseCloudable {
    typealias ReturnType = [String: String]
    var functionName: String = "checkout"
    var cartId: String
}

let result = try await Checkout(cartId: cartId).runFunction()
print(result["status"] ?? "") // confirmed

// Android / Kotlin — Back4app Android SDK
// Calling the function: one named endpoint, no service discovery
val params = hashMapOf("cartId" to cartId)
ParseCloud.callFunctionInBackground<Map<String, String>>(
    "checkout", params
) { result, e ->
    if (e == null) {
        Log.i("Checkout", result["status"] ?: "")
    } else {
        Log.w("Checkout", "failed: ${e.code}")
    }
}

The microservice equivalent of that snippet is a repository: an HTTP server, a container build, deployment manifests, service discovery, health checks, a dashboard, and an on-call rotation — before the first line of checkout logic.

Serverless cloud functions vs. custom microservices

The microservices literature is explicit that the architecture’s benefits are bought with serious operational maturity — automated deployment, sophisticated monitoring, design-for-failure. Functions outsource exactly that bill to the platform, which is why Mike Roberts’ serverless analysis frames FaaS as trading control for radically less ops. Neither trade is free; the question is which tax your team can afford.

What actually happens to a request

Notice what the bottom half adds that the top half cannot express: service-to-service calls, per-service data stores, and a gateway — the coordination surface where microservice complexity actually lives. Distributed transactions, retries, and partial failures between the cart and order services are your code; in the function model, the same workflow is usually one function and one database, and the event-driven pieces (triggers, scheduled jobs) hang off the platform rather than off queues you operate.

When functions replace a microservice fleet — and when they can’t

The honest observation behind the BaaS pattern: most microservices in a typical product are thin. They validate input, enforce a rule, read or write a database, and call a neighbor — the operational shell around that logic is 90% of their weight. Cloud functions inside a BaaS delete the shell: the database, auth, file storage, and APIs are platform services, so each “service” collapses into a handful of functions and triggers. Teams of one to ten shipping CRUD-plus-logic products rarely need more.

The ceiling is equally honest. Functions cannot host a recommendation model that needs specialized hardware, a video transcoder that runs for an hour, a WebSocket fan-out engine with custom tuning, or a component whose sustained throughput makes per-invocation pricing the expensive option. When a component crosses those lines, extract it as a real service and let it interoperate with the functions — extraction of a proven hot spot is a far cheaper migration than decomposing a speculative fleet you built too early, which is the same lesson the monolith-first argument teaches one level up.

Common use cases

• Functions: API and mobile backends. Request-shaped logic over a managed database — the dominant case, and the one BaaS platforms package end to end.
• Functions: triggers and glue. Validate on save, resize on upload, sync to a third-party API, run nightly jobs — short-lived reactions that would embarrass a dedicated service.
• Functions: spiky and unknown traffic. Launches, campaigns, MVPs — scale-to-zero absorbs both the spike and the silence.
• Microservices: sustained heavy components. Search, feeds, pricing engines — steady load where always-on capacity is cheaper and tunable.
• Microservices: special runtimes. Non-standard languages, native dependencies, GPUs, long-running processes.
• The hybrid. Functions for the API surface and events; one or two extracted services for the components with numbers that demand it.

Should you build functions or microservices? A decision matrix

Limitations and trade-offs

• Functions: execution limits are hard walls. Long work must move to job systems or services — no amount of cleverness extends a timeout gracefully.
• Functions: cold starts and chains. Rare per invocation, but function-calling-function architectures stack them; keep hot paths shallow.
• Functions: platform coupling. The runtime and its APIs are the platform’s — an open-source foundation you can self-host is the practical hedge against lock-in.
• Microservices: the ops bill is per service. Pipelines, monitoring, versioned contracts, and on-call multiply with the fleet; underestimating this is the classic failure mode.
• Microservices: distributed-systems problems arrive on day one. Network partitions, partial failures, and cross-service consistency are architectural constants, not edge cases.
• Both: state is externalized anyway. Functions force it; well-run services choose it. The database, not the compute, ends up holding the truth in either design.

Serverless functions and microservices on Back4app

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 is the function side of this comparison delivered whole: Cloud Code runs named functions like checkout above, plus database triggers and scheduled jobs, next to everything a microservice fleet exists to provide — so the fleet most products would have built becomes functions over managed services. And because the foundation is open source and self-hostable, the extraction path stays open: when one component outgrows the function model, it can graduate to a dedicated service without abandoning the platform around it.