Patrón FLAME: un nuevo enfoque para el escalado elástico de aplicaciones
- Serverless/FaaS (Function as a Service) ofrece ventajas como el escalado elástico y el pago según uso, pero en la práctica también introduce más complejidad.
- Si el código de una app existente pudiera envolverse como una función y ejecutarse en copias temporales de la aplicación, sería posible lograr autoescalado.
- El patrón FLAME (Fleeting Lambda Application for Modular Execution) trata a toda la aplicación como si fuera una lambda y ejecuta partes modulares en infraestructura de corta duración.
Patrón FLAME
- El patrón FLAME busca un escalado elástico granular y bajo demanda para partes específicas del código de una app, sin administrar servidores.
- No requiere reescribir la aplicación existente ni reimplementarla parcialmente en un runtime propietario.
- La librería
flamede Elixir implementa el patrón FLAME e incluye un adaptador backend para Fly.io, pero puede usarse en cualquier nube que ofrezca una API para ejecutar el código de la aplicación.
Backend de FLAME
- En la infraestructura de Fly.io,
FLAME.FlyBackendpuede iniciar una nueva Machine y conectarla al trabajo padre en unos 3 segundos. - FLAME incluye por defecto
LocalBackendyFlyBackend, pero cualquier host que ofrezca una API para aprovisionar servidores y ejecutar código de aplicación puede funcionar como backend de FLAME. - Como Fly.io ejecuta aplicaciones empaquetadas como imágenes de Docker, solo hace falta arrancar una nueva Machine con la misma imagen.
Elixir fuera de FLAME
- Elixir es especialmente adecuado para el modelo FLAME porque ofrece de forma nativa funciones como supervisión de procesos y mensajería distribuida.
- Si un lenguaje cuenta con primitivas razonables de concurrencia, puede aprovechar este patrón.
- También hay ejemplos de cómo implementar el patrón FLAME en aplicaciones JavaScript, moviendo la ejecución modular a archivos nuevos.
Sobre los procesadores de trabajos en segundo plano
- FLAME funciona bien dentro de un procesador de trabajos en segundo plano, pero eso es un problema distinto a que una librería de jobs escale su pool de trabajo.
- Es importante separar los trabajos que garantizan durabilidad de la ejecución elástica.
Pooling para el escalado elástico
- Con la implementación de FLAME en Elixir se pueden definir runners de pools elásticos, lo que permite escalar a cero y ampliar elásticamente servidores FLAME con un límite máximo de concurrencia.
Ubicación de procesos
- En Elixir, las partes con estado de una aplicación se construyen alrededor de la primitiva de procesos, y funcionan bien cuando se envuelven con
FLAME.calloFLAME.cast.
Monitoreo remoto
- Cuando el padre pone en marcha un runner, este debe gestionar por sí mismo el estado idle cuando no hay trabajo y finalizar de forma segura si se pierde la conexión con el nodo padre.
Opinión de GN⁺
Lo más importante de este artículo es que el patrón FLAME puede simplificar el escalado elástico de aplicaciones al reducir la complejidad de los enfoques serverless/FaaS tradicionales. Este patrón permite a los desarrolladores escalar rápidamente solo las partes necesarias sin modificar demasiado el código existente, lo que puede convertirlo en una solución atractiva para muchos ingenieros de software que usan infraestructura en la nube. El patrón FLAME puede ser una herramienta especialmente potente en lenguajes como Elixir, y como también se está explorando su implementación en otros lenguajes, genera expectativas sobre su adopción en diversos entornos de desarrollo.
1 comentarios
Opiniones de Hacker News
Este artículo señala bien los problemas de una arquitectura FaaS serverless, a partir del dolor y la complejidad de haber trabajado durante 4 años con una aplicación compuesta por más de 100 funciones Lambda.
Como autor del artículo, espera despertar interés en personas que quieran implementar el patrón FLAME en otros lenguajes como JavaScript o Go, y está listo para responder preguntas.
El servicio PiCloud usaba un modelo que enviaba trabajos de forma transparente a los workers, lo que sugiere que algo similar también podría aplicarse en otros lenguajes además de Elixir.
Con FLAME, se puede envolver el código existente de una app en una función y ejecutarlo en una copia temporal de la aplicación, algo parecido a bifurcar procesos en un entorno serverless.
Windmill.dev considera las unidades de abstracción al nivel del código fuente, analiza funciones principales e imports para extraer argumentos y dependencias, y ejecuta el código en el runtime deseado.
Con FLAME, el runner de desarrollo y pruebas se ejecuta en un backend local, así que ofrece una buena experiencia de desarrollo local dentro de un entorno serverless.
Cada vez que se usa
Flame.call, se inicia un nuevo proceso de la app y se copia el contexto de ejecución; es una solución simple para escalar, pero hay que considerar la latencia adicional en el tiempo de arranque y el uso de memoria.Junto con una crítica al uso de mayúsculas en los titulares de Hacker News, se expresa la esperanza de que se reconsidere la empresa serverless.com, y no los principios de serverless.
Inngest.com ofrece un enfoque parecido para usar código existente como funciones serverless, administra el estado del código desde fuera y enfatiza la importancia del monitoreo y la observabilidad.
Si existiera un sistema llamado "Long Lambda" para que las Lambdas pudieran ejecutarse por más de 15 minutos, entonces todo podría resolverse con Lambda, además de poder ejecutarlo y depurarlo localmente.
Este resumen transmite de forma concisa los puntos principales de cada comentario y está escrito en un nivel fácil de entender para un ingeniero de software principiante. Las partes que requieren conocimiento previo se explican al mínimo, manteniendo una postura neutral y sin desviarse del tema.