Recordé la época en que me costaba entender serverless y lancé todas aquellas preguntas.

¿Desaparecieron los servidores? La verdadera identidad del mago

🧙‍♂️ (Profesor) «🐣, hoy aprenderemos qué es serverless. Al oír el nombre uno imaginaría un “hechizo que borra servidores”, pero la realidad es más discreta y a la vez profunda.»

🐣 (Estudiante) «¿Sin servidores? ¿No me diga que gritó “¡servidores, desvanezcan!” como Harry Potter y de verdad desaparecieron?»

🧙‍♂️ (Profesor) «Ja, eso es justo lo que piensa el 90 % la primera vez. En realidad, los servidores trabajan con todo en el fondo de la nube. Lo que cambia es que tú ya no tienes que preocuparte por ellos.»

🐣 (Estudiante) «¿Entonces es un engaño? Como esas verduras que dicen “sin pesticidas” aunque les echaron químicos donde no se ve.»

🧙‍♂️ (Profesor) «Tu metáfora es extraña, pero acierta. El “less” de serverless significa “sin gestión”. Antes criábamos servidores como si fueran mascotas: instalar sistemas operativos, parchar, atender incidentes… igual que cuidar un hámster. Con serverless, el proveedor de la nube se encarga de todo.»

🐣 (Estudiante) «Con un hámster lloras cuando muere; con un servidor, los clientes te gritan. Peor todavía.»

🧙‍♂️ (Profesor) «Y, a diferencia de un hámster, a las tres de la mañana te despierta con un “la base de datos no responde”.»

📌 Nota: Concepto básico de serverless Serverless no significa que no existan servidores, sino que el proveedor de nube los opera en tu lugar.

  • Modelo tradicional: comprar, instalar y administrar los servidores por cuenta propia.
  • Serverless: el proveedor gestiona toda la infraestructura y tú te concentras en el código.

Cómo funciona serverless: ninjas que aparecen solo cuando los invocan

🐣 (Estudiante) «Suena complicado. ¿En qué se diferencia de un servidor normal?»

🧙‍♂️ (Profesor) «Serverless se enciende con un “pop” cuando lo llaman, procesa y desaparece enseguida. Por eso las aplicaciones deben diseñarse como velocistas, no como maratonistas.»

🐣 (Estudiante) «O sea, aparece cuando le piden “¡procesa esto ya!” y se esfuma en cuanto termina.»

🧙‍♂️ (Profesor) «Exactamente. Es como un ninja que solo se muestra cuando lo convocan. Mientras está oculto en la niebla, no pagas alquiler por tiempo ocioso.»

🐣 (Estudiante) «Pero los ninjas aparecen cada vez desde un lugar distinto. ¿Qué pasa con la dirección IP?»

🧙‍♂️ (Profesor) «Buena observación. No tienen domicilio fijo. Como cada vez corre en un servidor distinto, la puerta del pueblo ninja es la API Gateway del proveedor, que recibe las peticiones externas y las distribuye al ninja adecuado.»

🐣 (Estudiante) «Entonces, si cada ninja es diferente, ¿no recuerda lo que pasó antes?»

🧙‍♂️ (Profesor) «Correcto. Por eso necesitas un diseño sin estado. No puede decir “ah, seguimos con lo de ayer”. Cada vez comienza con memoria de pez.»

🐣 (Estudiante) «¿No es incómodo? ¿Qué hacemos con el inicio de sesión o las sesiones?»

🧙‍♂️ (Profesor) «Guardas el estado en una base de datos externa o en Redis. El ninja no conserva recuerdos, pero deja los pergaminos importantes en un almacén aparte.»

📌 Nota: La importancia de diseñar sin estado Las funciones serverless se inician en contenedores nuevos cada vez, por lo que no conservan estado local (variables, archivos, sesiones).

  • Gestión de estado: usar bases de datos externas, Redis, S3, etc.
  • Sesiones: almacenar en tokens JWT o almacenamiento externo.
  • Archivos: salvo procesos temporales, todo debe ir a almacenamiento externo.

Diferencias con los servidores tradicionales: mascotas vs. ninjas

🐣 (Estudiante) «¿Cómo se ve en la práctica?»

🧙‍♂️ (Profesor) «Imagina el proceso de crear miniaturas al subir una imagen. Con el enfoque tradicional tienes un servidor 24/7 esperando con “¿ya llegó algo?”. Consume electricidad y puede fallar.»

🐣 (Estudiante) «Como un guardia en la puerta esperando sin parar.»

🧙‍♂️ (Profesor) «Exacto, y ese guardia se resfría a veces. En serverless, cuando suena la campana “se subió una imagen”, aparece el ninja, genera la miniatura y se esfuma.»

🐣 (Estudiante) «¿Y no tarda en aparecer?»

