Elegir hosting después de un prototipo: serverless vs contenedores

Por qué el hosting se complica justo después del prototipo

Un prototipo se siente rápido porque solo tiene que funcionar para un grupo pequeño, por poco tiempo y en un entorno controlado. Puedes estar probando con datos de ejemplo, un admin y unas pocas páginas. Cuando llegan usuarios reales, la misma app actúa diferente: más logins, más subidas, más refrescos y más casos límite.

Las decisiones de hosting se complican porque los prototipos suelen saltarse las partes aburridas que determinan si una app sobrevive en producción: tiempo de actividad, reintentos, límites de tasa, gestión de secretos y cómo se comporta la base de datos bajo carga. Cuando finalmente necesitas esas cosas básicas, acabas eligiendo entre opciones que suenan parecidas pero se comportan muy distinto.

Señales comunes de que has superado tu setup actual:

• Las páginas se vuelven lentas cuando unas pocas personas usan la app a la vez
• Los trabajos en background fallan a veces, sin razón clara
• Las conexiones a la base de datos expiran o obtienes “demasiadas conexiones”
• Los despliegues dan miedo porque un cambio puede romperlo todo
• Encuentras API keys o contraseñas en texto plano

No necesitas un conocimiento profundo de DevOps para tomar una buena decisión de hosting. Necesitas una forma clara de emparejar las necesidades de tu app con el tipo de hosting correcto, para no tener que rehacerlo dos veces.

Cuando la gente dice “tráfico, jobs y base de datos”, suelen referirse a:

• Tráfico: usuarios cargando páginas y llamando APIs. La pregunta clave es si el uso es estable (predecible) o espigado (tranquilo la mayor parte del día y de repente muy activo).
• Jobs: trabajo que corre en background, como enviar emails, generar informes, procesar subidas o sincronizar datos. La pregunta clave es si debe ejecutarse de forma fiable aunque nadie esté usando la app activamente.
• Base de datos: dónde tu app guarda datos y estado. La pregunta clave es si necesita conexiones de larga duración, migraciones, backups y rendimiento consistente.

En este post comparamos serverless, contenedores y plataformas gestionadas usando tablas de decisión sencillas.

Qué anotar antes de comparar opciones

Antes de elegir serverless, contenedores o una plataforma gestionada, escribe qué hace tu app día a día. Esto evita elegir por sensaciones y tener que rehacerlo después.

Empieza con un mapa simple de tus pantallas y flujos. Lista las pantallas principales (página de marketing, dashboard, ajustes, admin, checkout) y marca cuáles deben sentirse rápidas siempre. “Rápido siempre” suele significar login, la primera pantalla tras el login y cualquier cosa ligada al dinero.

Luego estima el tráfico de forma de bajo esfuerzo. No necesitas números exactos aún. Usa una etiqueta como bajo, medio, espigado o desconocido. Espigado puede significar “puede que tengamos 10 usuarios la mayoría de los días, pero 5.000 el día del lanzamiento” o “un partner puede enviar ráfagas por webhook”. Si el tráfico es desconocido, escríbelo también, porque cambia lo que optimizas.

A continuación, separa el trabajo en background de las cargas de página. Muchas apps funcionan en una demo pero fallan en producción porque los trabajos no tienen un lugar seguro donde ejecutarse. Ejemplos comunes:

• Envío de emails o SMS (registro, recibos, restablecer contraseña)
• Importaciones y exportaciones (subidas CSV, sincronización de datos)
• Tareas largas de IA (generar informes, resumir documentos, procesamiento por lotes)
• Trabajo con medios (redimensionar imágenes, procesar vídeo)
• Webhooks (lógica de reintentos cuando otros servicios fallan)

Ahora captura tus necesidades de datos en palabras llanas. No tienes que elegir proveedores todavía. Describe qué tipo de estado tienes y qué pasa si se pierde:

• Datos SQL (usuarios, pagos, permisos)
• Archivos (subidas, facturas, avatares)
• Búsqueda (full-text, filtros, relevancia)
• Caché (acelerar páginas populares, límites de tasa)

Finalmente, escribe las restricciones que importan más que cualquier detalle técnico: tiempo para lanzar, presupuesto y quién lo mantendrá. Si eres fundador en solitario sin equipo on-call, dilo. Si necesitas algo en 48 horas, dilo también.

Un ejemplo rápido: si tienes un prototipo con un dashboard rápido, tráfico espigado en lanzamiento, un job de importación diario y una base SQL, ya tienes suficiente para comparar opciones sin adivinar.

