Es más una pregunta abierta y solo espero opiniones y sugerencias. Tengo AWS en mente, pero probablemente también pueda relacionarse con otros proveedores de la nube.
Me gustaría aprovisionar una solución IaaC que sea fácil de mantener y cubra todos los requisitos de la arquitectura moderna sin servidor. Terraform es una gran herramienta para definir la infraestructura, tiene muchos recursos oficiales y un apoyo estable de la comunidad. Me gusta mucho su sintaxis y todo el concepto de módulos. Sin embargo, es bastante malo para trabajar con Lambdas. También plantea otra pregunta: ¿debería implementarse el cambio de código utilizando el mismo flujo que el cambio de infraestructura? ¿Dónde trazar la línea entre el código y la infraestructura?
Por otro lado, Serverless Framework permite un desarrollo y una implementación muy sencillos de Lambdas. Es muy obstinado cuando se trata del uso de recursos, pero viene con muchas características listas para usar que valen la pena. Realmente no debería usarse para definir toda la infraestructura.
Mi enfoque actual es definir cualquier recurso compartido usando Terraform y cualquier recurso relacionado con el dominio usando Serverless. Aquí tengo otro problema relacionado con mis preguntas anteriores: dependencia de implementación. El escenario simple: Lambda.1 agrega usuarios a Cognito (recurso compartido) que tiene Lambda.2 como disparador. Tengo que crear una solución personalizada para administrar el orden de implementación (primero se debe implementar Lambda.2 , etc.). Es posible conectar la implementación de Serverless Framework a Terraform pero, de nuevo: ¿debería combinarse la implementación del código con la implementación de la infraestructura?
Es totalmente posible mezclar los dos y he tenido que hacerlo varias veces. Cómo se ve esto en realidad termina siendo más simple de lo que parece.
En primer lugar, si piensa en cualquier cosa que haga con Serverless Framework como el desarrollo de microservicios (sin la carga de administración de infraestructura asociada), eso lo lleva un paso en la dirección correcta. Luego, lo que puede hacer es decidir que todo lo que se requiere para que ese microservicio funcione internamente se define dentro de ese microservicio como parte de la configuración de servicios en serverless.yml, ya sean tablas de DynamoDB, integraciones de Auth0, flujos de Kinesis, SQS. , SNS, permisos de IAM asignados a funciones, etc. Mantenga todo definido como parte de ese microservicio. No se requiere terraformación.
Ahora piense en lo que ese y otros microservicios podrían necesitar para interactuar de manera más amplia. No son críticos para la operación interna de ese servicio, pero son críticos para la integración en el resto de la infraestructura de las organizaciones. Esto incluye cosas como roles de IAM de implementación utilizados por los servicios de Serverless Framework para implementar en CloudFormation, bases de datos relacionales que deben compartirse entre múltiples servicios y recursos, elementos de red (VPC, grupos de seguridad, etc.), clústeres monolíticos como ElasticSearch y Redis. Todos estos elementos son excelentes candidatos para la definición fuera de Serverless Framework y funcionan muy bien con Terraform.
Cualquier recurso podría conectarse a estos recursos definidos por Terraform según sea necesario, a diferencia de la asociación dura, como las funciones Lambda desencadenadas desde un punto final de API Gateway.
Espero que ayude