Funciones Serverless vs. Microservicios: ¿cuál elegir?

Una función serverless es una unidad única de deploy de lógica de backend; un microservicio es un servicio completo operado de forma independiente. Esa sola frase es la comparación entera en miniatura — todo lo demás (carga de ops, curvas de costo, cold starts, estado) se desprende de cuál es la unidad de deploy: una función que le entregas a una plataforma, o un servicio que operas tú mismo.

Puntos clave

La unidad de deploy, en código

Este es el deployable completo de una operación de checkout — una función, sin repositorio por servicio, sin imagen de contenedor, sin 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}")
    }
}

El equivalente en microservicio de ese snippet es un repositorio: un servidor HTTP, un build de contenedor, manifiestos de deploy, service discovery, health checks, un dashboard y una rotación de guardias — antes de la primera línea de lógica de checkout.

Funciones serverless vs. microservicios propios

La literatura de microservicios es explícita: los beneficios de la arquitectura se compran con una madurez operativa seria — deploy automatizado, monitoreo sofisticado, diseño para el fallo. Las funciones tercerizan exactamente esa cuenta a la plataforma, y por eso el análisis de serverless de Mike Roberts encuadra el FaaS como cambiar control por radicalmente menos ops. Ninguno de los dos intercambios es gratis; la pregunta es qué impuesto puede pagar tu equipo.

Qué le pasa realmente a una request

Fíjate en lo que la mitad de abajo agrega y la de arriba no puede expresar: llamadas de servicio a servicio, almacenes de datos por servicio y un gateway — la superficie de coordinación donde realmente vive la complejidad de los microservicios. Las transacciones distribuidas, los reintentos y los fallos parciales entre los servicios de carrito y de pedidos son código tuyo; en el modelo de funciones, el mismo workflow suele ser una función y una base de datos, y las piezas orientadas a eventos (triggers, jobs programados) cuelgan de la plataforma y no de colas que tú operas.

Cuándo las funciones reemplazan una flota de microservicios — y cuándo no pueden

La observación honesta detrás del patrón BaaS: la mayoría de los microservicios de un producto típico son delgados. Validan entrada, aplican una regla, leen o escriben una base de datos y llaman a un vecino — el caparazón operativo alrededor de esa lógica es el 90% de su peso. Las funciones en la nube dentro de un BaaS borran el caparazón: la base de datos, la autenticación, el almacenamiento de archivos y las APIs son servicios de la plataforma, así que cada “servicio” colapsa en un puñado de funciones y triggers. Los equipos de una a diez personas que entregan productos de CRUD-más-lógica rara vez necesitan más.

El techo es igual de honesto. Las funciones no pueden hospedar un modelo de recomendaciones que necesita hardware especializado, un transcodificador de video que corre una hora, un motor de fan-out de WebSocket con tuning a medida, ni un componente cuyo throughput sostenido convierte el precio por invocación en la opción cara. Cuando un componente cruza esas líneas, extráelo como un servicio de verdad y deja que interopere con las funciones — extraer un hot spot comprobado es una migración mucho más barata que descomponer una flota especulativa construida demasiado pronto, la misma lección que el argumento monolith-first enseña un nivel más arriba.

Casos de uso comunes

• Funciones: backends de API y mobile. Lógica con forma de request sobre una base de datos gestionada — el caso dominante, y el que las plataformas BaaS empaquetan de punta a punta.
• Funciones: triggers y pegamento. Validar al guardar, redimensionar al subir, sincronizar con una API de terceros, correr jobs nocturnos — reacciones cortas que harían pasar vergüenza a un servicio dedicado.
• Funciones: tráfico con picos o desconocido. Lanzamientos, campañas, MVPs — escalar a cero absorbe tanto el pico como el silencio.
• Microservicios: componentes pesados y sostenidos. Búsqueda, feeds, motores de precios — carga estable donde la capacidad siempre activa es más barata y ajustable.
• Microservicios: runtimes especiales. Lenguajes fuera del estándar, dependencias nativas, GPUs, procesos de larga duración.
• El híbrido. Funciones para la superficie de API y los eventos; uno o dos servicios extraídos para los componentes cuyos números lo exigen.

¿Deberías construir funciones o microservicios? Matriz de decisión

Limitaciones y trade-offs

• Funciones: los límites de ejecución son paredes duras. El trabajo largo debe mudarse a sistemas de jobs o a servicios — ninguna astucia estira un timeout con elegancia.
• Funciones: cold starts y cadenas. Raros por invocación, pero las arquitecturas de función-llama-función los apilan; mantén las rutas calientes poco profundas.
• Funciones: acoplamiento a la plataforma. El runtime y sus APIs son de la plataforma — una base open-source que puedes auto-hospedar es la cobertura práctica contra el lock-in.
• Microservicios: la cuenta de ops es por servicio. Pipelines, monitoreo, contratos versionados y guardias se multiplican con la flota; subestimarlo es el modo clásico de fallar.
• Microservicios: los problemas de sistemas distribuidos llegan el primer día. Las particiones de red, los fallos parciales y la consistencia entre servicios son constantes arquitectónicas, no casos borde.
• Ambos: el estado se externaliza de todos modos. Las funciones lo obligan; los servicios bien operados lo eligen. Es la base de datos, no el cómputo, la que termina guardando la verdad en ambos diseños.

Funciones serverless y microservicios en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. Es el lado de las funciones de esta comparación entregado completo: Cloud Code corre funciones con nombre como la checkout de arriba, más triggers de base de datos y jobs programados, junto a todo lo que una flota de microservicios existe para proveer — así la flota que la mayoría de los productos habría construido se convierte en funciones sobre servicios gestionados. Y como la base es open source y auto-hospedable, la ruta de extracción sigue abierta: cuando un componente supera el modelo de funciones, puede graduarse como servicio dedicado sin abandonar la plataforma que lo rodea.