Investigación serverless para implementación microservicio de pólizas y amparos

[edwargl7]

Se requiere realizar la investigación de casos de uso de serverless y costos. Actualmente se encuentra implementado para la gestión de datos de Syllabus (CRUD) y renderizado utilizando el framework SAM. Documentación implementación lambdas en Syllabus.

Sub Tareas

• [x] Investigación costos y recomendaciones para el uso de serverless.
• [x] Investigación alternativas para la implementación de CRUD con serverless.

Criterios de aceptación

• [x] Documentación de la investigación en la Issue.

Requerimientos

No aplica

Especificaciones técnicas

1. Repositorio implementación de lambdas para Syllabus prueba_piloto_funciones_lambda

Definition of Ready - DoR

• [x] Está refinada y estimada en puntos de historia por el equipo.
• [x] Incluye la descripción y criterios de aceptación, con el detalle funcional y especificaciones técnicas, de forma entendible por cualquier miembro del equipo.
• [x] No tiene bloqueos que impidan su ejecución.
• [x] Las dependencias están identificadas y resueltas.
• [x] Puede ser probada dentro del Sprint.

Definition of Done - DoD - Desarrollo

• [x] Criterios de aceptación cumplidos.
• [x] Documentación de issue realizada.
• [x] Aprobada por SM/Líder técnico.

[mau-oati]

Siguiendo el documento base con el framework SAM, tenemos varios puntos importantes:

Costos Serverless

• Número de solicitudes
• Duración de la ejecución
• Memoria asignada

Esta combinación nos genera los costos computados. En el caso de Lambda, se dan por millón de solicitudes y Gb/segundo.

Ventajas en el costos:

• Solo se paga por el tiempo de ejecución real
• Escala automáticamente, evitando costos de infraestructura ociosa

Desventajas:

• Para cargas de trabajo constantes y predecibles, los servidores tradicionales pueden ser más económicos
• Las Funciones con ejecuciones largas son muy costosas
• El Cold starts pueden aumenta la latencia (varios segundos)

Esencialmente es ideal mantener los costos los costos más bajos posibles, para ello el reto es:

Combinación con persistencia serverless: Es esencial para mantener el mismo modelo de arquitectura, que una función lambda apunte a opciones de almacenamiento distribuido como Mongo Serverless, o Dynamo o Aurora en AWS.

Optimizar el código: Asegurarse de que las funciones Lambda sean eficientes para reducir tiempo de ejecución. (Simples, directas, no complejas)

Monitoreo: Esencial el uso de AWS CloudWatch para monitorear el rendimiento y costos, y analizar comportamientos no esperados.

Seguridad: Implementar el principio de mínimo privilegio en los roles IAM.

En el caso específico de ARGO V2, por la naturaleza del proyecto y el tipo de usuario, es muy probable que sea conveniente del uso de serverless, siempre y cuando vaya de la mano de DBs serverless o que hagan parte de clusters que estén en uso constante por otros servicios. La complejidad computacional no es muy alta por lo que la ejecución de tareas cortas y específicas en lambdas puede ahorrar muchos costosm en tiempos ociosos del sistema.

[mau-oati]

Entre alternativas a AWS SAM está:

AWS CDK. Zappa: Para desplegar aplicaciones Python (como Django o Flask) en AWS Lambda. Apex: Para desplegar funciones Go en AWS Lambda. Azure Functions (Alternativa de Lambda de Azure) Google Cloud Functions.

Por la naturaleza de los servicios actuales (en su mayoría en AWS), usar SAM o CDK puede ser la mejor opción.

[mau-oati]

Un punto importate es aprovechar los recursos gratuitos indefinidos que ofrece lambda en su capa gratuita,

1 000 000 solicitudes gratuitas por mes Hasta 3,2 millones de segundos de tiempo de informática por mes

[edwargl7]

Complementada la investigación apoyando la capacitación de uso de serverless a otro equipo. Se finaliza la Issue.