Function as a Service (FaaS) es una categoría de servicios de computación en la nube que abstrae completamente la infraestructura subyacente, permitiendo a los desarrolladores desplegar y ejecutar funciones de código individuales en respuesta a eventos. En este modelo serverless, el proveedor de la nube es responsable de aprovisionar, escalar y mantener los servidores. Las funciones son efímeras, sin estado y se ejecutan en contenedores ligeros que se instancian bajo demanda ('cold start') y se terminan después de la ejecución, o se mantienen 'warm' para futuras invocaciones. La facturación se basa en el número de invocaciones y el tiempo de computación consumido, no en la capacidad de servidor aprovisionada.
La implementación de FaaS es omnipresente en los principales proveedores de nube. Ejemplos concretos incluyen AWS Lambda, Google Cloud Functions, Azure Functions y Cloudflare Workers. Estos servicios se integran con otros componentes de la nube, como bases de datos (ej. DynamoDB, Firestore), colas de mensajes (ej. SQS, Pub/Sub), y gateways API (ej. API Gateway), para construir arquitecturas orientadas a eventos. Casos de uso comunes abarcan desde el procesamiento de datos en tiempo real (ej. redimensionamiento de imágenes tras una subida a S3), la construcción de APIs RESTful, la ejecución de tareas programadas (cron jobs), hasta la lógica de backend para aplicaciones móviles y web.
Para un Arquitecto Staff+, FaaS representa un cambio estratégico significativo en la forma de diseñar sistemas distribuidos. Ofrece una escalabilidad elástica inherente y un modelo de costos 'pay-per-execution' que puede reducir drásticamente los gastos operativos para cargas de trabajo intermitentes o variables. Sin embargo, introduce desafíos como la gestión de 'cold starts', la depuración distribuida, la observabilidad en un entorno efímero y la complejidad de la orquestación de múltiples funciones. La decisión de adoptar FaaS implica evaluar el trade-off entre la reducción de la sobrecarga operativa y la potencial latencia, la gestión del estado externo, y la posible dependencia del proveedor (vendor lock-in). Es crucial diseñar funciones idempotentes y sin estado, y considerar patrones como el 'event-driven architecture' para maximizar sus beneficios.