La arquitectura serverless te permite ejecutar aplicaciones basadas en servidor sin tener que administrar uno. Si trabajas en desarrollo o cloud computing, entender este modelo te ayuda a decidir cuándo conviene usarlo y qué obstáculos podrías encontrar.

La idea es simple pero poderosa: el cloud provider se encarga de toda la capa de sistema operativo, parches, escalabilidad y mantenimiento. Tú solo te concentras en el código de tu aplicación.

¿Qué significa serverless si igual hay servidores detrás?

La palabra puede confundir. Serverless no quiere decir que no existan servidores, significa que tú no los administras. El proveedor cloud te entrega una función o un contenedor donde pones tu código, y de ahí en adelante él se hace cargo de la infraestructura.

Esto cambia por completo el foco del trabajo. Ya no inviertes tiempo instalando antivirus, parchando el kernel o lidiando con un kernel panic. Ese tiempo lo dedicas a escribir código bonito, escalable y seguro.

¿Qué es serverless? Es un modelo donde ejecutas aplicaciones sin administrar servidores. El cloud provider gestiona el sistema operativo y la escalabilidad, y tú solo te encargas del código de tu aplicación.

¿Qué ventajas reales ofrece una arquitectura serverless?

Las funciones, APIs, streamings y bases de datos llave-valor en modo serverless escalan automáticamente según la cantidad de requests. Esa elasticidad viene acompañada de otros beneficios concretos.

• Escalabilidad automática según el volumen de peticiones, aunque limitada por las cuotas que define cada cloud provider [02:30].
• Seguridad enfocada en el código y el cifrado en tránsito, ya no en proteger el sistema operativo.
• Fiabilidad alta con SLAs que superan el 99 % de disponibilidad [03:45].
• Pago por uso real: tiempo de ejecución, memoria consumida y número de invocaciones.
• Ahorro de tiempo y dinero al eliminar tareas de administración de servidores.
• Mejor productividad del desarrollador gracias a despliegues rápidos y entornos de prueba ágiles.

Un ejemplo concreto del transcript: una función que convierte una imagen grande en miniatura para Platzi Wallet. Si tarda 200 milisegundos en ejecutarse, te cobran exactamente esos 200 milisegundos más la memoria usada [04:30]. Si la corres una vez al día, el costo tiende a cero. Si la ejecutas tres millones de veces al día, escala sin que tengas que mover un dedo y pagas por ese consumo.

¿Cuáles son los retos de adoptar serverless?

No todo es magia. Hay limitaciones técnicas que debes conocer antes de migrar una aplicación a este modelo.

¿Qué es el cold start y por qué importa?

El cold start o tiempo de inicio frío ocurre cuando una función lleva tiempo sin ejecutarse y necesita despertarse. Esa primera invocación puede tardar dos o tres segundos [06:50].

Para muchas aplicaciones eso es inaceptable. Si tu sistema necesita responder en menos de 100 o 200 milisegundos, el cold start puede romper la experiencia de usuario y obligarte a buscar alternativas o estrategias de calentamiento.

¿Cuánto tiempo puede correr una función?

Las funciones tienen un timeout máximo. En varios cloud providers ese límite es de 15 minutos de ejecución [07:50]. Si tu proceso necesita correr 30 minutos, una función serverless no es la herramienta correcta y tendrás que mover ese workload a otro servicio.

¿Qué es el cold start en serverless? Es el retraso de 2 a 3 segundos que sufre una función cuando lleva tiempo inactiva y debe inicializarse antes de procesar la petición.

¿Cómo afecta serverless al consumo de IPs y a la conectividad?

Si colocas una función lambda dentro de una VPC (virtual private cloud) y se ejecuta 10 millones de veces al día, el consumo de direcciones IP se dispara [08:40]. La recomendación es ubicar los servicios serverless fuera de la VPC siempre que sea posible, salvo que necesiten comunicarse con componentes internos de la red.

¿Qué es el vendor lock-in en arquitecturas serverless?

El vendor lock-in aparece porque cada cloud provider implementa sus servicios serverless de forma distinta. Si tienes Platzi Wallet corriendo con Azure Functions y Azure API Manager y decides migrar a AWS, lo más probable es que tengas que reescribir buena parte de la aplicación [09:50].

¿Qué es vendor lock-in? Es la dependencia técnica que te ata a un cloud provider porque sus servicios serverless no son compatibles con los de la competencia, dificultando una migración.

¿Cuándo conviene elegir serverless para tu aplicación?

La decisión depende del tipo de carga de trabajo. Conviene cuando tu aplicación tiene tráfico variable, cuando quieres pagar solo por lo que usas y cuando la velocidad de despliegue importa más que tener control total sobre el sistema operativo.

No conviene cuando necesitas tiempos de respuesta bajísimos sin tolerancia al cold start, cuando tus procesos superan los límites de tiempo de cómputo o cuando la portabilidad entre nubes es un requisito crítico.

Con estos criterios ya puedes evaluar una arquitectura serverless con cabeza fría. ¿Qué reto crees que sería el más difícil de resolver en tu próximo proyecto? Cuéntamelo en los comentarios.