# Propuesta Técnica Wenu Work

## Objetivos

La arquitectura propuesta fue diseñada con los siguientes objetivos:

#### Escalabilidad:

La plataforma e infraestructura que la disponibiliza deberá tener la capacidad de soportar la incorporación de un número indefinido de clientes y sensores.

Además, el diseño de la plataforma deberá permitir la fácil incorporación de nuevas funcionalidades y/o módulos en el futuro.

#### Mantenibilidad:

El tiempo de mantención requerido por la plataforma debe ser mínimo, logrando enfocar los esfuerzos del equipo de **WenuWork** en la implementación de nuevas funcionalidades.

#### Robustez:
La recopilación de datos será prioritaria, se buscará evitar a toda costa la pérdida de datos.

La arquitectura elegida para la plataforma estará enfocada en entregar a sus usuarios respuestas rápidas y consistentes.

La plataforma deberá ser capaz de soportar altas alzas de uso, sin impactar la experiencia de usuario.

#### Orden y calidad de código:

Se buscará ordenar la plataforma para evitar acoplamiento de responsabilidades.

También se realizará una separación entre la lógica de negocios y la toma de datos.

## Arquitectura Propuesta

#### Servicios Cloud

La arquitectura fue diseñada para utilizar los servicios de Amazon Web Services (AWS).

Una gran diferencia con las arquitectura actual, es la utilización de muchos de los múltiples servicios especializados de AWS, evitando el arriendo de servidores Linux. Esto tiene como principales beneficios:

- Menores costos de operación
- Reducción sustancial de esfuerzos de mantención
- Escalamiento automático frente a subidas de demanda
- Simplificación de procesos de paso a producción

#### Explicación de alto nivel

La arquitectura propuesta es la siguiente:

<img src="https://i.imgur.com/bJwxrZv.png" width="100%" />

A continuación, se entrega una explicación de esta. Los distintos elementos se encuentran numerados para una mejor comprensión.

#### Recepción de los datos

El elemento 2 corresponde a un servicio IoT, que permite recibir mensajes con distintos protocolos y exponerlos en distintos protocolos. Esto es eleguido con el foco de poder migrar toda la administración de sensores a IoT. En un futuro se podran administrar los sensores, actualizar, dar de baja, etc. Este servicio se utilizará con la facil integración con otros servicios de AWS. Por último, no hay que preocuparse de la cantidad de mensajes que puede recibir.

El servicio de IoT tiene la capacidad de administrar la autentificación de los dispositivos, su firmware, etc. Evitando la necesidad de implementar un "dashboard de dispositivos".

El elemento 3 es un *broker* de datos. Amazon Kinesis permite implementar un *streaming* de datos, el cual tendrá un *buffer* de 24 horas, en caso de necesitar reprocesar algo.

AWS Kinesis Firehoes (elementos 4, 7 y 9), permiten recibir datos desde un streaming y trabajarlos por *batches* de tamaño controlado, estos *batches* de datos son administrados según "ventana de tiempo máxima" o "número de datos máximos" (lo que se cumpla primero), logrando un flujo de datos en tiempo semi-real (desde 1 minuto de desfase hasta 15 minutos o 128mb).

Los elementos 5 y 8 corresponden a una capa de desencriptación. Este procesamiento se realiza empleando Amazon Lambda Functions, que entregan capacidad de procesamiento desasociado de mantenimiento de servidores.

El elemento 6 corresponde a un Data Lake implementado con Amazon S3, como Data Lake, su labor es almacenar datos históricos.

#### Módulo Alarmas

Los datos que serán procesados son dirigidos por un AWS Firehose (elemento 9) a dos destinos simultáneamente: al módulo de Alarmas y al módulo Procesamiento.

El módulo de Alarmas (elementos 10, 11 y 12) estarán encargados de detectar anomalías dentro de los datos recibidos. Gracias a que se encuentra completamente separado del resto de la arquitectura, su funcionamiento continuo no tendrá un impacto en el rendimiento del resto de la plataforma.

#### Módulo Procesamiento

Lo primero que se realiza es un enriquecimiento y normalización de la data (elemento 13). Para realizar este proceso será necesario consumir información de la lógica de negocio (17, 18 y 19)

