Entregable final - Mirror Strategy

Introducción

Contexto SPIN

SPIN by OXXO nace y crece de manera acelerada. Entre los diversos retos que tiene en su evolución del producto y mejorar la experiencia de sus usuarios, hoy evalúa el estado y escalabilidad de su arquitectura además de si su interacción con FISERV como Core Banking y procesador de pagos es el aliado adecuado para la visión de su crecimiento futuro.​

Con el avance preliminar del Assessment hemos detectado una primera fase de acción con beneficios en el corto plazo. Beneficios en experiencia y estabilidad para el usuario final, como impactos en ahorros financieros por usuario con la creación de una copia local de los datos del core bancario Fiserv.​

Objetivo general

Diseño y desarrollo de la integración del Mirror Strategy funcional para SPIN​.

​Mirror Strategy consiste en desarrollar una copia local de los datos del core bancario Fiserv relacionado al saldo disponible, códigos de bloqueo de tarjeta/cuenta y límites de operación, correspondientes a:​

  • Consulta de bloqueos​

  • Consulta de saldo​

  • Consulta de límites​

Índice

Propuesta de solución

Una vez iniciado el proyecto, el equipo comenzó a analizar y diseñar las bases en las que estaríamos trabajando y lograr el objetivo principal. Para ello, dedicamos tiempo en entender la solución enconjunto con el equipo involucrado en SPIN principalmente.

Se identificaron los siguientes componentes a desarrollar en el tiempo:

Marco tecnológico

Protocolo gRPC

En gRPC, una aplicación cliente puede llamar directamente a un método en una aplicación de servidor en una máquina diferente como si fuera un objeto local, lo que facilita la creación de aplicaciones y servicios distribuidos. Como en muchos sistemas RPC, gRPC se basa en la idea de definir un servicio, especificando los métodos que se pueden llamar de forma remota con sus parámetros y tipos de devolución. En el lado del servidor, el servidor implementa esta interfaz y ejecuta un servidor gRPC para manejar las llamadas de los clientes. En el lado del cliente, el cliente tiene un stub (denominado simplemente cliente en algunos idiomas) que proporciona los mismos métodos que el servidor.

Diagrama conceptual

Los clientes y servidores de gRPC pueden ejecutarse y comunicarse entre sí en una variedad de entornos, desde servidores dentro de Google hasta su propio escritorio, y pueden escribirse en cualquiera de los lenguajes compatibles con gRPC. Entonces, por ejemplo, puede crear fácilmente un servidor gRPC en Java con clientes en Go, Python o Ruby. Además, las últimas API de Google tendrán versiones gRPC de sus interfaces, lo que le permitirá incorporar fácilmente la funcionalidad de Google en sus aplicaciones.

¿Por qué querría usar gRPC?
Los principales escenarios de uso:

  • Sistemas distribuidos de baja latencia y altamente escalables.

  • Desarrollo de clientes móviles que se comunican con un servidor en la nube.

  • Diseñar un nuevo protocolo que debe ser preciso, eficiente e independiente del idioma.

  • Diseño en capas para permitir la extensión, por ejemplo. autenticación, balanceo de carga, registro y monitoreo, etc.

¿Quién está usando esto y por qué?
gRPC es una base de computación nativa en la nube(Proyecto CNCF).

Google ha estado usando muchas de las tecnologías y conceptos subyacentes en gRPC durante mucho tiempo. La implementación actual se está utilizando en varios de los productos en la nube de Google y en las API externas de Google. También está siendo utilizado por Square, netflix, CoreOS, ventana acoplable, CucarachaDB, cisco, Redes de enebroy muchas otras organizaciones e individuos e incluso en el sector fianciero y bancario.

Fuente: https://grpc.io/docs/what-is-grpc/introduction/ | https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2365653064

Protocolo Rest

¿Qué es REST?
La transferencia de estado representacional (REST) es una arquitectura de software que impone condiciones sobre cómo debe funcionar una API. En un principio, REST se creó como una guía para administrar la comunicación en una red compleja como Internet. Es posible utilizar una arquitectura basada en REST para admitir comunicaciones confiables y de alto rendimiento a escala. Puede implementarla y modificarla fácilmente, lo que brinda visibilidad y portabilidad entre plataformas a cualquier sistema de API.

Los desarrolladores de API pueden diseñar API por medio de varias arquitecturas diferentes. Las API que siguen el estilo arquitectónico de REST se llaman API REST.

