En el modelo de hosting tradicional (EC2, DigitalOcean), alquilas una computadora. Pagas €50/mes. Si nadie visita su sitio a las 3:00 a. m., la computadora permanece inactiva. Aún pagas. Si 100.000 personas lo visitan a las 10:00 a. m., la computadora falla. Pierdes ingresos.

Éste es el dilema de la planificación de la capacidad. Es estrictamente necesario sobreaprovisionar para manejar los picos, lo que significa que estás pagando de más el 99% del tiempo.

Sin servidor (FaaS) invierte el modelo. No alquilas una computadora. Subes el código. Pagas por invocación.

0 visitas = €0.00.
1 millón de visitas = AWS activa 1000 funciones simultáneas. Pagas exactamente 1 millón de segundos de ejecución.

En Maison Code Paris, utilizamos Serverless no solo por el costo, sino también por la simplicidad operativa. No parcheamos los kernels de Linux. No rotamos claves SSH. Nos centramos en la Lógica.

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

Por qué Maison Code adopta primero la tecnología sin servidor

Tratamos la infraestructura como un pasivo, no como un activo. Cada servidor que administramos es un servidor que puede fallar. Nuestra filosofía “Scale-to-Zero” se alinea con las pérdidas y ganancias de nuestros clientes:

Eficiencia: Migramos las tareas cron heredadas de un cliente desde un EC2 dedicado de €100/mes a Lambda. El costo se redujo a €0,12/mes.
Resiliencia: durante el Black Friday, nuestros puntos finales sin servidor aumentaron a 5000 ejecuciones simultáneas sin un solo tiempo de espera.
Enfoque: Nuestros ingenieros dedican el 100 % de su tiempo a la lógica empresarial (precios, carrito, pago), no a la orquestación de Docker.

Arquitectura: patrones basados en eventos

Sin servidor es mejor cuando es asíncrono. Si bien puedes ejecutar una API estándar (GET /users), el verdadero poder está en Event Sourcing.

El patrón de búfer (SQS + Lambda)

Escenario: realiza una venta flash. 10.000 usuarios realizan pagos en 1 segundo. Si conecta Lambda directamente a su ERP (SAP/NetSuite), utilizará DDoS en su propio ERP. No puede manejar conexiones de 10k.

Solución:

API Gateway: Acepta la solicitud HTTP. Devuelve “202 Aceptado”.
SQS (Servicio de cola simple): Almacena la solicitud en una cola. Puede contener millones de mensajes.
Lambda: sondea la cola. Procesa mensajes a un ritmo controlado (por ejemplo, 50 a la vez).
Resultado: Su ERP recibe un flujo constante de pedidos, no un tsunami. El usuario obtiene una respuesta rápida.

Manejo de fallas: la cola de mensajes fallidos (DLQ)

En un servidor Node.js, si una solicitud falla, se pierde. En Serverless configuramos Reintentos. AWS Lambda reintentará una función asíncrona fallida 2 veces automáticamente. Si aún falla (por ejemplo, error en el código), mueve el evento a una Cola de mensajes fallidos (DLQ). Los ingenieros pueden inspeccionar el DLQ, corregir el error y “Redrive” los mensajes. No se pierde ningún dato.

El problema del arranque en frío

Los recursos no son gratuitos. Para ahorrar dinero, AWS cierra su contenedor si no se ha utilizado durante aproximadamente 15 minutos. La siguiente solicitud desencadena un Arranque en frío.

AWS asigna una microVM (Firecracker).
Descarga tu código.
Inicia Node.js.
Ejecuta tu controlador.

Latencia: ~300 ms - 1 s (Node.js). ~3s (Java). Impacto: Bien para trabajos en segundo plano. Malo para las API de pago.

La solución: Vercel Edge Runtime (aislamientos V8)

Vercel (y Cloudflare Workers) introdujeron un nuevo tiempo de ejecución. En lugar de iniciar un contenedor Node.js completo (VM + OS + Node), se ejecutan en V8 Isolates. Este es el mismo motor que ejecuta JavaScript en Chrome.

Arranque en frío: ~0ms.
Límites: No puedes usar API de Node.js como fs, child_process o archivos binarios nativos.
Caso de uso: middleware, redireccionamiento de autenticación, depósitos de pruebas A/B, enrutamiento geográfico.

La trampa de la base de datos: agrupación de conexiones

Aquí es donde fracasa el 90% de los principiantes. Una biblioteca estándar de Postgres (pg) abre una conexión TCP. En un servidor monolito, abres 1 conexión y la compartes. En Serverless, cada función es un contenedor aislado. Si tiene 1000 usuarios simultáneos, abre 1000 conexiones de base de datos. Postgres se queda sin RAM y falla. FATAL: las ranuras de conexión restantes están reservadas.

Solución 1: Agrupación de conexiones (PgBouncer) Un servicio de middleware que se encuentra frente a Postgres. Tiene 1000 conexiones de clientes pero las asigna a 10 conexiones de base de datos reales. DigitalOcean y AWS RDS Proxy lo convierten en un servicio.

Solución 2: Bases de datos basadas en HTTP Los nuevos proveedores de bases de datos (Neon, PlanetScale, Supabase) ofrecen API HTTP. No abres un socket TCP. Usted busca ('https://db.neon.tech/query'). HTTP no tiene estado. Se escala perfectamente con Serverless.

