El poder de lo simple en la modernización

El 12 de octubre de 2026 AWS anunció Lambda Web Functions: la posibilidad de desplegar en Lambda un servidor HTTP común, el mismo Express que corre en la laptop con node index.js, sin que sea necesario convertirlo en un handler de eventos. Tan simple que se logra con un comando, una URL HTTPS, y si se quiere, varias regiones detrás de un solo dominio.

Técnicamente, la idea ya existía. Google Cloud Run ya ofrece servidores que escuchan en un puerto, y Vercel ya cobra solo por CPU activa. Lo interesante, desde la óptica de la modernización es en lo que el anuncio deja ver entre líneas: que durante una década pedimos a los equipos adaptar su código a la plataforma, cuando lo razonable era lo contrario.

Lambda es solo el punto de partida. El tema de este artículo es el poder de lo simple como criterio de arquitectura en la modernización de aplicaciones, y la parte de esa decisión que conviene mantener en manos humanas.

Qué dice el anuncio de AWS Lambda pasa a tener tres formas: Event Functions (la Lambda de siempre), Web Functions (servidores HTTP) y MicroVMs (entornos aislados con estado para código no confiable). Las tres corren sobre Firecracker y comparten el modelo operativo. Lo que cambia en Web Functions:

• Modelo de programación HTTP nativo. El código escucha en el puerto que indica la variable AWS_LAMBDA_HTTP_ENDPOINT. Express, Hono, Fastify o Next.js funcionan sin adaptadores como serverless-http o Lambda Web Adapter.

• Concurrencia por entorno. Hasta 128 solicitudes simultáneas por entorno de ejecución, en lugar de una solicitud por entorno.

• Facturación por CPU activa. Se cobra el tiempo de CPU que el código realmente consume, más la memoria durante toda la vida del entorno, solicitudes y transferencia. Esperar a la base de datos casi no cuesta CPU, pero la memoria sigue corriendo.

• Multirregión con un comando. --regions us-east-1,eu-west-1,ap-northeast-1 replica el código y configura enrutamiento por latencia detrás de una URL global.

• Revisiones inmutables y canary. Un endpoint puede repartir tráfico entre dos revisiones (90/10, por ejemplo) sin herramientas adicionales.

Lo que no anunció, y hay que saber:

• Solo Node.js (nodejs24.x sobre Arm64). Java, .NET y Python, que dominan el legado empresarial en la región, quedan fuera por ahora.

• Cinco regiones: Virginia, Ohio, Oregón, Tokio e Irlanda. Ninguna en Latinoamérica; São Paulo no está.

• Dominio propio y WAF requieren CloudFront delante del endpoint.

• Despliegue como .zip, sin soporte para imágenes de contenedor.

Impacto en la modernización: dónde sí y dónde todavía no El aporte de estas alternativas como lambda-web-functions es que elimina un paso intermedio que muchas veces bloqueaba la modernización: reescribir la aplicación para que cupiera en el modelo de eventos. Ese paso convertía un "movamos esto a serverless" en un proyecto de refactorización, con su presupuesto, su riesgo y su comité.

Dónde tiene sentido:

• APIs y BFF en Node.js que hoy corren en EC2, Elastic Beanstalk o un ECS subutilizado. Se pueden mover casi sin tocar código y apagar infraestructura.

• Aplicaciones con SSR (Next.js, React Router) que hoy dependen de capas de hosting adicionales o de adaptadores frágiles.

• Endpoints de IA que transmiten tokens. Pasan la mayor parte del tiempo esperando al modelo; con CPU activa, esa espera deja de ser el costo dominante.

• Strangler fig. Una ruta nueva de un monolito se puede servir desde un Web Function detrás de CloudFront sin introducir un segundo modelo de programación en el equipo.

Dónde todavía no:

• El grueso del legado empresarial. En banca, seguros y gobierno de la región, lo que hay que modernizar está escrito en Java, .NET o RPG. Para esos casos, el anuncio por ahora solo marca una dirección.

• Cargas con residencia de datos o latencia exigente en LATAM. Sin región en la zona, el cómputo queda en Virginia u Ohio.

