8Doc_Conclusiones - iesgrancapitan-proyectos/202324ASIR-Junio-Microservices-and-CI-CD-Pipeline-Builder GitHub Wiki
8. Conclusiones
8.1.- Grado de consecución de objetivos
Había principalmente dos objetivos, uno crear los microservicios separando la función del cliente y del empleado y otra realizar este proceso a través de una canalización CI/CD.
Objetivos | Consecusión |
---|---|
Dividisión de la aplicación monolítica en microservicios | Completo |
Canalizaciones CI/CD | Completo |
También en el laboratorio de AWS, especificaba que la solución debería de tener algunos requisitos como portabilidad, escalabilidad, costo optimizado, etc. En cuanto a esos requisitos, se han cumplido al haber seguido y completado la solución que daba AWS.
8.2.- Problemas encontrados
Los problemas que nos hemos encontrado, han sido principalmente de permisos o roles.
El principal de ellos es que al intentar este proyecto planteado por AWS en un laboratorio listo para ello, no se debería de tener problemas, pero al hacerlo en un LabLearner, tenemos limitados los roles.
Para crear las canalizaciones, era necesario el rol RolePipeline para los servicios CodePipeline y CodeDeploy pero no era posible tener este rol en un LabLearner.
Las primeras veces donde dió error fue al crear las definiciones de tareas porque se especificaban que se crearan con ese rol.
Al introducir el comando para registrar definiciones de tareas:
aws ecs register-task-definition --cli-input-json "file:///home/ec2-user/environment/deployment/taskdef-customer.json"
Lanza el siguiente error:
Se intentó realizar con el rol LabRole, aunque al crear las canalizaciones solamente era posible con RolePipeline, por lo que no se han podido realizar en el LabLearner.
También otra dificultad que ha surgido es la cantidad de créditos que gasta este tipo de proyecto que usa tantos servicios y se pueden desplegar tantos contenedores que por ello precisamente he tenido que hacer el laboratorio 2 veces, ya que aún teniendo todo detenido gasta por todos los servicios que usa.
8.3.- Futuras mejoras
Como posibles mejoras, tampoco se puede hacer mucho, pero estaría bien mejorar la aplicación y darle algo de seguridad, como crear una página de logueo, que los usuarios estén guardados en la base de datos y dependiendo de si es empleado o cliente acceda solamente al servicio correspondiente.
Sería algo parecido a lo que hicimos como proyecto de IAW, pero en vez de ser administrador o no, cambiaría a cliente o empleado. Al entrar como cliente, solo tendría accesible la lista de proveedores, sin la posibilidad de ir al otro servicio y lo mismo con el empleado que tendría la lista de proveedores con la posibilidad de añadir, modificar o eliminar.