// Usando Neon (Postgres sin servidor)
importar {neón} desde '@neondatabase/serverless';

const sql = neón(process.env.DATABASE_URL);

exportar controlador de función asíncrona (evento) {
  resultado constante = esperar sql`SELECT * FROM usuarios`;
  return {cuerpo: JSON.stringify(resultado) };
}

Gestión de estado: no hay memoria

En un servidor normal, puedes hacer: dejar requestCount = 0; app.get('/', () => requestCount++); En Serverless, requestCount efectivamente siempre será 1 o 0. El contenedor se destruye después de la ejecución. Las variables globales se borran.

Regla: Todo estado debe ser externo.

Datos de sesión -> Redis.
Datos de usuario -> Base de datos.
Carga de archivos -> S3 / Blob Storage. No escriba en /tmp (desaparece). No utilice variables globales.

Análisis de costos: el punto de inflexión

La tecnología sin servidor no siempre es más barata. Tiene un “marcado” en el cálculo sin procesar (~2 veces el costo por ciclo de CPU en comparación con EC2). Los ahorros provienen del 0 % de tiempo de inactividad.

Tráfico bajo/tráfico intenso: la tecnología sin servidor es un 90% más barata.
Carga alta constante: si tiene un proceso que se ejecuta las 24 horas del día, los 7 días de la semana (como un servidor WebSocket o una gran cantidad de datos), EC2 es más barato. Realizamos auditorías de TCO (coste total de propiedad) para los clientes. A menudo, el costo operativo de administrar EC2 (parches, seguridad) hace que Serverless sea el ganador incluso en volúmenes más altos.

Código: Ruta API de Vercel (mejores prácticas)

Estructuramos nuestras funciones para que sean comprobables, separando la Lógica de la Red.

// app/api/checkout/route.ts (enrutador de aplicaciones Next.js)
importar {NextResponse} desde 'siguiente/servidor';
importar { createCheckout } desde '@/lib/checkout'; // Lógica empresarial

// El controlador (capa de red)
exportar función asíncrona POST (solicitud: Solicitud) {
  prueba {
    cuerpo constante = esperar solicitud.json();
    
    // Validar entrada (Zod)
    si (!body.cartId) {
      return NextResponse.json({ error: 'Falta el ID del carrito' }, { estado: 400 });
    }

    // Lógica de llamada
    URL constante = espera createCheckout(body.cartId);

    devolver NextResponse.json({url});
  } captura (error) {
    consola.error(error); // Inicia sesión en CloudWatch / Datadog
    return NextResponse.json({ error: 'Error interno' }, { estado: 500 });
  }
}

10. Observabilidad: seguimiento distribuido

En un monolito, grep server.log. En Serverless, una solicitud de un solo usuario llega a API Gateway -> Lambda A -> SQS -> Lambda B -> DynamoDB. Si falla, ¿dónde falló? No puede registrar registros en 5 servicios. Implementamos Seguimiento Distribuido (OpenTelemetry / AWS X-Ray). Pasamos un encabezado trace_id a través de cada servicio. Esto genera un “Gráfico de llamas” que muestra exactamente dónde se produjo el pico de latencia (por ejemplo, “Lambda B tardó 3 segundos porque DynamoDB estaba acelerando”).

11. El mito del bloqueo del proveedor

Los revisores suelen decir: “Sin servidor lo encierra en AWS”. Verdadero. Pero Docker te encierra en el kernel de Linux. React te bloquea en el DOM virtual. El bloqueo es inevitable. La pregunta es: “¿Vale la pena el bloqueo por la velocidad?” Podemos reescribir una función Lambda en Go/Rust en 1 día. El costo de migrar fuera de Serverless es bajo porque las unidades de código son pequeñas. El costo de no usar Serverless (administrar flotas EC2) es alto y continuo.

13. Seguridad: privilegio mínimo (IAM)

Una Lambda = Un rol. No le dé a su Lambda AdministratorAccess. Si ese Lambda está comprometido (inyección de dependencia), el atacante es dueño de su cuenta. Dale: s3:GetObject en bucket-a SOLAMENTE. Este modelo de seguridad granular es superior a un Monolith donde todo el servidor tiene acceso raíz a la base de datos. Herramientas como SST (Serverless Stack) automatizan esta generación de políticas: bucket.grantRead(lambda) genera la política estricta de IAM automáticamente.

14. Marcos: por qué usamos SST

Raw CloudFormation es doloroso. Terraform es detallado. Usamos SST (Serverless Stack). Nos permite definir infraestructura en TypeScript. Permite “Live Lambda Development” (proxies de entorno local para AWS). Establece puntos de interrupción en VS Code, llega a un punto final y se detiene dentro de Lambda que se ejecuta en AWS. Es la única forma de desarrollar Serverless de forma sensata.

15. Conclusión

Las funciones sin servidor son el pegamento de la Internet moderna. Permiten a los ingenieros frontend convertirse en “Full Stack” sin necesidad de un título en Administración de Linux. Escalan infinitamente. No cuestan nada cuando están inactivos. Pero requieren una mentalidad disciplinada de “apátrida”.

¿Pagando por el tiempo de actividad inactivo?

¿Está ejecutando un servidor de €100 para un trabajo que toma 5 segundos al día? Contrate a nuestros arquitectos.