• Código que asumía aislamiento por invocación. Una Lambda clásica podía guardar estado en variables globales sin consecuencias. Con 128 solicitudes compartiendo proceso, ese mismo código filtra datos entre usuarios. Paradoja: es más fácil mover un Express viejo que una Lambda vieja.

Hay un efecto quizá más importante: baja el costo de reversión. Si el código sigue siendo un servidor HTTP estándar, salir de Lambda hacia un contenedor se resuelve en el despliegue, sin reescribir. Eso cambia la conversación sobre lock-in, aunque no la elimina, como veremos.

La misma idea en Azure, Google e IBM AWS no llega de primero a esta categoría. Google Cloud Run resolvió el "trae tu servidor HTTP" hace años con contenedores; Azure lo cubre con Container Apps e IBM con Code Engine. Lo que AWS aporta es la combinación de CPU activa con multirregión en un solo comando.

Cuatro matices de la comparación:

• CPU activa y CPU por solicitud miden cosas distintas. Cloud Run, en su modo por solicitud, cobra la CPU mientras haya al menos una solicitud en vuelo, incluida la espera de I/O; la concurrencia diluye ese costo. Lambda Web Functions y Vercel Fluid dejan de cobrar CPU durante la espera. Para endpoints de IA o SSR con mucha espera, la diferencia puede ser material; para APIs con CPU sostenida, casi irrelevante.

• Contenedor contra .zip. Cloud Run, Container Apps y Code Engine aceptan cualquier lenguaje porque aceptan cualquier imagen. Esa generalidad es la razón por la que hoy son la opción natural para modernizar Java o .NET.

• Un modelo operativo abierto. Code Engine está construido sobre Kubernetes y Knative, el mismo modelo de revisiones, concurrencia y escala a cero que inspiró a Cloud Run. Con eso se vuelven portables el código y buena parte de los conceptos operativos. Es la respuesta más directa al lock-in que describo más abajo, a cambio de menos automatización de un solo comando. Además, una sola plataforma cubre aplicaciones web, jobs por lotes y funciones, lo que reduce la cantidad de servicios que un equipo tiene que aprender.

• Azure Functions Flex sigue siendo un modelo de funciones. Añade concurrencia HTTP por instancia, aunque el código se sigue escribiendo como funciones con triggers. Para "trae tu servidor", el equivalente en Azure es Container Apps.

La complejidad cambia de lugar A mediados de los años ochenta, en Xerox PARC, Larry Tesler formuló lo que hoy se conoce como la ley de conservación de la complejidad: toda aplicación tiene una complejidad inherente que alguien tiene que gestionar, ya sea quien la construye o quien la usa. Tesler pensaba en interfaces y defendía que esa carga la asumiera el programador, para ahorrársela a millones de usuarios. La idea quedó documentada en la entrevista que Dan Saffer le hizo para Designing for Interaction.

La ley aplica igual a las plataformas. Lambda Web Functions traslada la complejidad de la distribución global desde el código del equipo hacia el interior de la plataforma. Eso está bien, siempre que el arquitecto sepa dónde quedó.

Tres lugares donde reaparece:

1. Los datos. Desplegar el cómputo en tres regiones con un comando es trivial. Replicar los datos sigue siendo un proyecto aparte. Si la base de datos vive en Virginia y el código responde desde Tokio, cada consulta cruza el Pacífico y la latencia empeora. La multirregión de un comando es honesta solo para aplicaciones sin estado o con datos replicados.

• La facturación. CPU activa suena a ahorro, pero la memoria se cobra mientras el entorno exista, también entre solicitudes. Un modelo más justo también es un modelo más difícil de predecir. Sin una prueba con tráfico real, cualquier promesa de ahorro es solo una hipótesis.

• El límite de la abstracción. Dominio propio y WAF obligan a sumar CloudFront. El "un solo comando" sirve para empezar; la arquitectura de producción pide más piezas. Lo simple del demo y lo simple de la operación son cosas distintas.