Serverless, contenedores y plataformas gestionadas en términos simples

Elegir hosting tras un prototipo es en gran medida decidir cuánto del trabajo de “mantener la app” quieres asumir.

Serverless: el código corre solo cuando es necesario

Serverless significa que tu código despierta bajo demanda y vuelve a dormirse cuando no hay nada que hacer. No gestionas un servidor en ejecución contínua. Envías pequeños fragmentos de código (funciones) o un servicio web serverless, y la plataforma gestiona el escalado.

Los compromisos son reales: las peticiones pueden empezar más lentas tras un tiempo inactivo, y a menudo necesitas diseñar alrededor de límites (timeouts, ejecución sin estado y patrones específicos para conexiones a BD). Serverless puede ser estupendo para tráfico espigado o APIs sencillas.

Contenedores: controlas más y cargas con más responsabilidades

Un contenedor es tu app empaquetada con su runtime para que se ejecute igual en cualquier sitio. Tú decides cómo arranca, qué corre junto a ella y cómo usa CPU y memoria.

La ventaja es el control: workers en background, runtimes previsibles y menos “reglas de la plataforma”. La desventaja es el trabajo de operaciones: mantener servicios saludables, reglas de escalado, logs, secretos, parches y respuesta a incidentes.

Plataformas gestionadas: el punto intermedio

Las plataformas gestionadas están en medio. Despliegas una app y la plataforma la ejecuta por ti en su infraestructura. “Gestionado” suele incluir pasos de build, HTTPS, autoscaling y cheques básicos de salud.

Lo que sigue siendo tu responsabilidad: bugs de la app, diseño de la base de datos, comportamiento de los jobs en background y mantener los secretos fuera del repo.

Un modelo mental simple de precios:

• Serverless: pagas por petición y tiempo de cómputo. Barato con tráfico bajo o ráfagas, pero los costes pueden subir con uso estable y pesado.
• Contenedores: pagas por capacidad reservada (máquinas que mantienes en ejecución), aunque el tráfico esté tranquilo. Más predecible con carga constante.
• Plataformas gestionadas: suelen tener un coste base mensual más add-ons (bases de datos, logs, ancho de banda). A menudo lo más fácil de presupuestar al inicio.

Los despliegues y rollbacks también se sienten diferentes:

• Serverless: despliegues rápidos, pero más piezas si tienes muchas funciones. Los rollbacks suelen ser fáciles, pero depurar entre funciones puede ser más complejo.
• Contenedores: releases versionadas y rollbacks rápidos, pero debes montar el proceso.
• Plataformas gestionadas: “push to deploy” es simple. Los rollbacks suelen ser de un clic, aunque la personalización puede ser limitada.

Si tu prototipo es una API pequeña con tráfico ocasional y un par de tareas programadas, serverless puede ser un inicio de bajo esfuerzo. Si ya necesitas una cola, jobs de larga duración o control estricto del runtime, contenedores (o una plataforma gestionada que soporte workers) suelen ser más tranquilos.

Tabla de decisión parte 1: patrones de tráfico

El tráfico es lo primero porque afecta coste, fiabilidad y el trabajo que debes hacer para mantenerlo estable.

Los cold starts importan cuando los usuarios los notan. Si tu app tiene checkout, login o cualquier cosa donde la gente haga clic y espere, una pausa de 1–3 segundos puede perjudicar. Si es una herramienta interna pequeña, los cold starts a menudo no importan.

Las necesidades en tiempo real cambian la respuesta. Si necesitas WebSockets, streaming largo o colaboración en vivo, los servicios de larga duración suelen ser más sencillos. Contenedores o plataformas gestionadas tienden a ser menos dolorosas. Algunos setups serverless pueden manejar tiempo real, pero añaden piezas y más formas de fallar.

Las expectativas sobre autoscaling suelen ser demasiado optimistas. “Serverless significa escalado infinito” no es la sensación en la práctica. Aún te topas con límites: topes de concurrencia, límites de conexiones a BD y límites de APIs de terceros. Los contenedores autoscalan también, pero pueden reaccionar más despacio si no mantienes algo de capacidad caliente.

Regla práctica:

• Tráfico constante: contenedores o plataforma gestionada, mantenlo aburrido.
• Tráfico espigado: serverless funciona bien para peticiones web por ráfaga, pero planea cold starts y límites.
• Tráfico desconocido: empieza simple, instrumenta temprano y ajusta cuando veas uso real.

Tabla de decisión parte 2: trabajos en background y colas

