Serverless vs. servidor: cómo alojar una app pequeña

En resumen: Un servidor tradicional cobra las 24 horas del día, lo uses o no; el pago por uso (serverless) cobra solo cuando alguien usa la aplicación. Para una app interna que se usa en horario de oficina, el pago por uso o una plataforma administrada suele salir más barato. El riesgo está en los picos: pon alertas y límites de gasto desde el primer día.

Dónde alojar una aplicación suele decidirse por costumbre: se alquila un servidor y listo. Para una app pequeña, eso puede significar pagar todo el mes por una máquina que trabaja unas pocas horas al día. Aquí comparamos las opciones comunes sin tecnicismos, para que puedas preguntarle con criterio a quien te construya el sistema.

Si algún término no te suena, en el glosario de tecnología para gerentes están explicados en lenguaje sencillo.

¿Qué significa alojar una aplicación?

Es alquilar el lugar donde corre tu aplicación y donde se guardan sus datos, para que tu equipo la use desde internet. Ese lugar es lo que se conoce como hosting o infraestructura.

Una analogía útil es la de un local comercial:

• Servidor tradicional: arriendas un local y pagas el mes completo, abras o no.
• Plataforma administrada: arriendas un local en un centro comercial que se encarga de la seguridad, el aseo y los servicios.
• Pago por uso: pagas por horas en un coworking, solo cuando lo usas.
• Sitio estático: pones una vitrina que muestra siempre lo mismo y casi no gasta.

¿Cuáles son las opciones para alojar una app pequeña?

Hay cuatro opciones comunes, y muchas aplicaciones combinan dos o más.

Servidor tradicional o VPS: pagas 24/7

Es una máquina virtual encendida todo el tiempo. Pagas una tarifa mensual fija, sin importar si la app recibió mil visitas o ninguna. Tienes control total y también la responsabilidad: alguien tiene que aplicar parches de seguridad, configurar respaldos y vigilar que no se caiga.

Plataformas administradas

Subes tu aplicación y el proveedor se encarga del sistema operativo, los certificados, las publicaciones de nuevas versiones y parte de la escalabilidad. Pagas por un plan, normalmente mensual. Por la misma capacidad pueden costar algo más que un servidor básico, pero te ahorran mucho trabajo de mantenimiento.

Serverless o pago por uso

El código se ejecuta solo cuando llega una petición: alguien abre una pantalla, envía un formulario o una integración pide un dato. Pagas por esas ejecuciones y por el tiempo que duran. Si nadie usa la app un fin de semana, el costo de ese fin de semana es cercano a cero. El nombre engaña un poco: sí hay servidores, pero los administra el proveedor y tú no pagas por tenerlos encendidos.

Sitios estáticos

Son páginas que se generan una vez y se sirven tal cual desde una red de distribución de contenido. Es la opción más barata y rápida, pero solo sirve para contenido que no cambia según quién lo mire, como una página corporativa o un blog. Se puede combinar con funciones de pago por uso para lo dinámico, por ejemplo un formulario de contacto.

Un detalle que se olvida: la base de datos. En muchas arquitecturas de pago por uso es la pieza que sigue encendida todo el tiempo. Algunas también cobran por uso o se pausan sin actividad, pero conviene revisarlo, porque puede ser la parte más grande de la factura.

¿Qué opción conviene según el tipo de aplicación?

En infraestructura para pymes no hay una opción mejor en abstracto; hay una que encaja con cómo se usa tu aplicación. Esta tabla resume las diferencias:

Opción	Cómo cobra	A favor	En contra	Ideal para
Servidor o VPS	Tarifa fija mensual, 24/7	Costo predecible; control total	Pagas las horas ociosas; tú administras parches y respaldos	Carga constante o software que exige servidor propio
Plataforma administrada	Plan mensual según capacidad	Menos mantenimiento; publicar versiones es sencillo	Menos control; puede costar más por la misma capacidad	Apps de negocio con uso moderado y constante
Serverless o pago por uso	Por ejecución, tiempo y datos transferidos	Casi cero costo sin uso; crece solo	Factura variable; arranque en frío; más amarrado al proveedor	Apps internas en horario de oficina, integraciones, tareas programadas
Sitio estático	Muchas veces gratis o casi gratis	Rapidez, seguridad, costo mínimo	Solo contenido que no cambia por usuario	Páginas corporativas, blogs, documentación

¿Por qué el pago por uso suele ser más barato para apps internas?

Porque una app interna pasa la mayor parte del tiempo sin que nadie la use. Si tu equipo trabaja de lunes a viernes, de 7:00 a. m. a 5:00 p. m., la aplicación está en uso unas 220 horas de las casi 730 que tiene un mes. Un servidor encendido cobra también las otras 510.

Y aun dentro del horario de oficina, el uso no es continuo. Con pago por uso, pagas por los momentos en que alguien consulta o registra algo, no por el tiempo entre ellos.

El cálculo cambia si la aplicación tiene uso constante día y noche o hace procesamiento pesado todo el tiempo. En ese caso, pagar por cada ejecución puede terminar costando más que una tarifa fija. Hay un punto de equilibrio, y vale la pena estimarlo antes de elegir.

La infraestructura prendida sin hacer nada es uno de los cuatro costos que suelen quedar por fuera de la cuenta, como explicamos en el costo real del software que ya estás pagando.

¿Qué riesgos tiene el pago por uso en la nube?

El principal es la factura variable: si el uso se dispara, el costo también, y a veces te enteras cuando llega la factura. Las causas más comunes de un pico inesperado:

• Un error en el código que hace llamadas en bucle, por ejemplo una integración que se reintenta sin parar.
• Bots o tráfico malicioso que golpean la aplicación.
• Una campaña exitosa que multiplica las visitas de un día para otro.
• Costos secundarios que no se miraron: transferencia de datos, almacenamiento de archivos o registros de actividad.

Cómo protegerte desde el primer día:

1. Configura alertas de presupuesto para que te avisen, por ejemplo, al llegar a la mitad, a tres cuartas partes y al total de lo que esperas gastar en el mes.
2. Pon límites de gasto donde el proveedor lo permita. Algunos ofrecen un tope que detiene el servicio; otros solo envían avisos. Pregunta cuál es tu caso.
3. Limita la cantidad de peticiones que la aplicación acepta por usuario o por minuto.
4. Revisa la factura cada semana durante el primer mes, hasta entender el patrón normal.
5. Define quién recibe las alertas. Una alerta que llega a un correo que nadie lee no protege nada.

Hay dos riesgos menores: el arranque en frío, porque la primera petición tras un rato sin uso tarda un poco más, y la dependencia del proveedor, porque cada nube tiene funciones propias y mudarse exige ajustes.

¿Sirven los planes gratuitos para una aplicación de empresa?

Sirven para empezar y para aplicaciones pequeñas, siempre que conozcas sus límites. Los más comunes:

• Pausas por inactividad. Algunos planes gratuitos duermen el proyecto o la base de datos tras un tiempo sin uso. El primer usuario después de la pausa espera, o alguien tiene que reactivarlo a mano.
• Topes mensuales de ejecuciones, ancho de banda o almacenamiento. Si los pasas, el servicio se detiene o empieza a cobrar.
• Sin garantías ni soporte. Si algo falla, no hay a quién reclamar.
• Condiciones que cambian. Los proveedores ajustan sus planes gratuitos con el tiempo, y las condiciones de uso permitido varían entre ellos. Léelas antes de montar algo crítico.

Si la operación diaria depende de la app, usa el plan gratuito para validar y ten claro cuánto costaría el plan pago.

¿Cómo alojamos nuestra propia web?

Con un sitio estático en un plan gratuito, a cero pesos al mes de infraestructura. En CodeLess Co construimos la web con Next.js compilado a páginas estáticas y alojado en el plan gratuito de Vercel. Los artículos del blog son archivos de texto en el repositorio de GitHub, sin base de datos, y un panel de administración propio los publica a través de la API de GitHub. Los detalles están en esta página cuesta cero pesos al mes.

Funciona porque es un blog con pocos autores y un contenido que cambia pocas veces por semana. Si mañana necesitáramos que muchos usuarios iniciaran sesión y vieran información propia, agregaríamos una base de datos y funciones de pago por uso. La regla no cambia: la cosa más simple que resuelve el problema.

¿Cuándo no conviene el pago por uso?

No conviene cuando la aplicación trabaja de forma constante o cuando necesitas un costo fijo sin sorpresas. En concreto:

• Carga continua las 24 horas, como una integración que procesa datos sin parar.
• Procesos largos, como reportes que tardan muchos minutos: muchas plataformas de pago por uso limitan cuánto puede durar cada ejecución.
• Software que exige instalarse en un servidor, como algunos programas comerciales.
• Un equipo sin tiempo para vigilar la factura. Si nadie va a revisar las alertas, un servidor de tarifa fija es más tranquilo, aunque pagues horas ociosas.

La infraestructura es solo una parte de lo que cuesta operar un sistema; el resto lo contamos en cuánto cuesta mantener un software a medida.

La idea de fondo

El costo de hosting de una aplicación depende menos de la tecnología que de cómo se usa. Pagar 24 horas por algo que se usa diez es la opción por defecto, no la más sensata. Cuando hacemos desarrollo de software a medida, elegimos la infraestructura según el uso real de la aplicación, buscando un costo bajo y predecible.

Si pagas un servidor encendido para una aplicación que se usa pocas horas al día, revisemos si hay una opción más simple. La primera conversación es gratis: cuéntanos cómo está alojada tu app.

Preguntas frecuentes

¿Qué es serverless en palabras simples?

Serverless es una forma de alojar aplicaciones en la que no alquilas un servidor encendido todo el tiempo: el código se ejecuta solo cuando alguien lo usa y pagas por esas ejecuciones. Los servidores existen, pero los administra el proveedor. Es útil para aplicaciones con uso intermitente, como apps internas, formularios o integraciones que corren algunas veces al día.

¿Cuánto cuesta el hosting de una aplicación pequeña?

Depende de cómo se use. Un sitio estático puede costar cero en un plan gratuito; una app con pago por uso y poco tráfico puede costar muy poco; un servidor encendido cobra una tarifa fija cada mes aunque nadie lo use. A eso hay que sumar la base de datos, el dominio y el tiempo de quien mantiene la infraestructura. Pide siempre una estimación mensual antes de elegir.

¿Se puede poner un límite de gasto en la nube?

Los principales proveedores de nube permiten configurar alertas de presupuesto que avisan cuando el gasto llega a cierto valor. Algunos permiten además un tope que detiene el servicio al alcanzarlo, y otros solo envían avisos. Revisa qué ofrece el tuyo, configura las alertas desde el primer día y asegúrate de que lleguen a alguien que las lea.

¿Qué pasa cuando un plan gratuito pausa mi aplicación?

La aplicación o su base de datos dejan de responder hasta que se reactivan. En algunos casos basta con que llegue una visita y el primer usuario espera un momento; en otros, alguien tiene que reactivarla manualmente desde el panel del proveedor. Para una app de la que depende la operación diaria, esa pausa es un riesgo que conviene evitar con un plan pago o una arquitectura sin esa dependencia.