3. Estudio previo

3.1. Estado actual

El estado actual es que disponemos de una aplicación que tanto clientes como empleados utilizan la misma aplicación para ver o editar los proveedores de café, por lo que se ejecuta como una aplicación monolítica y tiene problemas de fiabilidad y rendimiento.

Sería necesario que los clientes solo pudieran acceder a la aplicación para visualizar los datos de los proveedores y que los empleados además de ver sus datos, pudieran aditarlos, eliminar proveedores y añadir nuevos.

3.2. Estudio de soluciones existentes

La solución o el objetivo existente y que se pide es dividir la aplicación monolítica en microservicios y se tendrá que desarrollar una canalización CI/CD, de modo que pueda escalar los servicios de forma independiente y asignar más recursos de cómputo a los servicios que experimentan la mayor demanda, con el objetivo de evitar cuellos de botella, también evitará los puntos únicos de error, los que podrían hacer caer toda la aplicación en un diseño monolítico.

Para ello llevaremos los archivos que contienen la aplicación a un entorno de desarrollo de Cloud9 para modificarlos dependiendo del microservicio, se creará un repositorio en CodeCommit para guardar los archivos y se probará su funcionalidad en contenedores de Docker.

Después se creará un repositorio ECR para cada microservicio donde se guardará la imagen Docker, también se crea un clúster ECS y un nuevo repositorio en CodeCommit para los archivos de configuración de la implementación.

Una vez se tengan todos los archivos, se crearán 4 grupos de destino con un balanceador de carga de aplicación, se crearán los servicios ECS para cada microservicio. Al final se creará una aplicación CodeDeploy, creando los grupos de implementación y las canalizaciones.

Solo quedará limitar el acceso al microservicio del empleado y ajustar el código de microservicio para hacer que la canalización se ejecute de nuevo.