Los trabajos en background son todo lo que tu app necesita hacer fuera de la petición principal: enviar emails, redimensionar subidas, sincronizar datos, cobrar tarjetas o llamar a un modelo de IA. Para muchos prototipos, esto decide, porque los jobs revelan qué se rompe cuando llegan usuarios reales.

La mayoría de problemas con jobs no son tanto “dónde corre” sino las cosas básicas: timeouts, reintentos, idempotencia (para que los reintentos no dupliquen trabajo) y concurrencia segura.

Serverless puede ser genial cuando cada tarea es pequeña e independiente. Obtienes escalado automático y pagas solo cuando corre. Se complica cuando las tareas alcanzan límites de tiempo, necesitan CPU constante por largo tiempo o dependen de dependencias pesadas que hacen que los cold starts sean lentos.

Los contenedores suelen ser más sencillos para jobs largos y workers dedicados. Un contenedor worker puede tirar de una cola, mantenerse caliente y manejar memoria o CPU mayores sin luchar con límites de funciones. La contraparte es que debes pensar en escalado, reinicios y garantizar que un solo worker procese cada trabajo a la vez.

Las plataformas gestionadas ayudan cuando empaquetan las partes aburridas: colas hospedadas, scheduling, autoscaling de workers, dashboards de fallos y manejo de dead-letter.

Un ejemplo concreto: un prototipo SaaS que genera facturas puede crear PDFs en serverless si termina rápido. Si los clientes empiezan a subir facturas enormes y la generación tarda minutos, un worker en contenedor tirando de una cola suele ser más tranquilo de operar y más fácil de depurar.

Tabla de decisión parte 3: base de datos y servicios con estado

Empieza por la parte más “pegajosa” de tu app: la base de datos y cualquier cosa que guarde estado. Puedes cambiar el hosting web después. Mover datos y estado es donde los equipos pierden semanas.

Si tu prototipo usa Postgres o MySQL, mantenlo. Postgres/MySQL gestionados son por lo general el valor por defecto más seguro porque upgrades, problemas de disco y backups son donde las BDs autohospedadas más fallan.

Si tu prototipo usa SQLite, trátalo como una señal de aviso. Está bien para una demo, pero se desmorona rápido cuando añades usuarios concurrentes, múltiples instancias de app o jobs en background.

BD gestionada vs BD autohospedada: qué falla

Autohospedar una BD dentro de un contenedor puede funcionar, pero los modos de fallo suelen ser aburridos y caros: almacenamiento lleno, backups inexistentes, una actualización menor rompe una extensión o un reinicio corrompe datos porque los volúmenes estaban mal configurados. Una BD gestionada reduce estos riesgos, sobre todo cuando aún cambias el esquema a menudo.

Más allá de la BD, lista otras necesidades con estado:

• Las subidas de archivos suelen necesitar object storage (no el disco local de la app).
• La búsqueda suele necesitar un servicio separado si quieres filtrado rápido a escala.
• La caché suele requerir algo como Redis gestionado si dependes de sesiones, límites de tasa o consultas costosas.

Los límites de conexión importan más de lo que se espera. Cada conexión abierta a la BD consume memoria en el servidor de BD. Las apps serverless pueden crear muchas conexiones de corta duración, lo que provoca errores de “demasiadas conexiones”. La solución habitual es el pooling de conexiones: tu app habla con un pool y el pool reutiliza un número menor de conexiones a la BD.

Cómo elegir: un camino paso a paso que puedes seguir

Intentar comparar cada característica de cada plataforma es una manera rápida de atascarse. Un mejor enfoque: parte de lo que más probablemente falle primero y elige lo más simple que lo prevenga.

Paso 1: Elige tu cuello de botella actual

Sé honesto sobre lo que duele hoy, no sobre lo que puede importar en un año:

• Tráfico: páginas lentas, timeouts o límites de tasa.
• Jobs en background: emails, importaciones, llamadas a IA o trabajo programado fallan o se ejecutan dos veces.
• Base de datos/estado: datos inconsistentes, migraciones temibles o estás almacenando archivos/sesiones en el sitio equivocado.

Una vez elijas un cuello de botella, puedes ignorar la mayoría del ruido.

Paso 2: Escoge el hosting más simple que elimine ese cuello de botella

Apunta a la menor cantidad de piezas móviles que cubran tu necesidad.

Si el tráfico es el problema, serverless o una plataforma gestionada suelen bastar porque escalan sin que configures servidores. Si las peticiones son largas o necesitas WebSockets, los contenedores pueden ser más sencillos que luchar contra límites.

