Tag Middleware

Case: Evolving User Experience – A Three-Phase Banking Solution

By en casos de uso Tag

Case: Evolving User Experience – A Three-Phase Banking Solution

 
Introduction:
The unprecedented impact of COVID-19 on several financial institutions reshaped user habits almost overnight. During lockdown, the surge in online banking showcased the unpreparedness of many portals to handle heavy workloads. While some lagged in adapting, others, like our client, a renowned Chilean financial institution with over 50 years of service and over a million users, swiftly began their digital transformation journey.
 
Phase 1: The Pandemic Response
During the peak of the pandemic, our client embarked on its initial digital transformation. They adopted the cloud to ensure their platforms remained stable, scalable, and secure. Consequently, they were able to introduce new functionalities, enabling users to execute tasks previously limited to physical branches. For this massive endeavor, they employed the Amazon Web Services (AWS) Cloud platform, paired with the expert guidance of a team of specialized professionals.
 
Phase 2: Post-Pandemic Enhancements
Post-pandemic, as users and businesses acclimated to online operations, our client entered the second phase of their transformation. This involved enhancing their architecture. Their first order of business was load testing to understand how concurrent online activity impacted their on-premises components. This was crucial in determining optimal configurations for AWS EKS and AWS API Gateway services.
 
Furthermore, as the business expanded its online offerings, new services were integrated. Security became paramount, prompting the institution to implement stricter validations and multi-factor authentication (MFA) for all users.
 
Phase 3: Continuous Improvements and Expansion
With more users adapting to online banking, the third phase saw the introduction of additional applications, enhancing the suite of services offered. The architecture was continuously revised and updated to cater to the ever-increasing demands of online banking.
 
Security was further tightened, and robust monitoring and traceability features were incorporated, providing deeper insights and ensuring system stability.

Proyectos Realizados

El Cliente, junto con sus áreas de Arquitectura, Desarrollo, Seguridad e Infraestructura, vio en AWS un aliado para llevar a cabo la construcción de un nuevo Portal, aprovechando las ventajas de la Nube como elasticidad, alta disponibilidad, conectividad y gestión de costos.

El proyecto concebido contempló la implementación de un frontend (Web y Mobile) junto con una capa de microservicios con integración hacia sus sistemas On-Premise vía consumo de servicios expuestos en su ESB que a su vez accede a sus sistemas legacy, formando así una arquitectura. híbrido.

En el marco de este proyecto, 3HTP Cloud Services participó activamente en el asesoramiento, definiciones e implementaciones técnicas de la infraestructura y soporte a los equipos de desarrollo y automatización, tomando como referencia los 05 pilares del marco bien arquitectónico de AWS.

La participación de 3HTP Cloud Services se centró en las siguientes actividades:

  • Validation of architecture proposed by the client 
  • Infrastructure as code (IaC) project provisioning on AWS 
  • Automation and CI / CD Integration for infrastructure and micro-services  
  • Refinamiento de infraestructura, definiciones y estándares para operación y monitoreo
  • Pruebas de estrés y carga para AWS y la infraestructura local

Outstanding Benefits Achieved