La lógica de negocios se almacenará en una base de datos relacional, alojada en Amazon RDS (Relational Database Service). Esta información será administrada por una API (18) y configurada por WenuWork a través de una aplicación web de *backoffice* (19).

Una vez que la data se encuentre normalizada y enriquecida, será:
- Encolada en una lista de trabajos para ser procesada. Esta lista (14) será implementada con el servicio de Amazon SQS, diseñada para este tipo de casos de uso.
- Almacenada en un Data Warehouse, alojado en Amazon Redshift. Desde aquí se realizarán los procesamientos para obtener reportes "avanzados" o de datos "históricos".

La lista de trabajos será consumida por el motor de procesamiento de datos (Company Stats)(15). Este proyecto funcionará en paralelo, una instancia por serie de tiempo que se quiera procesar. Será desplegado sobre Amazon Lambda Functions, eliminando la posibilidad de falla de servidores.

Los datos procesados serán almacenados en un en una base de datos no-relacional (16) de acceso rápido. Todos los datos ya procesados con tendrán un *time to live*, lo que implica que se mantendrá un *buffer* de los últimos N meses hacia atrás, lo que permitirá a los clientes visualizar la data reciente de forma rápida. La base de datos será alojada en AWS DynamoDB.

#### Ventajas de la propuesta

Utilizando el framework Serverless y el servicio AWS CDK, podemos definir toda la infraestructura de WenuWork como código. Esto permite automatizar los pasos a producción y la creación de ambientes paralelos; así como también quitar esa responsabilidad al equipo de desarrollo.
Otro beneficio de definir la infraestructura como código, es que puede ser entendida y mantenida por cualquier programador, y no es necesario tener un experto en infraestructura en el equipo. Además, tiene grandes ventajas en seguridad.

La infraestructura propuesta emplea únicamente servicios *cloud*, en contraste al arriendo de servidores. Esto trae el siguiente beneficio clave: no existe la necesidad de mantener servidores, por lo que la disponibilidad de la plataforma pasa a ser responsabilidad de Amazon; también se logra una alta robustez y un rendimiento constante.
Con esto no hay problemas de IPs cambiados, de maquinas pegadas, de costos de sobre dimensiones, entre otros.

Finalmente, la infraestructura propuesta presenta un alto desacoplamiento de responsabilidades. Esto trae como beneficio la facilidad de agregar cualquier nueva funcionalidad sin afectar la infraestructura ni código existente.

## Estimación de tiempos

Para las funcionalidades antes mencionadas se estima una duración de 3 meses y medio.

## *Disclaimers*

- La estimación de tiempo para la implementación de la plataforma se realizó bajo el supuesto que aparecerán dificultades imprevistas. A pesar de esto, pueden existir diferencias de tiempo.
- La estimación de tiempo para la implementación de la plataforma se realizó bajo el supuesto que existirá una estrecha colaboración de WenuWork. De existir retrasos en la comunicación los períodos podrían extenderse.
- La estimación de tiempo no incluye la migración de los datos históricos. Se planifica que esta migración la realicen los equipos de WenuWork y Abstract en conjunto, una vez terminada y testeada la nueva plataforma.
- Esta propuesta no considera trabajos en el *frontend* de WenuWork.
- No se consideran esfuerzos en el área de *hardware*. La nueva plataforma trabajará con los mismos datos que WenuWork cuenta hoy en día.
- Se genera esta propuesta a partir de la información recabada por Abstract hasta el momento, tomando en cuenta las prioridades inmediatas y futuras de WenuWork. Si es que las prioridades y/o líneas de negocio cambian en el futuro, la plataforma deberá ser reevaluada.
- Durante el paso a producción de la nueva plataforma podrán existir ventanas acotadas de *downtime*.
- La plataforma propuesta mejora enormemente la estabilidad de WenuWork, en comparación con la plataforma actual. Sin embargo, esto no descarta que puedan existir incidentes aislados, sobre todo en el período inicial de funcionamiento de la nueva plataforma.
- El rendimiento de la nueva plataforma mejorará en gran medidad en comparación con la plataforma actual. No se realizarán esfuerzos para entregar una estimación cuantificada de esta mejora.