Si los jobs son el problema, prioriza una cola real y un worker que pueda reintentar de forma segura. Eso puede seguir siendo serverless, pero solo si controlas timeouts y reintentos. Si no, un worker en un contenedor pequeño suele ser más fácil de razonar.

Si la base de datos es el problema, consigue primero una BD gestionada estable. La elección del hosting de la app importa menos que tener backups, migraciones y límites de conexión claros.

Paso 3: Ejecuta una pequeña prueba de carga y una prueba de fallo

Mantenlo pequeño. Buscas puntos de quiebre obvios.

Prueba de carga: simula un pico modesto (por ejemplo, 5–10x tu tráfico normal durante 10 minutos) y observa errores y latencias.

Prueba de fallo: fuerza que algo falle y confirma que se recupera limpiamente. La prueba más simple es un reinicio. Para jobs, también prueba reintentos: falla intencionadamente un job y confirma que se reintenta una vez y no duplica trabajo.

Paso 4: Define un flujo básico de despliegue

Necesitas un camino mínimo seguro del cambio en código a producción:

• Staging y producción (aunque staging sea pequeño)
• Un proceso de deploy que no dependa de clicks manuales
• Un plan de rollback (idealmente un comando o un ajuste)

Si no puedes explicar tu rollback en una frase, tu hosting no es “simple” todavía.

Paso 5: Planifica qué vas a monitorizar

Elige unas pocas señales que realmente comprobarás semanalmente: tasa de errores, latencia y fallos de jobs suelen bastar. Añade una señal de BD (consultas lentas o conteo de conexiones) si tu app depende mucho de la base de datos.

Trampas comunes que causan rehacer trabajo más tarde

La manera más rápida de perder un mes es elegir hosting por lo que suena “profesional” en lugar de por lo que tu app realmente hace. La opción correcta suele ser la que tu equipo puede operar con calma cada semana, no la que tiene el diagrama más bonito.

Una trampa es elegir contenedores porque parecen profesionales y luego descubrir que nadie quiere asumir el trabajo operativo. Los contenedores están bien, pero suelen implicar que debas manejar actualizaciones, monitorización, reglas de escalado y arreglos de incidentes. Si tu equipo es pequeño, ese trabajo aparece en el peor momento.

Serverless tiene la trampa opuesta: es fácil empezar, pero muerde cuando el trabajo dura demasiado. Si tienes procesamiento de vídeo, importaciones grandes, llamadas de IA encadenadas o generación de informes que tarda minutos, puedes alcanzar límites de tiempo o picos de coste. Los equipos luego añaden colas y workers y acaban rediseñando bajo presión.

Desencadenantes de rehacer trabajo a vigilar:

• Tratar los secretos como un pensamiento tardío (claves en código, .env compartidos, sin plan de rotación)
• Lanzar cambios de esquema y código en el mismo paso, sin rollback seguro
• Elegir una plataforma que complique los flujos de autenticación (callbacks, almacenamiento de sesiones, dominios personalizados)
• No planear las subidas de archivos y su almacenamiento desde temprano (dónde viven, permisos)
• Suponer que las características en tiempo real “simplemente funcionarán” (WebSockets, conexiones largas, consumidores en background)

Un ejemplo concreto: un prototipo puede usar una librería de login simple, guardar archivos en disco local y ejecutar un job nocturno dentro del servidor web. Eso parece bien en demos, pero en producción suele fallar cuando añades múltiples instancias o despliegas una nueva versión.

Ejemplo: llevar un prototipo generado por IA a hosting de producción

Un fundador lanza un prototipo construido con IA usando una herramienta como Replit o Cursor. Funciona en una laptop. Tras el lanzamiento, empieza a fallar en producción: usuarios reciben cierres de sesión aleatorios, emails se envían dos veces y la base de datos caduca durante picos.

Esto ocurre porque los prototipos suelen mezclar todo: peticiones web, trabajo en background (importaciones, emails) y acceso a base de datos en el mismo proceso. Cuando hay un pico, todo compite por los mismos recursos.

Recorriendo la tabla de decisiones

Tráfico: el lanzamiento trae tráfico espigado (ráfagas grandes por posts en redes). Esto apunta a una capa web/API que escale rápido. Las funciones serverless pueden encajar bien si las peticiones son cortas y sin estado. Si las peticiones son largas o necesitas control estricto del runtime, un servicio en contenedor pequeño suele ser más seguro.