🧙‍♂️ (Profesor) «Ahí está el problema del cold start. El ninja necesita unos segundos para despertarse, sobre todo con lenguajes pesados como Java: es como si se estirara, preparara la esterilla y desayunara antes de trabajar.»

🐣 (Estudiante) «Eso desespera. Entonces no sirve para tareas en tiempo real.»

🧙‍♂️ (Profesor) «Existen mecanismos de warm-up, pero en general brilla en procesamiento por lotes o asincrónico. Lo de “quiero la respuesta ya” no es su fuerte.»

Entenderlo con un ejemplo: una app para compartir fotos

🐣 (Estudiante) «Dame un caso concreto. ¿Qué pasa si creo una app para compartir fotos?»

🧙‍♂️ (Profesor) «Buena idea. Con el modelo tradicional sería así：»

Servidor tradicional：

Servidor web funcionando 24/7 (5 000 yenes al mes)
↓
“Se cargó una foto”
↓
Procesamiento de miniaturas dentro del servidor
↓
Guardar en la base de datos

🧙‍♂️ (Profesor) «En ese modelo sigues pagando 5 000 yenes incluso en meses sin usuarios. Como un local vacío que de todos modos paga la renta.»

🐣 (Estudiante) «Qué desperdicio.»

🧙‍♂️ (Profesor) «Serverless se ve así：»

Versión serverless：

La imagen se sube a S3
↓
El evento de S3 dispara una función Lambda
↓
La función Lambda arranca (0,1 s)
↓
Genera la miniatura y la guarda en otro bucket de S3
↓
La función Lambda desaparece
↓
Facturación: solo el tiempo de ejecución (aprox. 0,001 ¥ por llamada)

🐣 (Estudiante) «Entonces, si nadie lo usa, ¿sale gratis?»

🧙‍♂️ (Profesor) «Así es: pagas solo por uso. Pero si se vuelve viral, la factura también se dispara. Si un video se vuelve trending y se ejecuta un millón de veces…»

🐣 (Estudiante) «¡Llegaría una factura de 1 000 yenes!»

🧙‍♂️ (Profesor) «El cálculo es correcto, pero en realidad se suman los costos de transferencia, API Gateway, base de datos. No es raro que termines en decenas de miles de yenes. La tragedia moderna de “me volví famoso y quebré”.»

📌 Nota: Ventajas y riesgos de la facturación por uso

Ventajas

  • Coste inicial casi cero.
  • Escalado automático según el uso.
  • Sin gestión de infraestructura.

Riesgos

  • Facturas inesperadas (especialmente en picos virales).
  • Estructuras de precios complejas.
  • Difícil ver el costo combinado de varios servicios.

Contramedidas

  • Configurar alertas de facturación.
  • Implementar límites de tasa.
  • Hacer pruebas de carga y estimaciones de costo por adelantado.

Tipos de serverless: las especialidades del ninja

🐣 (Estudiante) «Escuché que hay varias clases de serverless.»

🧙‍♂️ (Profesor) «Tres grandes escuelas: FaaS (Function as a Service), BaaS (Backend as a Service) y contenedores serverless.»

🐣 (Estudiante) «¿Qué es FaaS?»

🧙‍♂️ (Profesor) «Servicios que “solo te guardan las funciones”. AWS Lambda, Google Cloud Functions, Azure Functions. Escribes la función y la dejas allí; la ejecutan cuando la invocas y te cobran por consumo. Como una barra de sushi por pieza.»

🐣 (Estudiante) «¿Y BaaS?»

🧙‍♂️ (Profesor) «Ofrecen “nos ocupamos de la base de datos, la autenticación, las notificaciones push”. Firebase, Supabase, AWS Amplify. Es como vivir en casa de tus padres: todo resuelto.»

🐣 (Estudiante) «Vivir con los padres es cómodo, pero hay que seguir sus reglas.»

🧙‍♂️ (Profesor) «Exacto. Existe el riesgo de vendor lock-in. Un día te das cuenta de que no puedes vivir sin ese servicio.»

Qué se le da bien y qué no

🐣 (Estudiante) «Entonces, ¿por qué no esforzarnos con servidores tradicionales? ¿Para qué usar serverless?»

🧙‍♂️ (Profesor) «Por velocidad. Puedes lanzar una idea en horas y, mientras el uso sea bajo, el coste es casi cero. Es publicar hoy lo que imaginaste anoche.»

🐣 (Estudiante) «Pero no servirá para todo.»

🧙‍♂️ (Profesor) «Tiene fortalezas y debilidades claras.»

Lo que hace bien：

  • Procesamiento de imágenes (subir → generar miniaturas).
  • Transformación de datos (convertir CSV a JSON).
  • Envío de notificaciones (correo, push).
  • Procesos por lotes periódicos (reportes diarios).
  • Pequeñas operaciones de API (buscar usuarios, obtener datos).

