IaaS, PaaS, SaaS y FaaS: seis preguntas antes de decidir dónde corre tu software

Una de nuestras herramientas, la de actas de reuniones con IA, tardaba entre siete y quince minutos en generar un acta compleja. En un servidor tradicional eso no era problema: la máquina estaba encendida y no había reloj. Cuando la movimos a una plataforma serverless para ganar velocidad, la plataforma cortó la ejecución a los cinco minutos, con el acta a medias.

El código estaba bien. Fallamos al tratar el lugar donde corre el software como un detalle operativo, cuando en realidad es una decisión de diseño.

Ese corte abrió una conversación interna en SKALLING con todo el equipo, técnico y no técnico. Esta es la versión ordenada: qué distingue a IaaS, PaaS, SaaS y FaaS, seis preguntas para elegir entre ellos y por qué, al final, nos importa más dejar escrito el porqué de cada decisión que acertar a la primera.

¿Qué diferencia hay entre IaaS, PaaS, SaaS y FaaS?

IaaS, PaaS, SaaS y FaaS son cuatro maneras de repartir la responsabilidad entre tu equipo y un proveedor. En IaaS arriendas máquinas virtuales y administras todo lo que corre encima. En PaaS entregas código y el proveedor lo despliega. En SaaS usas un software terminado. En FaaS subes una función que solo corre, y solo cobra, cuando alguien la invoca.

El NIST, en su definición SP 800-145 de 2011, estableció los tres primeros modelos de servicio. FaaS llegó después, como la forma más granular de lo que hoy se llama serverless. La tabla resume cómo se ve cada uno en la práctica:

Modelo	Qué contratas	Qué sigue siendo tuyo	Cómo te cobran	Ejemplos
On-premise	Nada: compras el hardware	Todo: sala, energía, red, sistema operativo, seguridad	Inversión inicial + costo fijo	Servidores propios
IaaS	Máquinas virtuales con CPU, RAM y disco	Sistema operativo, parches, runtime, aplicación	Tarifa fija por máquina encendida	VPS en Hetzner, AWS EC2
PaaS	Un lugar donde desplegar código	La aplicación	Por uso (CPU activa, memoria) o por plan	Vercel, Google App Engine
FaaS	La ejecución de una función	La función	Por invocación, duración y memoria	AWS Lambda, Cloudflare Workers
SaaS	Un software terminado	Configuración y datos	Suscripción	Webflow, ClickUp, Resend, Zapier

Dos precisiones que surgieron en la charla y que conviene tener claras.

La primera: los servidores propios en una sala fría, con control de humedad, firewall y alguien que los vigile, se llaman on-premise. IaaS empieza cuando el hardware lo pone otro y tú arriendas la máquina virtual. Un VPS es IaaS.

La segunda es la línea fina entre PaaS y SaaS. Muchos SaaS se consumen por API: Resend envía correos desde tu código y Zapier dispara automatizaciones desde otro sistema. Eso no los vuelve plataforma. En un PaaS tú llevas el código; en un SaaS llevas configuración y datos. Por eso un WordPress autoalojado no cabe en Vercel: necesita un servidor con PHP y una base de datos propia, es decir, una máquina que alguien administre.

¿Qué cambia entre un servidor encendido y una función que se apaga?

Cambian dos cosas: cómo pagas y cuánto tiempo te dejan correr.

Un VPS cobra lo mismo si recibe diez visitas o ninguna. Una madrugada sin uso cuesta igual que una tarde de alta demanda. En un PaaS o en una función, el recurso se enciende con cada petición, responde y se apaga; la noche en que nadie genera un acta no aparece en la factura.

A cambio, estas plataformas ponen reloj y límite de carga:

• Vercel corta una función a los 300 segundos (5 minutos) por defecto, y ese es el techo del plan gratuito. En los planes pagos Pro y Enterprise se puede subir a 800 segundos, y hasta 30 minutos con la duración extendida, hoy en beta y solo para algunos runtimes. El cuerpo de la petición o de la respuesta no puede pasar de 4,5 MB (documentación de Vercel).
• AWS Lambda permite hasta 15 minutos por invocación y 6 MB de payload en llamadas síncronas (cuotas de AWS Lambda).
• Cloudflare Workers mide otra cosa: tiempo de CPU, no tiempo de reloj. El límite por defecto es de 30 segundos de CPU y se puede subir a 5 minutos; esperar una base de datos o una API no cuenta (límites de Workers).