Trabajos en background: enviar emails y ejecutar importaciones CSV no deberían ocurrir dentro de la petición web. Los picos vuelven lentos los servidores web y los reintentos pueden causar duplicados. Los jobs necesitan una cola y un worker que pueda correr más tiempo que el timeout típico de una petición.

Base de datos y auth: los timeouts vienen a menudo de demasiadas conexiones y consultas lentas. Los fallos de autenticación bajo carga suelen ser mezcla de cookies mal configuradas, almacenamiento de sesiones faltante o límites/tiempos de espera al llamar a la BD.

Una combinación realista de hosting para este caso:

• Serverless o un servicio web gestionado para la API (escalado rápido para tráfico espigado)
• Una cola gestionada y un worker (contenedor o job runner gestionado) para emails/importaciones
• Una base de datos gestionada con pooling de conexiones (y monitorización básica)
• Almacenamiento de secretos gestionado para que las claves no estén en el repo

No se trata de la pila más bonita. Se trata de separar responsabilidades para que un problema (importaciones) no tumbe todo.

Plan simple para la primera semana: estabilizar, luego optimizar

La primera semana debe centrarse en fiabilidad antes que en optimizar costes:

• Día 1: Añade logging de peticiones, tracking de errores y health checks para hacer visibles los fallos.
• Día 2: Mueve emails e importaciones a una cola + worker, añade idempotencia (no enviar dobles).
• Día 3: Arregla timeouts de BD con pooling, índices para consultas lentas y timeouts sensatos.
• Día 4: Estabiliza la autenticación (sesiones, cookies, redirecciones) y añade rate limiting básico.
• Día 5: Prueba de carga los flujos principales y ajusta límites de escalado para que un pico no provoque una factura sorpresa.

Lista de comprobación rápida y siguientes pasos

Si quieres elegir hosting tras un prototipo sin quedarte atrapado en comparaciones infinitas, mantén la decisión pequeña y práctica. No estás eligiendo “la plataforma para siempre”. Estás eligiendo el siguiente paso más seguro para usuarios reales.

Empieza con estas comprobaciones:

• Forma del tráfico: ¿mayoritariamente constante o espigada? Anota si los usuarios están mayormente en una región.
• Duración de los jobs: ¿son rápidos (segundos) o largos (minutos)? ¿Necesitan reintentos, programación o entrega garantizada?
• Crecimiento de la BD: ¿qué tan rápido crecerán los datos y necesitas migraciones o backups estrictos pronto?
• Estado y archivos: ¿guardas subidas, sesiones o archivos generados que deben sobrevivir reinicios?
• Responsabilidad del equipo: ¿quién está de guardia cuando algo se rompe y cuánto saben sobre despliegues y depuración?

Antes de lanzar algo público, ten lo básico mínimo en producción:

• Backups probados: no solo activados, sino restaurados al menos una vez.
• Logs buscables: peticiones, jobs y errores de BD en un mismo lugar.
• Alertas de errores: notificar a una persona rápidamente, con suficiente contexto para actuar.
• Rollbacks: una forma de deshacer un despliegue malo sin heroísmos.

Mantén una cosa simple a propósito. Para muchos equipos eso es usar una base de datos gestionada y evitar operaciones de BD personalizadas temprano, incluso si la elección del runtime de la app aún evoluciona. También escribe qué decides postergar (multi-región, autoscaling perfecto o colas complejas) para que no se convierta en una sorpresa más adelante.

Siguientes pasos que funcionan bien para la mayoría de equipos:

• Documenta tus decisiones en una página: runtime, jobs/cola, BD, almacenamiento y quién es responsable de cada cosa.
• Haz una prueba en producción pequeña: un lanzamiento limitado con monitorización real, luego arregla los principales problemas.
• Prueba de carga un flujo clave: registro, checkout o tu endpoint principal, lo suficiente para detectar límites obvios.
• Practica un fallo: reinicia la app, rompe una configuración o simula una acumulación en la cola y observa qué ocurre.
• Programa una revisión: dos semanas tras el lanzamiento, decide si te quedas o mejoras una pieza.

Si heredas código generado por IA que ya es frágil, vale la pena arreglar los fundamentos (auth, secretos, reintentos de jobs y patrones de acceso a BD) antes de cambiar de hosting. FixMyMess (fixmymess.ai) se centra en diagnosticar y reparar prototipos generados por IA para que estén listos para producción, incluyendo endurecimiento de seguridad y preparación para despliegue, y ofrecen una auditoría de código gratuita para revelar los problemas que suelen descarrilar las migraciones de hosting.