Fuente: https://aws.amazon.com/es/what-is/restful-api/#:~:text=La%20API%20RESTful%20es%20una,llevar%20a%20cabo%20varias%20tareas.

Rest Assured

REST Assured es un DSL de Java para simplificar las pruebas de servicios basados ​​en REST construidos sobre HTTP Builder. Admite solicitudes POST, GET, PUT, DELETE, OPTIONS, PATCH y HEAD y se puede utilizar para validar y verificar la respuesta de estas solicitudes.

Fuente: https://github.com/rest-assured/rest-assured/wiki/Usage

K6

¿Qué es k6?

Grafana k6 es una herramienta de pruebas de carga de código libre que hace fácil a equipos de software testear el rendimiento de sus aplicaciones.

Con k6, puedes testear la fiabilidad y rendimiento de aplicaciones e identificar regresiones y errores más tempranamente. k6 te ayudará a construir aplicaciones rápidas y robustas que puedan escalar.

Casos de uso

Los usuarios de k6 suelen ser desarrolladores, ingenieros de control de calidad y DevOps. Ellos utilizan k6 para probar el rendimiento de las APIs, los microservicios y los sitios web. Los casos de uso más comunes de k6 son:

  • Pruebas de carga. k6 está optimizado para un consumo mínimo de recursos del sistema y diseñado para ejecutar pruebas con alta carga (spike, stress, soak tests) .

  • Browser testing. Con k6 browser, puedes interactuar con el navegador para validar la interfaz web o rendimiento. Ejecuta browser tests juntos o separados de otros tests de carga.

  • Pruebas de chaos. Puede utilizar k6 para simular tráfico como parte de sus experimentos de chaos, lanzarlos desde el script de k6 o injectar fallos en Kubernetes con xk6-disruptor.

  • Monitoreo del rendimiento. Con k6, puede automatizar la ejecución de tests frequentemente con una pequeña cantidad de carga para supervisar continuamente el rendimiento y disponibilidad de su entorno de producción.

¿Qué no hace k6?

k6 es una herramienta de pruebas de carga de alto rendimiento, que se puede programar en JavaScript. El diseño de la arquitectura para tener estas capacidades trae algunas compensaciones:

  • No ejecuta nativamente en un navegador

    Por defecto, k6 no renderiza las páginas web de la misma manera que lo hace un navegado. Los navegadores pueden consumir muchos recursos del sistema. No usando el navegador, nos permite ejecutar tests de más carga en una misma máquina. Sin embargo, con k6 browser, puedes interactuar con navegadores reales y monitorizar métricas del frontend en tus tests de k6.

  • No se ejecuta en NodeJS. Por lo general, JavaScript no es adecuado para obtener un alto rendimiento. Para lograr el máximo rendimiento, la herramienta en sí está escrita en Go, incorporando un tiempo de ejecución de JavaScript que permite un fácil scripting de pruebas. Si quieres importar módulos npm o librerías usando las APIs de NodeJS, puedes empaquetar módulos npm con webpack e importarlos en tus pruebas.

Fuente: https://k6.io/docs/es/#que-es-k6

Entregables

A continuación, enlistaremos los entregables comprometidos para este proyecto y la documentación que dejamos como referencia para dar contexto e incluso la continuidad de la siguiente fase de implementación en los procesos que así lo considere SPIN.

Lo que podrán encontrar son los diseños de arquitectura, códigos fuente, documentación específica entre otros.

Mirror

El detalle de los componentes los encontrarán en las siguientes URLs:

Gateway

El detalle de los componentes los encontrarán en las siguientes URLs:

Aggregation

El detalle de los componentes los encontrarán en las siguientes URLs:

Arquitectura de datos

Feature flag

Con el fin de reducir los riesgos en la implementación del proyecto se planteó el uso de Feature Flags con Config Cat. Detalles en el siguiente enlace: https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2527494164

Entregas parciales por sprint

Nuestro proyecto fue planetado realizarse en un tipo de 13 sprints dividios en sprint de 2 semanas cada uno, con el objetivo de entregar valor a través del trabajo comprometido en el equipo.

Es por ello que, en elsiguiente link encontrarán los objetivos comprometidos y los entregables que evidencian nuestras entregas parciales e incrementales: https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2344124421

Asimismo, se realizaron 2 revisiones de avances para dar seguimiento estratégico a los principales stakeholders y sponsors del proyecto.

