Serverless Architecture

Qué hace significativa la delegación

Serverless Architecture es un architecture-profile en el que la delegación de infraestructura, lifecycle y capacidad a una plataforma gestionada se vuelve una característica arquitectónica central. El equipo expresa trabajo y recursos mediante contratos de plataforma; el proveedor asigna y administra una parte relevante de su realización, habitualmente orientada a demanda.

Los servidores, la infraestructura y las operaciones siguen existiendo. Cambia quién administra ciertas capas. Tener una función cloud o una base gestionada no basta para caracterizar todo el sistema: importa cuánto condiciona esta delegación su ejecución, estado, entrega y operación.

El CNCF Serverless Whitepaper v1.0, 2018 distingue consumidores y proveedores, FaaS y BaaS; también contempla plataformas internas. Para el equipo consumidor puede haber abstracción de servidores mientras otro equipo mantiene la plataforma. Eso cambia la frontera organizacional, no elimina trabajo.

Terminología, FaaS y servicios gestionados

Function-as-a-Service es una categoría de ejecución: código invocado bajo demanda por requests, eventos u otros triggers. Puede formar parte del perfil junto con almacenamiento, mensajería, workflows y servicios especializados. Serverless no se reduce a FaaS, ni una función vuelve serverless toda la arquitectura.

Jonas y colaboradores describen serverless mediante FaaS y BaaS, exigen autoscaling sin provisioning explícito y facturación por uso en su definición. A Berkeley View on Serverless Computing, 2019, secciones 1–2. Aquí se conserva ese alcance como definición de los autores; la representación editorial como Profile permite analizar realizaciones y fronteras sin convertir cada propiedad comercial en ley universal.

Una base gestionada puede servir a monolith, microservices o una realización serverless. La gestión de un componente y el perfil del conjunto son preguntas distintas. PaaS también abstrae infraestructura; serverless suele enfatizar recursos y ejecución más granulares, asignación por demanda y menor gestión explícita de hosts. Las fronteras varían entre autores y productos: Baldini et al., 2017, secciones 1.1 y 3 ilustran una perspectiva centrada en funciones, no una taxonomía universal.

Las fuentes pueden decir architecture, paradigm, style o computing model. architectural-style-vs-architecture-profile explica la convención del Atlas sin corregirlas. El nombre de un proveedor no define el concepto.

Responsabilidades que cambian de manos

La frontera se acuerda por servicio, no por la palabra serverless.

Área	Plataforma puede gestionar	Equipo de aplicación conserva
Infraestructura	Provisioning, hosts, reemplazo y capas gestionadas de runtime.	Selección de servicios, configuración y restricciones aceptadas.
Ejecución y capacidad	Asignación, routing, instancias y mecanismos de scaling.	Concurrencia permitida, admisión y protección de dependencias.
Mantenimiento y seguridad	Patching de las capas incluidas en su contrato.	Código, librerías o imágenes propias, identidades y permisos.
Estado y operación	Persistencia y herramientas operativas contratadas.	Modelo, ownership, contratos, recuperación, observabilidad y costo.

Delegar un mecanismo no delega su intención de negocio. El equipo decide qué significa completar un pedido, quién puede cobrar y qué evidencia necesita ante un incidente.

La responsabilidad compartida también depende del packaging: entregar una imagen puede conservar obligaciones sobre sus librerías y runtime. AWS distingue seguridad del servicio y del cliente, incluida protección de datos, identidades y configuración. Data protection in AWS Lambda. Muchas identidades permiten permisos específicos, pero también generan riesgo de políticas excesivas, recursos olvidados y acceso mal configurado. Secrets y permisos sobre triggers y recursos siguen requiriendo decisiones explícitas del equipo.

Execution Model, lifecycle y estado

execution-model describe activación y duración. El perfil puede combinar requests HTTP, handlers de eventos, timers, consumidores, pasos de workflow y procesamiento de streams. No prescribe que todo sea una función breve. Las ofertas de containers y jobs gestionados muestran otras realizaciones; Cloud Run, por ejemplo, documenta servicios y tareas que terminan. What is Cloud Run. Usar containers y delegar hosts son decisiones compatibles.

