Con este experimento se espera poder comprobar que las siguientes tácticas de aquitectura:

• Táctica Priorización de Eventos como forma de aumentar la disponibilidad y asegurar que las notificaciones mas importantes (las de alertas) sean atendidas primero.
• Táctica Procesamiento Asíncrono para el manejo de eventos y de esta forma evitar la saturacion del sistema en general esperando que las multiples notificaciones de baja prioridad se procesen.

Con el experimento se espera poder comprobar los siguientes comportamientos:

• El establecimiento de parametros base necesarios para la configuracion de eventos priorizados en la cola de mensajes Pub/Sub del proveedor GCP, que nos permita hacer una diferenciacion entre notificaciones de alerta y notificaciones masivas generales.
• Establecer los parametros de reintentos minimos necesarios para asegurar que se cumpla con los niveles de 99.99% de disponibilidad esperados por los usarios finales.
• Confirmar que con el uso de Procesamiento Asincrono con el uso de GCP Pub/Sub, es posible alcanzar los niveles de 99.99% de disponibilidad esperados por los usarios finales.

Como elementos de Software necesitaremos:

• Google Gloud Platform.
• Python
• Docker
• JMeter

Como elementos de Cloud Computing necesitamos:

• Consola de comandos de GCP.
• Servicio de Cola de Mensajes Pub/Sub ofrecida por GCP.

Elementos de Arquitectura	Punto de Sensibilidad
Ingress Load Balancer	Garantizar que el sistema puede procesar las notificaciones enviadas de forma simulataneas de hasta 1000 usuarios, con una disponibilidad de 99.99% y dandole prioridad a las Notificaciones de Alerta.
Microservicio de Gestor de Notificaciones
Microservicio de Gestor de Servicios
Microservicio de Gestor de Entrenamientos
Configuracion de GCP Pub/Sub

Se estiman 20 horas de esfuerzo para la ejecucion de este experimento distrinbuidos en las siguientes actividades:

• Creación de los microservicios Mockup para el Gestor de Notificaciones.
• Creación de los microservicios Mockup para el Gestor de Entrenamientos.
• Creación de los microservicios Mockup para el Gestor de Servicios.
• Configuracion de Cola de Mensajes Pub/Sub en Cloud GCP.
• Creacion de la Configuracion DockerFiles como pre-requisito de los Kubernetes.
• Creacion de la Configuracion de Kubernetes para el despliegue del experimento.
• Creacion de los parametros de Prueba en JMeter para la comprobacion de Hipotesis.

Punto de Sensibilidad	Historia de Arquitectura asociada	Nivel de Incentidumbre
Garantizar que el sistema pueda procesar al menos 99.99% de las peticiones de alerta y notificaciones que realizan las plataformas web y movil, de al menos 1000 usuarios de manera concurrente.	Como Usuario de SportApp, cuando haga uso de la funcionalidad de Alerta de Emergencia dado que el sistema opera normalmente, quiero que dicha alerta llegue por correo a mi contacto de emergencia previamente regsitrado para que yo pueda recibir asistencia de forma oportuna. Esto debe suceder el 99.99% de las veces.	Media

Estilo de Arquitectura de Microservicios, esto con el fin de validar la decision de estilo de arquitectura y validar si la misma nos ayuda a cumplir con lo esperado en el proyecto.

Atributos de calidad favorecidos	Atributos de calidad desfavorecidos
Capacidad de procesamiento autónomo e independiente.	Complejidad en el desarrollo, pruebas y puesta en producción es más complicada.
Se pueden trabajar tecnologías heterogéneas para su desarrollo.	Consistencia eventual de los datos.
Facilidad al implementar escalamiento y reinicio de servicios fallidos.	Complejidad Operacional.

