Vista de Despliegue

Modelo de Despliegue

El modelo presentado solo representa la vista y los elementos necesarios para entender las tacticas y los tradeoff seleccionados para los ASR escogidos, los modelos mas generales se encuentran en la seccion de Vision de Arquitectura

Enlace para Imagen ampliada

Modelo de Dependiencia Tecnologica

En la siguiente imagen podemos ver la relacion entre los elementos mostrados en los diagramas y las soluciones tecnologicas que se van a utilizar:

Elemento	Tencologia	Razonamiento
Framework de Desarrollo Web	Angular	Se utilizara este Framework de desarrollo ya que el equipo tiene experiencia y el desarrollo es compatible con los entregables y las demas herramientas
Framework de Desarrollo Movil	Android + Kotlin	Se utilizara este Framework de desarrollo ya que el equipo tiene experiencia y existe extensa documentacion tanto oficial como por parte de la comunidad.
Microservicios	Python / Pods / Kubernetes	Se utilizara estea forma de trabajar ya que el equipo tiene experiencia y el desarrollo se facilitaria con las herramientas del proveedor de nube.
Contenerizacion	Docker	Se utilizara esta plataforma ya que el equipo tiene experiencia y permite tanto despliegues locales como en la nube.
Administrador de Contenedores	Kubernetes	Se utilizara esta plataforma ya que el equipo tiene experiencia y permite tanto despliegues locales como en la nube.
Balanceadores de Carga	GCP Cloud Load Balanacer	Se utilizara este servicio del proveedor de nube pya que el equipo lo ha utilizado antes y se cuentan con extensos tutoriales y soporte de la comunidad.
Balanceadores de Carga	Ingress-Load Balancer	Se utilizara esta funcionalidad dentro de la plataforma de Kubernetes ya que nos permite cumplir con algunas consideraciones de Arquitectura pero tambien por su extensa documentacion.
Almacenamiento de Datos	GCP Cloud Storage	Se utilizara este servicio del proveedor de nube pya que el equipo lo ha utilizado antes y se cuentan con extensos tutoriales y soporte de la comunidad.
Bases de Datos	GCP Cloud SQL + PostgresSQL	Se utilizara este servicio del proveedor de nube pya que el equipo lo ha utilizado antes y se cuentan con extensos tutoriales y soporte de la comunidad.
Cola de Mensajes	GCP Cloud Pub/Sub	Se utilizara este servicio del proveedor de nube pya que el equipo lo ha utilizado antes y se cuentan con extensos tutoriales y soporte de la comunidad.
Serverless Cloud FaaS	GCP Cloud Functions	Se utilizara este servicio del proveedor de nube pya que el equipo lo ha utilizado antes y se cuentan con extensos tutoriales y soporte de la comunidad.
Proveedor PaaS	Googel Cloud Platform	Se selecciono este proveedor de Nube porque el equipo lo ha utilizado previamente y es que nos ofrece mejores capacidades en la capa gratuita.
Plataforma de Envio de Correos	SendGrid	Se selecciono porque nos permite manejar un flujo de 10mil correos al mes con un costo bajo y con la certeza de entrega y monitoreo de estado.

Estilo Utilizado

En esta vista se puede ver el uso del estilo seleccionado de Microservicios, representados por los Pods de Kubernetes, cada uno de estos Pods correspondera a un Microservicio desarrollado y desplegado en un Cluster de Kubernetes dentro de una zona de una region en Google Cloud Platforms.

Estos Microservicios deplegados en Pods nos ayudaran a cumplir con las demandas de los usuarios, escalando de manera independiente segun las cargas de trabajo y disponibilidad.

Este estilo nos permite seguir buenas practicas del Desarrollo de Software y DevOps al tener unidades pequeñas y modulares de trabajo en donde podamos hacer despliegues continuos de cambios pequeños e incrementales que no afecten ni pongan el riesgo la experiencia de los usuarios.

Tácticas Utilizadas

• Táctica de Replicacion con el uso de diferentes Zonas de disponibilidad para la prevencias de fallas de hardware y favorecer la Disponibilidad.
• Táctica de Retiro de la Operacion para el manejo de fallas y favorecer la Disponibilidad.
• Táctica de Manejo de Excepciones para el Enmascaramiento de errores y favorecer la Disponibilidad.
• Táctica de Escalamiento Horizontal para manejar los recursos y favorecer la Latencia (Desempeño).

Patrones Utilizados

• Patrón Fachada y Principio de Abierto/Cerrado, para proporcionar un unico punto de acceso al sistema (el Load Balancer), pero tambien a los Clusters de Kubernetes (Ingress-Load Balancer) y de igual forma entre Pods (Utilizando los Services de Kubernetes).
• Alta cohesión y Principio de Responsabilidad Única, ya que cada Pod tiene un conjunto de responsabilidades agrupadas segun su afinidad o el tipo de informacion que maneja.
• Singleton ya que si bien va a existir varios Pods del microservicio (por el escalamiento horizontal) segun la demanda, cada Pod solo tendra un Microservicio desplegado, esto con la finalidad de los recursos utilizados en el procesamiento de la informacion de dicho servicio sean utilizado exclusivamente para esto y no haya indisponibilidad por falta de recursos.

Razonamiento sobre Principales decisiones de Diseño

Decision de Diseño	Razonamiento
Táctica de Replicacion	Esta decision de diseño se basa en el uso de un cluster de Kubernetes por zona de disponibilidad pero considerando varias zonas dentro de la misma region para evitar que los riesgos de indisponibilidad de hardware afecten al sistema como un unico punto de falla, cada cluster tendra la capacidad de escalar diferentes Pods segun las demandas que se tengan en el sistema.
Manejo de Excepciones	Usaremos esta tactica para que tanto el load balancer de GCP como los Ingress load balancer de cada cluster en cada zona del despliegue detecten cualquier tipo de error se puedan tomar acciones correctivas como diriguir el trafico a otra instancia u otro pod disponible.
Escalamiento Horizontal	Esta táctica va de la mano con las anteriores ya que se quiere configurar el escalamiento Horizontal de los Pods mas significativos (Como el Gestor de Monitoreo, el Gestor de Usuarios o el Gestor de Entrenamientos) para que se puedan atender los picos de trafico que presente el sistema, pero tambien usar el escalamiento Horizontal como metodo de recuperacion de fallas, mediante el aprovisionamiento de nuevos Pods en caso de fallos en los Pods actuales.
Retiro de la Operacion	Con esta táctica esperamos poder retirar de la operacion los Pods que se encuentren incapacitados para responder y poder proceder a su reinicio o restauracion para luego re-integrarlos a la operacion de forma que puedan procesar eventos nuevamente.