Hay un tercer factor que suele aparecer tarde: la distancia. Una función que corre en Virginia y consulta una base de datos en São Paulo paga esa latencia en cada ida y vuelta. Las edge functions acercan la ejecución al usuario. Cuando lo que manda es la base de datos, conviene más fijar la región de la función junto a ella. Vercel, por ejemplo, ejecuta en una sola región por defecto y permite elegirla.

¿Y si el proceso es más largo que el límite?

Hay dos caminos. El primero es pagar un plan con más tiempo de ejecución, si el proceso cabe en ese techo y el costo lo justifica. El segundo es partirlo en pasos, que es lo que hicimos con Actas de reuniones con IA. Los workflows de Vercel y de Cloudflare guardan el estado de cada paso, reintentan el que falla y retoman desde el último paso completo en vez de empezar de cero. El proceso total puede durar lo que necesite, siempre que cada tramo quepa en la ventana.

Partirlo en pasos nos obligó a rediseñar la lógica interna de Actas. Desde entonces tratamos el entorno de despliegue como una variable de diseño desde el día uno.

Cómo elegir entre IaaS, PaaS, SaaS y FaaS: seis preguntas

Sebastián las dejó como lista de bolsillo para el equipo. Se responden antes de escribir la primera línea de configuración:

1. ¿Tiene que estar encendido las 24 horas? Si escucha de forma continua (un buzón de correo, una cola, un socket), una plataforma que se apaga entre peticiones no le sirve.
2. ¿Cada cuánto lo van a llamar? Pocas llamadas al día hacen que una máquina fija pague horas ociosas. Miles de llamadas cortas hacen que la función sea la opción barata.
3. ¿Cuánto dura cada ejecución? Segundos o pocos minutos caben en PaaS y FaaS. Un proceso de quince minutos obliga a elegir: pagar un plan con más tiempo de ejecución, partirlo en pasos o llevarlo a una máquina sin reloj.
4. ¿Qué tan pesado es lo que le envías? Una película 4K de 20 GB no pasa por una función. Para eso existen servicios de archivos o una máquina con los códecs instalados.
5. ¿Qué tan pesada es la respuesta? Si la función devuelve un token o un sí/no, su costo es mínimo. Un reporte extenso consume tiempo facturable en la subida y en la bajada.
6. ¿Qué tan rápido tiene que responder, y dónde están sus datos? Si la latencia importa, la función va cerca de la base de datos o del usuario, según quién pese más.

Leídas juntas, las respuestas casi siempre apuntan a un modelo. Encendido permanente y ejecuciones largas: VPS. Llamadas cortas, frecuentes y con respuesta liviana: función. Un proceso largo que se puede dividir: PaaS con workflows. Algo que ya existe como producto y no es tu diferenciador: SaaS, sin culpa.

Un ejemplo de función en nuestra casa: el login que comparten varios de nuestros productos vive en una sola función serverless. Cada producto le pregunta si la credencial es válida, la función responde y cada uno sigue con su lógica. Un componente crítico, escrito una vez y reutilizado sin duplicar código.

Tres decisiones reales del equipo

La herramienta que migró

Actas de reuniones con IA, nuestro producto que convierte grabaciones de reuniones en actas formales, es el caso del inicio. Generar un acta compleja tomaba hasta quince minutos. Al moverlo a una plataforma serverless, el límite de cinco minutos lo cortó. Lo rediseñamos en pasos que guardan su estado y hoy carga más rápido y paga por uso. Antes de mover un producto, hay que mirar su proceso más largo.

El producto que decidimos no mover

Otro de nuestros productos tiene un panel con mucho volumen de datos y un proceso que lee un buzón de correo de forma continua. El panel ganaría velocidad en una plataforma serverless. El lector de correos, en cambio, necesita estar encendido siempre, justo lo que esa plataforma no ofrece.

Migrar era posible, pero exigía desacoplar ese proceso, montarlo en otro proveedor y pagar dos cuentas. Pusimos el beneficio al lado del trabajo y decidimos esperar. De ahí salió un patrón que ahora aplicamos a todo: primero identificar qué piezas no caben en el modelo nuevo, después ponerle precio al desacople y recién entonces decidir.

El script que vivía en un laptop

Una persona del equipo de growth mantenía actualizadas más de cincuenta páginas con un script propio. Cada fin de mes encendía su computador, lo corría y esperaba. Funcionaba, y ella misma vio el riesgo: si se tomaba vacaciones, el proceso se detenía.