Our client’s three-phase approach to digital transformation wasn’t just an operational shift; it was a strategic masterstroke that propelled them to the forefront of financial digital innovation. Their benefits, both tangible and intangible, are monumental. Here are the towering achievements:

  1. Unprecedented Automation & Deployment: By harnessing cutting-edge tools and methodologies, the client revolutionized the automation, management, and deployment of both their infrastructure and application components. This turbocharged their solution’s life cycle, elevating it to industry-leading standards.
  2. Instantaneous Environment Creation: The ingeniousness of their automation prowess enabled the generation of volatile environments instantaneously, showcasing their technical agility and robustness.
  3. Robustness Redefined: Their infrastructure didn’t just improve; it transformed into an impregnable fortress. Capable of handling colossal load requirements, both in productive and non-productive arenas, meticulous dimensioning was executed based on comprehensive load and stress tests. This was consistently observed across AWS and on-premises, creating a harmonious hybrid system synergy.
  4. Dramatic Cost Optimization: It wasn’t just about saving money; it was about smart investing. Through astute utilization of AWS services, like AWS Spot-Aurora Server-less, they optimized costs without compromising on performance. These choices, driven by findings and best practices, epitomized financial prudence.
  5. Achievement of Exemplary Goals: The institution’s objectives weren’t just met; they were exceeded with distinction. Governance, security, scalability, continuous delivery, and continuous deployment (CI/CD) were seamlessly intertwined with their on-premises infrastructure via AWS. The result? A gold standard in banking infrastructure and operations.
  6. Skyrocketed Technical Acumen: The client’s teams didn’t just grow; they evolved. Their exposure to the solution’s life cycle made them savants in their domains, setting new benchmarks for technical excellence in the industry.

    Servicios realizados por 3HTP Cloud Services: Validación inicial de la arquitectura

    La institución ya contaba con una primera arquitectura de adopción en la nube para su portal de cliente, por ello, como equipo multidisciplinario, comenzamos con un diagnóstico de la situación actual y la propuesta realizada por el cliente; De este diagnóstico y evaluación se obtuvieron las siguientes recomendaciones relevantes para la arquitectura:

    • Separación de arquitecturas para entornos productivos y no productivos
    • El uso de Infraestructura como código para crear entornos volátiles, por proyectos, por unidad de negocio, etc.
    • Implementación de CI / CD para automatizar la creación, gestión y despliegue tanto de Infraestructura como de microservicios.

    Arquitectura del entorno productivo

    • Esta arquitectura se basa en el uso de tres zonas de disponibilidad (AZ), además, las instancias Bajo demanda se utilizan para los trabajadores de AWS EKS y el uso de instancias reservadas para la base de datos y la memoria caché con alta disponibilidad 24×7.

    Se define la cantidad de instancias que se utilizarán para el clúster de Redis.

    Diagrama productivo

    Arquitectura de entorno no productivo

    Considerando que los ambientes no productivos no requieren un uso 24/7, pero si es necesario que tengan al menos una arquitectura similar a la de producción, se definió una arquitectura aprobada, que permite ejecutar los diferentes componentes en alta disponibilidad y al mismo tiempo permite minimizar costes. Para ello se definió lo siguiente:

    • Reducción de zonas de disponibilidad para entornos no productivos, permaneciendo en dos zonas de disponibilidad (AZ)
    • Uso de instancias puntuales para minimizar los costos de los trabajadores de AWS EKS
    • Configuración de encendido y apagado de recursos para su uso en horario comercial.
    • Using Aurora Serverless 

    Las instancias a utilizar se definen considerando que solo hay dos zonas de disponibilidad, la cantidad de instancias para entornos de No Producción es simplemente 4.

    Diagrama de entornos de no producción

    Infraestructura como código

    Para lograr la creación de las arquitecturas de manera dinámica adicionalmente que los entornos pudieran ser volátiles en el tiempo, se definió que la infraestructura debe ser creada mediante código. Para ello, Terraform se definió como la herramienta principal para lograr este objetivo.

    Como resultado de este punto se crearon 2 proyectos Terraform totalmente variables los cuales son capaces de crear las arquitecturas mostradas en el punto anterior en cuestión de minutos, cada ejecución de estos proyectos requiere el uso de un Bucket S3 para poder almacenar la estados creados por Terraform.

    Además, estos proyectos se ejecutan desde Jenkins Pipelines, por lo que la creación de un nuevo entorno está completamente automatizada.

    Automation and CI / CD Integration for infrastructure and micro-services 

     Implementación de microservicios en EKS

    Ayudamos a la entidad financiera a desplegar los microservicios asociados a su solución empresarial en el Clúster de Kubernetes (AWS EKS), para ello se realizaron varias definiciones con el fin de poder llevar a cabo el despliegue de estos microservicios de forma automatizada. forma, cumpliendo así con el proceso Complete DevOps (CI y CD).

    Canal de implementación

     A Jenkins pipeline was created to automatically deploy the micro-services to the EKS cluster.

    Tareas ejecutadas por la canalización:

    En resumen, los pasos del pipeline:

    1. Obtener código de microservicio de Bitbucket
    2. Compilar código
    3. Crea una nueva imagen con el paquete generado en la compilación
    4. Enviar imagen a AWS ECR
    5. Crear manifiestos de Kubernetes
    6. Aplicar manifiestos en EKS

    Refinement and definitions and standards to be used on the infrastructure 

    Endurecimiento de la imagen

    Para la institución y como para cualquier empresa, la seguridad es crítica, para ello, se creó una imagen exclusiva de Docker, la cual no tenía vulnerabilidades conocidas ni permitía la elevación de privilegios por parte de las aplicaciones, esta imagen se utiliza como base para microservicios, Para este proceso, el Área de Seguridad de la Institución realizó PenTest concurrente hasta que la imagen no reportó vulnerabilidades conocidas hasta entonces.

    Configuraciones de AWS EKS

    Para poder utilizar los clústeres EKS de manera más productiva, se realizaron configuraciones adicionales en él:

    • Uso de Kyverno: Herramienta que nos permite crear diversas políticas en el clúster para llevar a cabo el cumplimiento de la seguridad y las buenas prácticas en el clúster (https://kyverno.io/)
    • Instalación de Metrics Server: Este componente se instala para poder trabajar con Horizontal Pod Autoscaler en los microservicios posteriormente
    • Radiografía: Se habilita el uso de rayos X en el clúster para tener un mejor seguimiento del uso de microservicios
    • Escalador automático de clúster: Este componente está configurado para tener un escalado elástico y dinámico sobre el clúster.
    • Malla de aplicaciones de AWS: Se lleva a cabo una prueba de concepto del servicio AWS App Mesh, utilizando algunos microservicios específicos para esta prueba.

    Definición de objetos de Kubernetes

    En implementación:

    • Límite de uso de recursos:para evitar desbordamientos en el clúster, la primera regla que debe cumplir un microservicio es la definición del uso de recursos de memoria y CPU tanto para el inicio del Pod como para la definición de su crecimiento máximo. Los microservicios de cliente se clasificaron según su uso (Bajo, Medio, Alto) y cada categoría tiene valores predeterminados para estos parámetros.
    • Uso de la sonda de preparación: Es necesario evitar la pérdida de servicio durante el despliegue de nuevas versiones de microservicios, es por eso que antes de recibir una carga en el clúster necesitan realizar una prueba del microservicio.
    • Uso de Liveness Probe: Cada microservicio a desplegar debe tener configurada una prueba de vida que permita comprobar el comportamiento del microservicio

    Servicios

    Se definió el uso de 2 tipos de servicios de Kubernetes:

    • ClusterIP: Para todos los microservicios que solo utilizan la comunicación con otros microservicios dentro del clúster y no exponen las API a clientes o usuarios externos.
    • NodePort: Para ser utilizados por servicios que exponen API a clientes o usuarios externos, estos servicios se exponen posteriormente a través de un equilibrador de carga de red y API Gateway.

    ConfigMap / Secretos

    Los microservicios deben traer sus configuraciones personalizables en archivos secretos o de configuración de Kubernetes.

    Horizontal Pod Autoscaler (HPA) 

    Cada microservicio que debe implementarse en el clúster de EKS requiere el uso de HPA para definir el número mínimo y máximo de réplicas requeridas.

    Los microservicios del cliente se clasificaron según su uso (Bajo, Medio, Alto) y cada categoría tiene un valor predeterminado de réplicas a utilizar.

    Pruebas de carga y estrés para AWS y la infraestructura local

    Uno de los grandes desafíos de este tipo de arquitectura (Híbrida) donde el backend y el core del negocio son On-Premise y las capas de Frontend y lógica están en nubes dinámicas elásticas, es definir hasta qué punto la arquitectura puede ser elástica sin afectar la Servicios locales y heredados relacionados con la solución.

    Para resolver este desafío, se realizaron pruebas de carga y estrés en el entorno, simulando cargas pico de negocio y cargas normales, este, se realizó un seguimiento en las diferentes capas relacionadas con la solución completa a nivel de AWS (CloudFront, API Gateway, NLB , EKS, Redis, RDS) a nivel local de ESB, heredado, redes y enlaces.

    Como resultado de las diversas pruebas realizadas, fue posible definir los límites de elasticidad mínimos y máximos en AWS, (N° Worker, N° Replicas, N° Instances, Types of Instances, entre otros), a nivel On-Premise (N° Worker, Bandwidth, etc).

     

      Conclusión

      Navigating the labyrinth of hybrid solutions requires more than just technical know-how; it mandates a visionary strategy, a well-defined roadmap, and a commitment to iterative validation.
      Our client’s success story underscores the paramount importance of careful planning complemented by consistent execution. A roadmap, while serving as a guiding light, ensures that the course is clear, milestones are defined, and potential challenges are anticipated. But, as with all plans, it’s only as good as its execution. The client’s commitment to stick to the roadmap, while allowing flexibility for real-time adjustments, was a testament to their strategic acumen.
      However, sticking to the roadmap isn’t just about meeting technical specifications or ensuring the system performs under duress. In today’s dynamic digital era, users’ interactions with applications are continually evolving. With each new feature introduced and every change in user behavior, the equilibrium of a hybrid system is tested. Our client understood that the stability of such a system doesn’t just rely on its technical backbone but also on the real-world dynamic brought in by its users.
      Continuous validation became their mantra. It wasn’t enough to assess the system’s performance in isolation. Instead, they constantly gauged how new features and shifting user patterns influenced the overall health of the hybrid solution. This holistic approach ensured that they didn’t just create a robust technical solution, but a responsive and resilient ecosystem that truly understood and adapted to its users.
      In essence, our client’s journey offers valuable insights: A well-charted roadmap, when paired with continuous validation, can drive hybrid solutions to unprecedented heights, accommodating both the technological and human facets of the digital landscape.

      Validador de identidad de referencia pública de AWS

      By en casos de uso Tag

      SISTEMA VALIDADOR DE IDENTIDAD DE REFERENCIA DEL PROYECTO – Administradora de Fondos de Pensiones

      El La Administradora de Fondos de Pensiones de Colombia hace parte de un reconocido holding colombiano y es una de las mayores administradoras de fondos de pensiones y censos del país con más de 1,6 millones de afiliados. Esta gestora de fondos de pensiones gestiona tres tipos de fondos: seguro de desempleo, pensiones voluntarias y pensiones obligatorias.

      En 2011, la empresa adquirió los activos de los fondos de pensiones en otros países de la región, en 2013 la firma completó un proceso de fusión con un grupo extranjero agregando a su cartera de administración de Fondos de Pensiones y Cesantías, seguros de vida y administración de inversiones.

      La dificultad técnica y la implicación empresarial.

      Actualmente, esta gestora de Fondos de Pensiones tiene un desarrollo constante de aplicaciones para fidelizar a sus clientes y también para estar a la vanguardia del negocio, por ello, actualmente con una gran cantidad de aplicaciones, estas aplicaciones se agrupan de acuerdo a los usuarios que la utilizan, hay dos grupos:

      • Aplicaciones internas o aplicaciones de uso interno de la empresa
      • Las aplicaciones tipo satélite son utilizadas principalmente por afiliados que realizan operaciones de autogestión en los diferentes canales existentes de acuerdo a sus requerimientos y / o necesidades.

      En aplicaciones de tipo satélite, el administrador debe permitir operaciones que por su naturaleza requieran diferentes mecanismos de seguridad como autenticación, identificación y autorización. Sin embargo,

      • Para lograr la autenticación, los afiliados utilizan el mecanismo de nombre de usuario y contraseña.
      • La autorización se realiza a través de un sistema de roles, perfiles y permisos, todos configurados en función del tipo de afiliado y los accesos que requieran para realizar sus respectivas operaciones.
      • La identificación del afiliado es una tarea más compleja, teniendo en cuenta que el objetivo de este mecanismo es conseguir que el usuario sea realmente quien dice ser y que no ha sido suplantado.

      Este último mecanismo de identificación es el núcleo del problema a resolver ya que debe permitir al administrador asegurar que los afiliados realicen los trámites, operaciones y / o uso de los servicios de manera confiable y segura con la calidad que merecen.

      Ahora, la combinación de diferentes factores de seguridad agrega más capas de seguridad al procedimiento de autenticación, brindando robustez a la verificación y dificultando la intrusión y el robo de identidad por parte de terceros. Para ellos, introducimos autenticación fuerte, que es cuando se combina con menos dos factores para garantizar que el usuario que se autentica sea realmente quien dice ser, toda autenticación fuerte es también una autenticación multifactor (MFA), donde el usuario verifica su identidad. Cuantas veces se combinen los factores, incluso si uno de los factores falla o es atacado por un ciberdelincuente, existen más barreras de seguridad antes de que el ciberdelincuente pueda acceder a la información.

      Como consecuencia de ello, surge el "sistema validador de identidad", que es el sistema como servicio que realiza el proceso de identificación de los afiliados en el administrador, el cual es utilizado por los demás sistemas que lo requieran para que puedan decidir si autorizan o no la ejecución de un procedimiento.

      Solución realizada, servicios de AWS, arquitectura 

      Para lograr una correcta identificación del afiliado, la recolección de datos se hace evidente como un primer paso, en función de estos datos se debe tomar la mejor decisión en cuanto a qué mecanismos de identificación se deben aplicar, luego se deben aplicar estos mecanismos, esperar la Afiliarse la respuesta y verificarla, en paralelo todo el proceso consta de su respectivo registro de operaciones y estadísticas.

      La arquitectura general del sistema se compone esencialmente de los siguientes componentes:

      • Satélite: son aquellos que consumen los servicios del sistema validador de identidad ya que necesitan validar la identidad de sus afiliados antes de realizar un trámite.
      • UI: Interfaz gráfica del sistema validador de identidades. Conjunto de componentes y librerías desarrolladas en React JS que pueden ser utilizadas por los Satélites, que contienen la lógica de conexión hacia los servicios del sistema validador de identidad. 
      • APIGateway: Contiene los endPoints que expone el sistema de validación de identidades 

      • Trazabilidad en Splunk: Componentes que se encargan de registrar los mensajes que intercambia sistema validador de identidad (externa e internamente)

      • Exhaustividad: Componente que se encarga de realizar las llamadas necesarias a los servicios del sistema validador de identidad externo que extrae la información necesaria del cliente para tomar la decisión de qué mecanismo se aplicará.

      • Validar Pass: Componente que se encarga de eliminar los mecanismos a aplicar al cliente aquellos que ya han sido validados teniendo en cuenta una serie de criterios configurables.

      • Gerente de Mecanismo: Encargado de ejecutar el mecanismo y realizar la validación a través de la comunicación con servicios de terceros e interpretar y validar sus respuestas.
      • Rule Manager: Encargado de tomar la decisión de los mecanismos que se aplicarán al cliente.

      Flujo de arquitectura

      El sistema validador de identidad es un sistema integrado internamente por varios microservicios que interactúan entre sí. El flujo general del sistema validador de identidad consiste en una solicitud de validación del mecanismo para un cliente que recorre los diferentes microservicios que componen el sistema. La siguiente es la arquitectura del flujo de mensajes del sistema de validación de identidad.

      La imagen muestra, de forma similar a la arquitectura lógica del sistema validador de identidad, la arquitectura interna de los microservicios utilizando colas de AWS SQS como canal de comunicación intermedio, que conforman el sistema y el flujo de datos de una solicitud. que se realiza al mismo. El flujo de imágenes es un flujo funcional, lo que significa que la solicitud no se cancela.

      El flujo se describe a continuación:

      1. El sistema validador de identidad recibe una solicitud de validación de uno de los canales correspondientes y, que están configurados, valida los datos enviados de acuerdo con una estructura definida y un ID de solicitud.
      2. Autentica la solicitud según el satélite que la realiza.
      3. Registre la información en Redis donde seguirá esperando la respuesta para el ID de solicitud (simulación de sincronización)
      4. Determina si es una solicitud no iniciada, valida si la transacción y el canal existen.
      5. Comienza el proceso de cumplimentación de los datos de la solicitud.
      6. Se denominan servicios de completitud externa del sistema validador de identidad para extraer la información requerida del afiliado, que será utilizada en la toma de decisiones del mecanismo de identificación que se deba aplicar.
      7. Los datos de completitud se envían al microservicio RuleProcessor, mediante el esquema de fan-out y utilizando SNS y SQS, que se encargará de orquestar las reglas para determinar la lista de mecanismos a aplicar al cliente.
      8. Están determinadas por los datos que se extrajeron en Completitud, más los datos de la propia Solicitud inicial, y teniendo en cuenta una serie de reglas que se debe cumplir con la lista de mecanismos a aplicar.
      9. Se determinan las validaciones que ha pasado el cliente en un tiempo determinado
      10. Se realizan las consultas necesarias para completar la información requerida
      11. Los datos de completitud y la lista de mecanismos a aplicar se envían al microservicio ExecuteMechanism, que busca en la lista de mecanismos a solicitar el primero que no ha sido validado y llama al servicio externo al sistema validador de identidad que inicia el mecanismo de validación.
      12. Los datos recopilados más la respuesta desde el inicio del primer mecanismo no válido se envían a SendResponse. Esto almacena la solicitud completa en la base de datos para solicitudes posteriores.
      13. Empuje los datos a Redis donde RestRequest está esperando para enviar la solicitud-respuesta
      14. Se inicia una solicitud de validación del mecanismo iniciado. Sigue leyendo de Redis la respuesta.
      15. Se valida que la solicitud de inicio se ha ejecutado correctamente y que la solicitud es válida
      16. Se envía para validar el mecanismo, donde se llama al servicio de validación correspondiente al mismo mecanismo iniciado
      17. Se verifica que la validación ha sido exitosa y el mecanismo está marcado como válido en la lista de mecanismos.
      18. Enviar respuesta de mecanismo no válida

      Arquitectura de bajo nivel 

      Una arquitectura de sistema de validación de identidad de nivel inferior muestra la complejidad del sistema y la cantidad de componentes que intervienen e interactúan con la información de la Solicitud que viaja de un microservicio a otro; donde cada uno va enriqueciendo y modificando su estado.

      ¿Cuáles son los beneficios de esta solución para el cliente?

      Como parte de la solución implementada, el cliente obtuvo mayor seguridad en los procesos de autogestión y operaciones que requirieron verificación de la identidad de la persona que lo requirió. Que en este sentido, el consumo del sistema se implementó en los satélites para tomar la decisión de permitir o no realizar operaciones, lo que trajo una mayor titulización de las operaciones y previene en un alto grado el spoofing. Con esto, ha ganado mayor prestigio y confianza por parte de los afiliados sabiendo que existen formas de verificar su identidad al operar con sus servicios y productos de su día a día.

      Proyecto AWS EKS – PROTECCIÓN S.A.

      Por en casos de uso Tag
      Contenedores

      AFP Protección S.A., una subempresa del holding colombiano Grupo de Inversiones Suramericana, es la segunda administradora de fondos de pensiones e indemnizaciones más grande del país con casi 1,6 millones de afiliados. AFP Protección S.A., una unidad del holding colombiano Grupo de Inversiones Suramericana, es la segunda administradora de fondos de pensiones e indemnizaciones más grande del país con casi 1,6 millones de afiliados.
www.proteccion.com

      Logo Protección Colombia

      PROTECCIÓN comenzó con el proyecto de implementación de aplicaciones con tecnología Docker a principios de 2017, orientado en su momento sobre la infraestructura totalmente OnPremise que 3HTP acompañó desde la administración de todas sus plataformas de middleware.

      En 2018 PROTECCIÓN comenzó con planes de transformación digital orientados a descubrir e implementar estrategias Cloud y por ello emprendió un análisis de los principales proveedores de este servicio en el mercado. Al mismo tiempo, se inició un proceso de llamada para encontrar servicios de administración de contenedores en la nube, de los proveedores más importantes del mercado y fue allí donde 3HTP ofreció a Protection la opción de un análisis del servicio AWS Elastic Container Service Container Management (ECS).

      A través del trabajo cooperativo entre AWS y 3HTP,se propuso al cliente realizar una prueba de concepto para mostrar las funcionalidades y beneficios de utilizar los servicios de gestión de contenedores ecs y a su vez, como una buena estrategia para el cliente, también comenzó a mostrar la compatibilidad, descripción e integración con otros servicios en la nube que permitirían a PROTECCIÓN tener en cuenta en la evaluación para sus proveedores de servicios en la nube. A pesar de que el cliente ya estaba bastante interesado en el servicio entregado por otro proveedor de nube, fue posible demostrar con el arduo trabajo técnico realizado en la implementación de una aplicación como prueba de funcionalidad y alcance, que AWS ECS entregaría una solución de mayor nivel e impacto en sus expectativas de funcionalidad e implementación.

      PROTECCIÓN,finalmente convencida de la solución, otorgó la licitación del servicio a 3HTP-AWS y designó dos aplicaciones relevantes para su operación, para ser migradas de contenedores desplegados en los entornos OnPremise a la nube de AWS.

      Tras la designación del proyecto y a petición de uno de los jefes de equipo, se inició una evaluación con la intención de ampliar el alcance del proyecto en cuanto a tecnología de gestión, administración y portabilidad entre nubes para casos solicitados por PROTECCIÓN y a partir de ahí se propuso la opción de implementar el uso de Kubernetes con el servicio AWS Amazon Elastic Kubernetes Service(EKS).