Lo que se le da mal：

  • Procesamiento en tiempo real (chat, juegos).
  • Procesos de larga duración (codificar video, entrenamiento de ML).
  • Aplicaciones con estado complejo.
  • Integraciones rígidas con sistemas heredados.

🐣 (Estudiante) «O sea, tiene mucha explosividad pero poca resistencia.»

🧙‍♂️ (Profesor) «Tal cual: es un corredor de 100 metros que sufre en un maratón.»

La trampa de los costos: ninjas pagados por hora

🐣 (Estudiante) «Así que no es para quienes confían en la fuerza bruta, porque una factura mal controlada te mata, pero quien piensa bien sale ganando.»

🧙‍♂️ (Profesor) «Exactamente. Serverless es “ganas si piensas, explotas si te descuidas”. Si no entiendes cómo se factura, terminas en el infierno.»

🐣 (Estudiante) «¿Qué clase de infierno?»

🧙‍♂️ (Profesor) «Imagina que escribes código con un bucle infinito. Con un servidor tradicional se vuelve lento; con serverless invocas ninjas sin parar.»

🐣 (Estudiante) «¿Un ejército de ninjas trabajando para cobrarte horas eternamente? Eso da miedo.»

🧙‍♂️ (Profesor) «Y te enteras al final de mes: “¿por qué debo 1 000 000 de yenes?”. Hay muchos casos reales en AWS con facturas de cientos de miles.»

🐣 (Estudiante) «Terrorífico. ¿Hay defensas?»

🧙‍♂️ (Profesor) «Claro. Configura alertas de facturación, límites de tiempo de ejecución y de concurrencia. Es redactar bien el contrato laboral del ninja.»

Casos reales: cuando hacerse viral da miedo

🐣 (Estudiante) «¿Has oído historias de facturas gigantes?»

🧙‍♂️ (Profesor) «Montones. Famosa es la app de retoque fotográfico que terminó pagando 3 millones de yenes en un mes.»

🐣 (Estudiante) «Cuéntame más.»

🧙‍♂️ (Profesor) «Una startup lanzó una app de embellecimiento con IA. Calculaban 0,1 yenes por foto.»

🐣 (Estudiante) «¿Y qué pasó?»

🧙‍♂️ (Profesor) «Se hizo viral en redes y subieron un millón de fotos al día. Además, cada proceso tardaba más de lo esperado y pasó a costar 3 yenes por foto.»

🐣 (Estudiante) «1 000 000 × 3 = 3 000 000…»

🧙‍♂️ (Profesor) «Y eso durante 30 días. Es la tragedia moderna de “me hice famoso y la empresa quebró”.»

🐣 (Estudiante) «¿No tenían defensas?»

🧙‍♂️ (Profesor) «No fijaron límites de gasto. Subestimaron la posibilidad de hacerse virales. Hoy es sentido común definir un “tope del éxito”.»

🐣 (Estudiante) «Suena irónico hablar de techo del éxito.»

🧙‍♂️ (Profesor) «El “grito de alegría” que se vuelve un grito literal.»

Experiencia de desarrollo: placer mágico y dolor por las restricciones

🐣 (Estudiante) «¿Cómo es programar así? ¿Se siente diferente a escribir un programa normal?»

🧙‍♂️ (Profesor) «Al principio es divertido. Escribes una función, haces clic en desplegar y la publicas al mundo. Te sientes un mago.»

🐣 (Estudiante) «Suena emocionante.»

🧙‍♂️ (Profesor) «Pero cuando te acostumbras, ves las costuras. Probar en local es difícil, depurar es pesado. Si algo falla, el ninja ya desapareció y solo queda seguir rastreando logs.»

🐣 (Estudiante) «Como llegar a la escena del crimen y encontrar solo evidencias.»

🧙‍♂️ (Profesor) «Exacto. Y los logs están dispersos en varios servicios: CloudWatch, X-Ray, CloudTrail… empieza el juego de detectives.»

🐣 (Estudiante) «Qué fastidio. ¿No es más fácil levantar un servidor?»

🧙‍♂️ (Profesor) «Esa es la trampa. Al principio es mágico, luego se vuelve una maldición. Aun así, cuando te acostumbras, ya no quieres volver al “cuidar servidores”.»

🐣 (Estudiante) «¿Genera adicción?»

🧙‍♂️ (Profesor) «Sí. La sensación de “no preocuparse por los servidores” es adictiva, pero a cambio aparecen el estrés de la factura y las restricciones de diseño.»

Serverless vs. modelo tradicional: la realidad del costo

🐣 (Estudiante) «Entonces, ¿cuál sale más barato?»

🧙‍♂️ (Profesor) «Depende de dos ejes: el volumen de uso y qué tan bien puedes predecirlo. Piensa en dos gráficas：»

