Funciona como un servicio

La función como servicio es una "capacidad de nube a nivel de plataforma" que permite a sus usuarios "crear y administrar aplicaciones de microservicios con una baja inversión inicial para la escalabilidad", según ISO/IEC 22123-2. ^{[ 1 ]}

La función como servicio es un subconjunto del ecosistema de computación sin servidor . ^{[ 2 ]}

El "antipatrón del grano de arena" se refiere a la creación de componentes excesivamente pequeños (por ejemplo, funciones) dentro de un sistema, lo que a menudo resulta en una mayor complejidad, sobrecarga operativa e ineficiencias de rendimiento. ^{[ 3 ]} El "pinball de Lambda" es un antipatrón relacionado que puede ocurrir en arquitecturas sin servidor cuando las funciones (por ejemplo, AWS Lambda, Azure Functions) se invocan excesivamente entre sí en cadenas fragmentadas, lo que genera latencia, dificultades de depuración y pruebas, y una observabilidad reducida. ^{[ 4 ]} Estos antipatrones están asociados con la formación de un monolito distribuido.

Estos antipatrones suelen abordarse mediante la aplicación de límites de dominio claros, que distinguen entre interfaces públicas y publicadas. ^{[ 4 ] [ 5 ]} Las interfaces públicas son interfaces técnicamente accesibles, como métodos, clases, puntos finales de API o disparadores, pero no ofrecen garantías formales de estabilidad. Por el contrario, las interfaces publicadas implican un contrato de estabilidad explícito, que incluye versionado formal, documentación exhaustiva, una política de obsolescencia definida y, a menudo, compatibilidad con versiones anteriores. Las interfaces publicadas también pueden requerir el mantenimiento simultáneo de múltiples versiones y el cumplimiento de procesos formales de obsolescencia cuando se introducen cambios incompatibles. ^{[ 5 ]}

En sistemas donde los componentes sin servidor (funciones) interactúan con otros recursos en patrones complejos, a veces descritos como arquitectura espagueti o monolito distribuido, se observan con frecuencia cadenas fragmentadas de llamadas a funciones. Por el contrario, los sistemas con límites más definidos suelen organizar los componentes sin servidor en grupos cohesionados, donde las interfaces públicas internas gestionan la comunicación entre componentes y las interfaces publicadas definen la comunicación entre grupos. Esta distinción resalta las diferencias en las garantías de estabilidad y los compromisos de mantenimiento, lo que contribuye a reducir la complejidad de las dependencias. ^{[ 4 ] [ 5 ]}

Además, los patrones asociados con el encadenamiento excesivo de funciones sin servidor a veces se abordan mediante estrategias arquitectónicas que enfatizan las integraciones de servicios nativos en lugar de funciones individuales, un concepto conocido como mentalidad sin funciones. Sin embargo, se ha observado que este enfoque implica una curva de aprendizaje más pronunciada y las limitaciones de integración pueden variar incluso dentro del mismo ecosistema de proveedores de la nube. ^{[ 2 ]}

Las cargas de trabajo de función como servicio pueden encontrar obstáculos para la migración debido a la dependencia del servicio derivada de las estrechas integraciones con el proveedor. La arquitectura hexagonal puede facilitar la portabilidad de las cargas de trabajo. ^{[ 6 ]}

• como servicio
• Interfaz de puerta de enlace común
• computación sin servidor
• Marco de trabajo sin servidor
• Ofertas específicas
  • AWS Lambda
  • Funciones de Google Cloud