Laboratorio 9
Sebastián Rojas
22 de mayo de 2025
1. Despliegue del microservicio Places
El despliegue del microservicio Places se realizó utilizando Infraestructura como Có-
digo (IaC) mediante Google Cloud Deployment Manager.
1.1. Comando de despliegue
Se utilizó el archivo places_deployment.yaml junto con el siguiente comando en la
consola de GCP:
1 gcloud deployment - manager deployments create places - microservice -
deployment \
2 -- config pl aces_d eploy ment . yaml
Listing 1: Comando gcloud para el despliegue
1.2. Verificación en GCP Console
Tras la ejecución del comando, se verificó la creación y el estado de las instancias en
la consola de Google Cloud Platform. Como se indica en la captura, el despliegue ya se
había realizado previamente al rehacer el deployment de todo por una actualización del
repositorio.
Figura 1: Lista de despliegues en GCP mostrando las instancias, incluyendo
msd-places-ms y msd-places-db.
1.3. Verificación del funcionamiento del microservicio Places
Se accedió a la máquina virtual msd-places-ms y se ejecutó el microservicio. La in-
terfaz de documentación de FastAPI (Swagger UI) confirma que el servicio está operativo
y responde a las peticiones.
Laboratorio 9: Microservicios 2 Modificación de configuración de Kong
Figura 2: Interfaz de FastAPI para el microservicio Places mostrando los endpoints dis-
ponibles.
2. Modificación de configuración de Kong
Para integrar el nuevo microservicio Places con el API Gateway (Kong), se actualizó
su archivo de configuración. Se añadió una nueva entrada para places_service y su
correspondiente upstream, apuntando a la IP interna y puerto de la máquina virtual
donde corre el microservicio Places.
2
Laboratorio 9: Microservicios 2 Modificación de configuración de Kong
Figura 3: Fragmento del archivo kong.yaml mostrando la nueva configuración para el
servicio places_service y su upstream. 3
Laboratorio 9: Microservicios 3 Modificación del microservicio Measurements
3. Modificación del microservicio Measurements
Para asegurar la integridad referencial, el microservicio Measurements fue modificado
para validar que los lugares (places) a los que se asocian las mediciones realmente existan.
Esto se hizo consultando al microservicio Places.
3.1. Actualización de views.py
Se añadió la función check_place() en measurements/views.py, la cual consume el
endpoint del microservicio Places para verificar la existencia de un lugar. Esta función
se utiliza en los métodos MeasurementCreate y MeasurementsCreate.
Figura 4: Modificaciones en measurements/views.py para incluir la validación de lugares.
3.2. Actualización de settings.py
Se añadió la variable PATH_PLACES en monitoring/settings.py para definir la ruta
base del API Gateway hacia el microservicio Places.
1 PATH_API_GATEWAY = " http :// " + os . environ . get ( " KONG_HOST " , " 10.128.0.81 "
) + " : " + os . environ . get ( " KONG_PORT " , " 8000 " )
2 PATH_VAR = PATH_API_GATEWAY + " / variables "
3 PATH_PLACES = PATH_API_GATEWAY + " / places " # Nueva linea
Listing 2: Definición de PATH_PLACES en settings.py
4
Laboratorio 9: Microservicios 4 Creación y verificación de Places
4. Creación y verificación de Places
Se utilizaron las capacidades de FastAPI para crear nuevos lugares a través de su
interfaz de documentación.
4.1. Creación de lugares
Se aprovechó el endpoint POST /places/ expuesto por el microservicio Places y ac-
cesible a través de FastAPI para crear nuevas instancias de lugares.
Figura 5: Uso de la interfaz de FastAPI para enviar una petición POST y crear un nuevo
lugar.
4.2. Verificación de lugares creados
Se consultó el endpoint GET /places/ a través del API Gateway (Kong) para confirmar
que los lugares fueron creados correctamente.
Figura 6: Respuesta del endpoint GET /places (a través de Kong) mostrando la lista de
lugares, incluyendo los recién creados.
5
Laboratorio 9: Microservicios
5 Ingesta de datos de oxígeno: Cloud Function y Scheduler
5. Ingesta de datos de oxígeno: Cloud Function y
Scheduler
Se implementó una Cloud Function para procesar datos de oxígeno y un Cloud Sche-
duler para invocarla periódicamente.
5.1. Cloud Function
Se creó una Cloud Function basada en la del laboratorio anterior (api-consumption),
modificando la variable de entorno API_PATH para que apunte al JSON de datos de oxí-
geno. La función recupera estos datos y los envía al microservicio Measurements.
Figura 7: Configuración y código de la Cloud Function oxygen-consumption.
5.2. Cloud Scheduler
Se configuró un Cloud Scheduler para ejecutar la Cloud Function oxygen-consumption
cada 10 minutos.
Figura 8: Configuración del Cloud Scheduler para la ingesta periódica de datos de oxígeno.
5.3. Verificación de ejecución de Cloud Function
Se confirmó que la Cloud Function se ejecuta correctamente al ser invocada.
6
Laboratorio 9: Microservicios 7 Diagrama de despliegue actualizado
Figura 9: Mensaje "The function was successfully executed"tras la invocación de la Cloud
Function.
6. Verificación del funcionamiento integral
Se muestra el estado y logs de los diferentes microservicios y el API Gateway, así
como el acceso a los endpoints a través de Kong, demostrando que el sistema completo
está operativo.
Figura 10: Consolas mostrando logs de Kong, Places-MS, Variables-MS, Measurements-
MS y acceso a los endpoints /measurements, /variables, y /places a través de Kong.
7. Diagrama de despliegue actualizado
El siguiente diagrama ilustra la arquitectura del sistema después de integrar el micro-
servicio Places y la nueva función serverless para la ingesta de datos de oxígeno.
7
Laboratorio 9: Microservicios 8 Análisis del Atributo de Calidad del Sistema (ASR)
Figura 11: Diagrama de despliegue del sistema con los tres microservicios, sus bases de
datos, el API Gateway Kong, la Cloud Function api-consumption (para oxígeno) y el
Scheduler.
8. Análisis del Atributo de Calidad del Sistema (ASR)
Tiempo de implementación: 48 minutos y 32 segundos.
El ASR 1 indica que, si se necesita añadir un nuevo servicio al sistema ya en fun-
cionamiento, el equipo de desarrollo debe ser capaz de realizarlo en menos de 2 horas.
En este caso, se logró implementar el microservicio Places, conectarlo con el sistema de
monitoreo térmico existente, ajustar el servicio Measurements para verificar los lugares y
crear una nueva función serverless para manejar los datos de oxígeno, todo en menos de
una hora. Esto demuestra un cumplimiento excelente del requisito ASR 1, evidenciando la
agilidad que proporciona la arquitectura de microservicios y las funciones serverless para
extender la funcionalidad del sistema.
8
Laboratorio 9: Microservicios 9 Revisión de créditos de GCP
9. Revisión de créditos de GCP
Se verificó el estado actual de los créditos de prueba gratuita en Google Cloud Plat-
form.
Aún hay suficientes créditos disponibles (más de 20 USD equivalentes). Se han gastado
varios creditos pero en un sevidor de Minecraft que es ajeno a la clase.