Una instancia temporal y reemplazable exige revisar dependencia de memoria, disco local e identidad del proceso. Stateless execution no significa stateless system: el estado puede vivir en base, object storage, cache, stream o workflow. La corrección necesita persistencia y recuperación acordadas; una cache local prescindible puede mejorar desempeño sin ser autoridad.

Lambda documenta inicialización, invocación, congelación, reutilización y terminación; advierte contra asumir persistencia indefinida. Execution environment lifecycle. Es un ejemplo concreto, no el lifecycle de toda plataforma serverless.

Un cold start añade inicialización de un entorno nuevo. Su efecto depende de runtime, paquete, configuración, provisioning y patrón de tráfico; no es definición ni una penalización universalmente grande. Warm reuse puede optimizar conexiones o caches, pero «seguirá caliente» no constituye garantía de corrección. Una instancia preinicializada tampoco resuelve por sí sola latencia de storage, red o serialización.

Diez Decision Axes

Las celdas expresan preguntas y tendencias, no garantías.

Eje	Lectura del perfil
decomposition	Funciones, servicios, workflows y recursos; contar funciones no evalúa separación de responsabilidades.
dependency-structure	Dependencias hacia APIs, IAM, triggers y semántica gestionada; menos gestión de servidores puede implicar mayor dependencia de plataforma.
communication	HTTP, eventos, colas, streams, llamadas a workflows o llamadas locales; no exige interacción solo mediante eventos.
coordination	Transacciones locales, orquestación, colas o Sagas; externalizar progreso no define acuerdos de negocio.
data-ownership	Storage gestionado no decide quién tiene autoridad para cambiar datos.
isolation	Instancias aisladas pueden compartir cuotas, cuentas, región, red, bases y otros servicios.
tenancy	Tenancy del proveedor y tenancy de la aplicación son decisiones separadas.
deployment	Funciones y recursos admiten entregas pequeñas; contratos, configuración y schemas pueden exigir cambios coordinados.
execution-model	La plataforma administra capacidad y lifecycle bajo distintos triggers; el trabajo conserva obligaciones de progreso y recuperación.
scaling	Elasticidad delegada dentro de cuotas y límites; capacidad end-to-end depende también de estado y downstream.

En particular, tenancy del proveedor no define si Commerce comparte datos y capacidad entre sus clientes o dedica recursos a cada uno. Una aplicación puede combinar single-tenant y multi-tenant; requests, mensajes y workflows deben conservar su contexto autorizado. Separar instancias no elimina un dominio de fallo compartido en cuenta, región, base o transporte.

architecture-decision-axes permite comparar esa combinación con otros perfiles. Deployment, Execution Model y Scaling suelen aportar las diferencias más visibles, sin resolver automáticamente los demás ejes.

Concurrencia, límites y presión downstream

Autoscaling no equivale a capacidad infinita. Más invocaciones simultáneas pueden multiplicar conexiones y competir sobre el mismo pedido. AWS documenta límites compartidos de concurrencia y controles para proteger recursos downstream. Understanding Lambda function scaling. Es evidencia de una realización con límites, no de un número universal.

En una variante propia de Commerce, backlog de Inventory activa muchas ejecuciones y todas abren conexiones a una misma base. Compute crece mientras la base se satura; aumenta duración, se acumula trabajo y puede crecer nuevamente la concurrencia. La documentación Lambda/RDS confirma el problema de agotar conexiones y ofrece pooling como mecanismo específico. Using Lambda with Amazon RDS.

La arquitectura debe relacionar backpressure, admission-control y rate-limiting con capacidad real, edad de backlog y prioridades. Un tope de concurrencia puede limitar presión sin bastar para sostener latencia o justicia entre tenants. Un stream agrega particiones, orden y checkpoints: aumentar consumidores no elimina una partición caliente ni permite paralelizar cualquier secuencia.

