Ejecutar una aplicación sin preocuparte por el sistema operativo, los parches o la infraestructura suena casi mágico, pero es exactamente lo que promete el modelo serverless. Comprender este concepto te dará el criterio necesario para evaluar si tu próximo proyecto debería adoptar esta arquitectura o si los retos que implica requieren otra estrategia.
¿Qué significa realmente serverless?
El término serverless —literalmente "sin servidor"— no significa que los servidores desaparezcan. Significa que tú no los administras [0:42]. El cloud provider se encarga de todo lo relacionado con el sistema operativo: parcheo, actualizaciones, escalabilidad y seguridad de la infraestructura. A cambio, te entrega una función o un contenedor serverless donde solo depositas tu código [1:18].
De esta forma, problemas como un kernel panic, la instalación de antivirus o la desactualización del sistema operativo pasan a ser responsabilidad exclusiva del proveedor de nube [1:42]. Tu único foco queda en lo más importante: el código de tu aplicación.
¿Qué ventajas ofrece una arquitectura serverless?
¿Cómo funcionan la escalabilidad y los límites?
Los servicios serverless —APIs, funciones, streamings, bases de datos llave-valor— escalan automáticamente según la cantidad de requests que reciben [2:14]. Sin embargo, esa escalabilidad tiene cuotas y límites definidos por el cloud provider. Por ejemplo, una función podría tener un límite de mil ejecuciones concurrentes por segundo [2:35]. Estos límites suelen ampliarse mediante un ticket de solicitud al proveedor.
¿Cómo cambia el enfoque de seguridad?
Al dejar de administrar servidores, la seguridad del sistema operativo deja de ser tu problema [3:05]. El enfoque se traslada a:
- Proteger el código que publicas en la función.
- Garantizar cifrado en tránsito en las comunicaciones.
- Aprovechar los SLA del proveedor, que suelen comprometer disponibilidad por encima del 99 % [3:24].
¿Cómo funciona el modelo de pago por uso?
El cobro se basa en ejecución real. Si una función tarda doscientos milisegundos en convertir una imagen grande en miniatura, pagas por esos doscientos milisegundos y por la memoria utilizada [3:48]. Si la ejecutas una vez al día, el costo tiende a cero; si la ejecutas tres millones de veces, pagas por cada ejecución [4:12]. Las variables de precio incluyen:
- Cantidad de peticiones.
- Tiempo de ejecución.
- Cantidad de tráfico consumido.
Otra ventaja significativa es el ahorro de tiempo y dinero [4:34]. El equipo que antes dedicaba horas a instalar y mantener servidores ahora redirige ese esfuerzo al desarrollo. Además, la productividad del desarrollador mejora notablemente: con un código de ejemplo en Python y una cuenta en tu cloud provider, puedes tener una función corriendo en diez o quince minutos [5:20].
¿Cuáles son los retos de serverless que debes considerar?
El primer reto es el cold start o tiempo de inicio frío [5:52]. Cuando una función no se ha ejecutado recientemente, necesita "despertarse" antes de responder, lo que puede añadir dos o tres segundos de latencia. Para aplicaciones que exigen respuestas por debajo de cien o doscientos milisegundos, esto representa un problema real [6:18].
El segundo reto es el tiempo de cómputo [6:40]. Algunos proveedores limitan la ejecución de una función a un máximo de quince minutos. Si tu proceso necesita treinta minutos, un timeout cortará la ejecución y tendrás que buscar un servicio alternativo [6:55].
¿Cómo afecta la conectividad y el vendor lock-in?
Desplegar funciones serverless dentro de una VPC (Virtual Private Cloud) puede generar un alto consumo de direcciones IP, especialmente si la función se ejecuta millones de veces al día [7:22]. La recomendación es ubicar estos servicios fuera de la red a menos que necesiten comunicarse con componentes internos [7:45].
Por último, el vendor lock-in es un reto estratégico [7:58]. Los servicios serverless no funcionan igual entre proveedores. Si despliegas tu aplicación con Azure Functions y Azure API Manager, migrar a AWS probablemente implica reconstruir la aplicación desde cero [8:18].
Con estas ventajas y retos claros, ya cuentas con el criterio para evaluar cuándo serverless es la mejor opción para tu arquitectura. ¿Has enfrentado alguno de estos retos en tus proyectos? Comparte tu experiencia en los comentarios.
