¿Estás construyendo algo serverless? Esto es lo que nadie te dice.

Tiempo de lectura: 5 minutos Ambiente: Un café con un amigo que trabaja en la nube

---

Seamos sinceros

El serverless suena increíble. Solo escribes código, le das a desplegar, y ocurre la magia. Sin servidores. Sin operaciones. Solo funcionalidad pura.

Y luego lo intentas. Y tu primer usuario espera cinco segundos por un arranque en frío. O tu función se detiene después de quince minutos. O llega la factura de la nube y te atragantas con tu café.

Aquí está el asunto: El "serverless" no es una sola cosa.

Está el serverless de AWS Lambda (el donde AWS lo hace todo por ti). Y está el serverless sobre Kubernetes (el donde tienes más control pero también más responsabilidad).

Y el lenguaje de programación que funciona perfectamente en uno te va a destruir completamente en el otro.

Déjame mostrarte lo que quiero decir con cinco proyectos reales que podrías estar construyendo.

---

Proyecto 1: El pequeño bot que revisa cosas cada hora

Qué es: Una cosita diminuta que se despierta cada hora, revisa una base de datos y envía un mensaje a Slack. Eso es todo. Duerme el resto del tiempo.

Qué pasa realmente: Nada durante 59 minutos. Luego cobra vida durante dos segundos. Luego vuelve a dormir.

La decisión inteligente: Pon esto en AWS Lambda. Escríbelo en Python o Node.js.

Por qué: Porque los arranques en frío no importan mucho aquí. ¿Unos cientos de milisegundos de retraso? A quién le importa. El bot solo envía un mensaje a Slack.

Lo que la gente hace mal: Alguien dice: "¡Usemos Rust por rendimiento!" Rust es increíble. Pero ¿para un bot que corre dos segundos por hora? Nunca notarás la diferencia. En cambio, te será difícil encontrar a otra persona que sepa Rust cuando esta se vaya.

La verdad: Usa la herramienta simple. Guarda las herramientas sofisticadas para los problemas difíciles.

---

Proyecto 2: La página de pago que recibe una paliza cada lunes por la mañana

Qué es: El proceso de compra de una tienda online. La mayor parte de la semana está tranquilo. Pero cada lunes a las 9am, diez mil personas hacen clic en "comprar" al mismo tiempo. Si la página tarda más de un cuarto de segundo en responder, la gente se va y compra en otro lado.

Qué pasa realmente: A las 8:59am, cero funciones están ejecutándose. A las 9:00am, llega el aluvión. Los primeros usuarios activan arranques en frío. Esperan. Algunos se van.

La decisión inteligente: AWS Lambda también, pero con Node.js en lugar de Python.

Por qué: Node.js arranca más rápido. Hablamos de 50ms frente a 200ms. Esa diferencia importa para el primer usuario del lunes por la mañana.

Lo que la gente hace mal: Un científico de datos dice: "Me encanta pandas, usemos Python". Pandas es genial para análisis. Pero cargarlo añade medio segundo al arranque. Tu primer usuario del lunes se queda colgado. Pierdes esa venta.

La verdad: Los arranques en frío son invisibles hasta que te cuestan dinero. Ahí no piensas en otra cosa.

---

Proyecto 3: El procesador de video que corre dos horas seguidas

Qué es: Una plataforma donde la gente sube videos en 4K. Tu sistema los comprime, añade una marca de agua y genera una miniatura. Cada video tarda entre veinte minutos y dos horas en procesarse.

Qué pasa realmente: AWS Lambda tiene un tiempo límite estricto de quince minutos. Tu tarea de dos horas muere a mitad de camino.

La decisión inteligente: Serverless sobre Kubernetes (usando algo como Knative o OpenFaaS). Esto permite ejecutar funciones que toman horas. También permite adjuntar GPUs si las necesitas para codificar video más rápido.

Por qué: Porque quince minutos no son suficientes. Necesitas horas. A Kubernetes no le importa cuánto tardes.

Lo que la gente hace mal: Alguien dice: "Reescribamos el codificador de video en Rust para máxima velocidad". No. FFmpeg ha sido optimizado por cientos de personas durante treinta años. No vas a hacerlo mejor. Solo llama a FFmpeg desde el lenguaje que quieras.

La verdad: A veces la herramienta correcta es la aburrida que simplemente funciona.

---

Proyecto 4: El detector de fraudes que necesita responder en milisegundos

Qué es: Un procesador de pagos que verifica cada transacción contra cincuenta reglas de negocio, tres APIs externas y una caché. Necesita responder "fraude o no fraude" en menos de 80 milisegundos. Los bancos son auditados por esto. A los reguladores les importa.