Escala a cero puede reducir compute idle; no define por sí sola el perfil ni siempre conviene. Arranque, conexiones y pérdida de caches afectan predictibilidad. Storage, logs o dependencias reservadas pueden seguir costando.

Duración máxima, memoria, payload, runtimes, regiones, red y cuotas son constraints de plataforma. Algunas pueden revisarse; otras requieren cambiar el diseño. No se deducen del nombre del producto ni se documentan aquí con cifras que envejecerían.

Datos, transacciones y workflows

Externalizar estado exige examinar consistencia, latencia, conexiones y data-ownership. No requiere que la base tenga una etiqueta serverless. Una transacción local puede ejecutarse dentro de una invocación; la función no crea atomicidad entre recursos externos.

Persistir Orders y emitir OrderPlaced son dos efectos distintos. transactional-outbox puede conservar intención de publicación junto al estado mediante una transacción local; el relay sigue necesitando política de recuperación. saga-pattern ayuda a examinar resultados parciales entre capacidades, sin convertir compensación en rollback global.

Un workflow gestionado puede conservar pasos, timers y recuperación fuera de memoria del proceso. Step Functions ejemplifica state machines, branching y tratamiento de errores. What is Step Functions?. El servicio ejecuta una política; la aplicación define qué resultado confirma el pedido, cuándo expira una reserva y cómo tratar respuestas tardías.

Delivery y efectos repetidos

La semántica de trigger decide qué ocurre después de un error, timeout o acknowledgment perdido. No existe una política universal de retry para todo serverless. Lambda diferencia invocación directa, async y fuentes de eventos. Understanding retry behavior in Lambda.

retry puede repetir ejecución parcial o un efecto ya realizado. idempotency debe proteger la operación bajo su contrato, especialmente cobros y reservas. Retrying una función no implica repetir sin daño sus llamadas externas. Duplicados, orden y agotamiento de intentos requieren políticas explícitas, y el éxito de infraestructura no demuestra finalización del negocio.

Composición con otros perfiles

cloud-migration puede conservar una aplicación en VMs o trasladar solo algunas capacidades a servicios gestionados. No implica adoptar este perfil ni una arquitectura cloud-native completa. A la inversa, elegir Serverless exige decidir qué delegación resulta central y cómo siguen operándose datos, contratos y efectos; cambiar de hosting no responde por sí solo esas preguntas.

Aproximación	Pregunta predominante	Composición posible
Serverless	¿Quién administra infraestructura, lifecycle y capacidad?	Ejecución y servicios gestionados con límites explícitos.
event-driven-architecture	¿Los hechos organizan interacción y reacción?	Handlers serverless o servicios de larga duración.
microservices	¿Qué fronteras de servicio tienen autonomía efectiva?	Una capacidad puede reunir funciones, workflow, datos y colas.

Una API HTTP serverless puede tener poca interacción EDA; una EDA puede funcionar sobre procesos persistentes. Tampoco función equivale a microservice: separar handlers no concede autoridad propia ni evolución independiente.

modular-monolith puede conservar su núcleo y delegar jobs, integración o tareas programadas a componentes serverless. service-based-architecture y service-oriented-architecture pueden implementar capacidades gruesas mediante ejecución gestionada. Containers, VMs y SaaS pueden coexistir con esas partes: el perfil describe relevancia arquitectónica, no pureza ni una escala de madurez.

Una función tampoco demuestra modularity ni buena granularity. Muchos handlers pueden compartir un schema gigante y reglas duplicadas; funciones pequeñas agregan contratos, hops y coordinación, mientras unidades gruesas pueden impedir scaling selectivo. architectural-quantum examina cohesión e independencia: varias funciones, datos, queues y workflow pueden necesitar evolución conjunta. Ni función, ni módulo, ni deployment unit equivalen automáticamente a un quantum.

Commerce: aceptación, progreso y confirmación

Variante ilustrativa, no implementación prescrita:

HTTP PlaceOrder -> handler Orders
  -> transacción local: pedido pendiente + intención OrderPlaced
  -> relay -> transporte gestionado -> Inventory
  -> reserva válida -> Payments / workflow
  -> autorización válida -> Orders confirma
  -> OrderConfirmed -> Shipping

Orders gobierna el pedido; Inventory las reservas; Payments la autorización; Shipping el envío. La plataforma puede suministrar ejecución, transporte, persistencia y workflow sin tomar esas decisiones de ownership.

El acknowledgment de PlaceOrder representa aceptación durable, no confirmación del pedido. Shipping actúa únicamente sobre la confirmación válida. Si Inventory rechaza, no se inicia pago; si Payments rechaza, se libera la reserva según política. Eventos tardíos requieren comprobar el estado actual. Una función completada correctamente puede haber avanzado solo un paso.

Si Inventory queda atrás, hay que limitar presión y revisar expiraciones; si Payments recibió dos intentos, proteger el mismo efecto. Preguntar qué handlers, contratos y recursos deben cambiar juntos, qué cuotas comparten y cómo recuperar progreso. El workflow no garantiza transacción entre servicios ni borra esas preguntas.

Dos variantes aclaran que EDA no es obligatoria:

HTTP consulta -> función -> base gestionada -> respuesta
Timer de conciliación -> job -> storage gestionado -> resultado

La primera puede tener ejecución serverless sin hechos como mecanismo central entre capacidades. La segunda no depende de requests ni broker; necesita política de solapamiento, repetición y finalización.

Costos, portabilidad y operación

cost-efficiency debe evaluar costo por resultado útil. Facturación por request, duración o uso puede favorecer demanda irregular y reducir capacidad idle, pero carga sostenida, transferencia, retries, transiciones y servicios auxiliares pueden alterar la comparación. Menos hosts propios no prueba menor costo total: incluir logs, datos, integración y esfuerzo operacional.

portability es multidimensional. Código en el mismo lenguaje puede trasladarse mientras IAM, triggers, workflows, storage y observabilidad requieren adaptación sustancial. Acoplarse a servicios de alto nivel puede reducir trabajo de infraestructura y aumentar costo de cambio; es un trade-off situado, no un juicio binario sobre vendor lock-in.

operability conserva diagnóstico de cuotas, backlog, permisos e incidentes de proveedor. Correlación y causalidad deben conectar request, invocaciones, mensaje, workflow y efecto; logs de una función no explican por sí solos la operación completa. Que el host esté disponible no demuestra disponibilidad de la aplicación: región, dependencias, configuración y recuperación siguen importando.

testability combina pruebas de reglas, contratos e integración selectiva de permisos, triggers, timeouts y retries. Mocks y emuladores aportan evidencia parcial; probar localmente un handler no demuestra comportamiento real de servicios gestionados. AWS, How to test serverless applications. No toda prueba necesita cloud, pero algunas obligaciones requieren el entorno correspondiente.

deployability puede mejorar con cambios dirigidos, a cambio de versionar muchos artifacts, configuración y permisos. Rollback del código no revierte datos ni efectos externos. Evaluar comportamiento observado y recuperación, no contar unidades entregadas.

sustainability tampoco mejora automáticamente: pooling y utilización pueden ayudar, pero replicación, región, volumen inducido y recursos persistentes requieren evidencia. La comparación ambiental necesita alcance y medición, no la etiqueta serverless.

Cuándo considerar el perfil

Demanda irregular, tareas activadas independientemente y procesamiento acotado pueden beneficiarse de delegar capacidad. Trabajo largo, hardware especializado, estado local intenso, latencia estricta o carga previsiblemente saturada pueden plantear dificultades, dependiendo de plataforma y configuración.

La elección debe responder architectural-drivers y escenarios verificables. No promete cero operaciones, precio mínimo, estado inexistente, disponibilidad automática o independencia de proveedor. architecture-profiles conecta otras combinaciones posibles y permite continuar la comparación sin transformar funciones o productos en definiciones.