En el camino apareció una confusión muy común. GitHub guarda y versiona el código, como un Drive para programas. Tiene GitHub Actions para tareas automáticas, pero está pensado para integrar y desplegar software, no para sostener un proceso de negocio. Ella había chocado con las políticas de seguridad de la plataforma al intentar recorrer sitios externos.

La solución no fue la arquitectura más moderna disponible. El mismo script pasó a una pequeña máquina Linux que el equipo ya tenía, con el código en el repositorio corporativo y commits cada vez que cambia algo. Si mañana crece, se evaluará una función o un workflow. Primero se resuelve con lo que hay a mano, se valida que sirva y después se migra. Es la misma lógica de piloto y escala que aplicamos en innovación y adopción.

¿Qué es un ADR y por qué lo adoptamos?

Un ADR (Architecture Decision Record) es un archivo corto que registra una decisión de arquitectura: el contexto, lo que se decidió, el estado y las consecuencias. Michael Nygard propuso el formato en 2011 en Documenting Architecture Decisions: una o dos páginas, guardadas junto al código, numeradas y nunca borradas. Cuando una decisión se revierte, el ADR antiguo queda marcado como reemplazado.

Llegamos a ellos por tres razones.

Pivotear cuesta. Probar un proveedor, romper algo y moverse a otro se paga con tiempo y con tarjeta de crédito. El informe State of the Cloud 2026 de Flexera, basado en 753 responsables de nube, estima en 29% el gasto en IaaS y PaaS que se desperdicia, la primera alza en cinco años.

La IA amplía el menú. Con asistentes que proponen tres arquitecturas por minuto, elegir parece más fácil y justificar se vuelve más difícil. Sin registro, a los seis meses nadie recuerda por qué se descartó la alternativa que hoy parece obvia.

Una certificación pide pruebas. Cuando llegue una auditoría, mostrar el porqué de cada decisión con fecha y contexto ahorra semanas.

La razón de fondo es otra: una decisión que vive en la cabeza de una sola persona es tan frágil como el script del laptop. Un ADR mínimo se ve así:

# ADR-007: Mantener el lector de correos en un VPS

Estado: aceptado (2026-10)

## Contexto
El servicio lee un buzón de forma continua. La plataforma serverless
apaga los recursos entre peticiones.

## Decisión
El servicio sigue en el VPS. El panel se evaluará por separado.

## Consecuencias
Costo fijo mensual. El panel no gana velocidad por ahora.
Revisar si el volumen de datos se duplica.

¿Cuándo se justifica volver a tener hardware propio?

Se justifica cuando el volumen es sostenido y predecible, y el costo fijo de operarlo resulta menor que la factura por uso. Antes de eso, casi nunca.

La pregunta quedó abierta en la charla con un caso hipotético: un agente de IA que haga de coach para un equipo comercial. Los tokens pueden comprarse a un proveedor o generarse con un modelo propio en una máquina con GPU. La máquina propia trae energía, mantenimiento, fallas que alguien tiene que investigar y horas de equipo que dejan de ir al producto. No basta con ir a una tienda y comprar un computador con una tarjeta gráfica potente: hay que pasarlo por las mismas seis preguntas, con números.

Lo que nos llevamos

La infraestructura correcta no es la más moderna: es la que el equipo puede explicar dentro de un año. Eso exige tres hábitos. Hacer las seis preguntas antes de desplegar, resolver primero con lo que hay a mano y escribir un ADR cada vez que la respuesta no es obvia.

Lo mismo vemos en los equipos de TI de minería, salud y banca con los que trabajamos. La herramienta pocas veces es lo que falla. Falla la capacidad de decidir con criterio y de sostener la decisión cuando cambia la gente. De eso trata nuestro trabajo en excelencia operacional TI, y por eso vale la pena distinguir cuándo conviene comprar software como servicio y cuándo construir con low-code.

Preguntas frecuentes sobre IaaS, PaaS, SaaS y FaaS

Fuentes

• NIST. SP 800-145, The NIST Definition of Cloud Computing, 2011. csrc.nist.gov
• Vercel. Vercel Functions Limits, consultado en octubre de 2026. vercel.com
• AWS. Lambda quotas, consultado en octubre de 2026. docs.aws.amazon.com
• Cloudflare. Workers limits, consultado en octubre de 2026. developers.cloudflare.com
• Michael Nygard. Documenting Architecture Decisions, Cognitect, 2011. cognitect.com
• Flexera. 2026 State of the Cloud Report, 2026. flexera.com

Si tu equipo está por mover un sistema, o heredó decisiones de arquitectura que nadie sabe explicar, conversemos.

Hablemos 30 min