Y el lock-in cambia de forma. El código se puede llevar a cualquier plataforma, mientras que el modelo operativo queda ligado a AWS. Las revisiones, el enrutamiento por latencia, los límites por endpoint y la integración con CloudFront son ventajas de AWS. Salir es barato en código pero necesita entenderse en relación a todo lo demás. Ese costo es aceptable si se visible al tomar la decisión; descubrirlo después de llegar a producción es lo que duele.

Patrones de simplificación en modernización La simplicidad se construye con decisiones repetibles. Estos son los patrones que, en mi experiencia, separan una modernización sostenible de una que cambia una deuda por otra:

• Modernizar el despliegue antes que el código. Mover la aplicación a una plataforma gestionada sin reescribirla da valor temprano y deja la refactorización para donde realmente duele. Web Functions, Cloud Run y Container Apps hacen esto posible.

• Elegir el primitivo estándar. Un servidor HTTP es el contrato más estable que tenemos. Cuanto más se parezca el código a lo que corre en la laptop, menos depende del proveedor y más fácil es que otra persona lo entienda.

• Contar las piezas en movimiento. Antes de aprobar una arquitectura: ¿cuántos servicios, adaptadores y configuraciones hay que entender para atender una solicitud? Si la respuesta no cabe en una pizarra, algo sobra.

• Preferir decisiones reversibles. Una decisión que se puede deshacer en una semana no necesita un mes de análisis. Una que no, sí. El arte está en distinguirlas.

• Strangler fig. Rutas nuevas en la plataforma nueva, rutas viejas donde están, y un punto de entrada (CloudFront, API Gateway, un balanceador) que decide.

• No distribuir lo que no se necesita distribuir. Multirregión, microservicios y eventos son herramientas para problemas concretos. La caída de una región es un riesgo real, y para un sistema de pagos o un canal transaccional crítico puede justificar operar en dos. La decisión depende de la criticidad de la carga: cuánto cuesta una hora fuera de línea, qué RTO y RPO exigen el negocio o el regulador, y si una estrategia más simple los cumple. Para muchas aplicaciones internas basta una región con varias zonas de disponibilidad y un plan de recuperación probado en otra. Lo que conviene evitar es la multirregión por defecto, sin datos replicados ni pruebas de conmutación: suma complejidad y entrega una resiliencia que nadie ha verificado.

Estos patrones tienen años; las plataformas apenas empiezan a facilitarlos.

La decisión sigue siendo humana Hoy un agente de IA puede generar en minutos la infraestructura como código para un despliegue multirregión con colas, cachés y tres tipos de cómputo. Ese es precisamente el riesgo. Cuando producir complejidad es barato, la complejidad se acumula sin que nadie la haya decidido. Bruce Tognazzini lo anticipó como corolario de la ley de Tesler: cuando algo se simplifica, la gente aprovecha el margen para intentar tareas más complejas.

Escribir código ya es barato. Lo escaso ahora es el criterio para decidir qué dejar fuera. Y ese criterio depende de cosas que pocas veces están en el prompt:

• El contexto de la organización. Qué sabe operar el equipo un sábado a las 3 a. m., qué exige el regulador, qué contrato de soporte existe.

• La tolerancia real al riesgo. La que aparece cuando falla producción, que suele diferir de la declarada en la presentación.

• El costo de la reversión. Saber cuál decisión se puede deshacer y cuál no requiere haber vivido las consecuencias de alguna.

• La responsabilidad. Alguien firma la arquitectura. Un modelo puede proponer; no puede rendir cuentas.

La IA es muy buena explorando opciones y muy mala renunciando a ellas: tiende a sumar, porque sumar parece más completo. El arquitecto aporta la disciplina de restar. Elegir entre Lambda Web Functions, Cloud Run, Code Engine o una VM bien configurada exige juzgar qué complejidad está dispuesta a cargar la organización y dónde.

Lambda Web Functions es una buena noticia porque confirma una tendencia: las plataformas empiezan a adaptarse al código estándar. Eso hace más barato modernizar y más barato equivocarse.

Decidir sigue siendo tarea nuestra. La pregunta de arquitectura sigue siendo la misma de siempre, solo que ahora con menos excusas: ¿cuál es la solución más simple que resuelve el problema real, y dónde va a vivir la complejidad que no pudimos eliminar?