Serverless para aplicaciones: arquitectura con ejemplos reales

La tecnología sin servidor es fácil de explicar en abstracto y difícil de visualizar en la práctica. La mayoría de las introducciones hablan de funciones, eventos y escalabilidad automática, que son conceptos correctos, pero no ayudan a quienes necesitan decidir si eso se adapta al problema en cuestión.

La mejor manera de entender sin servidor es ver dónde brilla realmente. ¿Qué problemas concretos resuelve mejor que las alternativas? Qué patrones se repiten en arquitecturas que funcionan.

Este texto intercambia teoría por ejemplos. Miremos arquitecturas reales, de esas que aparecen todos los días en los productos digitales, y entendamos por qué serverless tiene sentido en cada una. No para vender la tecnología, sino para permitirle reconocer cuándo es la elección correcta.

El patrón detrás de casi todos los buenos usos de la tecnología sin servidor

Antes de los ejemplos, cabe señalar una cosa. Las mejores aplicaciones [sin servidor2] comparten una característica: son tareas que suceden en respuesta a un evento y no necesitan estar ejecutándose todo el tiempo.

Algo sucede, llega un archivo, un usuario hace clic, se llega a una hora, se recibe un mensaje y una función se despierta, hace su trabajo y vuelve a dormir. Sólo pagas por el momento de la ejecución. No hay ninguna máquina esperando.

Cuando internalizas este patrón, comienzas a ver oportunidades sin servidor en todas partes. Y también empieza a reconocer dónde no encaja.

Ejemplo 1: procesamiento de carga

Imagine un producto donde los usuarios envían imágenes, documentos, fotos de perfil, recibos. Cada carga debe ser procesada: redimensionada, validada y tal vez analizada.

En una arquitectura tradicional, los servidores se mantendrían listos para este procesamiento, inactivos la mayor parte del tiempo y sobrecargados durante los picos. En sin servidor, el flujo es diferente. El archivo llega al almacenamiento, este evento activa una función, la función procesa la imagen y finaliza.

Si llegan mil cargas simultáneas, la plataforma ejecuta mil ejecuciones en paralelo. Si no llega ninguno, no pagas nada. El ajuste es perfecto porque el trabajo se basa en eventos y es intermitente, exactamente el terreno donde gana serverless.

Ejemplo 2: API con tráfico irregular

Piense en una API de backend para una aplicación que tiene horas pico bien definidas. Una aplicación de transporte utilizada mañana y noche. Un sistema de programación de citas con ráfagas a principios de mes.

Mantener servidores con el tamaño adecuado significa pagar por la capacidad inactiva en los valles. Dimensionar el valle significa no manejar la cima. Es un dilema clásico.

Una API sin servidor resuelve esto de manera elegante. Cada solicitud desencadena una ejecución y la plataforma escala según el tráfico. En la cima, escala; en el valle, recoger. Usted realiza un seguimiento de la curva de uso real en lugar de provisionar para el peor de los casos. Para el tráfico irregular, este es uno de los casos de uso más rentables.

Ejemplo 3: automatizaciones y tareas programadas

Muchas organizaciones viven de pequeñas automatizaciones. Genera un informe cada mañana. Envía recordatorios en momentos específicos. Sincronizar datos entre sistemas periódicamente. Borrar registros antiguos.

Tradicionalmente, estas tareas requerían un servidor funcionando todo el tiempo sólo para funcionar unos minutos al día. Un desperdicio. En serverless, defines el disparador, una hora, por ejemplo, y la función solo se ejecuta en ese momento.

Para un gobierno municipal, esto podría significar consolidar los datos del servicio todas las noches o activar notificaciones de impuestos adeudados sin mantener una infraestructura dedicada. Tareas administrativas que se ejecutan solas, costando sólo los segundos que ocupan.

Ejemplo 4: arquitectura basada en eventos entre servicios

El ejemplo más sofisticado es también el más poderoso. Las aplicaciones modernas suelen constar de varias partes que deben reaccionar entre sí.

Se realiza un pedido. Esto necesita actualizar el inventario, notificar al cliente, registrar la transacción y tal vez activar la logística. En lugar de que un sistema monolítico haga todo de forma acoplada, cada una de estas reacciones puede ser una función independiente, desencadenada por el evento de “orden realizada”.

Esta arquitectura basada en eventos es naturalmente sin servidor. Cada pieza es pequeña, independiente y escala por sí sola. Si un componente falla, los demás continúan. La flexibilidad es enorme, aunque como veremos, trae consigo su propia complejidad.

La tesis: la tecnología sin servidor se trata de idoneidad, no de superioridad

Lo que estos ejemplos revelan es mi posición central. Serverless no es ni mejor ni peor que las arquitecturas tradicionales. Es diferente y su valor depende enteramente de su adecuación al problema.

Cuando el trabajo se basa en eventos, es intermitente y variable, sin servidor suele ser una excelente opción. Cuando el trabajo es constante, predecible y sensible a la latencia, otros enfoques pueden resultar más útiles.

La madurez técnica no está en adoptar la tecnología sin servidor para la moda, sino en reconocer la forma del problema y elegir la herramienta que se ajuste. Los ejemplos anteriores comparten una firma común y es esta firma la que debes aprender a identificar.

Errores que aparecen en la práctica

El primer error es forzar serverless donde no encaja. Las aplicaciones con procesamiento largo y continuo, o que dependen de una latencia baja constante, sufren las limitaciones del enfoque. La adaptación forzada genera frustración y costos.

El segundo es subestimar la complejidad distribuida. Las arquitecturas basadas en eventos, con docenas de funciones, pueden convertirse en una maraña difícil de entender y depurar. Más flexibilidad significa más piezas comunicándose entre sí, y eso requiere disciplina de diseño.

El tercero es ignorar los costos en una escala extrema. Para volúmenes muy altos y constantes, el modelo de pago por ejecución puede resultar más caro que las máquinas dedicadas. Vale la pena hacer cuentas, no asumir ahorros.

Reconocer el patrón es lo que importa

Después de estos ejemplos, la lección práctica es sencilla. Aprenda a reconocer el formato de problema que serverless resuelve bien: eventos, intermitencia, variabilidad, independencia entre partes.

Cuando ves este patrón, la decisión se vuelve natural. Y cuando no lo ve, se ahorra la molestia de adoptar una arquitectura que no se ajusta a lo que necesita hacer.

La buena arquitectura no se trata de elegir la tecnología más nueva. Es elegir el que se adapta al problema como una pieza que siempre ha faltado.

Si está diseñando una arquitectura y quiere analizar dónde encaja realmente sin servidor en su caso, vale la pena hablar de ello. Tengo otros artículos en el blog sobre serverless en la práctica y en la vida cotidiana, con enfoque en ejecución y operación, para aquellos que ya han decidido seguir este camino.