Qué pasa realmente: Tienes 200,000 líneas de código Java existente llenas de reglas complejas. No puedes reescribir eso. Pero Java estándar tarda 8 segundos en arrancar. Tu primera transacción del día se quedará fuera de tiempo.

La decisión inteligente: Serverless sobre Kubernetes, pero con una versión especial de Java llamada GraalVM. Compila tu código Java en un binario nativo que arranca en 150 milisegundos en lugar de 8 segundos.

Por qué: Porque puedes mantener tu código existente. Sin reescritura. Sin proyecto de seis meses. Solo una forma más rápida de ejecutar lo que ya tienes.

Lo que la gente hace mal: "Usemos Java estándar sobre Kubernetes". Java estándar tarda 8 segundos en arrancar. Tu detector de fraudes se perderá las primeras transacciones de cada evento de escalado. Eso es dinero real perdido por fraude.

Otro error: "Reescribamos todo en Go". Eso es un proyecto de seis meses con alto riesgo de romper las reglas de negocio. Tu equipo te va a odiar.

La verdad: Modernizar es a menudo mejor que reescribir. Mantén el código que funciona. Solo haz que arranque más rápido.

---

Proyecto 5: El sensor de fábrica que vive con casi nada de memoria

Qué es: Una pequeña computadora dentro de una fábrica. Mil sensores envían datos cada décima de segundo. La computadora valida los datos, los agrega y los envía a la nube. Toda la computadora tiene solo 4GB de RAM en total.

Qué pasa realmente: Cada milisegundo importa. Las pausas del recolector de basura son inaceptables. La memoria es increíblemente limitada.

La decisión inteligente: Serverless sobre Kubernetes ligero (como K3s) ejecutándose en el borde. Escrito en Rust.

Por qué: Rust usa casi nada de memoria. No tiene pausas de recolector de basura. Arranca instantáneamente. Fue básicamente construido para este escenario.

Lo que la gente hace mal: "Sé Python, puedo aprender Rust en el trabajo". Rust tiene una curva de aprendizaje brutal. Se necesitan seis meses para ser realmente productivo. Tu fábrica no puede esperar seis meses.

La verdad: Rust es asombroso pero difícil. Encuentra a alguien que ya lo sepa. La curva de aprendizaje es real.

---

Tabla resumen — Qué lenguaje para cada proyecto

---

Entonces, ¿cómo piensas sobre tu propio proyecto?

Hazte una sola pregunta:

"Cuando esta cosa se despierta desde cero, ¿qué tan rápido necesita responder?"

Si la respuesta es "un par de cientos de milisegundos está bien" → Estás en territorio AWS Lambda con Python o Node.js. Esto es la mayoría de los proyectos. La vida es buena. Manténlo simple.

Si la respuesta es "menos de 100ms, pero tengo código Java existente" → Estás en territorio GraalVM sobre Kubernetes. Puedes mantener tu código. Solo necesitas ejecutarlo de forma más inteligente.

Si la respuesta es "menos de 10ms y tengo 4GB de RAM en total" → Estás en territorio Rust sobre Kubernetes en el borde. Trae a una persona de sistemas. Esto es lo difícil.

Si la respuesta es "no me importa, corre durante dos horas" → Estás en la zona "todo vale". Elige el lenguaje que quieras. Solo asegúrate de que tu plataforma no tenga tiempo límite.

---

Guía de selección: plataforma y lenguaje

---

La cosa que me hubiera gustado que alguien me dijera antes

La mayoría de los proyectos son como el primero. El bot de Slack. La API simple. Puedes usar Python o Node.js en Lambda y estarás totalmente bien.

Pero los proyectos que fallan — los detectores de fraudes que pierden transacciones, los dispositivos en el borde que se quedan sin memoria, las páginas de pago que se quedan colgadas el lunes por la mañana — esos fallan porque alguien los trató como el primer proyecto.

Usaron la herramienta simple para un problema difícil. No pensaron en los arranques en frío. No se dieron cuenta de que su elección de lenguaje importaba.

Adapta la herramienta al problema. No a la moda.

---

Último pensamiento

Si estás construyendo algo, empieza preguntándote cómo se comporta esa cosa cuando nadie la está usando.

¿Duerme? ¿Se despierta rápido? ¿Necesita mantenerse caliente todo el tiempo?

Las respuestas a esas preguntas te dirán más que cualquier artículo sobre cuál es el "mejor" lenguaje.

Ahora ve a construir algo chévere.

---

¿Te gustó? Ayudamos a las personas a elegir las herramientas adecuadas para los problemas adecuados en Quopa.io. Pasa a saludar.