¿Qué es la Arquitectura Serverless?

La arquitectura serverless es un modelo de ejecución en la nube donde el proveedor corre tu código bajo demanda: nunca aprovisionas ni gestionas servidores. Los servidores siguen existiendo — solo dejas de alquilarlos, parchearlos y escalarlos tú. Haces deploy de funciones; la plataforma asigna cómputo cuando llega un evento y te cobra únicamente por lo que corre.

Puntos clave

El problema que resuelve

Con un deployment tradicional alquilas capacidad antes de la demanda: dimensionas la instancia, configuras el autoscaling, pagas por el tiempo ocioso, parcheas el sistema operativo. Si te equivocas hacia un lado, quemas dinero; hacia el otro, pierdes requests en tu pico de tráfico.

En un modelo serverless, ese ciclo entero desaparece. Escribes una función, y escalar de cero a miles de ejecuciones concurrentes es trabajo del proveedor. Este es todo el código de backend necesario para calcular la calificación promedio de una película del lado del servidor:

// cloud/main.js — una función Cloud Code de Back4app
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;
});

No hay una app Express alrededor, ni Dockerfile, ni load balancer. La función es la unidad de deployment.

Llamarla desde cualquier cliente

Todo SDK de cliente invoca la misma función por nombre — el transporte, la auth y el escalado corren por cuenta de la plataforma:

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

Cómo fluye una request serverless

La rama a vigilar es el cold start. Cuando no existe una instancia warm, la plataforma debe aprovisionar un runtime antes de ejecutar tu código — desde unos pocos milisegundos hasta varios segundos según el lenguaje, el tamaño del código y las dependencias. En producción afecta solo a una pequeña fracción de las requests, ya que una función invocada con constancia sigue reutilizando instancias warm — despreciable para la mayoría de las APIs, pero real en rutas críticas de latencia, y una de las razones por las que existen las edge functions y las estrategias de warm-up.

Serverless vs. contenedores vs. servidores tradicionales

FaaS y BaaS: las dos mitades del serverless

“Serverless” cubre dos modelos complementarios, una distinción que el artículo canónico de Mike Roberts en martinfowler.com formalizó. La división tiene fecha de nacimiento: el cómputo comercial disparado por eventos se lanzó en 2014 y, en dos años, serverless pasó de idea de investigación a estándar de producción para el trabajo orientado a eventos — por eso el vocabulario todavía se siente más nuevo que las ideas que tiene debajo. FaaS (Functions as a Service) significa que tú sigues escribiendo lógica server-side, pero corre en cómputo stateless, disparado por eventos y totalmente gestionado — el modelo de las “cloud functions”. BaaS (Backend as a Service) va más allá: la base de datos, la autenticación, el almacenamiento de archivos y las APIs se consumen, ellos mismos, como servicios gestionados, así que la mayor parte del código de backend que habrías escrito desaparece por completo.

La mayoría de las aplicaciones reales necesita ambos — funciones para la lógica personalizada, servicios gestionados para todo lo demás. Esa combinación es exactamente lo que empaqueta una plataforma BaaS. Para profundizar en esa mitad del modelo, lee nuestra guía completa de Backend as a Service.

Casos de uso comunes del serverless

• APIs y backends mobile. El caso dominante: tráfico orientado a requests que duerme de madrugada y se dispara en el lanzamiento — exactamente la forma que el precio por ejecución recompensa.
• Procesamiento de eventos y datos. Redimensionar una imagen al subirla, validar un registro al guardarlo, sincronizar un cambio con un sistema de terceros — reacciones cortas a eventos.
• Jobs programados. Reportes nocturnos, tareas de limpieza y sincronizaciones recurrentes corren como funciones disparadas por cron, sin un servidor esperando entre ejecución y ejecución.
• Funcionalidades en tiempo real. Chat, notificaciones y dashboards en vivo combinan funciones serverless con infraestructura de tiempo real gestionada, en lugar de servidores WebSocket hechos a mano.
• MVPs y prototipos. Al validar una idea, gastar cero tiempo en infraestructura es el punto entero — haces deploy de una función, obtienes una URL, lanzas.
• Agentes de IA y webhooks. El código de pegamento entre LLMs, proveedores de pago y APIs SaaS es naturalmente orientado a eventos y de vida corta — un encaje perfecto para serverless.

¿Deberías adoptar serverless? Matriz de decisión

Sobre el costo, ayudan anclas concretas: las plataformas serverless cobran por request más el tiempo de cómputo consumido (GB-segundos), sin compromiso inicial — y el tier gratuito de Back4app incluye 25.000 requests de API al mes, suficiente para correr un MVP real a $0 antes de cualquier decisión de escala.

Limitaciones y trade-offs

• Cold starts. La primera invocación de una función ociosa paga una penalización de aprovisionamiento (de menos de 100 ms a más de un segundo). Mitigaciones: concurrencia warm, bundles más pequeños, runtimes de edge.
• Límites de tiempo de ejecución. Las funciones están hechas para trabajo corto; la codificación de video o los batches de una hora pertenecen a contenedores o a sistemas de background jobs.
• Debugging y observabilidad más difíciles. No hay servidor al que entrar por SSH. Dependes de los logs, las métricas y el tracing de la plataforma — evalúalos antes de comprometerte.
• Vendor lock-in. Las funciones escritas contra APIs propietarias cuestan caro de migrar. Prefiere plataformas construidas sobre open source — Cloud Code de Back4app corre sobre una base open-source que puedes auto-hospedar cuando quieras.
• Costo a escala sostenida. Pagar por ejecución es imbatible con volumen bajo y con picos, pero puede superar el precio fijo de servidor bajo carga constante y pesada. Rehaz la cuenta cuando el tráfico se estabilice.
• Ausencia de estado. Las funciones no guardan nada entre invocaciones; la sesión y el estado de la aplicación deben vivir en una base de datos o un caché — una restricción de diseño si estás portando código stateful.

Arquitectura serverless 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. Te da las dos mitades en una sola plataforma. La mitad FaaS es Cloud Code: funciones JavaScript como la averageStars de arriba, con deploy desde el dashboard o la CLI, además de triggers de base de datos y jobs programados — sin gateway, políticas de IAM ni infraestructura que configurar. La mitad BaaS viene aprovisionada con cada app de Back4app: la base de datos, la autenticación de usuarios, el almacenamiento de archivos y las APIs REST y GraphQL generadas automáticamente. Y como Back4app se construye sobre una base open-source, las funciones que escribes son portátiles — puedes auto-hospedar la misma stack después, lo que elimina la objeción de lock-in que pesa sobre las plataformas serverless atadas a un proveedor.