Servidor tradicional

  • Coste fijo: 50 000 yenes al mes.
  • Coste variable: casi cero.
  • Modelo de “restaurante con menú del día”.

Serverless

  • Coste fijo: casi cero.
  • Coste variable: según uso.
  • Modelo de “sushi giratorio”.

🐣 (Estudiante) «Así que la cuenta depende de cuánto comas.»

🧙‍♂️ (Profesor) «Eso es. Si comes poco, el sushi giratorio; si comes mucho, el menú fijo. En números：»

Hasta 1 millón de solicitudes al mes: serverless es mucho más barato. Más de 10 millones al mes: el servidor tradicional resulta más económico. En medio: depende; hay que considerar el coste operativo.

🐣 (Estudiante) «¿Y si calculas mal?»

🧙‍♂️ (Profesor) «Ahí está la parte de apuesta. Si estimas mal cuánto usarán, puedes terminar como “fui al menú fijo pero no tenía apetito” o “entré al sushi para un bocado y acabé en un concurso de comilona”.»

¿Serverless ganará la partida?

🐣 (Estudiante) «En definitiva, ¿serverless va a ganar o perder?»

🧙‍♂️ (Profesor) «No habrá victoria ni derrota absolutas. Los modelos tradicionales, los contenedores y serverless coexistirán cada uno en su terreno. Es un mundo donde necesitamos caballeros, ninjas y magos.»

🐣 (Estudiante) «Entonces ninguna tecnología lo resuelve todo.»

🧙‍♂️ (Profesor) «Correcto. No hay bala de plata. Pero usada en el contexto adecuado, es una herramienta potentísima.»

🐣 (Estudiante) «¿Para quién la recomendarías?»

🧙‍♂️ (Profesor) «Para este perfil：»

Personas que encajan con serverless

  • Quienes quieren poner algo en marcha rápido.
  • Gente capaz de entender estructuras de facturación.
  • Quienes prefieren menos gestión a cambio de menos control total.
  • Personas que se emocionan con nuevas tecnologías.

Personas que no encajan con serverless

  • Artesanos que quieren controlarlo todo.
  • Quienes son malos gestionando presupuestos.
  • Los que priorizan por encima de todo la operación estable.
  • Equipos atados a sistemas heredados.

🐣 (Estudiante) «Un “ahorrador amante de la innovación”, ¿no?»

🧙‍♂️ (Profesor) «Gran expresión. Serverless exige innovación y frugalidad.»

Cierre: vivir de forma serverless

🐣 (Estudiante) «Entonces, ¿lo recomiendas?»

🧙‍♂️ (Profesor) «No digo “úsalo sí o sí”. Digo “úsalo entendiendo cómo funciona”. Serverless es un conjuro moderno que hay que equilibrar entre la tentación de la conveniencia y la realidad del riesgo.»

🐣 (Estudiante) «Los conjuros mal usados se devuelven al lanzador.»

🧙‍♂️ (Profesor) «Por eso hay que aprender la pronunciación correcta. Serverless te premia cuando usas la cabeza y te castiga cuando te descuidas. No es para quien confía solo en el músculo, pero en manos inteligentes es un arma poderosa.»

🐣 (Estudiante) «Entonces：

  • Operar servidores: un entrenamiento infernal de resistencia.
  • Serverless: sobrevivir a la factura con inteligencia.

¿Así?»

🧙‍♂️ (Profesor) «Resumen perfecto. Escoger uno u otro depende del contexto. La única opción que no existe es “no elegir”. Hoy debemos decidir si ser caballeros, ninjas o magos.»

🐣 (Estudiante) «Entendido. Primero dominaré lo básico y luego aprenderé a manejar ninjas.»

🧙‍♂️ (Profesor) «Con esa actitud serás una gran “domadora de ninjas”. Solo vigila las facturas.»

🐣 (Estudiante) «¡Sí! Pondré alertas de cobro, lo prometo.»

📌 Nota final: Marco para decidir si adoptar serverless

La adopción de serverless debe evaluarse considerando estos factores：

Factores técnicos

  • Naturaleza de la carga (procesamiento por lotes vs. tiempo real).
  • Frecuencia de ejecución (baja vs. alta).
  • Necesidad de gestionar estado.
  • Integración con sistemas heredados.

Factores de negocio

  • Presupuesto de inversión inicial.
  • Habilidades del equipo de operaciones.
  • Certidumbre sobre el crecimiento.
  • Nivel de tolerancia al vendor lock-in.

Conclusión: serverless no es una solución universal, sino una técnica especializada que brilla en contextos concretos. Con comprensión y preparación se vuelve un arma poderosa; adoptarlo a la ligera puede terminar en facturas elevadas.

Para la ingeniería moderna, serverless es una opción que hay que conocer y una tecnología que debe usarse con criterio.