Documentación adicional

Documento

Descripción

URL

Aprobador

Documento

Descripción

URL

Aprobador

Diagramas de Arquitectura (C4, primeros 2 niveles)

Conjunto de diagramas que describen los componentes del proyecto.​

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2472935426

Miguel C

Diagramas de secuencia

Esquemas conceptuales que representa el comportamiento del sistema del proyecto.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2384003077

Miguel C

Configuración para iniciar microservicio

Serie de valores que permiten administrar la configuración de los microservicios desarrollados.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2500820997

Miguel C

Postman de los servicios

Colecciones de lo que se ha desarrollado para automatizar, configurar pruebas y comprobar el correcto funcionamiento.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2480439300

Jessy Schuler

Documentación de endpoints​

En formato Swagger documentar los endpoints desarrollados para el proyecto.​

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2364736041

Miguel C + JC del Villar

Diccionario de datos - MongoDB

Listado de nombres, definiciones y características de los campos y atributos de la base de datos a utilizar para el proyecto.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2523824149

Miguel C

Plan de pruebas

Plan de pruebas donde se describen el detalle de las pruebas a ejecutarse en el proyecto.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2420834305

Dorian Romero

Casos de prueba

Identificar en los casos de prueba del proyecto las etiquetas que permitan la ejecución del set de pruebas correspondiente en formato CSV

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2442035240

Dorian Romero

Ejecución de pruebas

Evidencia del proceso de pruebas ejecutado para el proyecto con los resultados arrojados. - Scripts de pruebas automatizadas (REST + gRPC), resultados y evidencias

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2521661800

Hugo Flores

Diagramas de infraestructura

Diagramas que permitan comprender la infraestructura del proyecto para que se pueda administrar, mejorar y mantener seguro.

 https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2472935426/Diagramas+de+arquitectura#Infraestructura

Ricardo P + Miguel C

Capacidades de microservicios (pods)

Conocer la proyección de consumo de los endpoints del proyecto.​

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2472837144

Mario Mendez

Métricas para monitoreo de infraestructura (logs para crear dashboards)

Los servicios del proyecto estarán reportando su estado mediante dos vías: reporte de logs y reporte de métricas.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2486665253/Observabilidad+de+servicios+-+Mirror+Strategy#Reporte-de-logs

Mario Mendez

Métricas para monitoreo de negocio/semántico

Planificar de acuerdo con los objetivos o estrategia de la funcionalidad del negocio.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2486665253/Observabilidad+de+servicios+-+Mirror+Strategy#Reporte-de-m%C3%A9tricas

Mario Mendez

Estrategia y ejecución de pruebas

Plan de pruebas

Para lograr los resultados esperados y considerar casos positivos y negativos se realizó una estrategia de pruebas para garantizar el uso correcto del framework de QA que se tiene en SPIN, nuestros desarrollos llegarán hasta staging, por lo que garantizar que funcione de acuerdo con lo diseñado, es de suma importancia para este proyecto.

Consulta el detalle del Plan de estrategia: https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2420834305

Secciones del plan de pruebas

Sección

Descripción

URL

Sección

Descripción

URL

Casos de prueba

Los casos de prueba son los escenarios que se utilizan para medir la funcionalidad de la aplicación a través de un conjunto de ciertas acciones o condiciones para verificar los resultados esperados.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2442035240

Automatización de pruebas

Es el proceso de utilizar herramientas de software que ejecutan software recién desarrollado o actualizaciones a través de una serie de pruebas para identificar posibles errores de codificación, cuellos de botella y otros obstáculos para el rendimiento.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2484961314

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2521694326

Pruebas de rendimiento

Evalúan el rendimiento de un sistema con una carga de trabajo determinada. Ayudan a medir la fiabilidad, la velocidad, la escalabilidad y la capacidad de respuesta de una aplicación.

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2521661750

https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2521694421

Ejecución de pruebas

Tipo de prueba

Resultados

Transferencia de conocimiento (KT)

Con la finalidad de garantizar el éxito de la entrega de los compromisos de este proyecto, compartimos el material que se trabajó en nuestro periodo de transferencia de conocimiento con el propósito de mostrar el resultado de lo trabajado.

Roadmap

Para más detalle: https://fintechdigital.atlassian.net/wiki/spaces/TPP/pages/2496430085

Conclusiones generales

 

https://fintechdigital.atlassian.net/browse/SPMS-400