Tácticas de Arquitectura asociadas al experimento	Descripción
Táctica Procesamiento Asíncrono	Cuando alguno de los clientes de la cola de mensajeria Pub/Sub (Microservicios de Gestor de Servicios o Entrenamientos) desee enviar una notificacion se pondra en la cola para que estos puedan seguir atendiendo otras peticiones de los usuarios, mientras el Gestor de Notificaciones puede tomar las peticiones de notificacion de la cola segun su capacidad y atenderlas sin bloquear a los clientes antes mencionados.
Táctica Publicación/Suscripción	Este patron se refiere a la forma de funcionar de la cola de Mensajes Pub/Sub, en donde los clientes de la cola (Microservicios de Gestor de Servicios o Entrenamientos) publican sus mensajes de notificacion a la cola, mientras que el consumidor de la cola (Microservicio de Gestor de Notificaciones) se subscribe para recibir
Táctica Priorización de Eventos	Con esta táctica se espera hacer una distincion entre las notificaciones de Alerta y Masivas, para que las primeras sean atendidas con alta prioridad (dada la importancia de las mismas) y asegurar que en caso de perdida o indisponibilidad las de mas alta prioridad siempre sean atendidas.

Microservicio	Propósito y comportamiento esperado	Tecnología Asociada
Microservicio de Gestor de Notificaciones	Este Microservicio se encargara de obtener las Notificaciones (ya sean de alertas o masivas) de la cola de mensajes priorizados y enviar el correo de notificacion correspondiente	Python / Flask / Docker
Microservicio de Gestor de Entrenamiento	Este microservicios tendra la responsabilidad de atender las peticiones de notificaciones de alerta de los usuarios y ponerlas en la cola de mensajes con la prioridad mas alta.	Python / Flask / Docker
Microservicio de Gestor de Servcios	Este microservicios tendra la responsabilidad de atender las peticiones de notificaciones masivas de los proveedores de servicios y eventos deportivos y ponerlas en la cola de mensajes con la prioridad normal.	Python / Flask / Docker
Ingress Load Balancer	Este componente se encarga de enrutar las peticiones desde el cliente de pruebas para que los microservicios antes descritos puedan cumplir sus funciones	Kuberentes
Configuraciones de Cola GCP Pub/Sub	En esta cola de mensaje se espera concentrar todas las notificaciones (ya sean de alertas o masivas) para que el Microservicio de Notificaciones pueda procesarlas de forma priorizada.	Consola de GCP

Conector	Comportamiento deseado en el experimento	Tecnología Asociada
Enviar_notificacion	Este conector debe recibir las peticiones desde los clientes para que la cola de mensaje las pueda guardar y ponerlas a disposicion de los consumidores.	Rest-API
Enviar_email	Este es el conector de debe utilizar los consumidores de la cola, para obtener el evento encolado mas prioritario y mas antiguo para que se procese primero.	Rest-API
noti_alerta	Este conector sera el encargado de recibir las peticiones de los usarios para que el Microservicio de Gestor de Entrenamiento puedo enviar una notificacion de Alerta con los datos correspondientes a la cola de mensajes.	Rest-API
noti_masiva	Este conector sera el encargado de recibir las peticiones de los usarios para que el Microservicio de Gestor de Servicios puedo enviar una notificacion de Alerta con los datos correspondientes a la cola de mensajes.	Rest-API

Tecnología asociada con el experimento	Descripcion
Lenguajes de programación	Python
Plataforma de despliegue	Docker y Kubernetes
Bases de datos	SQLite
Herramientas para ejecución de pruebas	JMeter
Herramientas de análisis	Excel
Librerías	Nginx
Frameworks de desarrollo	Flask
Proveedor de Nube	Google Cloud Platform

Integrante	Actividad	Esfuerzo Asociado
Shiomar	Creacion de Microservicio de Gestor de Servicios	2 horas
Jhon	Creacion de Microservicio de Gestor de Notificaciones	3 horas
Shiomar	Creacion de Microservicio de Gestor de Entrenamientos	2 horas
Jhon	Configuracion de GCP Pub/Sub	3 horas
Shiomar	Creacion Configuracion DockerFile	1 horas
Jhon	Creacion Configuracion de Kubernetes	1 horas
Shiomar	Preparacion de Ambiente de Prueba	1 hora
Jhon	Creacion de Set de Pruebas	2 horas
Jhon	Ejecucion de Pruebas	2 horas
Shiomar	Analisis de Datos	3 horas