Sin servidor para aplicaciones: arquitectura en la práctica

Comprender sin servidor es una cosa. Implementarlo bien es otra muy distinta. Muchas personas que abrazaron el concepto descubrieron, en el camino, que la tranquilidad prometida iba acompañada de decisiones difíciles que nadie había mencionado.

La distancia entre el serverless de las diapositivas y el serverless del código de producción es donde los equipos salen perjudicados. No porque la tecnología sea mala, sino porque requiere una forma de pensar que pocos desarrollan antes de estar en problemas.

Este texto es para aquellos que decidieron construir con serverless y quieren hacerlo bien. Hablemos de las decisiones de diseño reales, los obstáculos que aparecen en la implementación y la disciplina que separa una arquitectura sólida de un montón de funciones que son difíciles de mantener.

La engañosa facilidad del comienzo

Serverless tiene un comienzo seductor. En unos minutos subes tu primera función, responde y parece que todo será así de sencillo. Ahí es donde está la trampa.

El problema no es escribir una función. Se trata de escribir cincuenta funciones que se comunican entre sí, comparten lógica, dependen de datos y deben ser comprendidas por un equipo seis meses después. La complejidad no desaparece con serverless. Cambia de ubicación, deja la infraestructura y pasa a la arquitectura.

Aquellos que no se dan cuenta de esto construyen lo que se llama un "monolito distribuido": todas las desventajas de un sistema distribuido, sin ninguna de las ventajas de un diseño bien pensado. Es el peor de todos los mundos y es más común de lo que piensas.

La tesis: la tecnología serverless requiere más diseño, no menos

Aquí está mi posición central. Serverless no prescinde de la arquitectura, exige más de ella.

Cuando gestionas servidores, parte de la disciplina la impone la infraestructura. Te ves obligado a pensar en cómo están organizadas las piezas. Serverless elimina esta imposición y devuelve la libertad total. Y la libertad sin disciplina se convierte en caos.

Por lo tanto, implementar bien sin servidor es un ejercicio de diseño consciente. Es necesario decidir, a propósito, cómo dividir las responsabilidades, cómo se comunican las funciones, dónde vive el Estado y cómo todo sigue siendo comprensible. Aquellos que tratan la tecnología sin servidor como "código rápido sin servidor" obtienen deuda técnica a una velocidad récord.

Decisiones de diseño que definen el resultado

Granularidad: qué tan pequeña debe ser cada función

La primera decisión difícil es el tamaño. Las funciones demasiado pequeñas multiplican la complejidad de la comunicación. Las funciones que son demasiado grandes pierden los beneficios de la modularidad y la escalabilidad independiente.

Una buena regla general es organizar los roles en torno a responsabilidades comerciales claras, no a operaciones triviales. Cada función debe hacer algo coherente y comprensible. Resiste la tentación de fragmentarlo todo en microtrozos, la seducción de lo "extremadamente granular" suele terminar en la ingobernabilidad.

Estado: dónde residen realmente los datos

Las funciones sin servidor son, por naturaleza, sin estado. Nacen, ejecutan y mueren. Esto significa que todo estado necesita vivir fuera de ellos, en bases de datos, cachés y almacenes.

Este es uno de los mayores cambios de mentalidad. No puedes guardar nada en la memoria entre ejecuciones. Toda persistencia es explícita y externa. Diseñar bien esto, elegir los almacenes adecuados para cada tipo de datos, es lo que separa una aplicación confiable de una llena de comportamiento impredecible.

Comunicación: cómo las piezas se comunican entre sí

En una arquitectura real sin servidor, las funciones necesitan interactuar. La decisión de cómo se comunican, de forma sincrónica, esperando una respuesta, o de forma asincrónica, a través de eventos y colas, da forma a toda la robustez del sistema.

La comunicación asincrónica, a través de eventos, tiende a aportar más resiliencia: si una parte falla, el mensaje espera. Pero añade complejidad al seguimiento. La comunicación síncrona es más sencilla de entender, pero crea acoplamiento y propaga fallos. Esta elección no es técnica menor, sino estructural.

Un ejemplo de implementación consciente

Imagine crear el backend de una aplicación de entrega usando serverless. El flujo de un pedido implica varios pasos: validación, cobro, notificación al restaurante, seguimiento de la entrega.

La implementación ingenua crearía una función gigante que intentaría orquestar todo de forma sincrónica. Resultado: lento, frágil e imposible de depurar. Si la notificación falla, toda la solicitud se bloquea.

La implementación consciente separa responsabilidades. Una función recibe y valida la solicitud, registrándola. Esto emite un evento que activa de forma independiente la facturación, la notificación y el seguimiento. Cada parte falla y se recupera por sí sola. El estado del pedido se guarda en una base de datos accesible para todos.

La diferencia entre los dos no es la tecnología. Es el cuidado del diseño que se tuvo antes de escribir la primera línea.

Los peligros de la implementación

El primer problema es la depuración. Cuando algo sale mal en un sistema distribuido en docenas de funciones y eventos, es difícil encontrar la causa. Sin un seguimiento adecuado desde el principio, quedarás ciego. Invertir en observabilidad no es opcional, es una condición para la supervivencia.

El segundo es la explosión de la configuración. Cada función tiene sus permisos, sus variables, sus disparadores. A escala, gestionar esto manualmente se convierte en una fuente de errores. Tratar la infraestructura como código, versionada y automatizada, deja de ser un refinamiento y se convierte en una necesidad.

La tercera es la ilusión de aislamiento. Las funciones parecen independientes, pero comparten bancos, colas y límites de proveedores. Una función mal comportada puede afectar a las demás. Pensar en estas dependencias invisibles es parte del trabajo.

La disciplina es la verdadera infraestructura

Lo que he descubierto, en la práctica, es que [sin servidor] no elimina el trabajo duro, sino que lo desplaza. Se deja de cuidar las máquinas y se empieza a cuidar el diseño, la comunicación y el estado. Para quienes abordan esto con disciplina, el resultado es poderoso: sistemas flexibles, escalables y rentables.

Para quienes lo tratan como un atajo, el resultado es un enredo que nadie entiende y nadie quiere mantener. La tecnología es la misma. Lo que cambia es el rigor de quienes lo esgrimen.

Sin servidor no es más fácil. Es diferente. Y la diferencia se gana con diseño, no con prisas.

Si está implementando una arquitectura [sin servidor] y desea evitar los errores clásicos, vale la pena cambiar de opinión. Tengo otros artículos en el blog sobre el concepto serverless, casos de uso y operaciones del día a día que complementan esta visión de implementación.